What happened to "someBuffer"? (was Phonon Sample Cache)

[Ian Wadham]

On 28/08/2011, at 12:48 PM, Trever Fischer wrote:
> Back on topic here, I'm not entirely sure if we should do any kind of theming 
> at all. I've been thinking a bit about the problem today, and it might just be 
> in everyone's best interest for the sample cache to simply play files and not 
> handle any theming or anything. Using libcanberra to handle this in libphonon 
> (instead of the backends themselves) would simply be a convienence for us 
> since all the low latency bits are already handled.

In the Qt 4.7 doco for Phonon::MediaSource, the Detailed Description suggests
that you can present Phonon with a QBuffer (descended from QByteArray) and
say, "Here, play this."  I cannot find the current KDE Phonon doco, but AFAICR
it has always said the same thing, since several years ago.  The problem for
me has always been, "How do you get a sound sample into the buffer?".  See:

   MediaObject m;
   QString fileName("/home/foo/bar.ogg");
   QUrl url("http://www.example.com/stream.mp3");
   QBuffer *someBuffer;
   m.setCurrentSource(fileName);
   m.setCurrentSource(url);
   m.setCurrentSource(someBuffer);
   m.setCurrentSource(Phonon::Cd);

If one could easily set up an in-memory MediaSource, wouldn't that solve the
problem, without bringing in extra libraries, dependencies, build problems, etc?

A game could pre-load its sounds into buffers and present them to Phonon as
and when required.  Phonon could then play them without latency (???).  Better
still, as I expected (hoped?) would happen when I first read about Phonon about
four years ago, one could just pass (category = Phonon::GameCategory) to
Phonon::createPlayer and then Phonon would take care of the buffers.  Sadly
there appears to be no code support for Phonon::Category at present.

The above is essentially what is happening now with OpenAL in KGoldrunner.
The TagaroAudio library mainly just loads up buffers from files, using libSndFile,
and manages buffers and OpenAL playback instances, without cacheing.

There is a comment in TagaroAudio somewhere about using *Phonon* to load the
sound files (rather than libSndFile), but I do not know how that could be done.  I do
not like using libSndFile because there are several versions in circulation on
various platforms and not all of them support *.ogg, so I had to play safe and
revert all my sound files to *.bmp ... :-(

> If a pure Qt application needs to use the sound theme, they can use 
> libcanberra directly. If a KDE application needs to use the sound theme, they 
> can use kdelibs to find the right file and pass it to phonon, which would allow 
> it to work on all platforms.

I do not like the sound (heh) of libcanberra.  Canberra is our nation's capital,
an artificial city, designed by an American and populated mainly with politicians
and bureaucrats ... :-)

Cheers, Ian W.

> The way I see it, a kdelibs application will already have the 
> /usr/share/sounds/ filesystem and such in place on non-linux platforms. They'll 
> have the sound theme "in place" so to speak.
> 
> A boring, proprietary Qt application (and some FOSS ones) won't have any 
> concept of the XDG specs simply because they want to work on all platforms. 
> For those applications, they'll be in control of the files that get installed 
> into which location. For those applications, it would be in their best 
> interest to either use kdelibs to get a properly implemented theme resolution 
> algorithm or to figure out how to write their own if it really matters to them.
> 
> A simple C library that resolves themes that everyone can share probably isn't 
> that bad an idea.