Page 1 of 1

What about track playback with little delay ?

Posted: 30 Sep 2012 23:43
by TheoOrl45
Hi everybody,

Trying to make a smooth & Perfect transition with modstream watcher, i'm wondering of something else would help me.

Broadcast distant machine :

During the automated playback, a local dj request for live show using tcp commands.
For example, after track3, he will do his show following the original scheduled tracks until jingleD, where he "tells" the distant machine to re-start the automated broadcast.

There are 2 difficulties : passing from the distant playback to te modstream of the local show, and passing from the local show to the distant playlist.
For that, we need to use an external streaming server to which the distant proppfrexx will connect to, and to which the local Dj will encode his live show.

His live show will be :

With modstream watcher, we can't be sure that, after track3, live stream will begin with the jingleC launching by the local dj, due to delay from streaming servers (buffers...) and when Dj will send thé watcher stop tcp command in real time, it's possible that, due to delay, the streaming playback would not be at the end of the show. Not smooth and not Perfect.

So, what about buffering (into file) the streaming playback in order to:
- begin the buffered sounds at the very beginning of the show (using acpd), here jingleC.
- stop thé buffered streaming playback at the end of the show where we could put a "next" command using acpd.
The idea would be to begin the buffered playback whereas it's currently writing data, with a delay.

What do you think about it?

Sorry for my poor english : it's very hard to be clear...


Re: What about track playback with little delay ?

Posted: 01 Oct 2012 11:51
by TheoOrl45
Yes, I imagine that we can't calculate the delay time (I work with computers, I know those constraints)... That's why I'm looking for an other solution :-)

Imagine : modstream watcher connects to an url stream. It detects the beginning of the "sound" and begins to save it into a file.
At the end of the current playlist track in the playlist, modstream watcher (or other new system, no matter) starts the playback of the file, which is currently being updated by modstream watcher at the same time. Both runs in parallel : playback + buffering... This can simulate the delay... players plays the file, while modstream watcher (or other) keeps to saving the stream received at the same time.

When modstream watcher detects the end of the "sound", it stops saving it to the file. File keeps being played into the playlist, until that end of the "sound" where the next playlist track starts.

The main barriers are : will it be possible to :
- starts playing a track which is not finished (is currently updated at the end by the modstream watcher).
- detects the beginning of the "sound" into the data saved (on a file which is not entirely finished).
- detects the end of the "sound" during its playback.

If yes, I think we could make some nice, smooth and perfect system for syncing....

Re: What about track playback with little delay ?

Posted: 01 Oct 2012 12:24
by radio42
That should almost all theoretically be possible I guess.
But there are still a few issues with it:

a) saving the 'buffered' stream to a file might get very huge (as it must be saved in raw PCM data, WAVE; additional encoding might add extra buffers)
So your hard disk needs a lot of free space!
But this still limits the total duration of a recorded mod stream to a few hours only.

b) The other main issue is, that most streaming servers disconnect the source, if only silence is streamed.
Your assumption is, that the remote machine connects prior to the effective start, but sends 'silence' until its effective due time.
If that time period is longer than the servers timeout, the remote machine will get disconnected.
If on the other hand the remote machine starts streaming (too) 'late', you still have the delay problem.

However, I'll think about it and put this onto the wish-list for a future release!

Re: What about track playback with little delay ?

Posted: 01 Oct 2012 13:41
by TheoOrl45
You get the point Bernd :-)

a) It's true that the 'buffered' stream must be saved in raw data and hard disk should be very big. But this kind of new "delay" system could be use only for certain case. For example, if the goal is to broacast 12 h of a streaming playback, it should not be use. But, if the goal is to broadcast an external event for only a few hours, why not ?:-)
As long as user know the constraint caused by this new system....He will have to choose.

b) I don't know how streaming servers react with "silence". But, in the past, when I lead my own web radio, I used shoutcast server, and I remember that "silence" streamed "silence". But you're right : this needs to be thought and deepened.

Happy to ear you put it onto the wish-list :-)

Re: What about track playback with little delay ?

Posted: 01 Oct 2012 19:45
by radio42
I guess the main issue is, that you would need to know the exact server 'buffering' delay time for perfect syncing.
But unfortunately there is no real way to calculate or compensate this.

Re: What about track playback with little delay ?

Posted: 12 Jan 2013 12:23
by TheoOrl45
Hi Bernd,

Any news about this functionnality ?



Re: What about track playback with little delay ?

Posted: 12 Jan 2013 20:05
by radio42
Not so far.