Phonon Sample Cache

[Harald Sitter]

On Fri, Aug 26, 2011 at 6:37 PM, Trever Fischer
<tdfischer at fedoraproject.org> wrote:
> I've come up with a preliminary UML diagram to illustrate what I think
> might work: http://i.imgur.com/4VIEr.png

One random thought: how about creating something like QAction for
samples to increase usage convenience?
IMHO one should not need to use the player or the cache directly -
ever. It would be much nicer (IMHO anyway) if I could have
> Phonon::Sample *m_fooSample, m_barSample;
and then play them like
> m_fooSample->play();
Or create a SampleCollection and do stuff like
> m_sampleCollection["foo"]->play();
Signal/slotting of course would also be garoovy then. Like you create
a sample object and all you need to do to trigger it is
> connect(m_fooButton, SIGNAL(clicked()), m_fooSample, SLOT(play()));

Rationale is that the API consumer essentially only works with
samples, but the uml actually describes a player, which seems somewhat
confusing. The detail that underneath the sample is a player and a
cache should not be particularly important to the API consumer.

There is one thing though: a sample class would have to allow setting
the cache and player to use. For example one could implement a
SampleCollection that makes addressing different players and caches
easy, so those would set their player and cache on the samples that
get added to the collection. Honestly though, I fail to find an actual
use case for this (might just turn out to be useless API).

Also about Player::play(QPointF(0,0)) --- if this is to set audio
balance between left and right channel, then this will be tricky...
you do not know how big the overall action space (*) is (i.e. you do
not know whether the widget is 3x3 or 360x240 or whatever), so the
pointf alone is not very useful. Action space detection also is no
option, say you have 3 tiles of 3x3, then the actual action space
might still be 9x3 whereas a center click on a tile will be pos 1.5.
If the action came from the right most tile that would actually result
in a completely wrong sound balance :S
I guess what I am trying to say is that the API that way is not very
obvious. A dedicated function playBalanced(float left, float right,
float front, float back, ...) might be better as it leaves the balance
calculation to the consumer (we could still provide a class to help
with linear interpolation though). The advantage is that the consumer
knows that the 3x3 tile is just one of 3 and can thus calculate that a
click at 1.5,1.5 on the third tile is really at 7.5,1.5 of the action
space. Another case would be that the action space is curved (imagine
a game with a planet in space and clicking somewhere on the planet
would play a sample). Now we really should not calculate this anymore,
because you really do not want linear sound balance mapping onto a 3
dimensional action space.

(*) the space within our sample is positioned (e.g. a 2D playing
field, inside a 3D cube, or perhaps even a sphere).

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

IMHO there is still quite some additional thinking necessary to make
libcanberra fit the picture.

regards,
Harald