# [Documentation] Phonon

Matthias Kretz kretz at kde.org
Thu Jan 8 16:15:04 GMT 2009

Hi,

On Thursday 08 January 2009 10:53:40 Georg Grabler wrote:
> I've problems finding any API Documentation of Phonon. It seems as if
> api.kde.org has several broken links and other strange behaviour:
> 1.) phonon.kde.org seems to have just a mainpage, no documentation

It has other pages, too. But it's broken. And I have no power over it...

> 2.) on api.kde.org, when I want to view the phonon documentation, I just
> get the kdelibs main documentation page. There, I can't find anything else
> than a lot of broken links
> 3.) On the components page, pressing "Classes" at Phonon -> broken link.

Yes, one of the moves broke all of the docs. :( You can still find the
documentation in the header files, though.

One of these days I'll look into it again. For now you can use the docs
Trolltech provides - which is why it's not such a pressing issue to fix.

> Is there any reasonable documentaiton for phonon, for "users", means a API
> reference? I wanted to look up a few problems I have with JuK
> Phonon::State changes to stopped while playing).

Emitted before the playback of the whole queue stops. When this signal is
emitted you still have time to provide the next MediaSource (using \ref
enqueue) so that playback continues.
This signal can be used to provide the next MediaSource just in time for the
transition still to work.

You probably want to use MediaObject::setTransitionTime(<something negative>).

> Also I'm not sure about if i get the phonon state stopped by the right
> Phonon::MediaObject. In JuK, there's a line disconnecting the current
> mediaobject (using mo->disconnect(this)), creating a new one afterwards.
> I'm still receiving the stopped signal (Phonon::StoppedState triggered by
> stateChanged), and would like to know which phonon object triggered that,
> and why it was triggered.

You can debug it by looking at sender() in the receiving slot.

> Furthermore, aboutToFinish is emitted short before stopped, means both are
> emited in less than a second.

Yes, that's how it's supposed to be.

> Therefore, using this as  a trigger for
> crossfadeToFile isn't quite the best choice

yes - if crossfadeToFile does what I think it does.

> - the question is if that's as
> intended in this case.
>
> Any hints?

Look at setTransitionTime (doesn't work with phonon-xine though :( for