Phonon Sample Cache

Colin Guthrie gmane at colin.guthr.ie
Sat Aug 27 13:28:46 BST 2011


'Twas brillig, and Ian Wadham at 27/08/11 00:54 did gyre and gimble:
> On 27/08/2011, at 2:37 AM, Trever Fischer wrote:
>> As we discussed forever ago back in lovely Randa, Switzerland, Phonon was
>> going to get a sample cache for rapid playback of tiny sound files. This
>> is needed because phonon really isn't designed to do that.
>>
>> I've come up with a preliminary UML diagram to illustrate what I think
>> might work: http://i.imgur.com/4VIEr.png
>>
>> The delay between calling play() and the speakers making some noise must
>> be as low as possible. Eventually, the latency should be low enough that
>> even games can rely on low-latency audio to Just Work.
>>
>> 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.
> 
> Errrmmm, whilst I applaud this initiative, it may be a case of too little too
> late.  As KGoldrunner author, I spent months earlier this year trying to get
> Phonon to play sounds nicely after I had been forced to disable them
> completely a month or so before the KDE 4.6 release.  Not the least of
> the problems was battling with the effects of the move to "git" on the KDE
> build system as I struggled to install the "latest and greatest" Phonon and
> produce massive Phonon debugging logs, as requested by Harald Sitter.
> 
> I sent several emails to this list, some of which got stuck in moderation, but
> AFAICT nobody paid attention, except for recommending more upgrades.
> 
> Finally I balked at upgrading my entire desktop to KDE 4.6, which would
> risk disrupting other uses of my laptop that are not to do with KDE devel.

FWIW, even although this is a "libphonon" API, it should be worth noting
that if it uses libcanbarra (which is very much the plan) then the sound
will be going almost directly to PulseAudio on 99% of installs (I'm
being flippant here with the 99% but it's heading that way). It also
makes use of the sample cache in PA and thus allows the most reactive
experience possible.

Some other nice features could also be enabled, such as positional event
sounds. libcanberra can use information about the mouse position on
screen to e.g. automatically push more sound out of the left speaker
when he event is triggered on the left side of the screen. So there are
some nice features there for free too.

The only time phonon would be used as a libraray to output the sounds
(and I don't think any of us disagree that it is inappropriate for games
generally) is when libcanberra is not available, but basically means on
Windows and OSX platforms. I appreciate this would not be ideal, but
it's certainly not our primary target audience either.


> Instead, I decided to cut my losses and switch from Phonon to TagaroAudio.
> This is a small library which I expect will become part of libkdegames soon.
> It is based on the OpenAL sound library.  At present, the KGoldrunner and
> Granatier games are using TagaroAudio (statically) and OpenAL.
> 
> See http://websvn.kde.org/trunk/KDE/kdegames/kgoldrunner/src/TagaroAudio/
> 
> It took only a day or so to get game sounds working this way, as opposed
> to months of struggling with Phonon and its ramifications.  And they came
> crisp, clear and in time with the game action.  Maybe you heard my sigh of
> relief as far away as Germany ... :-)

Hehe, this is nice, but like I say, it wouldn't strictly speaking be
"phonon" you'd be using anyway.

OpenAL is a nice system and I don't disagree with using it, but I
personally think it's more appropriate for "heavy" games as opposed to
desktop games which IMO should be using something a bit more lightweight
(and also be playing nice with underlying audio systems for
power-conservation purposes - this may not be an issue - especially if
there are lots of reactive sounds in a game, but if they are infrequent,
then it could matter).

> Furthermore, I was able to hear sounds that had never played properly
> before and "tune" the sound-class code for relative volume and precise
> overlapping --- things I was never able to begin to do with Phonon.  Who
> knows, I may even play the KGoldrunner sounds in stereo one day ... :-)

Playing samples from the cache should be very quick with this proposed
API so I wouldn't envisage any major problems where.

>> A possible solution to this is to make the MRL arguments optional and
>> implement our own naive theme search algorithm that uses a supplied
>> directory to find samples.
>>
>> 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.
> 
> KGoldrunner sounds are already themed and have been for more than
> three years.  It is no sweat.  The sounds just go in the same directory
> structure as the graphics themes.  It is true, however, that while there are
> six graphics themes, there is only one sound theme.  I think that is just
> because sound composers are even harder to find than graphics artists.

This is great, but I'd be interested in making things work in a standard
way rather than an ad-hoc, per-application basis. I appreciate this may
mean some changes to where you install the sounds, but I don't think
it's a massive upheaval and I think the sound-theme specification is
something that can benefit everyone on the systems generally. That said,
I fully appreciate if you are reticent to this kind of change.


> Mind you, I could always ask my son to write another sound theme ... :-)


:)


Cheers

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



More information about the kde-multimedia mailing list