PDA

View Full Version : Can buffering be adjusted to minimize latency/delay?



dr_c
2008-11-15, 08:41
Hello,

I am streaming to my "SqueezeBox Duet" via the "Tune in URL" function in SqueezeCenter, from an IceCast/Edcast setup on my laptop. It works very well (quality-wise), but the audio is delayed by about 5 seconds.

Can I tell the SqueezeBox Reciever to turn off (or way down) the buffering to decrease the latency? Can this be done on a station-by-station basis (so I don't lose buffering of 'real' internet radio stations that aren't on my LAN!)?

Another question: I'm streaming mp3's -- is there another format that would be less delayed due to decoding?

Thanks for the help,

-Dr. C.

P.S. -- Here is an example of someone else trying something similar: http://lists.xiph.org/pipermail/icecast/2004-February/006461.html

andyg
2008-11-15, 08:55
I'd have thought Icecast would support pre-buffering, which means it sends a lot of data when you first connect in order to fill your buffer. Then this is not an issue and it should start very quickly.

dr_c
2008-11-15, 10:11
Well, what I'm trying to do is DJ some videos from a 'leading internet video site,' but have the audio play through the SqueezeBox. To do this, I'm piping the laptop's 'Stereo Mix' to EdCast and then onto IceCast for broadcast on the LAN (to squeezecenter and the squeezebox receiver). EdCast and Icecast are set-up for minimum delay.

A half-second or full second delay is acceptable (folks will notice but not a big deal).

It looks like the right parameter might be bufferSecs -- but I can only turn that down to 3 seconds (accessible from SqueezeCenter settings -> network -> Radio Station Buffer Seconds). Anyone know how I can change the 'check' on bufferSecs down to 0?

Thanks,

Dr. C.

andyg
2008-11-15, 10:25
Oh, you are trying to sync audio with video? It will likely be difficult/impossible to do this.

bpa
2008-11-15, 10:58
Why not use vlc to play the video as it
- enables the delay between video and audio to be adjusted to allow for latency issues. It may not be perfect but it is easily adjustable.
- audio can be streaming either directly from "Stereo Mix" into SC or over http to SC. Minimise need for multiple apps which each add delays.

dr_c
2008-11-15, 16:00
The VLC media player is pretty slick for this purpose. Works well for YouTube -- doesn't work for OnNetworks.

Unsurprizingly, with bufferSecs set at 3, the audio delay is 3075 milliseconds. I have got to find out where bufferSecs is forced to 3 (instead of allowing 0).

-Dr. C.

bpa
2008-11-15, 16:30
If the videos are being played on the same PC as SC then use WaveInput plugin rather than EdCast/IceCast - WaveInput can be used to feed "Stereo Mix" straight into SC and cuts out the "http" radio station buffer behaviour.

dr_c
2008-11-15, 16:47
Good idea. Unfortunately, in my case, the SqueezeCenter is on a server and the videos are being watched on a laptop (where the people are!).

Are there other low latency plugins for streaming directly into SqueezeCenter from another computer on the LAN?

-Dr. C.

bpa
2008-11-15, 17:00
Why not run a 2nd SC on the laptop as well - you don't need any other music files

dr_c
2008-11-15, 17:06
Ah-ha. I will try that. Didn't occur to me. Thanks!

-T

marcone
2009-01-03, 23:10
Hello,

I am streaming to my "SqueezeBox Duet" via the "Tune in URL" function in SqueezeCenter, from an IceCast/Edcast setup on my laptop. It works very well (quality-wise), but the audio is delayed by about 5 seconds.


Same problem here. Until yesterday I was running squeezecenter 7.0.1, and had it set up to use the waveinput plugin to grab input from a radioshark. Channel changes were very quick, I'd say less than a second. Today I updated to squeezecenter 7.3, and now I'm seeing very slow channel changes, about 8 seconds or so.
Clearly either squeezecenter itself or the new firmware for the receiver now does a lot buffering, which is a big pain if the input is real time.
A way to tune the buffer (that doesn't involve reverting to squeezecenter 7.0.1 and associated firmware) would be welcome.

bpa
2009-01-04, 02:40
The new Streaming code in 7.3 fills the SB buffer properly whereas the older version didn't fill it before playing starts.



the waveinput plugin to grab input from a radioshark.

There will be no difference if using the SharkPlay plugin as it also uses wavin2cmd to stream from RadioShark - the main advantage with SharkPlay is you can tune AM/FM Frequency from with SB.

There are some wavin2cmd settings which can be tweaked but the delay will still be secs. See http://wiki.slimdevices.com/index.php/WaveInput_plugin#Wavin2cmd_command_line_reference

marcone
2009-01-04, 11:35
The new Streaming code in 7.3 fills the SB buffer properly whereas the older version didn't fill it before playing starts.

So is there a way to get the "improper" behavior back in 7.3? It worked much better for me.


There will be no difference if using the SharkPlay plugin as it also uses wavin2cmd to stream from RadioShark - the main advantage with SharkPlay is you can tune AM/FM Frequency from with SB.

The SharkPlay plugin didn't work properly for me out of the box. There was substantial stuttering, and the delay seemed to be even bigger. I might have gotten it to work with some tweaking, but since I had the wavin plugin working already (I modified it slightly, so I can tune with it as well), I didn't bother trying.

bpa
2009-01-04, 13:24
So is there a way to get the "improper" behavior back in 7.3? It worked much better for me.

I don't believe so as SC now manages the SB buffer better to improve the general synchroisation feature. In 7.2 and earlier I think SC started playing as soon as it had some data for the SB which means if data didn't follow quickly - there was stuttering.

If wavin2cmd was delaying the 1st load of data then reducing buffer count and/or buffer size might help but I don't believe this would work as there was "immediate" playing in 7.2.



The SharkPlay plugin didn't work properly for me out of the box. There was substantial stuttering, and the delay seemed to be even bigger. I might have gotten it to work with some tweaking, but since I had the wavin plugin working already (I modified it slightly, so I can tune with it as well), I didn't bother trying.

Curious since the sharkplay plugin uses the exact same command line as waveinput. It's possible the app to turn on/off the LED is causing a small delay and thus the stuttering as data was not delivered to SB. Doesn't really matter since you have a solution for your needs.

marcone
2009-01-04, 18:37
I don't believe so as SC now manages the SB buffer better to improve the general synchroisation feature. In 7.2 and earlier I think SC started playing as soon as it had some data for the SB which means if data didn't follow quickly - there was stuttering.

Would you happen to know where in the squeezecenter source code this behavior is controlled?

bpa
2009-01-05, 01:32
now I'm seeing very slow channel changes, about 8 seconds or so

I did a test on Linux and on Vista using my SharkPlay - the time taken from clicking on a menu to start playing is 2-3 secs for a single player. The 8 secs delay makes me think a setting is not right possibly the RadioShark2 setting.

On Vista Check Control Panel/Manage Audio Devices/Recording/Analog Connection - RadioShark / Properties/Advanced that default format is "2 channel 16bit 441000Hz (CD Quality)"

What player is being used ?
Is the player synced with another player ?



Would you happen to know where in the squeezecenter source code this behavior is controlled?

slim/Player/StreamingController.pm
There is now a state machine approach to controlling streams so there is a state "BUFFERING" and the transition from this state into one when playing can start is by the event "BufferReady" which is sent by the routine playerBufferReady which is subclassed into each player - for a SB2/3 this is triggered by a message from the player ( "STMl" I guess it means buffer is full ) see slim/Player/Squeezebox2.pm.

awy
2009-01-05, 07:42
bpa has not got it quite right, although it is correct that several changes were made to fill in holes in the existing buffing calculations.

Slim/Utils/Prefs.pm is where the min value for bufferSecs is defined as 3s. Even if you change this, the code elsewhere will assume a value of 0 is undefined and apply a default of 3.

But I think that you are on a hiding to nothing here. The architecture is not designed for low latency in real time. Track startup time will typically be below 100ms for local tracks and can be almost as quick for remote streams so long as the remote stream sends at least 3s seconds of data in an initial burst, so you get low-latency but not real time.

bpa
2009-01-05, 08:23
The audio stream comes from an FM Tuner - so it is live radio and so it will take 3 secs to get 3 secs of data - it is not possible to get an initial burst.

The 3 secs prefs - I presume this is not the same as Settings/Advanced/Network/Radio station buffer because changing this value did not affect the 3 secs startup.

The issue for marcone is why is his startup 8 secs and not 3 secs as on my system.

andyg
2009-01-05, 08:30
Is Icecast involved?

bpa
2009-01-05, 09:00
No icecast - just Joe Bryan's wavin2cmd which takes PCM data from a Windows source and copies it out to stdout - which can then be used as normal - fed into Flac/lame or native.

Looking at the code it seems that Settings/Advanced/Network/Radio station buffer is bufferSecs and perhaps marcone has his bufferSecs set to 8.

marcone
2009-01-05, 20:36
No icecast - just Joe Bryan's wavin2cmd which takes PCM data from a Windows source and copies it out to stdout - which can then be used as normal - fed into Flac/lame or native.

Looking at the code it seems that Settings/Advanced/Network/Radio station buffer is bufferSecs and perhaps marcone has his bufferSecs set to 8.

It's set to 3 seconds, but it takes much longer than that to get started and for channel changes to take effect. It used to be much faster though, when I was still using 7.0.1

Is the "radio station buffer" setting used for the WaveInput plugin though?

awy
2009-01-06, 00:59
I'm not familiar with the WaveInput plugin (I thought you were using HTTP via IceCast or similar). If it does not return isRemote==true, then the value of the bufferThreshold player preference will be used. There is no WebUI to set this but you can get at it via the CLI. The default value is 255 (KB), which is about 1.5s at 44100 samples/s 16-bit, stereo. If the wav input is being transcoded to flac then this will be longer.

bpa
2009-01-06, 04:05
Thanks Alan,

I also see a protocol handler can have a routine called bufferThreshold to return a special protpcol specific threshold value.

I have a plugin SharkPlay to handle the RadioShark Tuner and it has a protocol handler so I tested adding a routine "bufferThreshold" to set the threshold at 75. Audio starts playing practically immediately whereas a value of 50 plays a burst of audio and then immediately rebuffers.

I think I may add a user setting to applicable plugins (e.g. WaveInput, SharkPlay) to adjust this Startup delay. Typically these plugins are providing a PCM audio stream which is constant and generated within the PC so there is little need for a large buffer of data.

bpa
2009-01-06, 05:03
Marcone,

you can try adding the following line to WAVIN.pm on SC 7.3


sub bufferThreshold { 100 }