search

mikebrady / shairport-sync

AirPlay and AirPlay 2 audio player
Other
7.2k stars 571 forks source link

Digital audio output has glitches #1278

Closed manrand closed 2 years ago

manrand commented 3 years ago

Hi,

I'm using shairport-sync within Volumio (but I've tried also with Moodeaudio), and I'm experiencing audio glitches on the digital output. I've read most if not all discussions about related problems and have tried with disable_synchronisation = yes as well as other parameters, but I always get issues.

Has anybody been able setup a RPi Zero W shairport-sync over Optical Audio out without audio glitches? and if so, what am I doing wrong?

I'm sharing my config to see if somebody could help me: HW:

SW:

diagnostics = { log_verbosity = 1; statistics = "yes"; disable_resend_requests = "yes"; };

alsa = { output_device = "plughw:2,0"; disable_synchronization = "yes"; };

sessioncontrol = { allow_session_interruption = "yes"; run_this_before_play_begins= "/usr/local/bin/volumio startairplayplayback"; run_this_after_play_ends = "/usr/local/bin/volumio stopairplayplayback"; run_this_before_entering_active_state="/usr/local/bin/volumio airplayactive"; run_this_after_exiting_active_state="/usr/local/bin/volumio airplayinactive"; };

metadata = { enabled = "yes"; include_cover_art = "no"; //pipe_name = "/tmp/shairport-sync-metadata"; //pipe_timeout = 5000; socket_address = "127.0.0.1"; socket_port = 5555; };


Others issues I noticed (which may or may not be related)
- I cannot send Mac system audio, for instance selecting "Volumio" as output device on the system audio panel. Only way to play audio from Mac seems to be from iTunes
- Moodeaudio works even worse than Volumio, as it essentially does 1 sec on, 1 sec off or something

Other remarks:
- the optical output is properly setup because it works just fine: Volumio can play other sources, it is just AirPlay that has audio glitches
- I believe the audio glitches may be harder to hear if using analog output, although I have no way to confirm. The reason I make this hypothesis is that many people get it working, but most of them are using analog out, and the output filters/capacitors may be hiding the glitches.
- with `disable_synchronization = yes` it seems to improve, but I do get some glitches further down, like if it skipped part of a song
- The optical output is connected to an old HiFi system

From the logs it appears that there is packet loss (resend), empty frames, and drift, but that seems like a lot of issues for a default config, while many people appear to have succeeded using the RPi Zero W for Airplay with `shairport-sync` (regardless of distro)

Other weird things (to me):
1)

volumio shairport-sync[14817]: 1.359341298 "audio_alsa.c:530" alsa: output format chosen is "S32". volumio shairport-sync[14817]: 0.003040983 "audio_alsa.c:570" alsa: output speed chosen is 44100.


2) HW config is different between web radio playback and `shairport-sync`
- web radio playback

volumio@volumio:~$ cat /proc/asound/sndrpihifiberry/pcm0p/sub0/hw_params access: RW_INTERLEAVED format: S24_LE subformat: STD channels: 2 rate: 44100 (44100/1) period_size: 4410 buffer_size: 22050

volumio@volumio:~$ cat /proc/asound/sndrpihifiberry/pcm0p/sub0/sw_params tstamp_mode: NONE period_step: 1 avail_min: 4410 start_threshold: 17640 stop_threshold: 22050 silence_threshold: 0 silence_size: 0 boundary: 1445068800


- `shairport-sync` AirPlay playback:

volumio@volumio:~# cat /proc/asound/sndrpihifiberry/pcm0p/sub0/hw_params access: MMAP_INTERLEAVED format: S24_LE subformat: STD channels: 2 rate: 44100 (44100/1) period_size: 256 buffer_size: 65536

volumio@volumio:~# cat /proc/asound/sndrpihifiberry/pcm0p/sub0/sw_params
tstamp_mode: ENABLE period_step: 1 avail_min: 256 start_threshold: 1 stop_threshold: 65536 silence_threshold: 0 silence_size: 0 boundary: 1073741824


3) Log with the config mentioned further above

Jul 02 12:38:45 volumio shairport-sync[17589]: 8.256483000 "player.c:1969" Player has supplied a silent frame, (possibly frame 9170) for play number 30809, status 0x11 after 7 resend requests. Jul 02 12:38:45 volumio shairport-sync[17589]: 0.003868000 "player.c:1969" Player has supplied a silent frame, (possibly frame 9171) for play number 30810, status 0x11 after 7 resend requests. Jul 02 12:38:47 volumio shairport-sync[17589]: 2.269939000 "player.c:2726" 0.00, 31093, 13, 0, 0, 0, 218, 519, 44213.17, 44103.32, -47.01, 35 Jul 02 12:38:55 volumio shairport-sync[17589]: 8.168548000 "player.c:2726" 0.00, 32096, 13, 0, 0, 0, 221, 246, 44125.68, 44092.77, -46.91, 37 Jul 02 12:39:04 volumio shairport-sync[17589]: 8.794668000 "player.c:2726" 0.00, 33099, 13, 0, 0, 0, 245, 344, 44114.01, 44092.77, -46.92, 38 Jul 02 12:39:13 volumio shairport-sync[17589]: 8.794760000 "player.c:2726" 0.00, 34102, 13, 0, 0, 0, 344, 443, 44108.58, 44094.07, -46.92, 38 Jul 02 12:39:14 volumio shairport-sync[17589]: 0.848276000 "player.c:1969" Player has supplied a silent frame, (possibly frame 12559) for play number 34198, status 0x5 after 7 resend requests. Jul 02 12:39:14 volumio shairport-sync[17589]: 0.002847000 "player.c:1969" Player has supplied a silent frame, (possibly frame 12560) for play number 34199, status 0x5 after 7 resend requests. Jul 02 12:39:22 volumio shairport-sync[17589]: 7.943234000 "player.c:2726" 0.00, 35105, 15, 0, 0, 0, 442, 542, 44105.72, 44094.15, -46.80, 40 Jul 02 12:39:31 volumio shairport-sync[17589]: 8.795334000 "player.c:2726" 0.00, 36108, 15, 0, 0, 0, 541, 641, 44103.96, 44093.73, -46.79, 41 Jul 02 12:39:39 volumio shairport-sync[17589]: 8.806750000 "player.c:2726" 0.00, 37111, 15, 0, 0, 0, 640, 739, 44102.88, 44093.45, -47.60, 42 Jul 02 12:39:40 volumio shairport-sync[17589]: 0.453279000 "player.c:1969" Player has supplied a silent frame, (possibly frame 15526) for play number 37165, status 0x5 after 7 resend requests. Jul 02 12:39:48 volumio shairport-sync[17589]: 8.341479000 "player.c:2726" 0.00, 38114, 16, 0, 0, 0, 739, 838, 44101.98, 44093.80, -47.55, 45 Jul 02 12:39:57 volumio shairport-sync[17589]: 8.794738000 "player.c:2726" 0.00, 39117, 16, 0, 0, 0, 837, 937, 44101.31, 44093.70, -47.55, 45 Jul 02 12:40:05 volumio shairport-sync[17589]: 7.666311000 "player.c:954" Aliasing of buffer index -- reset. Jul 02 12:40:07 volumio shairport-sync[17589]: 1.809527000 "audio_alsa.c:1674" alsa: underrun while writing 352 samples to alsa device. Jul 02 12:40:07 volumio shairport-sync[17589]: 0.021446000 "audio_alsa.c:1702" alsa: device status returns fault status -32 and SND_PCMSTATE 3 for play. Jul 02 12:40:07 volumio shairport-sync[17589]: 0.010307000 "audio_alsa.c:1674" alsa: underrun while writing 352 samples to alsa device. Jul 02 12:40:07 volumio shairport-sync[17589]: 0.024008000 "audio_alsa.c:1674" alsa: underrun while writing 352 samples to alsa device. Jul 02 12:40:07 volumio shairport-sync[17589]: 0.016400000 "audio_alsa.c:1702" alsa: device status returns fault status -32 and SND_PCMSTATE 3 for play. Jul 02 12:40:07 volumio shairport-sync[17589]: 0.003579000 "audio_alsa.c:1674" alsa: underrun while writing 352 samples to alsa device. Jul 02 12:40:07 volumio shairport-sync[17589]: 0.020200000 "audio_alsa.c:1674" alsa: underrun while writing 352 samples to alsa device. Jul 02 12:40:07 volumio shairport-sync[17589]: 0.032100000 "audio_alsa.c:1702" alsa: device status returns fault status -32 and SND_PCMSTATE 3 for play. Jul 02 12:40:07 volumio shairport-sync[17589]: 0.002808000 "audio_alsa.c:1674" alsa: underrun while writing 352 samples to alsa device. Jul 02 12:40:07 volumio shairport-sync[17589]: 0.067154000 "audio_alsa.c:1702" alsa: device status returns fault status -32 and SND_PCMSTATE 3 for play. Jul 02 12:40:07 volumio shairport-sync[17589]: 0.002796000 "audio_alsa.c:1674" alsa: underrun while writing 352 samples to alsa device. Jul 02 12:40:07 volumio shairport-sync[17589]: 0.015077000 "audio_alsa.c:1702" alsa: device status returns fault status -32 and SND_PCMSTATE* 3 for play. Jul 02 12:40:07 volumio shairport-sync[17589]: 0.004315000 "audio_alsa.c:1674" alsa: underrun while writing 352 samples to alsa device. Jul 02 12:40:08 volumio shairport-sync[17589]: 0.796903000 "player.c:2726" 0.00, 40120, 16, 0, 0, 0, 224, 1023, 44100.73, 44094.12, -48.72, 48 Jul 02 12:40:16 volumio shairport-sync[17589]: 8.006924000 "player.c:2726" 0.00, 41123, 16, 0, 0, 0, 222, 227, 44100.36, 44093.99, -48.50, 50 Jul 02 12:40:16 volumio shairport-sync[17589]: 0.003641000 "player.c:1969" Player has supplied a silent frame, (possibly frame 20509) for play number 41124, status 0x15 after 7 resend requests. Jul 02 12:40:16 volumio shairport-sync[17589]: 0.029811000 "player.c:1969" Player has supplied a silent frame, (possibly frame 20513) for play number 41128, status 0x15 after 7 resend requests.

manrand commented 3 years ago

I cannot send Mac system audio, for instance selecting "Volumio" as output device on the system audio panel. Only way to play audio from Mac seems to be from iTunes

About that issue in particular: after more tests apparently it was a firewall issue on the Mac.

You need to allow incoming connections to AirPlayXPCHelper or something similar. Actually I got the dialog only once and I don't find it listed anywhere, but I did allow it and now it works just fine. I do find a process called AirPlayXPCHelper (= /usr/libexec/AirPlayXPCHelper?)

I'm surprised that a source needs to allow incoming connections for this to work, while iTunes does not need this. Does anybody has a clue? Seems like a potential security issue.

mikebrady commented 3 years ago

Thanks for the posts. Here are a few observations:

AirPlay 1, which is the protocol Shairport Sync uses, uses a TCP stream originated by the player (e.g. iTunes) to control the session, three UDP streams from the player, a UDP stream to the player for timing and another for resend requests. Most players, including iTunes, also open a remote control port and some TCP transactions may occur between Shairport Sync and that port. So, absolutely, there must be incoming connections to the player.

Please let us know how things go.

mikebrady commented 3 years ago

It might be worth looking over TROUBLESHOOTING.md and REPORTING ISSUES.md in case there is useful information there.

Also, can you tell us the type of output device you are using (name and model) please?

manrand commented 3 years ago

Thank you for your kind reply. I tested again following your recommendations about the config, but I still get issues.

Here's the setup:

volumio@volumio:~$ sudo systemctl -l status shairport-sync
ā— shairport-sync.service - Shairport Sync - AirPlay Audio Receiver
   Loaded: loaded (/lib/systemd/system/shairport-sync.service; static)
   Active: active (running) since Sun 2021-08-29 10:20:16 UTC; 19min ago
 Main PID: 2373 (shairport-sync)
   CGroup: /system.slice/shairport-sync.service
           ā””ā”€2373 /usr/local/bin/shairport-sync --configfile=/tmp/shairport-sync.conf

Aug 29 10:25:31 volumio shairport-sync[2373]: Dload  Upload   Total   Spent    Left  Speed
Aug 29 10:25:31 volumio shairport-sync[2373]: [155B blob data]
Aug 29 10:25:38 volumio shairport-sync[2373]: 7.850720680 "mdns_avahi.c:147" (Browser) REMOVE: service 'iTunes_Ctrl_BA430124469E7CF9' of type '_dacp._tcp' in domain 'local'.
Aug 29 10:25:38 volumio shairport-sync[2373]: 0.003475974 "dacp.c:463" dacp_monitor_port_update_callback with Remote ID "BA430124469E7CF9", target ID "BA430124469E7CF9" and port number 0.
Aug 29 10:25:39 volumio shairport-sync[2373]: 0.633432295 "dacp.c:515" setting metadata_store.dacp_server_active and metadata_store.advanced_dacp_server_active to 0 with an update flag value of 1
Aug 29 10:25:39 volumio shairport-sync[2373]: 0.003101977 "dbus-service.c:196" Build metadata
Aug 29 10:25:40 volumio shairport-sync[2373]: 1.481635993 "activity_monitor.c:91" aend
Aug 29 10:25:41 volumio shairport-sync[2373]: {"time":1630232731023,"response":"stopAirplayPlayback Success"}  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
Aug 29 10:25:41 volumio shairport-sync[2373]: Dload  Upload   Total   Spent    Left  Speed
Aug 29 10:25:41 volumio shairport-sync[2373]: [155B blob data]

diagnostics = { log_verbosity = 2; statistics = "yes"; //disable_resend_requests = "yes"; };

alsa = { output_device = "hw:2,0"; //disable_synchronization = "yes"; };

sessioncontrol = { allow_session_interruption = "yes"; run_this_before_play_begins= "/usr/local/bin/volumio startairplayplayback"; run_this_after_play_ends = "/usr/local/bin/volumio stopairplayplayback"; run_this_before_entering_active_state="/usr/local/bin/volumio airplayactive"; run_this_after_exiting_active_state="/usr/local/bin/volumio airplayinactive"; };

metadata = { enabled = "yes"; include_cover_art = "no"; //pipe_name = "/tmp/shairport-sync-metadata"; //pipe_timeout = 5000; socket_address = "127.0.0.1"; socket_port = 5555; };


Please find below more information regarding your observations

> The logs indicate that audio packets are being lost on the network, so you should stop disabling resend requests. With resend requests enabled, it is unusual to lose packets to the extent that silent packets are substituted. If the problem persists, you need to find out why the network is losing packets.

Is there a way to know which protocol and port is in use in that particular case? Is it UDP?
Do you know if loosing packets is a common thing? (given that `resend` is enabled by default), and if so, how much packet loss can the default settings tolerate?

> Shairport Sync only sets a few parameters in the alsa device: format (two-channel interleaved frames), rate (44,100 or a multiple), depth (32/24/16/8 bit PCM) and transfer mode -- normal or memory-mapped ("mmap"). Given your example, it sets the format to 32 bit / 44,100 frames per seconds, interleaved stereo. It does not set buffers, buffer size, etc. Volumio may be setting these parameters, so if you could run Shairport Sync without allowing Volumio to run after restarting the computer, it might help in tracking down any related issue.

I see. It may take me a while to figure that out, in the meanwhile, did you see anything abnormal on those parameters?
Out of curiosity, which hardware have you tested personally?

> Your output device is plughw:2,0. This is not a real hardware device -- it is a virtual alsa device, which may be doing format translation and transcoding before outputting to the real device. This is all undesirable from a fidelity point of view and, importantly, may be slowing everything down, especially on a PI Zero. If you can (I don't know what Volumio does), you should direct Shairport Sync to the real hardware output device. Shairport Sync will then select the best capabilities of the real device. (It is possible that the real output device doesn't do a rate of 44,100 but only 48,000, and in that case you need the transcoding provided by the virtual alsa device. But let's see -- most hardware devices do 44,100.)

Thank you, I did not know that. I changed it (see config further above), although it is probably Volumio default setup, will check with them.

> When troubleshooting, you should leave as many settings commented out as possible, especially the advanced features. There should be no necessity to alter the setting audio_backend_buffer_desired_length and audio_backend_buffer_interpolation_threshold_in_seconds.

Ok, I did it as a test following this: https://github.com/mikebrady/shairport-sync/blob/master/TROUBLESHOOTING.md#buffer-underflow-to-audio-backend I think I had seen `underrun` messages.
Anyway, the config I'm using (above) does not has that parameter set.

> AirPlay 1, which is the protocol Shairport Sync uses, uses a TCP stream originated by the player (e.g. iTunes) to control the session, three UDP streams from the player, a UDP stream to the player for timing and another for resend requests. Most players, including iTunes, also open a remote control port and some TCP transactions may occur between Shairport Sync and that port. So, absolutely, there must be incoming connections to the player

Ok, so if I sum it up:
Source=>Sink:
- TCP control session
- UDP: 3 streams

Sink=>Source:
- UDP: for timing and resend requests

Weird that they [protocol designers] did not reuse the TCP control session as bidirectionnal, like for timing and resend.

> It might be worth looking over TROUBLESHOOTING.md and REPORTING ISSUES.md in case there is useful information there.

I did not find anything suitable, except for the `audio_backend_buffer_desired_length = 19845;` thing. 
Does anybody know if I overlooked something?
In any case, what puzzles me the most is that many people seem to have succeeded, and I'm using off-the-shelf HW/SW so I don't know what else could be wrong.

For what is worth, and I think I forgot to mention this, I have an Airport Express A1264 that runs perfectly fine on the same network.

> Also, can you tell us the type of output device you are using (name and model) please?

Yes, Audiophonics DigiPi+ Pro HAT https://www.audiophonics.fr/en/dac-and-interfaces-for-raspberry-pi/audiophonics-digipi-pro-digital-interface-wm8804-for-raspberry-pi-p-12150.html

Anyway, here are some parameters after using the config you suggested, I also have a log (played one song and disconnected) [dmesg7_trim.txt](https://github.com/mikebrady/shairport-sync/files/7072368/dmesg7_trim.txt)

volumio@volumio:~$ cat /proc/asound/sndrpihifiberry/pcm0p/sub0/hw_params access: MMAP_INTERLEAVED format: S24_LE subformat: STD channels: 2 rate: 44100 (44100/1) period_size: 256 buffer_size: 65536 volumio@volumio:~$ cat /proc/asound/sndrpihifiberry/pcm0p/sub0/sw_params tstamp_mode: ENABLE period_step: 1 avail_min: 256 start_threshold: 1 stop_threshold: 65536 silence_threshold: 0 silence_size: 0 boundary: 1073741824 volumio@volumio:~$ cat /proc/asound/sndrpihifiberry/pcm0p/sub0/info
card: 2 device: 0 subdevice: 0 stream: PLAYBACK id: HifiBerry Digi HiFi wm8804-spdif-0 name: HifiBerry Digi HiFi wm8804-spdif-0 subname: subdevice #0 class: 0 subclass: 0 subdevices_count: 1 subdevices_avail: 0

mikebrady commented 3 years ago

Thanks for the information.

It does indeed look as if your device is capable of 44,100 FPS operation and Shairport Sync has chosen 24-bit operation (it simply pads out the 16-bit samples to 24 bits with essentially zero overhead and zero loss of fidelity). So that looks okay.

It seems that there are lots of Player: packets out of sequence:... errors and very large synchronisation errors, e.g.

"player.c:2682"      29.79,   -2835.2,    2835.2,        5015,      0,     12,      0,      5,   7957,  210,  227,       0.00,       0.00,   40140.47,      0.00,     0,1000000.00

showing an error of almost 30 milliseconds and a huge around of [very expensive] interpolation.

The CPU cost of soxr interpolation may be causing the system to fall behind, so I suggest you set the interpolation to basic in the configuration file and see what happens.

Also, it's clear from the log that Volumio is running. Is there a way to stop it? We don't really know what it's doing to, e.g. CPU time and ALSA device settings.

Please find below more information regarding your observations

The logs indicate that audio packets are being lost on the network, so you should stop disabling resend requests. With resend requests enabled, it is unusual to lose packets to the extent that silent packets are substituted. If the problem persists, you need to find out why the network is losing packets.

Is there a way to know which protocol and port is in use in that particular case? Is it UDP? Do you know if loosing packets is a common thing? (given that resend is enabled by default), and if so, how much packet loss can the default settings tolerate?

I've experimented with artificially "losing" up to a few percent of UDP packets and it's been fine.

Shairport Sync only sets a few parameters in the alsa device: format (two-channel interleaved frames), rate (44,100 or a multiple), depth (32/24/16/8 bit PCM) and transfer mode -- normal or memory-mapped ("mmap"). Given your example, it sets the format to 32 bit / 44,100 frames per seconds, interleaved stereo. It does not set buffers, buffer size, etc. Volumio may be setting these parameters, so if you could run Shairport Sync without allowing Volumio to run after restarting the computer, it might help in tracking down any related issue.

I see. It may take me a while to figure that out, in the meanwhile, did you see anything abnormal on those parameters? Out of curiosity, which hardware have you tested personally?

Too many to remember, I'm afraid.

Your output device is plughw:2,0. This is not a real hardware device -- it is a virtual alsa device, which may be doing format translation and transcoding before outputting to the real device. This is all undesirable from a fidelity point of view and, importantly, may be slowing everything down, especially on a PI Zero. If you can (I don't know what Volumio does), you should direct Shairport Sync to the real hardware output device. Shairport Sync will then select the best capabilities of the real device. (It is possible that the real output device doesn't do a rate of 44,100 but only 48,000, and in that case you need the transcoding provided by the virtual alsa device. But let's see -- most hardware devices do 44,100.)

Thank you, I did not know that. I changed it (see config further above), although it is probably Volumio default setup, will check with them.

When troubleshooting, you should leave as many settings commented out as possible, especially the advanced features. There should be no necessity to alter the setting audio_backend_buffer_desired_length and audio_backend_buffer_interpolation_threshold_in_seconds.

Ok, I did it as a test following this: https://github.com/mikebrady/shairport-sync/blob/master/TROUBLESHOOTING.md#buffer-underflow-to-audio-backend I think I had seen underrun messages. Anyway, the config I'm using (above) does not has that parameter set.

That issue was with a device that could not do 44,100 fps and needed transcoding to 48,000, so not relevant here.

AirPlay 1, which is the protocol Shairport Sync uses, uses a TCP stream originated by the player (e.g. iTunes) to control the session, three UDP streams from the player, a UDP stream to the player for timing and another for resend requests. Most players, including iTunes, also open a remote control port and some TCP transactions may occur between Shairport Sync and that port. So, absolutely, there must be incoming connections to the player

Ok, so if I sum it up: Source=>Sink:

  • TCP control session
  • UDP: 3 streams

Sink=>Source:

  • UDP: for timing and resend requests

Weird that they [protocol designers] did not reuse the TCP control session as bidirectionnal, like for timing and resend.

Plus TCP for remote control.

manrand commented 3 years ago

Thanks again for your kind reply šŸ™ , and sorry to have so many questions šŸ˜¬

It does indeed look as if your device is capable of 44,100 FPS operation and Shairport Sync has chosen 24-bit operation (it simply pads out the 16-bit samples to 24 bits with essentially zero overhead and zero loss of fidelity). So that looks okay.

So, it is really sending 24bit on the optical output? or is it for internal processing? What happens if the receiver end only accepts or expects 16bit?

It seems that there are lots of Player: packets out of sequence:... errors and very large synchronisation errors, e.g.

"player.c:2682" 29.79, -2835.2, 2835.2, 5015, 0, 12, 0, 5, 7957, 210, 227, 0.00, 0.00, 40140.47, 0.00, 0,1000000.00

showing an error of almost 30 milliseconds and a huge around of [very expensive] interpolation.

The CPU cost of soxr interpolation may be causing the system to fall behind, so I suggest you set the interpolation to basic in the configuration file and see what happens.

What are the usual causes of those problems: out of sequence and synchronisation? For instance, how could synchronisation be improved? Is it w.r.t. wall clock (and therefore dependent on NTP)?

One more thing, could synchronisation issues change the pitch of the resulting audio?

I tried with interpolation = "basic"; and seems to work better, the very noticeably glitches are no longer there, will do more tests to see if less perceptible glitches are still present.

In the meanwhile, what would you suggest? To get a more powerful RPi? I don't know how much does "basic" vers "soxr" compares in terms of sound quality.

One more thing, what kind of logs should I enable to get only the logs that alert of audio issues? (for instance, buffer underflow/overflow, buffer reset, drift, resync, packet loss, etc.), I was thinking maybe I could light a LED when one of those issues happen.

I've experimented with artificially "losing" up to a few percent of UDP packets and it's been fine.

Ok, good to know. What settings can be tweaked to improve such resilience? Is it audio_backend_buffer_desired_length_in_seconds?

I see. It may take me a while to figure that out, in the meanwhile, did you see anything abnormal on those parameters? Out of curiosity, which hardware have you tested personally?

Too many to remember, I'm afraid.

Do you happen to know if there's a list somewhere?

Ok, so if I sum it up: Source=>Sink:

  • TCP control session
  • UDP: 3 streams

Sink=>Source:

  • UDP: for timing and resend requests

Weird that they [protocol designers] did not reuse the TCP control session as bidirectionnal, like for timing and resend.

Plus TCP for remote control.

Is it a new connection or the same that goes from Source to Sink (the above mentioned as "TCP control session")?

mikebrady commented 3 years ago

Thanks again for your kind reply šŸ™ , and sorry to have so many questions šŸ˜¬

That's fine!

It does indeed look as if your device is capable of 44,100 FPS operation and Shairport Sync has chosen 24-bit operation (it simply pads out the 16-bit samples to 24 bits with essentially zero overhead and zero loss of fidelity). So that looks okay.

So, it is really sending 24bit on the optical output? or is it for internal processing? What happens if the receiver end only accepts or expects 16 bit?

When the output_format is set to "auto" -- which is the default -- Shairport Sync will use the highest bit depth it can set the device to; hence 24 bits. You can set the output, say, to 16-bits by setting the output_format to "S16".

It seems that there are lots of Player: packets out of sequence:... errors and very large synchronisation errors, e.g. "player.c:2682" 29.79, -2835.2, 2835.2, 5015, 0, 12, 0, 5, 7957, 210, 227, 0.00, 0.00, 40140.47, 0.00, 0,1000000.00 showing an error of almost 30 milliseconds and a huge around of [very expensive] interpolation. The CPU cost of soxr interpolation may be causing the system to fall behind, so I suggest you set the interpolation to basic in the configuration file and see what happens.

What are the usual causes of those problems: out of sequence and synchronisation?

Typically either a bad network, a bad device or an overloaded CPU. I am guessing the network is okay and the device is okay.

For instance, how could synchronisation be improved? Is it w.r.t. wall clock (and therefore dependent on NTP)?

No, it is dependent purely on the quality of the network and the load on the CPU.

One more thing, could synchronisation issues change the pitch of the resulting audio?

Very very slightly. I suspect that a very skilled musician might be able to hear a tiny change in tone if a great deal of synchronisation (1,000s of parts per million (ppm)) was being done. Normally, synchronisation will be in the range of 10s to 100s of ppm, so a change in pitch will be inaudible.

I tried with interpolation = "basic"; and seems to work better, the very noticeably glitches are no longer there, will do more tests to see if less perceptible glitches are still present.

In the meanwhile, what would you suggest? To get a more powerful RPi? I don't know how much does "basic" vers "soxr" compares in terms of sound quality.

So, a Raspberry Pi Zero should be adequate, even using soxr interpolation, as long as nothing else is keeping it busy and as long as it is not transcoding. So, IMHO, one should be trying to identify the root cause of the problem. Soxr interpolation is much less intrusive than basic, although neither of them is particularly audible on normal material when interpolation is down in the 10s or 100s of ppm.

One more thing, what kind of logs should I enable to get only the logs that alert of audio issues? (for instance, buffer underflow/overflow, buffer reset, drift, resync, packet loss, etc.), I was thinking maybe I could light a LED when one of those issues happen.

The logs have not really been set up for this, but you could try setting the verbosity to 1.

I've experimented with artificially "losing" up to a few percent of UDP packets and it's been fine.

Ok, good to know. What settings can be tweaked to improve such resilience? Is it audio_backend_buffer_desired_length_in_seconds?

Yes, but really, it shouldn't be necessary to do any of this.

I see. It may take me a while to figure that out, in the meanwhile, did you see anything abnormal on those parameters? Out of curiosity, which hardware have you tested personally?

Too many to remember, I'm afraid.

Do you happen to know if there's a list somewhere?

No, not that I know of...

Ok, so if I sum it up: Source=>Sink:

  • TCP control session
  • UDP: 3 streams

Sink=>Source:

  • UDP: for timing and resend requests

Weird that they [protocol designers] did not reuse the TCP control session as bidirectionnal, like for timing and resend.

Plus TCP for remote control.

Is it a new connection or the same that goes from Source to Sink (the above mentioned as "TCP control session")?

It's another connection. The port number can be dynamic and is advertised in mDNS packets.

github-actions[bot] commented 2 years ago

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