Disabling aRts in knotify

Alexander Neundorf neundorf at kde.org
Thu Feb 19 20:20:08 GMT 2004

... responding on kde-multimedia

On Thursday 19 February 2004 20:56, Gioele Barabucci wrote:
> a lib? so instead of ::play("hello.ogg"), you want ktuberling to deal with
> threads, ov_open(), ov_comment(), ov_info(), ov_read(), ov_clear(),
> ov_close(), downsample and error recovery on four different UNIXes? No,
> please no.
> Or you want to put the decoding in the media-layer (ok, let's not call it
> dispatcher)... but then I want threads (no gui blocking API please) and
> plugins. 

Yes. Good old xmms does it this way. 
A singleton class with the required functions. If you say "play", it asks the 
backend whether it can play a stream right now (e.g. if a /dev/dsp is 
available). If this is not the case, return an error. If the backend is e.g. 
arts, it should always succeed.
Inside the thread start reading and decoding the file and feed it into the 
"backend", which can simply put it into /dev/dsp (or feed it to arts).

In the case that it doesn't succeed, no problem. It's no big deal if one 
desktop notification sound is lost. If already music is being played, no 
problem if you can't play a second song at the same time.

And for people who consider this a problem, they can install a sound daemon.

> Yet another sound server.

Where ?

> Can you put a page with one or two diagrams of the audio layer you are
> proposing? just show how should apps interact with him the the most common
> cases; I can not see how such an infrastructure could be more effective
> than a well written sound server.

Ok, but we don't have one. We have a all-in-one solution, which is overkill 
and has several issues.

Keep it simple, stupid.

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

More information about the kde-multimedia mailing list