Phonon Sample Cache

[Harald Sitter]

On Sat, Aug 27, 2011 at 2:56 PM, Colin Guthrie <gmane at colin.guthr.ie> wrote:
> '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.

So one would use Phonon to use libcanberra to use Phonon?

> 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 :)

One can not set the output device for libcanberra (consequently ALSA)?
That sounds a bit rubbish TBH.
Supposedly we can all agree that non-PA *nix setups are mostly
negligible, but if an application uses Phonon then it must be able to
expect a certain amount of integration. Particularly WRT the default
device used, so being able to set the default device on libcanberra
seems like must-have feature.

> 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....?

The people who make K* on Windows and OSX. Even if we do not care much
for those platforms, we should make it a priority to not reduce their
product's quality or make their life more difficult by not taking
cross platformness into consideration as early as possible. Let alone
the Qt applications using Phonon particularly for the cross platform
availability.

regards,
H