PDA

View Full Version : Using Squeezebox for Live Sound?



orrinc
2005-09-26, 12:24
Does anyone have a good way to stream analog audio directly in real time to a Squeezebox player?

I've had instances doing concert sound when it would be very useful to feed an audio stream wirelessly to a remote device- for a nearby listening area for overflow audience, stage mix, etc.

The audio quality and reliability is high enough for this to work, but I don't know the best way to get the audio to the SlimServer.

I guess a Barix ExStreamer would work, but I was thinking about a USB audio input device, such as an Edirol UA-1X or M-Audio Transit, which would also let me record the audio on the notebook PC.

Any suggestions? Has anyone tried this?

Orrin

Ben Sandee
2005-09-26, 13:38
On 9/26/05, orrinc <orrinc.1vzdnn (AT) no-mx (DOT) forums.slimdevices.com> wrote:
>
>
> Does anyone have a good way to stream analog audio directly in real time
> to a Squeezebox player?

I would think that streaming true live audio would be very difficult to do
without confounding and/or frustrating the remote listeners because of the
buffering that is done on the players. That is, unless the listeners are so
acoustically isolated that a small difference in synchronization would not
be heard. If you were to drop the buffering (or reduce it) in the players I
would expect that even the smallest blip in network activity or server load
would cause a dropout to occur which would also confound and frustrate the
remote listeners.
Ben

JJZolx
2005-09-26, 15:10
On 9/26/05, orrinc <orrinc.1vzdnn (AT) no-mx (DOT) forums.slimdevices.com> wrote:
>
>
> Does anyone have a good way to stream analog audio directly in real time
> to a Squeezebox player?

I would think that streaming true live audio would be very difficult to do
without confounding and/or frustrating the remote listeners because of the
buffering that is done on the players. That is, unless the listeners are so
acoustically isolated that a small difference in synchronization would not
be heard. If you were to drop the buffering (or reduce it) in the players I
would expect that even the smallest blip in network activity or server load
would cause a dropout to occur which would also confound and frustrate the
remote listeners.
I agree that if there's a delay, then it may not work out very well, but I would think that it isn't so much a factor of whether or not you're buffering, but more a matter of how much data the player requires in the buffer before it begins playback of the stream. If you can (reliably) start playback as soon as the buffer begins to fill, then there'd be little or no delay. Meanwhile, the buffer can probably be filled to near 100% since playback removes data much slower than a reliable network would refill the buffer. So you still have the benefit of buffering to combat dropouts.

The question is how much data does the Squeezebox require in the buffer before it begins playback (I suspect it differs for different streaming formats) and whether it can be adjusted.

Of course, you also have the problem of digitizing the analog data, which itself may introduce additional latency.

Ben Sandee
2005-09-26, 15:47
On 9/26/05, JJZolx <JJZolx.1vzliz (AT) no-mx (DOT) forums.slimdevices.com> wrote:
>
> I agree that if there's a delay, then it may not work out very well,
> but I would think that it isn't so much a factor of whether or not
> you're buffering, but more a matter of how much data the player
> requires in the buffer before it begins playback of the stream. If you
> can (reliably) start playback as soon as the buffer begins to fill, then
> there'd be little or no delay. Meanwhile, the buffer can probably be
> filled to near 100% since playback removes data much slower than a
> reliable network would refill the buffer. So you still have the
> benefit of buffering to combat dropouts.

If it's live audio, you can only buffer data as fast as the player plays it
(real-time). If you want two seconds of buffer then you're going to need to
delay playback by two seconds in order to guarantee that two seconds of
buffer can actually be used in the event of network or server issues. If you
start playback immediately there isn't any data IN the buffer and you'll
never catch up because it's live.
Ben

Robin Bowes
2005-09-26, 15:56
Ben Sandee said the following on 26/09/2005 23:47:
> If it's live audio, you can only buffer data as fast as the player plays
> it (real-time). If you want two seconds of buffer then you're going to
> need to delay playback by two seconds in order to guarantee that two
> seconds of buffer can actually be used in the event of network or server
> issues. If you start playback immediately there isn't any data IN the
> buffer and you'll never catch up because it's live.

Not so. Streaming is asynchronous.

For example, if you stream at > the playback rate then the buffer will
soon fill up.

R.
--
http://robinbowes.com

If a man speaks in a forest,
and his wife's not there,
is he still wrong?

Ben Sandee
2005-09-26, 16:05
On 9/26/05, Robin Bowes <robin-lists (AT) robinbowes (DOT) com> wrote:
>
> Ben Sandee said the following on 26/09/2005 23:47:
> > If it's live audio, you can only buffer data as fast as the player plays
> > it (real-time). If you want two seconds of buffer then you're going to
> > need to delay playback by two seconds in order to guarantee that two
> > seconds of buffer can actually be used in the event of network or server
> > issues. If you start playback immediately there isn't any data IN the
> > buffer and you'll never catch up because it's live.
>
> Not so. Streaming is asynchronous.
>
> For example, if you stream at > the playback rate then the buffer will
> soon fill up.

How can you stream faster than the playback rate when the playback rate is
inherently the same as the source data rate? It's not like we've got a file
full of data -- we have data coming in from a microphone (or soundboard) at
the sample rate and being played on the other end at the same sample rate.
Ben

Robin Bowes
2005-09-26, 16:13
Ben Sandee said the following on 27/09/2005 00:05:
> On 9/26/05, *Robin Bowes*
> <robin-lists (AT) robinbowes (DOT) com
> <mailto:robin-lists (AT) robinbowes (DOT) com>> wrote:
>
> Not so. Streaming is asynchronous.
>
> For example, if you stream at > the playback rate then the buffer will
> soon fill up.
>
>
> How can you stream faster than the playback rate when the playback rate
> is inherently the same as the source data rate? It's not like we've got
> a file full of data -- we have data coming in from a microphone
> (or soundboard) at the sample rate and being played on the other end at
> the same sample rate.

Ah. Good point. I over-looked about that :)

R.
--
http://robinbowes.com

If a man speaks in a forest,
and his wife's not there,
is he still wrong?

JJZolx
2005-09-26, 16:16
How can you stream faster than the playback rate when the playback rate is
inherently the same as the source data rate? It's not like we've got a file
full of data -- we have data coming in from a microphone (or soundboard) at
the sample rate and being played on the other end at the same sample rate.
Hmmm. Good point. The buffer can't fill to any degree unless you delay playback. Duh.