Difference between revisions of "RTP Buffering - Frame Based Buffering"
| Line 28: | Line 28: | ||
|} | |} | ||
== Configuration == | |||
The only configuration parameter for the RTP decoder is the '''delay''' in milliseconds. | |||
The delay parameter is the desired processing delay of the decoder (between the network input and the audio output). Please note that the end-to-end delay between the encoder and the decoder might be (significantly) different to the value configured. | |||
In an ideal case the delay parameter would be 0 ms, however due to device's internal buffers a small delay (depending on the hardware) is inevitable. The delay value should also cover possible temporary network hick-ups. E.g. if the network might sometimes delay the packet delivery by 20ms due to a temporary load, the configured parameter should not be less than 20ms. | |||
The maximum configurable delay is limited by the device's internal buffer (64, 32 or 16kB). | |||
The following sections show recommended delay values in different audio formats. | |||
===MP3=== | |||
===PCM=== | |||
== | == Multiple Device Synchronisation == | ||
Multiple devices receiving the same RTP stream can be configured to play in sync by entering the same delay parameter. | |||
Barix recommends to use broadcast or multicast together with synchronisation, otherwise a small inaccuracy (few milliseconds) might be caused by the network delivery to different locations. | |||
== Deliberate Delays == | |||
In some applications it is desired to artificially delay the audio. E.g. in a tunnel to eliminate the delay caused by the distance between the devices. | |||
An artificial delay can be introduced by configuring the devices to different delay values. E.g. 100ms, 120ms, 140ms, 160ms, etc. | |||
Revision as of 14:59, 22 June 2010
Introduction
In Song module version 8 a new RTP buffering method called frame based buffering was introduced. The algorithm calculates the audio buffer level in milliseconds rather than in bytes.
Features
Frame based buffering allows:
- configurable decoding delay with one frame accuracy
- synchronisation of several decoders to the same stream (just by configuring them to the same initial delay)
- stable delay over long period of time
- automatic correction of clock difference between encoder and decoder
Applications
The following applications use frame based buffering:
| Application Name | Version |
| Streaming Client | 2.17 |
| Annuncicom Full Duplex | 0.21 |
| RTP STL | 2.01 |
Configuration
The only configuration parameter for the RTP decoder is the delay in milliseconds.
The delay parameter is the desired processing delay of the decoder (between the network input and the audio output). Please note that the end-to-end delay between the encoder and the decoder might be (significantly) different to the value configured.
In an ideal case the delay parameter would be 0 ms, however due to device's internal buffers a small delay (depending on the hardware) is inevitable. The delay value should also cover possible temporary network hick-ups. E.g. if the network might sometimes delay the packet delivery by 20ms due to a temporary load, the configured parameter should not be less than 20ms.
The maximum configurable delay is limited by the device's internal buffer (64, 32 or 16kB).
The following sections show recommended delay values in different audio formats.
MP3
PCM
Multiple Device Synchronisation
Multiple devices receiving the same RTP stream can be configured to play in sync by entering the same delay parameter.
Barix recommends to use broadcast or multicast together with synchronisation, otherwise a small inaccuracy (few milliseconds) might be caused by the network delivery to different locations.
Deliberate Delays
In some applications it is desired to artificially delay the audio. E.g. in a tunnel to eliminate the delay caused by the distance between the devices.
An artificial delay can be introduced by configuring the devices to different delay values. E.g. 100ms, 120ms, 140ms, 160ms, etc.
