Low latency 'live' streaming...

Archived from groups: rec.audio.tech (More info?)

In article <51f1d8c1.0404142237.efa5838@posting.google.com>,
jon@richardson.net (Jon Richardson) wrote:

> Hi,
>
> I'm looking to implement a low-latency (I appreciate there will always
> be codec latency, but an absolute bare minimum) 'live' streaming
> solution for a point-to-point application.
>
> Unfortunately the timing is quite critical, so the receiving end must
> only be 100ms or so behind the sender otherwise everything falls
> apart! I've looked at some implementations using LAME on Linux/Windows
> which I've not experimented with yet but can someone tell me if its
> even possible to achieve this low latency? From some documentation I
> have read I understand a lot of the latency (5-25 seconds or so) is
> caused by the buffering, presumably related to error
> correction/protection etc.
>
> I'm looking to achieve MP3 128k type quality and for the purposes of
> this, you can assume that its across a LAN rather than over a flakey
> ADSL line
>
> Many thanks in advance,
> Jon

You'll need custom software that operates efficiently with unbuffered
and lightly buffered streams. Generic software won't do it.

- Custom software will have to set the sound hardware to use small
buffers. Normally the buffers are fairly large to prevent clicks and
pops while the computer is under load.

- Forget about MP3. Consider sending data uncompressed or using a
simple, zero-latency algorithm like ADPCM.

- Small UDP packets over Gigabit Ethernet have low latency. UDP is
terribly fussy without a dedicated network, though. The two solutions
for reliable audio without a dedicated network are TCP and error
correction with spreading. Both can add several seconds of latency,
though the second method has a constant amount.

- You'll have to disable all virtual memory or eliminate hard disk use
within your custom application. Mixing the two results in unpredictable
delays that will break your unbuffered streams.

- The sample rate of your source and destination will not exactly match.
There will have to be an algorithm to blend away the buzzing that would
result from buffer misalignments.


You could hire a programmer for this if you have a market. If not, I'd
go with simple analog solutions.

Archived from groups: rec.audio.tech (More info?)

jon@richardson.net (Jon Richardson) wrote in
news:51f1d8c1.0404142237.efa5838@posting.google.com:

> I'm looking to implement a low-latency (I appreciate there will always
> be codec latency, but an absolute bare minimum) 'live' streaming
> solution for a point-to-point application.

Your only real hope is to look into "voice over LAN" technology, but it's
still in its infancy. There are various standards that are being crafted
to help solve the problems (ST-2, RSVP, RTP), but the entire technology
isn't quite "finished" yet.

> Unfortunately the timing is quite critical, so the receiving end must
> only be 100ms or so behind the sender otherwise everything falls apart!
> [snip]

Getting a packet from one app to another in 100ms isn't that hard, but
guaranteeing that this will always be true is very, very difficult. At
present, I believe that your only option is to spend a lot of money on
custom software running on machines (and a wire) dedicated to this task.

It would be easier (and cheaper) to run a dedicated audio cable between
your two locations.