From 4b21fab859181311d878153c2961570a029efbf7 Mon Sep 17 00:00:00 2001 From: Mike Brady Date: Fri, 23 May 2014 19:39:06 +0100 Subject: [PATCH 1/2] Remove incorrect info about Pi latency. The different latency given for the built-in soundcard was incorrect and has been removed. It was caused by listing to the output using echo-cancelling headphones, which introduce a short delay of their own... --- README.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/README.md b/README.md index 4775344f..4f0d3062 100644 --- a/README.md +++ b/README.md @@ -70,8 +70,7 @@ If you run `$sudo make install`, `shairport` will be installed along with an ini Running Shairport 2.0 --------------------- -The `-L` setting is for the amount of latency -- the units are frames, with 44,100 frames to the second. Although 99,400 frames is slightly more than two seconds, it sounds good -- YMMV. For the built-in soundcard on the Raspberry Pi, a latency of about 98500 seems to be better. - +The `-L` setting is for the amount of latency -- the units are frames, with 44,100 frames to the second. Although 99,400 frames is slightly more than two seconds, it sounds good -- YMMV. Examples -------- The first is an example of a standard Ubuntu based laptop: From 852b91eb1e85371ebefb68a7de90137508b94739 Mon Sep 17 00:00:00 2001 From: Mike Brady Date: Fri, 23 May 2014 19:44:38 +0100 Subject: [PATCH 2/2] Shpelling --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 4f0d3062..8f671858 100644 --- a/README.md +++ b/README.md @@ -131,7 +131,7 @@ For reference, a drift of one second per day is approximately 11.57 ppm. Left un It's not unusual to have resend requests, late packets and even missing packets if some part of the connection to the Shairport device is over WiFi. -Miscelleanous +Miscellaneous ------------- Shairport 2.0 actively maintains synchronisation with the source. If synchronisation is lost -- say due to a very busy iTunes host or a very congested network -- then Shairport 2.0 will mute its output and resynchronise. The loss-of-sync threshold is a very conservative 30 ms -- i.e. the actual time and the expected time must differ by more than 30 ms to trigger a resynchronisation. Smaller disparities are corrected by insertions or deletions, as described above.