continuous play

[Harald Sitter]

On Tue, Sep 10, 2013 at 7:15 PM, Marcos Dione <mdione at grulic.org.ar> wrote:
> On Tue, Sep 10, 2013 at 09:51:36AM +0200, Harald Sitter wrote:
>> On Mon, Sep 9, 2013 at 6:39 PM, Marcos Dione <mdione at grulic.org.ar> wrote:
>> >
>> >     I'm not even talking about gapless here. I have a toy audio player.
>> > What I want to achieve is simply this: when the current song is about to
>> > end, pick another song, add it to the play queue. when the song really
>> > finishes, the one just queued should be played automatically. how the
>> > song is picked is not important.
>> >
>> >     I'm using two features for that: MediaObject.aboutToFinish() and
>> > MediaObject.enqueue(). the attached script (in python, using pyqt4) is an
>> > example of this. the script accepts two files to play using that scheme.
>> >
>> >     I'm using both phonon-vls and phonon-gstreamer. setting their debug
>> > envvars to 1 gave not much more info, but here's the output with VLC:
>> >
>> > mdione at diablo:~/src/projects/trash & toys$ python phonon.py /usr/share/sounds/purple/alert.wav /usr/share/sounds/purple/login.wav
>> > WARNING: Phonon needs QCoreApplication::applicationName to be set to export audio output names through the DBUS interface
>> > [0x1429cc8] main services discovery error: no suitable services discovery module
>> > next!
>>
>>  Phonon VLC does not support gapless playback. Phonon GStreamer on the
>>  other hand does, but only if the sound length is more than a couple of
>>  seconds, which considering the file names is likely not the case. So
>>  unfortunately this cannot be achieved with Phonon 4.
>
>     ok, so I discard VLC and I will focus on GST. I just tried with longer
> files (2 songs more than 1 minute long each) and it works :) what's strange
> is that I don't get more debug info with export PHONON_GST_DEBUG=5. does
> that still work? Thanks for the heads up.

http://techbase.kde.org/Development/Tutorials/Debugging/Phonon

Also apparently I have not been clear enough. As you explain it your
code relies on aboutToFinish to behave like a callback (which it is
not) and for the backends to wait for you to set the next source
(which they will not, because it's not a callback).

Real quick example of why you cannot rely on aboutToFinish for anything:
* vlc has no concept of about-to-finish
* phonon vlc manually adds a simulation of about-to-finish ontop of
vlc by emitting the signal 3 seconds before end of stream
* if end of stream cannot be determined accurately (for example we are
listening to a http stream) about-to-finish becomes equal to 'yeah, we
are stopping now'
* if about-to-finish is equal to 'yeah, we are stopping now' not only
can the transition to a new source not happen gaplessly (which is why
the entire abouttofinish madness is there to begin with) but we cannot
even transit to the new source without partially shutting down the
internal pipeline (again: no callback, i.e. you may not even respond
to about-to-finish, so we cannot wait for anything).

what you want to do is hold on to the finished() signal or the state
transitions and write all your handling around that. then to
complement that you write code acting on aboutToFinish. iff you get
abouttofinish and tried setnextsource and still you get the finished
signal after that, then there was no transition opportunity for the
backend and you simply do your completely generic finished() handling
(e.g. check currentSource is the right one or set the right one and
simply call play()), otherwise transition from source 1 to 2 worked
just fine and everythign will continue playing.

HS