Disabling aRts in knotify

Gioele Barabucci ml at gioelebarabucci.com
Wed Feb 18 21:01:14 GMT 2004


On Wednesday 18 February 2004 20:25, Alexander Neundorf wrote:
> I mean almost everything in KDE is plugin-based, I think it must be
> possible to make the kde sound backend plugin-based too. One plugin for
> arts, one for OSS, one for ALSA, one for gstreamer, one for MAS, ....
> Basically these plugins would simply forward sampled raw audio data to the
> backend. Almost no cpu usage, much few chances to crash, etc.
"plugin", means "plug this functionality into this app", so where will the 
ALSA plugin plug? I can say in a standard audio-packed dispatcher (btw, media 
is only audio for you?) that takes packets from various apps and mixes them 
(do you want only one playing app at a time?) before sending them to the raw 
device finally.
What if I play an AC3 file? my soundcard can send it directly to my Hi-Fi, so 
the "pluggable audio dispatcher" should be able to recognize them and avoid 
decoding... or should the app do this?
At the same time we don't want to rewrite Ogg and MP3 decoders in every app 
that need to play them so we write other plugins to plug in the same 
"dispatcher" (and solve also the AC3 problem).

Maybe it's me, but this "dispatcher" reminds me of aRts...

Yes, I like aRts and I think that KDE should keep it... or something like it.

OK, KDE did an experiment with aRts, we learned something, and we can now 
conclude that the current implementation lacks too many features (mostly a 
maintainer :). Can't KDE4 fix this?

I don't see how other solutions will not fall back being just another aRts...


Another thing is plugging directly into the apps that want to play 
video/audio, but then simple toy apps that want to play a nice 
"background.midi" will have to deal with a complex infrastructure...

--
Gioele




More information about the kde-core-devel mailing list