[Kde-games-devel] To ogg or not to ogg?

[Ian Wadham]

On Thu, 2 Jul 2009 7:55:16 am Aaron J. Seigo wrote:
> On Wednesday 01 July 2009, Casper van Donderen wrote:
> > If using OGG adds latency we should file a bug against Phonon since both
> > the unreal and I'd engines now use OGG sounds and I think we can use
> > those as benchmark.
>
> they probably load and decode the files once and replay them as many times
> as necessary; there is no such "store and replay" support in Phonon afaik,
>
IWICT (I wish I could tell) ... :-)

The Phonon doco is so deliciously skimpy.  For example, if you create a
Phonon::MediaObject and assign a Phonon::MediaSource to it (e.g. a
file) and play() it and then (sometime later) play() it again ... does Phonon
go through the whole buffering thing again?  Or can it somehow "remember"
what was played before (if not too large)?  Then there is the tantalising ...

http://api.kde.org/kdesupport-api/kdesupport-apidocs/phonon/html/classPhonon_1_1MediaSource.html#_details

which suggests that you can assign a QBuffer * as a source, but how do
you get a sound into one of those?

KGoldrunner uses "Phonon::createPlayer (Phonon::GameCategory);",
but does "Phonon::GameCategory" have any semantic backing?  Or is
it just a hook for future use?

KGr also dynamically assigns Phonon::MediaObject's from a pool of 8
as it comes time for each sound to be played.  Might it perform better if
it permanently assigned the more frequent sound types as one per
MediaObject (e.g.. one fixed MediaObject for the falling sound)?

And what can one make of bug 198597, against KGoldrunner for
KDE 4.2.2 (which just came in today)?  Threads 1-26 in libraries
somewhere and KGr itself on thread 0 in nanosleep.  Where is the
actual crash, even?  KGr does not itself do multi-threading.  Ref:

    https://bugs.kde.org/show_bug.cgi?id=198597

> and that's the major missing bit to clear latency for
> often-played-short-sounds- that-require-high-levels-of-sync ...
>
> pls correct me if i'm wrong :)
>
IWICT encore, Aaron ... :-)

All the best, Ian W.