knotify and libcanberra Re: KDE Sound and Multimedia Plan

[Colin Guthrie]

'Twas brillig, and Alex Fiestas at 02/12/10 11:19 did gyre and gimble:
> On 12/01/2010 07:22 PM, Ian Monroe wrote:
>> No, this sounds like a more useful thread. :)
>>
>> Reusing existing technology rather then build our own ->  sounds good
>> to me. Having a phonon backend for libcanberra would solve the "what
>> about Windows" problem of having kdebase-runtime depend on
>> libcanberra.
>>
> To do that, we should be able to set something like: "For Notifications, 
> use libcanberra", "For Music use vlc"... right?

I was thinking more that you could just say "use knotify" for
notifications. And knotify itself uses (only?) libcanberra.

If the system is using PA, then libcanberra can talk directly to PA,
(routing of audio streams i.e. device priority lists configured in
kcm_phonon would still be honoured via this scenario as with all audio
output (e.g. alsa) when PA is underneath these days). When this scenario
is used, then sample caches etc. will be used and thus you get the best
possible response times.

If the system is not running on top of PA, then libcanberra could use a
it's own phonon output layer to output the audio. This path will be
slower and will not have sample caching (unless someone writes this into
the libcanberra phonon layer as Martin suggested doing at the app level
in another branch of this thread - although an important distinction
would be that unless you delve into SHM usage, this cache will be
per-application rather than user-wide), but will provide support when
used under windows or OSX (I've not looked at libcanberra support on
windows or OSX but as it was specifically written to avoid any major
external libraries/deps etc. it should be trivial enough).


The one downside is that knotify+libcanberra would perhaps not support
the full range of media as phonon, but I suspect that's the case just
now anyway (libcanberra, or rather the sound theme spec, supports wav
and ogg but not sure about mp3 etc.). Like I say I doubt very much that
this is a problem. Almost all sounds that knotify should play would be
wav or ogg anyway.

I guess you could sum this up as follows:

System With PA: In KNotify, replace Phonon layer with Libcanberra layer
System Sans PA: In KNotify, inject a Libcanberra layer before Phonon.


So with PA the system technically looses a layer (phonon is really two
layers - phonon API itself and the backend it uses) - arguably this is A
Good Thing(tm)

But obviously sans PA, you do add a libcanberra layer in knotify. You
could almost certainly simplify knotify code in this scenario however to
remove the direct alsa support.


Or another option is just to keep phonon in knotify and implement the
sample caching stuff there to improve performance. I don't think it will
ever be as quick/responsive as the sample cache in PA however as no
matter what you do to cache things, it'll still have to go through the
backend first.

Some food for thought, hopefully and I'm sure you all know which option
I'd generally be most in favour of :D

Col

-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mageia Contributor [http://www.mageia.org/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]