Phonon Sample Cache

[Harald Sitter]

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.

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

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

> 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")?

> 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?
What if the application wants to be able to have specific themes only
within the scope of the application (downloaded via KHNS or
something)?
What if the sounds are to be overloaded by another dir in `kde4-config
--path data`?

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

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

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