Testing 4.0-dev-154, audio sync & dsp with multi room

[PaulWieland]

TLDR - digital signal processing works, but there are some multi room output sync issues that I'm trying to work out.

I'm currently testing with two endpoints, an Raspi 4 running Shairport Sync have a Raspi 4 and an Apple TV as end points. The aTV is plugged into a Marantz SR8001 via HDMI, driving KLF 20 speakers. The Raspi 4 is plugged into a Marantz SR5009 using analog audio and is driving a set of Bose 901s.

Of interest is that I am using Shairpoint-sync's built in DSP capability instead of the Bose 901 equalizer.

Build Version:
4.0-dev-154-g87c5888-AirPlay2-OpenSSL-Avahi-ALSA-soxr-convolution-metadata-dbus-sysconfdir:/etc

Digital Signal Processing always introduces lag, so I was expecting to hear additional lag with DSP enabled compared to when it is disabled, however the results aren't so clear.

I have tested stream from iOS, macos Music.app and from my aTV to the raspi.

No matter which client I use, or whether DSP is enabled or disabled the results are similar.

The Raspi lags slightly behind the the aTV in varying amounts. Stopping or starting, disconnecting and reconnecting affect the amount of sync that is lost. Sometimes the sync is very close, other times its too far off to listen to.

I am looking into ways I can objectively test the audio latency between the two endpoints, as its really hard to quantify the results just by listening.

[noelhibbard]

If I had to guess the sync issue is coming from the AVR. I have a few Roku TVs (Which have AirPlay 2 built in) and one is using HDMI ARC to connect to my AVR and it is always out of sync (behind) the other Roku TV which is using the built in speakers.

[PaulWieland]

But in my case the AVR which is using HDMI is ahead of the AVR which is using an analog signal...

[adamcstephens]

Maybe test the rpi using the HDMI or another sound output? Can you swap the two devices and see if it changes?

[jdtsmith]

Do you have subwoofers attached to your Marantz 5009? I found that my Denon (Marantz cousin) X4400H needs to be in "unprocessed stereo" mode to avoid ~500ms of latency, and that even Stereo + Subs (2.1) introduced notable lag. You can always hook up a cheap analog amp to check this.

Not very likely, but the other thing is to look at the nqptp logs and see if it is having issues negotiating the clock master (stop and run it as root as nqptp -vv).

As a last resort: I haven't yet test it, but @mikebrady did explore negative sync offsets and made some improvements there. There is less leeway for negative offset apparently in AP2, but some modest amount may be possible. I think this is still the operational config:

#  audio_backend_latency_offset = -4410; // Set this offset to compensate for a fixed delay in the audio back end. E.g. if the output device delays by 100 ms, set this to -4410.

[jdtsmith]

In terms of "what constitutes good sync", it's helpful to know that sound travels about one foot per millisecond, so a 30ms lag would occur if you were 30 ft closer to one set of speakers than the other. Probably can't aim for anything much better than this. From your description I bet you have 500ms of lag, and I'd guess the Marantz is to blame.

[PaulWieland]

I should mention that in my testing, I am sitting equidistant between the two receivers and speaker sets. Unfortunately the aTV doesn't have an analog output, so its quite difficult to remove the AVR's ADC processing delay from the equation. Plus - this is simulating my eventual setup where I have a mix of aTVs wherever I have a Television, with raspis + shairpoint where I just have audio.

[jdtsmith]

I was referring to hooking an amp in place of "a Marantz SR5009 using analog audio and is driving a set of Bose 901s." That's where your delay is yes?

[PaulWieland]

Yes it is, but it’s using analog inputs. The other marantz is hooked to the atv with hdmi. I would have expected the ADC process to add delay.

[jdtsmith]

I think even analog inputs are processed to separate out the signal to send to the sub in 2.1 setups. Could be worth a look. I turned that off and found instant improvement in lag. You could also rule out AP2 but using iTunes on a computer to send to the same pair of endpoints; is the same lag present? If so, can't be PTP, etc.

[mikebrady]

Thanks for looking into this, @PaulWieland.
The convolution is meant to be done in the processing chain before sync, so it should not introduce any audible delay to sync (unless it takes waaaaay too long).

Like @noelhibbard and @jdtsmith, I'd be suspicious that any amplifiers or headphones with a digital aspect to them would introduce some delay. As @jdtsmith suggests, an analog-only amp would not introduce a delay. Analog-only headphones are good too -- I can't tell you how many times I geeked out wearing two sets of headphones, one on each ear, checking for good sync. 🙂

[AlbanSeurat]

While shareport sync is in beta, I'll keep my setup with my code :) but once HomeKit is supported I might switch back to it.

[mikebrady]

Hi @AlbanSeurat, and firstly, congratulations on your player -- it is really interesting. I am not up to speed on Go, but it looks powerful and expressive. I haven't looked at your PTP stuff yet, but no doubt it will be instructive.

As regards the audio_backend_latency_offset_in_seconds setting, AFAIK it is working alright, for both positive and negative offsets. Certainly it was working a few months back. The audio_backend_latency_offset setting is deprecated.

If you have any hints to share about HomeKit, we'd love to hear them!

[AlbanSeurat]

Just found out this repository : https://github.com/xueming1988/test1/blob/1b6a732fda35f3423b12edabbaf4bc9389b41a98/middleware/private/mfi_airplay/MapleSDK/Sources/AirPlayReceiverServer.c

I am stuck at "POST /configure" after "/pair_setup", "/pair_add" .... I have not using the same "features" as airplay_receiver.py. For instance I receive from my iPhone and HomePod mini /pair_verify. I let you know once I have figure out what this configure endpoint does.

As for go, I've got 10+ years for cpp but I choose go as it is quicker to use - less boilerplate and easier to build.

[AlbanSeurat]

And for your point on PTP, I will probably at some point integrate hardware timestamp (like facebook does with their PTP implementation : https://github.com/facebookincubator/ptp)

[mikebrady]

One suggestion, @PaulWieland , might be to run Shairport Sync from the command line like this:

$ shairport-sync -vu --statistics

The statistics will indicate how close it calculates it is to exact synchronisation. (The user you are logged in as needs to be in the audio group.) For example:

        47.251140396 "rtsp.c:2063" Connection 1. Buffered Audio Stream Detected.
         1.683803185 "rtp.c:1318" Connection 1: Clock 91e17b32a58b0006 is now the new anchor clock and master clock. History: 5814.399018 milliseconds.
         0.002601920 "rtp.c:1397" Connection 1: NQPTP new master clock 91e17b32a58b0006.
         0.010556675 "player.c:1060" Connection 1: Lead time for first frame 1032713774: 0.313685 seconds.
         8.164516942 "player.c:2851" sync error ms, net sync ppm, all sync ppm,     packets, min DAC queue, min buffers, max buffers,  output fps
         0.003230900 "player.c:2851"          0.11,          0.0,          0.0,        1003,          6484,          46,          88,    44104.00
         8.008305042 "player.c:2851"          0.23,          2.8,          2.8,        2006,          6474,          86,          88,    44102.14
         7.995869711 "player.c:2851"          0.37,          2.8,          2.8,        3009,          6510,          86,          88,    44102.16
         8.009977563 "player.c:2851"          0.36,          0.0,          0.0,        4012,          6609,          87,          88,    44100.76
...