nils/shairport-sync
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Big documentation reorganisation. Comments wlecome!

Browse Source
This commit is contained in:
Mike Brady
2022-07-25 14:44:57 +01:00
parent a94de485ac
commit e78a88b64a
17 changed files with 724 additions and 1002 deletions
Download Patch File Download Diff File Expand all files Collapse all files
ADVANCED TOPICS/Events.md
+12
View File
@@ -0,0 +1,12 @@
## Events
Shairport Sync can run programs just before it starts to play an audio stream and just after it finishes.
You specify them using the `sessioncontrol` group settings `run_this_before_play_begins` and `run_this_after_play_ends`.
This is to facilitate situations where something has to be done before and after playing, e.g. switching on an amplifier beforehand
and switching it off afterwards.
Set the `wait_for_completion` value to `"yes"` for Shairport Sync to wait until the respective commands have been completed before continuing.
Note that the full path to the programs must be specified, and script files will not be executed unless they are marked as executable
and have the appropriate shebang `#!/bin/...` as the first line. (This behaviour may be different from other Shairports.)
Shairport Sync can run a program whenever the volume is set or changed. You specify it using the `general` group setting `run_this_when_volume_changes`.
This is to facilitate situations where something has to be done when the volume changes, e.g. adjust an external mixer value. Set the `wait_for_completion` value to `"yes"` for Shairport Sync to wait until the command has been completed before continuing. Again, please note that the full path to the program must be specified, and script files will not be executed unless they are marked as executable and have the appropriate shebang `#!/bin/...` as the first line.
ADVANCED TOPICS/GetTheBest.md
+54
View File
@@ -0,0 +1,54 @@
# Get The Best from Shairport Sync
Shairport Sync was designed to run best on dedicated stand-alone low-power "headless" Linux/FreeBSD systems with ALSA as the audio system
and with a decent CD-quality Digital to Analog Converter (DAC).
## CPU Power and Memory
Computer power and memory requirements are modest -- a Raspberry Pi 2 or better, including the Pi Zero 2 W, is fine.
Unfortunately, while the original Raspberry Pi and the Pi Zero are powerful enough for AirPlay operation,
they are not really suitable for AirPlay 2 operation.
## CPU Clock
For best performance, Shairport Sync requires a stable and accurate system clock.
This is because the output DAC's output rate is normally determined by the system clock (some high-end USB streamers use their own built-in clocks).
If the clock drifts, or if its actual frequency is far from its nominal frequency, Shairport Sync will have to do more interpolation,
which inevitably must degrade the audio fidelity, even if it is very hard to hear.
Some very old laptops are known to have inaccurate clocks and and some embedded systems can suffer from temperature-related clock drift.
Recent Raspberry Pis seem to have very accurate clocks with low drift.
## Linux
The best kind of Linux for Shairport Sync is a "bare" Linux.
Raspberry Pi OS Lite, Debian Minimal Server, Ubuntu Server, Fedora Server and Arch Linux (Minimal Configuration) are good examples.
Shairport Sync also runs on "desktop" Linuxes such as Raspberry Pi OS with desktop, Debian with a desktop environment,
Ubuntu Desktop and Fedora Workstation.
Desktop Linuxes are less suitable because they almost always use a sound server like PulseAudio or PipeWire.
These can interfere with Shairport Sync, which needs direct and exclusive access to the audio hardware.
## DAC
A good Digital to Analog Converter (DAC) will have a huge influence on the quality of the audio.
Shairport Sync runs at 44,100 frames per second (FPS), each frame consisting of a pair of signed 16 bit linear samples, one for left and one for right.
Actually, Shairport Sync will take advantage to 24- or 32-bit DACs if available, and will run at 44,100 or 88,200, 176,400 or 352,800 FPS if necessary,
though there is no advantage to the higher rates. The 44,100 FPS rate was chosen to match the rate of AirPlay.
Good DACs are available at a very wide range of prices, from low-cost USB "Sound Cards" to very high-end HiFi streaming DACs.
In the Raspberry Pi world, many very good low-cost I2S DACs, some with integrated amplifiers, are available. Staying with the Raspberry Pi, the DAC powering the built-in audio jack is not great. It may be good enough for trying out Shairport Sync, but it has a very limited frequency response and can generate very large transients when it starts up. A separate DAC will transform the output quality.
**Note**
Make sure that the DAC is capable of 44,100 FPS operation -- this is really mandatory.
Most recent DACs are okay, but some older DACs will only run at 48,000 FPS or multiples of it, and Shairport Sync can not use them.
## Maximum Output Level
The `volume_max_db` setting allows you to reduce the maximum level of DAC output to prevent possible overloading of the amplifier or premplifier it feeds.
## Volume Range
The volume range is the difference (technically the ratio, expressed in dB) between the highest and lowest level of the volume control. Ideally, this should give the highest volume at the high end and a barely audible sound at the lowest level. Typical volume ranges are 60 dB to 75dB. If the range is much less than this, the difference between high and low volume won't seem large enough to the listener. If the range is much more, much of the low end of the volume control range will be inaudible. (The built-in DAC of the Raspberry Pi has this problem.) Use the `volume_range_db` setting to set the volume range. The built-in attenuator will be used to augment the volume range if necessary.
## Volume Control
Audio is sent at full volume in AirPlay and AirPlay 2 with separate information being sent to set the actual volume. This volume information can be used in three ways:
* It can be used to control a built-in attenuator. This is the default.
* It can be used to control a mixer built in to the DAC. To use a mixer, set the `mixer_control_name` in the configuration file to the name of the mixer you wish to use.
* It can be ignored by Shairport Sync. This may be appropriate when you want the volume to be controlled by just one control, typically an audio system's volume control knob or the volume control of a car radio. To make Shairport Sync ignore the volume information, set `ignore_volume_control` to `"yes"`.
* AirPlay volume changes cause events when an executable -- a program or executable script -- can be called. So, you could get Shairport Sync to ignore volume control information but call an executable to control an external volume control.
## Other Settings
* The `disable_standby_mode` setting can be used to prevent the DAC from transitioning between active and standby states, which can sometimes cause a faint popping noise. If activated, Shairport Sync sends frames of silence to keep the DAC busy, preventing it from entering standby mode.
* The `disable_synchronisation` setting can be used to prevent Shairport Sync from doing any interpolation whatever. Normally, this would lead to a problem when the DAC's buffer either overflowed or underflowed, but some very high-end streamers adjust the rate at which their DACs run to match the exact rate at which audio arrives, thus preventing underflow or overflow.
ADVANCED TOPICS/InitialConfiguration.md
+205
View File
@@ -0,0 +1,205 @@
# Initial Configuration
Shairport Sync reads settings from a configuration file at `/etc/shairport-sync.conf` (note that in FreeBSD it will be at `/usr/local/etc/shairport-sync.conf`). When you run `$sudo make install`, a sample configuration file is installed or updated at `/etc/shairport-sync.conf.sample` (`/usr/local/etc/shairport-sync.conf.sample` in FreeBSD). This contains all the setting groups and all the settings available, but they all are commented out (comments begin with `//`) so that default values are used. The file contains explanations of the settings, useful hints and suggestions. In addition, if the file doesn't already exist, a default configuration is installed, which should work in almost any system with a sound card.
Settings in the configuration file are grouped. For instance, there is a `general` group within which you can use the `name` tag to set the service name. Suppose you wanted to set the name of the service to `Front Room` and give the service the password `secret`, then you should do the following:
```
general =
{
name = "Front Room";
password = "secret";
// ... other general settings
};
```
The password setting is only valid for classic Shairport Sync.
(Remember, anything preceded by `//` is a comment and will have no effect on the setting of Shairport Sync.)
**Important:** You should *never* use an important password as the AirPlay password for a Shairport Sync player -- the password is stored in Shairport Sync's configuration file in plain text and is thus completely vulnerable.
No backend is specified here, so it will default to the `alsa` backend if more than one back end has been compiled. To route the output to PulseAudio, add:
```
output_backend = "pa";
```
to the `general` group.
The `alsa` group is used to specify properties of the output device. The most obvious setting is the name of the output device which you can set using the `output_device` tag.
The following `alsa` group settings are very important for maximum performance. If your audio device has a mixer that can be use to control the volume, then Shairport Sync can use it to give instant response to volume and mute commands and it can offload some work from the processor.
* The `mixer_control_name` tag allows you to specify the name of the mixer volume control.
* The `mixer_device` tag allows you specify where the mixer is. By default, the mixer is on the `output_device`, so you only need to use the `mixer_device` tag if the mixer is elsewhere. This can happen if you specify a *device* rather than a *card* with the `output_device` tag, because normally a mixer is associated with a *card* rather than a device. Suppose you wish to use the output device `5` of card `hw:0` and the mixer volume-control named `PCM`:
```
alsa =
{
output_device = "hw:0,5";
mixer_device = "hw:0";
mixer_control_name = "PCM";
// ... other alsa settings
};
```
The `pa` group is used to specify settings relevant to the PulseAudio backend. You can set the "Application Name" that will appear in the "Sound" control panel.
Note: Shairport Sync can take configuration settings from command line options. This is mainly for backward compatibility, but sometimes still useful. For normal use, it is strongly recommended that you use the configuration file method.
**Raspberry Pi**
The Raspberry Pi Models A and B have a built-in audio DAC that is connected to the device's headphone jack. Apart from a loud click when used for the first time after power-up, it is now quite adequate for casual listening.
To get the benefits of improvements in the Pi's software and firmware, you should update to the Raspian release of October 2018 or later, as a number of improvements have been made to the built-in DAC.
Do the usual update and upgrade:
```
# apt update
# apt upgrade
```
To make Shairport Sync output to the built-in audio DAC and use its hardware mixer, in the `alsa` section of the configuration file, set the output device and mixer as follows:
```
alsa =
{
output_device = "hw:0"; // the name of the alsa output device. Use "alsamixer" or "aplay" to find out the names of devices, mixers, etc.
mixer_control_name = "PCM"; // the name of the mixer to use to adjust output volume. If not specified, volume in adjusted in software.
// ... other alsa settings
```
(Remember to uncomment the lines by removing the `//` at the start of each.) When these changes have been made, reboot the machine.
A problem with the built-in DAC that it declares itself to have a very large mixer volume control range – all the way from -102.38dB up to +4dB, a range of 106.38 dB. In reality, only the top 60 dB of it is in any way usable. To help get the most from it, consider using the `volume_range_db` setting in the `general` group to instruct Shairport Sync to use the top of the DAC mixer's declared range. For example, if you set the `volume_range_db` figure to 60, the top 60 dB of the range will the used. With this setting on the Raspberry Pi, maximum volume will be +4dB and minimum volume will be -56dB, below which muting will occur.
From a user's point of view, the effect of using this setting is to move the minimum usable volume all the way down to the bottom of the user's volume control, rather than have the minimum usable volume concentrated very close to the maximum volume.
*Command Line Arguments*
As previously mentioned, you can use command line arguments to provide settings to Shairport Sync as before, though newer settings will only be available via the configuration file. For full information, please read the Shairport Sync `man` page, also available at http://htmlpreview.github.io/?https://github.com/mikebrady/shairport-sync/blob/master/man/shairport-sync.html.
Apart from the following options, all command line options can be replaced by settings in the configuration file. Here is a brief description of command line options that are not replicated by settings in the settings file.
* The `-c` option allows you to specify the location of the configuration file.
* The `-V` option gives you version information about Shairport Sync and then quits.
* The `-d` option causes Shairport Sync to properly daemonise itself, that is, to run in the background. You may need sudo privileges for this.
* The `-k` option causes Shairport Sync to kill an existing Shairport Sync daemon. You may need to have sudo privileges for this.
The System V init script at `/etc/init.d/shairport-sync` has a bare minimum :
`-d`. Basically all it does is put the program in daemon mode. The program will read its settings from the configuration file.
Examples
--------
Here are some examples of complete configuration files.
```
general = {
name = "Joe's Stereo";
};
alsa = {
output_device = "hw:0";
};
```
This gives the service a particular name — "Joe's Stereo" and specifies that audio device `hw:0` be used.
For best results with the `alsa` backend — including getting true mute and instant response to volume control and pause commands — you should access the hardware volume controls. Use `amixer` or `alsamixer` or similar to discover the name of the mixer control to be used as the `mixer_control_name`.
Here is an example for for a Raspberry Pi using its internal soundcard — device hw:0 — that drives the headphone jack:
```
general = {
name = "Mike's Boombox";
};
alsa = {
output_device = "hw:0";
mixer_control_name = "PCM";
};
```
Here is an example of driving a Topping TP30 Digital Amplifier, which has an integrated USB DAC and which is connected as audio device `hw:1`:
```
general = {
name = "Kitchen";
};
alsa = {
output_device = "hw:1";
mixer_control_name = "PCM";
};
```
For a cheapo "3D Sound" USB card (Stereo output and input only) on a Raspberry Pi:
```
general = {
name = "Front Room";
};
alsa = {
output_device = "hw:1";
mixer_control_name = "Speaker";
};
```
For a first generation Griffin iMic on a Raspberry Pi:
```
general = {
name = "Attic";
};
alsa = {
output_device = "hw:1";
mixer_control_name = "PCM";
};
```
For an NSLU2, which has no internal sound card, there appears to be a bug in ALSA — you can not specify a device other than "default". Thus:
On an NSLU2, to drive a first generation Griffin iMic:
```
general = {
name = "Den";
};
alsa = {
mixer_control_name = "PCM";
};
```
On an NSLU2, to drive the "3D Sound" USB card:
```
general = {
name = "TV Room";
};
alsa = {
mixer_control_name = "Speaker";
};
```
Finally, here is an example of using the PulseAudio backend:
```
general = {
name = "Zoe's Computer";
output_backend = "pa";
};
```
Latency
-------
Latency is the exact time from a sound signal's original timestamp until that signal actually "appears" on the output of the audio output device, usually a Digital to Audio Converter (DAC), irrespective of any internal delays, processing times, etc. in the computer.
Shairport Sync uses latencies supplied by the source, typically either 2 seconds or just over 2.25 seconds. You shouldn't need to change them.
Problems can arise when you are trying to synchronise with speaker systems — typically surround-sound home theatre systems — that have their own inherent delays. You can compensate for an inherent delay using the appropriate backend (typically `alsa`) `audio_backend_latency_offset_in_seconds`. Set this offset (in frames) to compensate for a fixed delay in the audio back end; for example, if the output device delays by 100 ms, set this to -0.1.
Resynchronisation
-------------
Shairport Sync actively maintains synchronisation with the source.
If synchronisation is lost — say due to a busy source or a congested network — Shairport Sync will mute its output and resynchronise. The loss-of-sync threshold is a very conservative 0.050 seconds — i.e. the actual time and the expected time must differ by more than 50 ms to trigger a resynchronisation. Smaller disparities are corrected by insertions or deletions, as described above.
* You can vary the resync threshold, or turn resync off completely, with the `general` `resync_threshold_in_seconds` setting.
Tolerance
---------
Playback synchronisation is allowed to wander — to "drift" — a small amount before attempting to correct it. The default is 0.002 seconds, i.e. 2 ms. The smaller the tolerance, the more likely it is that overcorrection will occur. Overcorrection is when more corrections (insertions and deletions) are made than are strictly necessary to keep the stream in sync. Use the `statistics` setting to monitor correction levels. Corrections should not greatly exceed net corrections.
* You can vary the tolerance with the `general` `drift_tolerance_in_seconds` setting.
ADVANCED TOPICS/Metadata.md
+19
View File
@@ -0,0 +1,19 @@
# Metadata
Shairport Sync can deliver metadata supplied by the source, such as Album Name, Artist Name, Cover Art, etc.
through a pipe or UDP socket to a recipient application program — see https://github.com/mikebrady/shairport-sync-metadata-reader for a sample recipient.
Sources that supply metadata include iTunes and the Music app in macOS and iOS.
## Metadata over UDP**
As an alternative to sending metadata to a pipe, the `socket_address` and `socket_port` tags may be set in the metadata group to cause Shairport Sync
to broadcast UDP packets containing the track metadata.
The advantage of UDP is that packets can be sent to a single listener or, if a multicast address is used, to multiple listeners.
It also allows metadata to be routed to a different host. However UDP has a maximum packet size of about 65000 bytes; while large enough for most data, Cover Art will often exceed this value. Any metadata exceeding this limit will not be sent over the socket interface. The maximum packet size may be set with the `socket_msglength` tag to any value between 500 and 65000 to control this - lower values may be used to ensure that each UDP packet is sent in a single network frame. The default is 500. Other than this restriction, metadata sent over the socket interface is identical to metadata sent over the pipe interface.
The UDP metadata format is very simple - the first four bytes are the metadata *type*, and the next four bytes are the metadata *code*
(both are sent in network byte order - see https://github.com/mikebrady/shairport-sync-metadata-reader for a definition of those terms).
The remaining bytes of the packet, if any, make up the raw value of the metadata.
ADVANCED TOPICS/README.md
+17
View File
@@ -0,0 +1,17 @@
# Advanced Topics
Here you will find links to some of the more advanced features and things you can do with Shairport Sync.
* [Finish setting up](InitialConfiguration.md).
* [Get the best](GetTheBest.md) from Shairport Sync.
* [Metadata](Metadata.md).
* [Events](Events.md).
* [Update Shairport Sync](https://github.com/mikebrady/shairport-sync/blob/development/UPDATING.md) in place.
* The configuration file -- which contains lots of documentation -- on your system. By default, the sample configuration file is
placed at `/etc/shairport-sync.conf.sample` (`/usr/local/etc/shairport-sync.conf.sample` on FreeBSD).
You can also view it online [here](https://github.com/mikebrady/shairport-sync/blob/master/scripts/shairport-sync.conf).
* [Statistics](Statistics.md).
* Setting up an [MQTT](https://github.com/mikebrady/shairport-sync/blob/development/MQTT.md) system.
* Jack Audio.
* [Digital Signal Processing](https://github.com/mikebrady/shairport-sync/wiki/Digital-Signal-Processing-with-Shairport-Sync).
* [Build Configuration Flags](https://github.com/mikebrady/shairport-sync/blob/development/CONFIGURATION%20FLAGS.md).
* [Car Installation](https://github.com/mikebrady/shairport-sync/blob/development/CAR%20INSTALL.md)
– build an isolated WiFi network containing a Shairport Sync player on a Raspberry Pi. Suitable for a car radio with an `aux` input or for the stereo in that broadband-free holiday cottage.
ADVANCED TOPICS/Statistics.md
+118
View File
@@ -0,0 +1,118 @@
# Statistics
If you set the `statistics` setting in the `diagnostics` section of the configuration file to `"YES"`, some statistics will be logged at regular intervals. The items logged will depend on the type of stream being processed: AirPlay 1, AirPlay 2 Buffered Audio or AirPlay 2 Realtime Audio. If the `log_verbosity` is set to 1, 2 or 3, additional items will be logged.
From an audio enthusiast's point of view, the most important figure is possibly the `All Sync PPM` figure. This is the total amount of interpolation needed by Shairport Sync to keep the audio stream in sync. The number represents is the ratio of frames added and removed from the audio stream relative to all the frames output in the last interval, expressed in parts per million (PPM). For reference, adding or removing one frame per second into a 44,100 frames per second stream is ± 22.68 PPM. The lower this number number is, the higher the fidelity of the audio signal passed to the output device. On a well sorted system, this figure can be 0.0 for considerable periods, but it can't really be zero forever unless the output device is adapting to the true data rate (some very high-end streamers seem to do so). You may also find that the number might be higher at the start while the system settles down.
The second most important figure is possibly the `Sync Error ms`. This is the average synchronisation error in milliseconds in the last interval. Ideally it should be 0.0. By default, Shairport Sync has a tolerance of a sync error of ± 2.0 milliseconds without triggering interpolation.
Two other interesting measurements of the output rate may be available -- `Output FPS (r)` and `Output FPS (c)`, where `(r)` means "raw" and the `(c)` means "corrected".
The "raw" figure is the rate at which the output device (typically a DAC) accepts data measured relative to the computer's own system clock (specifically the `CLOCK_MONOTONIC_RAW` clock). The accuracy of the number depends on the accuracy of the clock, which will typically be accurate to within anything from 20 to 100 ppm.
The "corrected" figure is the rate at which the output device accepts data relative to the computer's network-time-disciplined clock (specifically the `CLOCK_MONOTONIC` clock). This clock is normally adjusted ("disciplined") to keep time with network time and should be accurate to with a few tens of milliseconds over a _long_ period. So (1) if you could run a play session for a long period -- say a day -- and (2) if network time synchronisation is enabled and (3) if the network connection to the network time service is fast and stable, then you should get an accurate absolute measure of exact frame rate of the output device. If your internet connection is not good, the corrected figure will be very inaccurate indeed.
Here is a brief description of the figures that might be provided.
##### Sync Error ms
Average playback synchronisation error in milliseconds in the last interval. By default, Shairport Sync will allow a sync error of ± 2.0 milliseconds without any interpolation. Positive means late, negative means early.
##### Net Sync PPM
This is the total amount of interpolation done by Shairport Sync to keep the audio stream in sync. The number represents is the total number of frames added and removed from the audio stream, expressed in parts per million (PPM) in the last interval. For reference, adding or removing one frame per second into a 44,100 frames per second stream is 22.68 ppm.
##### All Sync PPM
This is the net amount of interpolation done by Shairport Sync to keep the audio stream in sync. The number represents is the number of frames added plus the number removed from the audio stream, expressed in parts per million (PPM) in the last interval. The magnitude of this should be the same as the `net sync ppm'. If it is much larger it means that Shairport Sync is overcorrecting for sync errors -- try increasing the drift tolerance to reduce it.
##### Packets
This is the number of packets of audio frames received since the start of the session. A packet normally contains 352 ± 1 audio frames.
##### Missing
This is the number of packets of audio frames that were expected but not received in the last interval. It should be zero, and if not it usually indicates a significant problem with the network. AirPlay 1 and AirPlay 2 Realtime Streams only.
##### Late
This is the number of packets of audio frames that were received late -- but still in time to be used -- in the last interval. AirPlay 1 and AirPlay 2 Realtime Streams only.
##### Too Late
This is the number of packets of audio frames that were received too late to be used in the last interval. It is possible that these packets were already received, so those frames might not actually be missing when the time comes to play them. AirPlay 1 and AirPlay 2 Realtime Streams only.
##### Resend Reqs
This is the number of times Shairport Sync requests the resending of missing frames. Requests can be for one or more frames. AirPlay 1 and AirPlay 2 Realtime Streams only.
##### Min DAC Queue
The is the smallest number of frames of audio in the DAC's hardware queue. If it goes too low, the DAC may begin to underrun.
##### Min Buffers
The is the smallest number of packets of audio in the queue to be processed in the last interval. It is related to the overall latency in AirPlay 1 and AirPlay 2 Realtime Streams. If it comes close to zero it's often a sign that the network is poor.
##### Max Buffers
The is the largest number of packets of audio in the queue to be processed in the last interval.
##### Min Buffer Size
The is smallest remaining number of bytes in the Buffered Audio buffer in the last interval. It can legitimately be zero when a track ends or begins. If it reaches zero while a track is playing, it means that audio data is not arriving at Shairport Sync quickly enough and may indicate network problems. AirPlay 2 Buffered Audio streams only.
##### Nominal FPS
This is the rate specified in the AirPlay stream itself. AirPlay 1 only.
##### Received FPS
This is the rate at which frames are received from the network averaged since the start of the play session. AirPlay 1 only.
##### Output FPS (r)
Output rate measured relative to the computer system's clock since the start of the play session. See above for a discussion.
##### Output FPS (c)
Output rate measured relative to the network-clock-disciplined computer system's clock since the start of the play session. See above for a discussion.
##### Source Drift PPM
This is a measure of the difference between the source clock and Shairport Sync's clock expressed in parts per million. Only valid when 10 or more drift samples have been received. AirPlay 1 only.
##### Drift Samples
This is the number drift samples have been accepted for calculating the source drift. AirPlay 1 only.
#### Example
The following example is of an AirPlay 2 Buffered Audio Stream from a HomePod mini to a WiFi-connected Raspberry Pi 3 equipped with a Pimoroni "Audio DAC SHIM (Line-Out)" with `log_verbosity` set to `1` after 3 hours and 37 minutes of operation. The audio is from a radio station accessed through Apple Music:
```
5.292055362 "rtsp.c:3112" Connection 1. AP2 Buffered Audio Stream.
1.382815677 "player.c:2650" Connection 1: Playback Started -- AirPlay 2 Buffered.
7.899808955 "player.c:2491" Sync Error ms | Net Sync PPM | All Sync PPM | Min DAC Queue | Min Buffer Size | Output FPS (r) | Output FPS (c)
...
8.014025361 "player.c:2491" -1.69 2.8 2.8 7341 198k 44100.04 44100.35
7.992082237 "player.c:2491" -1.70 2.8 2.8 7332 188k 44100.04 44100.34
8.015987549 "player.c:2491" -1.68 0.0 0.0 7334 186k 44100.04 44100.35
8.010537393 "player.c:2491" -1.68 2.8 2.8 7335 187k 44100.04 44100.36
7.993940934 "player.c:2491" -1.85 0.0 0.0 7329 198k 44100.04 44100.37
8.015796195 "player.c:2491" -1.87 5.7 5.7 7325 194k 44100.04 44100.37
8.021665934 "player.c:2491" -1.92 5.7 5.7 7329 190k 44100.04 44100.37
7.990409477 "player.c:2491" -1.85 2.8 2.8 7347 201k 44100.04 44100.37
8.001858278 "player.c:2491" -1.96 17.0 17.0 7332 204k 44100.04 44100.37
8.007150986 "player.c:2491" -1.89 2.8 2.8 7327 195k 44100.04 44100.36
7.998612862 "player.c:2491" -1.87 2.8 2.8 7317 199k 44100.04 44100.36
8.020592653 "player.c:2491" -1.89 11.3 11.3 7323 203k 44100.04 44100.35
8.003245674 "player.c:2491" -1.89 8.5 8.5 7325 198k 44100.04 44100.35
7.990874789 "player.c:2491" -1.98 19.8 19.8 7103 197k 44100.04 44100.34
8.010600257 "player.c:2491" -1.85 2.8 2.8 7327 187k 44100.04 44100.33
8.004573122 "player.c:2491" -1.89 5.7 5.7 7327 187k 44100.04 44100.33
8.012853278 "player.c:2491" -1.89 5.7 5.7 7326 190k 44100.04 44100.32
8.005596664 "player.c:2491" -1.95 22.7 22.7 7322 165k 44100.04 44100.31
8.019198695 "player.c:2491" -1.85 5.7 5.7 7333 166k 44100.04 44100.31
7.999363382 "player.c:2491" -1.79 2.8 2.8 7349 153k 44100.04 44100.30
7.990332549 "player.c:2491" -1.87 5.7 5.7 7328 155k 44100.04 44100.29
8.012287445 "player.c:2491" -1.84 2.8 2.8 7352 185k 44100.04 44100.28
7.998929528 "player.c:2491" -1.94 14.2 14.2 7331 171k 44100.04 44100.28
8.008170622 "player.c:2491" -1.88 5.7 5.7 7327 188k 44100.04 44100.27
8.012935257 "player.c:2491" -1.87 19.8 19.8 7270 205k 44100.04 44100.26
8.006337966 "player.c:2491" -1.86 0.0 0.0 7334 199k 44100.04 44100.25
8.004206612 "player.c:2491" -1.76 2.8 2.8 7331 204k 44100.04 44100.25
7.998495257 "player.c:2491" -1.82 2.8 2.8 7329 204k 44100.04 44100.24
8.016859059 "player.c:2491" -1.88 2.8 2.8 7335 201k 44100.04 44100.23
7.993529320 "player.c:2491" -1.92 14.2 14.2 7329 205k 44100.04 44100.22
8.021956820 "player.c:2491" -1.96 11.3 11.3 7322 206k 44100.04 44100.21
8.006401820 "player.c:2491" -1.93 11.3 11.3 7322 199k 44100.04 44100.21
8.001469111 "player.c:2491" -1.89 5.7 5.7 7336 204k 44100.04 44100.20
7.995194320 "player.c:2491" -1.86 5.7 5.7 7330 202k 44100.04 44100.19
8.017805206 "player.c:2491" -1.99 22.7 22.7 7322 201k 44100.04 44100.18
7.995541038 "player.c:2491" -1.95 22.7 22.7 7331 203k 44100.04 44100.18
8.011463643 "player.c:2491" -1.87 0.0 0.0 7331 207k 44100.04 44100.17
7.995941403 "player.c:2491" -1.85 2.8 2.8 7331 206k 44100.04 44100.16
8.013330570 "player.c:2491" -1.71 2.8 2.8 7344 212k 44100.04 44100.15
8.012214580 "player.c:2491" -1.82 0.0 0.0 7333 203k 44100.04 44100.15
7.998585049 "player.c:2491" -1.85 8.5 8.5 7332 207k 44100.04 44100.14
8.023448799 "player.c:2491" -1.86 5.7 5.7 7328 206k 44100.04 44100.13
7.984586612 "player.c:2491" -1.87 8.5 8.5 7277 205k 44100.04 44100.12
8.017339372 "player.c:2491" -1.91 17.0 17.0 7327 207k 44100.04 44100.12
8.007090309 "player.c:2491" -1.94 17.0 17.0 7286 199k 44100.04 44100.11
8.007894164 "player.c:2491" -1.87 2.8 2.8 7334 201k 44100.04 44100.10
7.991787497 "player.c:2491" -1.89 2.8 2.8 7327 194k 44100.04 44100.09
8.019011611 "player.c:2491" -1.94 5.7 5.7 7323 185k 44100.04 44100.09
7.994695362 "player.c:2491" -1.99 14.2 14.2 7321 199k 44100.04 44100.08
8.010284632 "player.c:2491" -1.93 11.3 11.3 7325 191k 44100.04 44100.07
8.011451612 "player.c:2491" -1.87 8.5 8.5 7329 156k 44100.04 44100.09
7.993112549 "player.c:2491" -1.84 2.8 2.8 7330 150k 44100.04 44100.13
8.004971455 "player.c:2491" -1.77 11.3 11.3 7325 157k 44100.04 44100.16
8.010517133 "player.c:2491" -1.85 0.0 0.0 7322 182k 44100.04 44100.19
8.005598851 "player.c:2491" -2.00 39.7 39.7 7207 180k 44100.04 44100.22
8.006777965 "player.c:2491" -1.99 39.7 39.7 7320 183k 44100.04 44100.24
7.115508696 "player.c:1643" Connection 1: Playback Stopped. Total playing time 03:37:20. Output: 44100.04 (raw), 44100.24 (corrected) frames per second.
```
For reference, a drift of one second per day is approximately 11.57 ppm. Left uncorrected, even a drift this small between two audio outputs will be audible after a short time.