Some ideas for the aRts-replacement (was: aRts needs to be replaced (was Re: Disabling aRts in knotify))
Allan Sandfeld Jensen
kde at carewolf.com
Fri Feb 20 10:24:27 GMT 2004
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,
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.
More information about the kde-multimedia