[Documentation] Phonon

[Georg Grabler]

Hello,

I've done so already, and used ->sender() for this.Quite a strange behaviour
of JuK though.

I think the "main problem" is that JuK does not make use of the queue at
all. It does not add it to the queue, it fades out the mediaobject which is
running out (setting volume values), and sets a newly created mediaobject
with setMediaObject which JuK fades in the same time (setting the volume).

This shows the behaviour, that stateChanged mit Phonon::StoppedState is
emitted for the "new" file, so for the MediaObject added with setMediaObject
(I think that's not clean code anyway, but i'm not sure why it was done like
this in JuK, and if it was intended to be like this).

In the receiver function (slotStateChanged), it creates it's own bug
(deleting the m_file - setting it to FileHandle::null()).

I have two questions about Phonon:
1.) Can I expect that aboutToFinish should really emit right before it stops
(topic: working as intended, should it be right before or some seconds
before the track stops)? So crossfading there makes really no sense, and JuK
needs some different trigger when just a a few seconds of a song are left
(or not, see 2.)
2.) Can I crossfade between MediaObjects in the Queue (as an example)? Like
having 1 file playing, at aboutToFinish i set another file (mediasource) in
the queue, and set the transition time to -5 (or any other value which seems
to fit nicely). Wouldn't this mean, that I'd always need to have two
mediafiles in the queue, since aboutToFinish is too short before the end of
the track to make sense for crossfading (at the current behaviour I
experience), and that the transition time would be a "global" value.

How would the crossfade in Phonon work anyway? JuK currently fades out one
track, and fades in the other one at the same time. I don't like that, but I
think it's as the JuK developer and maintainer intended it to be like this.

Kind regards,
Georg

On Thu, Jan 8, 2009 at 5:15 PM, Matthias Kretz <kretz at kde.org> wrote:

> 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
> > (crossfadeToFile is triggered by phonons aboutToFinish as it seems, and
> > Phonon::State changes to stopped while playing).
>
> Docs for aboutToFinish:
> 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
> crossfades) or prefinishMark
>
>
> --
> ________________________________________________________
> Matthias Kretz (Germany)                            <><
> http://Vir.homelinux.org/
>
> _______________________________________________
> kde-multimedia mailing list
> kde-multimedia at kde.org
> https://mail.kde.org/mailman/listinfo/kde-multimedia
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-multimedia/attachments/20090109/9da1333d/attachment.htm>
-------------- next part --------------
_______________________________________________
kde-multimedia mailing list
kde-multimedia at kde.org
https://mail.kde.org/mailman/listinfo/kde-multimedia