On Thursday 19 February 2004 19:44, Maksim Orlovich wrote:
> On Thu, 19 Feb 2004, Alexander Neundorf wrote:
> > 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 ?
>
> Well, but it's not as simple as you make it. Please consider the case of
> synchronizing video w/audio when audio must be played by a sound-server
> due to a soundcard w/o multiple inputs. In this case, either decoded video
> must be pumped to the server, or one has to be very careful about doing
> clock synchronization accross two different apps. Anyway, the bottom line:
> please, no blanket statements like this, until you have a solution to
> every single difficulty that arises.

Keeping audio and video in sync is a major issue, and even the mplayer and 
xine folks (who focus only on this topic) have to work very hard to get this 
as good as possible, and still they are not perfect. I really think trying to 
do this in a general purpose sound daemon won't have success. For this 
purpose the video playing software needs to have as few layers to the audio 
hardware as possible. A sound server, streaming audio data via IPC won't work 
there.

Let's optimize for the common, i.e. playing music and short sound 
notifications. Everything else is special purpose. For these special purposes 
let's try to provide a low level access so that apps which need it can use it 
as directly as possible.

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