Phonon Sample Cache

[Colin Guthrie]

'Twas brillig, and Harald Sitter at 27/08/11 14:31 did gyre and gimble:
> On Sat, Aug 27, 2011 at 2:40 PM, Colin Guthrie <gmane at colin.guthr.ie> wrote:
>> 'Twas brillig, and Harald Sitter at 27/08/11 09:27 did gyre and gimble:
>>> On Fri, Aug 26, 2011 at 6:37 PM, Trever Fischer
>>> <tdfischer at fedoraproject.org> wrote:
>>>> Personally, I think theming game sounds is silly and would hardly ever be
>>>> used; I'm looking for input from those who disagree with me because I
>>>> don't think I'd be able to make a solution that satisfies that audience.
>>>
>>> No reason to not allow them though :P
>>> BUT Qt is not FDO aware(*), Phonon is not FDO aware, nothing we depend
>>> on is FDO aware, so simply finding the right folder for sound lookups
>>> would probably be rather a lot of code ... in Phonon.
>>
>> The suggestion I had here was to implement an incredibly dumb and
>> lightweight version of the lookup code.
>>
>> Any games or apps that have their own custom sound-events (i.e. not
>> standard sound names) will install these files into
>> /usr/share/sounds/freedesktop/stereo/ as e.g. kgoldrunner-wibble-foo.ogm
>> (or just symlink them).
>>
>> If we use libcanberra, and trigger the sound "kgoldrunner-wibble-foo"
>> then this file will always be used, regardless of the current sound
>> theme the user has chosen[1] (this is because "freedesktop" is the
>> fallback theme name (much like "hicolor" is to icons)).
>>
>> So this Just Works™
> 
> That sounds just perfect.

Just for clarity, I said "always" be used above... this is incorrect.
see comment below with regards to an oxygen sound theme.

>> Now if libcanberra is not present, all we need to do is look in the
>> folder /usr/share/sounds/freedesktop/stereo/ for the sound file (likely
>> supporting ogm or wav files only).
> 
> What if XDG_DATA_DIRS is not /usr?

Right. We cand do some XDG friendly lookup instead. But the general
principle is mostly the same I think.

libcanberra honours the path $XDG_DATA_DIRS/sounds (for each path).


>> Sure there would be no theme support but the sounds would work as the
>> author intended, so it covers the non-canberra case sufficiently IMO.
> 
> What if Oxygen starts doing custom sounds in /usr/share/sounds/oxygen/?

Yeah, my "always be used" above was not correct. I was thinking in the
sense that "if nothing customises it, it'll always be used". I was
really just trying to emphasise the fallback nature of this special
theme name "freedesktop". If oxygen creates a sound theme and it's used,
then libcanberra will use the sounds from this theme rather than
freedesktop. So the themeing works in this case. Sorry for the confusion.

>> On non-linux sustems the folder "/usr/share/sounds/freedesktop/stereo/"
>> could be replaced with "$APP_FOLDER\sounds\" or similar.
> 
> What if the application uses freedesktop sound theme provided sounds
> (e.g. "message")?

It's the same rules as if it provided a icon that conflicts with one of
the standard names. i.e. it shouldn't do that! All that's needed is the
application provides sounds in a kind of namespaced way e.g.
"game-kgoldrunner-message" or similar.

In theory they should also be able to rely on the "standard" sounds:

game-over-winner
game-over-loser
game-card-shuffle
game-human-move
game-computer-move

(see http://0pointer.de/public/sound-naming-spec.html)

Although I believe these are NOT part of the official freedesktop sound
theme so it would be up to distros to make sure that these sounds are
supplemented by a generic package that all games could share. This is
more a packaging and documentation issue however.

>> Thus authors of apps could just install all files into a sounds folder
>> (on linux this would be /usr/share/data/$APP/sounds/) and then a
>> standard CMAKE install rule could symlink them into
>> "/usr/share/sounds/freedesktop/stereo/" automatically.
> 
> What if the application has funny names that clash with other files?

It should change it's names.

> What if the application wants to be able to have specific themes only
> within the scope of the application (downloaded via KHNS or
> something)?

Then it should implement things itself and use the murl param to
manually specify the sound file and not rely on us.

> What if the sounds are to be overloaded by another dir in `kde4-config
> --path data`?

What is the use case to support this? I'd say that's out of scope...
Although I'd hope that just setting XDG_DATA_DIRS would be sufficient to
cover whatever is needed here.

>> Thus very little effort is needed by app developers and our fallback
>> code is pretty damn simple, we don't reinvent the wheel and everyone is
>> happy.
>>
>>> I think that FDO compliant theme support should not be implemented in
>>> Phonon but in a KDELibs wrapper ontop of a Phonon sample cache
>>> implementation. So that the wrapper (which as part of KDE is FDO aware
>>> and has all capabilities necessary to implement sound theme support
>>> sensibly) actually resolves the full path of the sound to use and then
>>> passes it to our FDO unaware Phonon class.
>>
>> I really don't think this is wise. libcanberra does this already. I
>> certainly have very little motivation to reimplement things when they
>> are already there.
> 
> That applies to just about any implementation of the FDO spec and yet
> they are duplicated in kdelibs despite having somewhat glibish
> implementations elsewhere (that is a topic out of phonon's scope
> anyway IMHO).

libcanberra was specifically designed to *not* have any glibish deps.
The core of it is 100% glib free. It was done this way very deliberately
to make it more portable. I really don't get the logic of reimplementing
everything. It just multiplies the places where bugs could be introduced
and makes upstream more annoyed and less willing to collaborate. As
people come to #pulseaudio to debug everything sound related, I have to
know all the different implementations etc. which is really sucky if
there are multiple different ones with various quirks here and there...
it's bad enough Ubuntu broke the spec by patching libcanberra. The NIH
attitude really sucks :(

Even if libcanberra needs patching to use it as a lookup only system or
similar (not a player) it would very much help to cut down on problems.
The lookup code is non-trivial and andy reimplementation will take
several weeks and likely several cycles to be free of bugs (canberra
itself is on it's 28th release).

>>> That is not to say that simple theme support could not be provided
>>> from within Phonon for Qt only API consumers. However for that I
>>> question the use as well.
>>>
>>> Scenario:
>>> - Qt only API consumer
>>> - Only targeting windows and mac
>>> - Does not care about some random FDO specs
>>> - Wants to have a boring and a pirate theme for his application (theme
>>> = graphics and sounds)
>>> - Consumer implements simple theme engine which searches in ./themes
>>> (relative from executable) for folders, each folder is assumed to be a
>>> theme, within each folder is /graphics/ and /sounds/ -> consumer can
>>> resolve full path to audio samples without any help from Phonon
>>>
>>> To summarize. IMHO name resolving against a theme is a high-level
>>> action that Phonon should allow but not implement.
>>
>> Well it's up to you but I'm not sure I'd want to expend quite that much
>> energy supporting the relatively rare case outlined above.
> 
> Looking at how graphics theming is done rather excessively, I do not
> think this is a use case that can be ignored. Plus if you have a
> pirate theme for a game then you definitely want an audio theme too,
> to get the best overall experience.

To be honest, I think if some game implements an internal themeing
system to change graphics, it means that the sound theme would want to
change outside of the "sound theme" the whole desktop is using.

In this case, the app should likely have a default set of sounds that go
into the freedesktop space, and when the user has the default theme
enabled in the game, it honours whatever sound theme the user has chosen
for his whole desktop (even if that is not the freedesktop theme).

If the user chooses the pirate theme in the game this should override
whatever desktop sound theme the user has. This can be set easily in
canberra by attaching a property to the canberra context specifying the
theme. So I suggest we expose this somewhere in the API, and just have
the default theme be the users desktop theme (which ultimately always
falls back to "freedesktop") if it's not overridden.

The graphics would be handled separately in whatever way the user wants.
It might be nice to define a standard way of doing this desktop wide
(e.g. a Graphic Naming Spec) but I don't think the use case is nearly as
strong as sound themeing.


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

_______________________________________________
kde-multimedia mailing list
kde-multimedia at kde.org
https://mail.kde.org/mailman/listinfo/kde-multimedia