On Thursday 19 February 2004 17:56, Guillaume Laurent wrote:
> On Thursday 19 February 2004 17:34, Stefan Gehn wrote:
> > And not every mediaplayer should have to code its own mp3 decoder,
> > equalizer and whatnot.
>
> There are libs for that.
>
> > Then it could as well go and pump data directly into
> > /dev/dsp because there's not much work left anymore and thus no
> > soundserver is needed.
>
> The only reason a sound server is needed is for braindead sound cards which
> do not allow multiple openings of /dev/dsp, I don't see any other valid
> one.
>
> > > > You don't want to set
> > > > different volumes for different apps?
> > >
> > > That's each app job, not the soundserver's.
> >
> > I don't think so.
>
> You really want a sound server to store and remember something as volatile
> as app names and volume settings ?
>
> > But that's the reason why there's arts. Don't reinvent the wheel all the
> > time. Just because some app wants to adjust its sound volume it would
> > need its own code to do so.
>
> Again, there are libs for that. Such code does not belong in a sound
> server. Keep it lean, invisible, and, most of all, *reliable*. The less
> code there's in it, the better.

I agree 100%

For almost all needs there is no sound server required. Decoding and adjusting 
volumes can be done *perfectly* with libs. Why should the api become harder 
if it is a in-process-lib compared to an out-of-process daemon ?
I need a daemon if I want to have sound on remote X. Then a daemon is required 
to get the sound over the network to my local soundcard, but a reliable one. 
A daemon which does *everything* is not reliable.
In this case I'd like to be able to say: "media framework lib, please use the 
mas/arts/... plugin instead the oss plugin to get the audio data to the host 
I am sitting at".

Bye
Alex
-- 
Work: alexander.neundorf@jenoptik.com - http://www.jenoptik-los.de
Home: neundorf@kde.org                - http://www.kde.org
      alex@neundorf.net               - http://www.neundorf.net