What about track playback with little delay ?
What about track playback with little delay ?
Hi everybody,
Trying to make a smooth & Perfect transition with modstream watcher, i'm wondering of something else would help me.
Imagine...
Broadcast distant machine :
Track1
JingleA
Track2
JingleB
Track3
JingleC
Track4
JingleD
Track5
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 :
JingleC
Speak
Track4
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...
Regards
Trying to make a smooth & Perfect transition with modstream watcher, i'm wondering of something else would help me.
Imagine...
Broadcast distant machine :
Track1
JingleA
Track2
JingleB
Track3
JingleC
Track4
JingleD
Track5
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 :
JingleC
Speak
Track4
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...
Regards
Theo, from France.
Re: What about track playback with little delay ?
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....
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....
Theo, from France.
Re: What about track playback with little delay ?
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!
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!
Bernd - radio42
ProppFrexx ONAIR - The Playout and Broadcast Automation Solution
ProppFrexx ONAIR - The Playout and Broadcast Automation Solution
Re: What about track playback with little delay ?
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
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
Theo, from France.
Re: What about track playback with little delay ?
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.
But unfortunately there is no real way to calculate or compensate this.
Bernd - radio42
ProppFrexx ONAIR - The Playout and Broadcast Automation Solution
ProppFrexx ONAIR - The Playout and Broadcast Automation Solution
Re: What about track playback with little delay ?
Hi Bernd,
Any news about this functionnality ?
Regards,
--
Theo
Any news about this functionnality ?
Regards,
--
Theo
Theo, from France.
Re: What about track playback with little delay ?
Not so far.
Bernd - radio42
ProppFrexx ONAIR - The Playout and Broadcast Automation Solution
ProppFrexx ONAIR - The Playout and Broadcast Automation Solution