Phonon Sample Cache

[Colin Guthrie]

'Twas brillig, and Harald Sitter at 27/08/11 10:12 did gyre and gimble:
> On Fri, Aug 26, 2011 at 6:37 PM, Trever Fischer
>> A quick discussion with Colin suggests to me that some further design
>> refinement is needed. To illustrate, everything should be handled with
>> libcanberra on Linux because reinventing the wheel sucks. That raises one
>> minor problem: using libcanberra on linux, we'd only need the correct
>> sample name, such as "new-message-im". For other desktops, we would need
>> the path to the sound or at least a place to look for the sound.
>>
>> One more note: This is in no way intended to replace KNotify or to create
>> a cross-desktop notification system. The primary intent is for something
>> such as the meego dialer to quickly play a DTMF tone the instant the
>> keypad button is pressed, or KGoldRunner to not be laggy and cut off the
>> sounds. libcanberra supports game sounds to be themed, so playing nice
>> with that is the reason for sound theme support.
> 
> One thing that puzzled me the the other day when thinking about sample caches.
> How exactly would this work with libcanberra on Linux?
> I mean, what is used on Windows and OSX seeing that libcanberra only
> does GStreamer and thelennart only cares about Linux, and only that?
> And where/how is one single API provided to KDE apps so that they do
> not have to mind crossplatformness?

libcanberra does pulse, alsa, gstreamer and OSS. The plan would be to
use pulse by default on most linux systems and write an additional
phonon backend for canberra for those users who do not want to use pulse
(which is an reducing minority but an annoying vocal one, so needs to be
supported). If written, this phonon backend would be committed upstream.

That said, the only drawback to using alsa rather than phonon backend in
canberra would be the device preferences as shown by systemsettings. I
don't really care that much about linux systems which don't use PA, so
the fact that when PA is not used these settings only affect a very
small subset of applications is something that makes them IMO of limited
usefulness anyway and thus I'm not super bothered that game sound events
do not go through these preferences in this case... (harsh I know!). But
this would of course be solved with a phonon backend in canberra :)

On other platforms, or where libcanberra is not available at build time,
the logic would fall back to what we discussed in Randa and what my
previous replies have said regarding non-linux minimal sound theme
lookups - i.e. no real themeing, but still actually working).

> IMHO there is still quite some additional thinking necessary to make
> libcanberra fit the picture.

Perhaps, but also the API should be the same regardless of the
underlying stuff. I think it's all too easy to get caught up thinking
about being wonderfully cross platform and super nice and cool, but
never actually get anything actually done. The code here would be
relatively lightweight wrapper around libcanberra on linux systems and
thus could be up and running quickly and thus used quickly. More
complete x-platform code could be added later as demand increases. I
mean what are the numbers here anyway? I'm quite dismissive as I don't
really believe that OSX and Windows is a massive target audience but
that's just my prejudice. What are the figures? Is linux like 95% or....?

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/]