Phonon Sample Cache

[Trever Fischer]

On Saturday, August 27, 2011 05:12:05 AM Harald Sitter wrote:
> 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.
Then it wouldn't be public API, merely an implementation detail. Discussion on 
that is still useful.

My idea behind the SamplePlayer was to use QActions on it so you can do as you 
previously described. Renaming it to merely "Sample" makes sense, as it hides 
the fact that it is actually a player at all.
> 
> 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

QPointF(1, 1) means the lower right of the screen.
QPointF(-1, -1) means the upper right of the screen.

Those values are calculated by the API user. Any out of range values get 
clipped.

The design's inspiration: 
http://0pointer.de/lennart/projects/libcanberra/gtkdoc/libcanberra-
canberra.html#CA-PROP-EVENT-MOUSE-HPOS:CAPS

QPointF(0, 0) is used as the center because if it were a 3-dimensional space, 
0,0,0 can be considered a local coordinate with respect to the viewport.

> 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

That is a lot of parameters. And what does it mean when left = 1.0 and right = 
1.0? Does that mean the sound is in the center? Or on both sides? What if 
they're all zero? Very confusing.

> 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.
We only care about where on the screen the sound comes from. For now, this is 
just a 2D api. If we need support for 3D positioning, we can use a QVector3D. 
I don't know how one would do that in the backends, since I don't believe they 
actually support anything like that. I know for a fact that libcanberra does 
not.
> 
> (*) 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.
Hence, this thread.
> 
> regards,
> Harald
> _______________________________________________
> kde-multimedia mailing list
> kde-multimedia at kde.org
> https://mail.kde.org/mailman/listinfo/kde-multimedia