Some ideas for the aRts-replacement (was: aRts needs to be replaced (was Re: Disabling aRts in knotify))

[Allan Sandfeld Jensen]

On Thursday 19 February 2004 18:42, Arnold Krille wrote:
> On Thursday 19 February 2004 18:16, Guillaume Laurent wrote:
> > This is a variant of the user space vs. kernel space debate. If you want
> > to do mp3 decoding/reverb/chorus/128 band equalization in a sound server
> > it means the beast has to reimplement some sort of multitasking, and it
> > means that one misprogrammed app can bring the server down. This kind of
> > features belongs in a media player, not in something which will go "ping"
> > every once in a while.
>
> This one brings me to an idea: What about some different kind of
> implementations:
>
> - A simple sound-interface apps can use for notifications/simple_playback
> like "Soundserver play this file" and some checking wether it succeded or
> not... - Some kind of "Sound System" which is the layer between apps
> wanting sounds played back or data streamed to whatever sound-server or
> hardware the user is using. This one should check/know wether the
> sound-server is able to decode and if not decode inprogress. Perhaps some
> kind of mixing can also be done for raw-streams.
> - A lib for synthesis (libkdesynth?) which is not just synthesizers but
> also effects/mixers/decoders/etc. This lib could be used by every app, that
> wants to. and the "Sound System" can use it for decoding if the soundserver
> doesn't implement it...
>
Hmm. I see three distinct tasks with three different quality goals for a 
soundserver:
1. Play Event Sound
The most important issue is to start playing the event-sound as quickly as 
possible, to give the user better feedback.
2. Play Music
The most important issue is to ensure good quality with absolutly no stutter, 
which can mean more buffering than above.
3. Play Movie-soundtrack 
The most important issue is to keep in sync with the video stream at all 
costs.

`Allan