IP Audio Delay - Revision history

Achims: /* Barix devices */

2013-06-13T09:21:08Z

Barix devices

← Older revision		Revision as of 09:21, 13 June 2013
Line 56:		Line 56:
	== Barix devices ==		== Barix devices ==
	One last comment, now specific to Barix devices: The Exstreamer 1xx and 2xx decoder devices use a DSP with ample buffering. There is reasons for that, not to be further detailed here. In contrast, the Exstreamer 1000 use a different DSP with lower buffers, and we are currently beta testing a DSP software patch which reduces the buffers much further to almost non-existing !		One last comment, now specific to Barix devices: The Exstreamer 1xx and 2xx decoder devices use a DSP with ample buffering. There is reasons for that, not to be further detailed here. In contrast, the Exstreamer 1000 use a different DSP with lower buffers, and we are currently beta testing a DSP software patch which reduces the buffers much further to almost non-existing !
	With the Exstreamer ~~500/~~1000, you can currently achieve delays of below 50ms - the software has not been optimized for very low delay. However, with optimized software, you can get the delay down to well below 20ms - that has been proven in our labs (for a specific project). We are in the process to bring this down further, obviously (goal 5ms ?) this can only be done by sending many more blocks over the network, for example, one per ms - 1000 blocks per second .. ask your Wifi router what it thinks about that ..), so it needs optimized software.		With the Exstreamer 1000, you can currently achieve delays of below 50ms - the software has not been optimized for very low delay. However, with optimized software, you can get the delay down to well below 20ms - that has been proven in our labs (for a specific project). We are in the process to bring this down further, obviously (goal 5ms ?) this can only be done by sending many more blocks over the network, for example, one per ms - 1000 blocks per second .. ask your Wifi router what it thinks about that ..), so it needs optimized software.

	Back to [[Main_Page#Software_Topics]]		Back to [[Main_Page#Software_Topics]]

Achims: /* Barix devices */

2013-06-13T09:20:16Z

Barix devices

← Older revision		Revision as of 09:20, 13 June 2013
Line 55:		Line 55:

	== Barix devices ==		== Barix devices ==
	One last comment, now specific to Barix devices: The Exstreamer 1xx and 2xx decoder devices use a DSP with ample buffering. There is reasons for that, not to be further detailed here. In contrast, the Exstreamer ~~500/~~1000 ~~and as well as all Annuncicom devices~~ use a different DSP with lower buffers, and we are currently beta testing a DSP software patch which reduces the buffers much further to almost non-existing !		One last comment, now specific to Barix devices: The Exstreamer 1xx and 2xx decoder devices use a DSP with ample buffering. There is reasons for that, not to be further detailed here. In contrast, the Exstreamer 1000 use a different DSP with lower buffers, and we are currently beta testing a DSP software patch which reduces the buffers much further to almost non-existing !
	With the Exstreamer 500/1000, you can currently achieve delays of below 50ms - the software has not been optimized for very low delay. However, with optimized software, you can get the delay down to well below 20ms - that has been proven in our labs (for a specific project). We are in the process to bring this down further, obviously (goal 5ms ?) this can only be done by sending many more blocks over the network, for example, one per ms - 1000 blocks per second .. ask your Wifi router what it thinks about that ..), so it needs optimized software.		With the Exstreamer 500/1000, you can currently achieve delays of below 50ms - the software has not been optimized for very low delay. However, with optimized software, you can get the delay down to well below 20ms - that has been proven in our labs (for a specific project). We are in the process to bring this down further, obviously (goal 5ms ?) this can only be done by sending many more blocks over the network, for example, one per ms - 1000 blocks per second .. ask your Wifi router what it thinks about that ..), so it needs optimized software.

	Back to [[Main_Page#Software_Topics]]		Back to [[Main_Page#Software_Topics]]

StefanG: /* Barix devices */

2013-04-10T13:20:58Z

Barix devices

← Older revision		Revision as of 13:20, 10 April 2013
Line 55:		Line 55:

	== Barix devices ==		== Barix devices ==
	One last comment, now specific to Barix devices: The Exstreamer 1xx and 2xx decoder devices use a DSP with ample buffering. There is reasons for that, not to be further detailed here. In contrast, the Exstreamer 1000 and ~~the "to be announced monday at NAB" device (hint hint !)~~ as well as all Annuncicom devices use a different DSP with lower buffers, and we are currently beta testing a DSP software patch which reduces the buffers much further to almost non-existing !		One last comment, now specific to Barix devices: The Exstreamer 1xx and 2xx decoder devices use a DSP with ample buffering. There is reasons for that, not to be further detailed here. In contrast, the Exstreamer 500/1000 and as well as all Annuncicom devices use a different DSP with lower buffers, and we are currently beta testing a DSP software patch which reduces the buffers much further to almost non-existing !
	With the Exstreamer 1000 ~~and the new device~~, you can currently achieve delays of below 50ms - the software has not been optimized for very low delay. However, with optimized software, you can get the delay down to well below 20ms - that has been proven in our labs (for a specific project). We are in the process to bring this down further, obviously (goal 5ms ?) this can only be done by sending many more blocks over the network, for example, one per ms - 1000 blocks per second .. ask your Wifi router what it thinks about that ..), so it needs optimized software.		With the Exstreamer 500/1000, you can currently achieve delays of below 50ms - the software has not been optimized for very low delay. However, with optimized software, you can get the delay down to well below 20ms - that has been proven in our labs (for a specific project). We are in the process to bring this down further, obviously (goal 5ms ?) this can only be done by sending many more blocks over the network, for example, one per ms - 1000 blocks per second .. ask your Wifi router what it thinks about that ..), so it needs optimized software.

			Back to [[Main_Page#Software_Topics]]

StefanG: /* Packetizing at the encoder */

2013-04-10T13:17:01Z

Packetizing at the encoder

← Older revision		Revision as of 13:17, 10 April 2013
Line 30:		Line 30:
	if 100 blocks per second is the target, 10ms of samples need to be collected, if 50 blocks per second are allowed, 20ms worth of samples need to be collected before they can be sent.		if 100 blocks per second is the target, 10ms of samples need to be collected, if 50 blocks per second are allowed, 20ms worth of samples need to be collected before they can be sent.

	With MP3, not only is a frame of samples first collected (20..50ms, depending on ~~quality~~ setting), but the collected samples then, once complete, must be processed with computational intensive functions (DSP), which takes significant time (but average less than it took to collect the samples, otherwise the system cannot work reliably).		With MP3, not only is a frame of samples first collected (20..50ms, depending on audio frequency setting), but the collected samples then, once complete, must be processed with computational intensive functions (DSP), which takes significant time (but average less than it took to collect the samples, otherwise the system cannot work reliably).

	=== Processing at the encoder ===		=== Processing at the encoder ===

Jrietschel at 06:10, 12 April 2010

2010-04-12T06:10:06Z

← Older revision		Revision as of 06:10, 12 April 2010
Line 1:		Line 1:
	Whenever you transport audio over an IP network - that is true for every vendor and every technology, you will incur a delay. That is unavoidable. Why ? This page will explain the general concept of how Audio over IP works, and explain specifically the reasons for an inherent delay.		Whenever you transport audio over an IP network - that is true for every vendor and every technology, you will incur a delay. That is unavoidable. Why ? This page will explain the general concept of how Audio over IP works, and explain specifically the reasons for an inherent delay.

	CURRENTLY WORK IN PROGRESS - ~~UNFINISHED~~		CURRENTLY WORK IN PROGRESS - NEEDS TO BE REVIEWED

	== Concept of Audio over IP ==		== Concept of Audio over IP ==

Jrietschel at 06:09, 12 April 2010

2010-04-12T06:09:06Z

Show changes

Jrietschel at 05:30, 12 April 2010

2010-04-12T05:30:05Z

@@ Line 1: / Line 1: @@
-This page discusses the general concept of how Audio over IP works and why there is always an inherent delay/latency in Audio over IP devices - whoever makes them.
+Whenever you transport audio over an IP network - that is true for every vendor and every technology, you will incur a delay. That is unavoidable. Why ? This page will explain the general concept of how Audio over IP works, and explain specifically the reasons for an inherent delay.
-CURRENTLY WORK IN PROGRESS - COME BACK in 2 hours ..
+The last addition of delay is not really necessary technology wise, but a fact in Barix devices. We use a Main CPU for network tasks and a DSP driving the D/A, which turns the samples back to analog audio. The DSP is necessary for MP3 (and AAC etc etc) decoding, for PCM it mainly works as a pass-through. The interface between the main CPU and the DSP also introduces a buffer at the DSP side, which is counted in bytes, and can introduce quite hefty delays for low bitrate/sample rate streams. Why ? Well, the buffer is counted in Bytes as i said, and let's assume for these examples here it is 2kBytes (2000 bytes), for a PCM 48kHz stream that means 96Bytes per ms, so roughly 20ms - but if you send a 8Khz PCM stream, you get 6x that delay.
 == Latency measurements ==

Jrietschel: New page: This page discusses the general concept of how Audio over IP works and why there is always an inherent delay/latency in Audio over IP devices - whoever makes them. CURRENTLY WORK IN PROGR...

2010-04-12T05:10:13Z

New page: This page discusses the general concept of how Audio over IP works and why there is always an inherent delay/latency in Audio over IP devices - whoever makes them. CURRENTLY WORK IN PROGR...

New page

This page discusses the general concept of how Audio over IP works and why there is always an inherent delay/latency in Audio over IP devices - whoever makes them.

CURRENTLY WORK IN PROGRESS - COME BACK in 2 hours ..

== Latency ==
The end-to-end latency of an Ethersound encoder and a Barix ES100spkr decoder heavily depends on the codec used.

=== VLSI based devices ===
On '''Exstreamer 100, Exstreamer 110 and Exstreamer 200''' the end-to-end latency is approximately '''57ms'''. This is caused by large internal buffers in the VLSI codec.

=== Micronas based devices ===
The internal buffers of the Micronas codec are much smaller which also positively affects the latency.
The end-to-end-latency of the '''Exstreamer 1000, Annuncicom 100, Annuncicom 200 and Annuncicom 1000''' is only about '''6ms'''.

== Latency measurements ==

Both latencies were measured in the below described test.

=== Test environment ===

The latency was measured with the following equipment:
* Digigiram ES220 as an input device
* another ES220 as a reference output device
* Exstreamer 100 as an output device (VLSI based device)
* Annuncicom 100 as an output device (Micronas based device)
* HP procurve 1700-8 switch where all devices were connected to

Both Barix devices were loaded with the version 00.03 of the Ethersound decoder module.

The input of the ES220 was fed with a 500Hz tone from a signal generator. The input, both output Barix devices as well as the reference ES220 device were monitored with an oscilloscope.

A trigger was set to capture the waveform after switching on the signal generator.

=== Test results ===
The below three diagrams show the results of the measurement. The top line (channel 4, green) is the clock source. Channels 1 (yellow), 2 (blue) and 3 (violet) are: the VLSI device (Exstreamer 100), the Micronas device (Annuncicom 100) and the reference ES220.

'''On the first diagram the 57.2ms latency of the VLSI decoder (Exstreamer 100) can be seen.'''

'''The second screen shot shows the end-to-end latency using a Micronas based device Annuncicom 100. The latency is significantly lower - only 6ms.'''

'''The last picture shows the end-to-end delay using the reference ES220 device. The latency is 1.44ms.'''