[Problem]: Large negative (i.e. early) sync error of (-> short audio glitch)

[microfx]

What happened?

I have installed everything new and it works pretty good so far. I just had one short audio glitch – which seems to be clock related. I am listening Spotify and send it over Airplay 2 on macOS Sonoma 14.1 (23B73) on to my Raspberry PI

Any idea how to prevent this in the future?

Relevant log output

Jan 16 11:10:10 shairport-sync[1203]: 0.014760759 "audio_jack.c:173" Average maximum JACK latency across all ports: 384 
Jan 16 11:10:10 shairport-sync[1203]: 0.000357185 "audio_jack.c:173" Average maximum JACK latency across all ports: 384 
Jan 16 12:52:23 shairport-sync[1203]: 6132.743654586 "rtsp.c:2902" Connection 3: AP2 PTP connection from 192.168.0.77:62750 ("MacBook") to self at 192.168.0.182:7000. 
Jan 16 12:52:23 shairport-sync[1203]: 0.801100851 "rtsp.c:3292" Connection 3. AP2 Realtime Audio Stream.  
Jan 16 12:52:24 shairport-sync[1203]: 0.346020963 "rtp.c:1738" AP2 Realtime Clock receiver initialised. 
Jan 16 12:58:20 shairport-sync[1203]: 356.531168602 "rtsp.c:3292" Connection 3. AP2 Realtime Audio Stream. 
Jan 16 13:43:20 shairport-sync[1203]: 2699.273506169 "rtsp.c:3292" Connection 3. AP2 Realtime Audio Stream. 
Jan 16 13:59:53 shairport-sync[1203]: 993.511872186 "rtsp.c:3292" Connection 3. AP2 Realtime Audio Stream. 
Jan 16 14:16:28 shairport-sync[1203]: 994.759924907 "player.c:2906" Large negative (i.e. early) sync error of -42188 frames (-0.956644 seconds), at frame: 2684720285. 
Jan 16 14:16:28 shairport-sync[1203]: 0.006985944 "player.c:2906" Large negative (i.e. early) sync error of -19550 frames (-0.443311 seconds), at frame: 2684714668. 
Jan 16 14:16:28 shairport-sync[1203]: 0.006522389 "player.c:2906" Large negative (i.e. early) sync error of -7811 frames (-0.177120 seconds), at frame: 2684719244. 

System Information.

OS: Raspbian GNU/Linux 11 (bullseye) aarch64 
Kernel: Linux 6.1.69-v8-16k+ 
Raspberry Pi 5 8 GB on microsdcard with Blokes PiSound

Configuration Information.

Linux 6.1.69-v8-16k+ #1711 SMP PREEMPT Thu Dec 21 14:32:15 GMT 2023 aarch64 GNU/Linux

4.3.2-2-g165431a8-AirPlay2-smi10-alac-OpenSSL-Avahi-jack-soxr-metadata-mqtt-sysconfdir:/etc

general =
{
    interpolation = "soxr"; // aka "stuffing". Default is "auto". Alternatives are "basic" or "soxr". Choose "soxr" only if you have a reasonably fast processor and Shairport Sync has been built with "soxr" support.
    output_backend = "jack"; // Run "shairport-sync -h" to get a list of all output_backends, e.g. "alsa", "pipe", "stdout". The default is the first one.
    volume_control_profile = "dasl_tapered" ; // use this advanced setting to specify how the airplay volume is transferred to the mixer volume.
//  audio_backend_buffer_desired_length = 9845;
        audio_backend_buffer_desired_length_in_seconds = 1; // If set too small, buffer underflow occurs on low-powered machines.
    dbus_service_bus = "system"; // The Shairport Sync dbus interface, if selected at compilation, will appear
    audio_backend_buffer_interpolation_threshold_in_seconds = 0.075; // Advanced feature. If the buffer size drops below this, stop using time-consuming interpolation like soxr to avoid dropouts due to underrun.
    default_airplay_volume = -30.0;
    high_threshold_airplay_volume = -30.0;
    high_volume_idle_timeout_in_minutes = 10;
};

sessioncontrol =
{
    run_this_before_entering_active_state = "/bin/bash /SCRIPTS/webhook_audio_start.sh"; // make sure the application has executable permission. If it's a script, include the shebang (#!/bin/...) on the first line
    run_this_after_exiting_active_state = "/bin/bash /SCRIPTS/webhook_audio_stop.sh"; // make sure the application has executable permission. If it's a script, include the shebang (#!/bin/...) on the first line
    active_state_timeout = 420.0; // wait for this number of seconds after play ends before leaving the active state, unless another play session begins.
    allow_session_interruption = "yes"; // set to "yes" to allow another device to interrupt Shairport Sync while it's playing from an existing audio source
    session_timeout = 900; // wait for this number of seconds after a source disappears before terminating the session and becoming available again.
};

alsa =
{
    output_device = "default"; // the name of the alsa output device. Use "shairport-sync -h" to discover the names of ALSA hardware devices. Use "alsamixer" or "aplay" to find out the names of devices, mixers, etc.
};

jack =
{
    client_name = "shairport-sync"; // Set this to the name of the client that should appear in "Connections" when Shairport Sync is active.
    autoconnect_pattern = "system:playback_[12]"; // Set this to a POSIX regular expression pattern that describes the ports you would like to connect to
        soxr_resample_quality = "very high"; // Enable resampling by setting this to "very high", "high", "medium", "low" or "quick"
};

dsp =
{
    loudness = "yes";                      // Set this to "yes" to activate the loudness filter
    loudness_reference_volume_db = -18.0; // Above this level the filter will have no effect anymore. Below this level it will gradually boost the low frequencies.

};

metadata =
{
};

diagnostics =
{
    log_verbosity = 1; // "0" means no debug verbosity, "3" is most verbose.
    log_output_to = "syslog";
};

PulseAudio or PipeWire installed?

• [X] Check if your system uses a Sound Server.

How did you install Shairport Sync?

Built from source

Check previous issues

• [X] Confirm

[mikebrady]

Thanks for the post. There are quite a few settings here, and one way to get to the bottom of the problem would be to absolutely minimise them and see if the problem recurs or disappears.

There is also the possibility that the glitch is caused by the Spotify stream itself -- this could be checked by playing to the Mac itself at the same time. If the audio from the two outputs remains in sync through that discontinuity, then it [seems to me that it] is a problem with the stream.

[crothhh]

Hi there,

I've run into the same problem on a Raspberry Pi Zero with WiFi (not a Zero 2 as recommended, I know). It worked with a standard airplay setup, but if I install a Airplay2 setup I doesn't play but generates these errors. Everything is up-to-date and installed brand new - fresh install of a new Raspbian Image, everything upgraded, followed the "offical" installation guide... no clue how to solve it (apart from setting high thresholds).

Playing on an HomePod while trying to play on my raspberry lewt's the raspberry stay silent, trying to use the raspberry alone doesn't change anything. But I've to add, my audio is dead - maybe the installation has broken something, I come back to you after I tried a few things

[mikebrady]

Thanks @crothhh. Yes, unfortunately the original Pi Zero does not have enough CPU power to keep up with the requirements of AirPlay 2 in Shairport Sync. Can I check with @microfx which model of the Pi you are using please?

[crothhh]

Hi there,

just wanting to add: I'm running shairport-sync on three Raspberry Pi Zeros with Adafruit MAX98357 I2S Class-D Mono Amp - as they are Zero 1 and not recommended I guess every error I run into is my very own fault. So far - however - they are working. I set them up again and they work like a charm - although I've set the threshold to zero to disable synconization in two raspberries. The one still syncronizing with my homepods is also working well. Not sure how it will play out in the long run.

Have a good day!

[klemensn]

I see the same sync errors on an OpenBSD/amd64 7.4-current notebook with all of 3.3.9 (Classic), 4.3.2 (Classic) and 4.3.2 (Airplay 2) against an iPad (can't tell which model).

The issue is sporadic and occurs upon first play -- either the source connects and plays fine, after which pause/resume also works, or it does not upon first play, at which point further reconnection attempts won't help unless I restart shairport-sync.

Another OpenBSD user reported that so far they've never been observing this kind of issue on their notebook running 3.3.9 (Classic) against an iPhone.

Given the non-deterministic nature, I have not looked further into this issue.

[github-actions[bot]]

This issue has been inactive for 28 days so will be closed 7 days from now. To prevent this, please remove the "stale" label or post a comment.