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 21:28, Alexander Neundorf wrote:
> On Thursday 19 February 2004 20:45, Allan Sandfeld Jensen wrote:
> ...
>
> > 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.
>
> Opening /dev/dsp and feeding the data into it should be fast enough, no ?
>
No network-transparancy? Remember KDE runs on top of X, and we would like the 
sound to come out the same place as the video. Anything less would be 
unacceptable since it would be equivalent to only support Qt/embedded.

> > 2. Play Music
> > The most important issue is to ensure good quality with absolutly no
> > stutter, which can mean more buffering than above.
>
> Where is the problem for /dev/dsp ?
>
Kernels <2.6 does not have preemption, and might need to have the buffers 
tuned, or the audio-feeding process set to realtime-scheduling. On slower or 
loaded machines with 2.6, this might still be the case.

> > 3. Play Movie-soundtrack
> > The most important issue is to keep in sync with the video stream at all
> > costs.
>
> I really doubt that we can do this. The video app has to care for this,
> really.
>
It is no problem for aRts or MAS, as they already do so.

If we provide feedback for the video-application about our internal delay, we 
could let the video-app do it. If we dont, the video-applications has no 
chance in hell to do so.

`Allan