summaryrefslogtreecommitdiff
path: root/README.md
diff options
context:
space:
mode:
authorMike Brady <mikebrady@eircom.net>2017-09-25 17:10:46 +0100
committerGitHub <noreply@github.com>2017-09-25 17:10:46 +0100
commite2d37dbe34d1c711389e5a2e6144165be38d9d3e (patch)
treec05f636c2cb7e2531773b17cae9a84b4c05343ae /README.md
parent60ead5a3cd09749fc8bcfa2206318b21e4def3b2 (diff)
Update README.md
Diffstat (limited to 'README.md')
-rw-r--r--README.md2
1 files changed, 1 insertions, 1 deletions
diff --git a/README.md b/README.md
index 8665984..6720e26 100644
--- a/README.md
+++ b/README.md
@@ -20,7 +20,7 @@ For more about the motivation behind Shairport Sync, please see the wiki at http
Synchronisation, Latency, "Stuffing"
---------
-The AirPlay protocol uses an agreed *latency* – the time difference between the time represented by a sound sample's `timestamp` and the time it is actually played by the audio output device, typically a Digital to Audio Converter (DAC). The latency to be used is specified by the audio source when it negotiates with Shairport Sync. Most sources set a latency of two seconds. Recent versions of iTunes and forkedDaapd use a latency of just over 2.25 seconds. A latency of this length allows AirPlay players to correct for network delays, processing time variations and so on.
+The AirPlay protocol uses an agreed *latency* – the time difference, or delay, between the time represented by a sound sample's `timestamp` and the time it is actually played by the audio output device, typically a Digital to Audio Converter (DAC). The latency to be used is specified by the audio source when it negotiates with Shairport Sync. Most sources set a latency of two seconds. Recent versions of iTunes and forkedDaapd use a latency of just over 2.25 seconds. A latency of this length allows AirPlay players to correct for network delays, processing time variations and so on.
As mentioned previously, Shairport Sync implements full audio synchronisation when used with `alsa`, `sndio` or PulseAudio systems. This is done by monitoring the timestamps present in data coming from the audio source and the timing information from the audio system, e.g. `alsa`. To maintain the latency required for exact synchronisation, if the output device is running slow relative to the source, Shairport Sync will delete frames of audio to allow the device to keep up. If the output device is running fast, Shairport Sync will insert frames to keep time. The number of frames inserted or deleted is so small as to be almost inaudible on normal audio material. Frames are inserted or deleted as necessary at pseudorandom intervals. Alternatively, with `libsoxr` support, Shairport Sync can resample the audio feed to ensure the output device can keep up. This is less obtrusive than insertion and deletion but requires a good deal of processing power — most embedded devices probably can't support it. The process of insertion/deletion or resampling is rather inelegantly called “stuffing”.