[Problem]: Slight crackling during loud parts of songs. #1919
Labels
Comments
|
Thanks for the post. If there is a lot of interpolation, then you might hear some crackling if using |
|
Okay so starting shairport with |
|
Thanks. As I suspected, there is a great deal of interpolation going on — it should be in the 10s of PPM or occasionally up to 150 PPM or so. However, you can see that synchronization error is going positive and negative, indicating that the system is overcompensating. My suggestion would be to make the |
|
I've set This is the output now: Other than that, is there a root cause of the interpolation that I could try to address? |
|
That’s good news. You will hardly hear a sync mismatch of 20 milliseconds, but you could experiment with reducing the drift tolerance until overcompensation starts — that will be when the All Sync PPM is considerably greater than the Net Sync PPM. There seems to be two issues at work here. First, the rate of arrival of audio frames from the player doesn’t quite match the rate at which they are played. Second — and apparently more significant in this case — it looks as if the reference clock on the sending device is wandering, slowly getting faster and slower then faster again, etc. over a period of 10s of seconds. If your Pi has a good connection to the internet, the Output FPS (c) should be accurate over a long period, as it should be adjusted by the NTP service used by the Pi. On the face of it, it looks as if your output device is pretty exactly on 44,100. It also looks like the audio is arriving at close to 44,100 fps, but the reference clock seems to be wandering by something in the region of 100 to 150 PPM. It would be interesting to run it continuously for a few hours if possible, in order to get better readings. Apple sources tend to be stable and accurate, but others maybe not so much. |
|
When I get a chance to do this I will, and then post the output here. Thank you so much for your help so far! |
|
Okay this is quite a long run, about 2 hours |
|
Thanks -- that's interesting. You could probably experiment with reducing the tolerance to 10 milliseconds and see what happens. There are a few discontinuities in the sequence -- was anything special happening at those times, e.g. the end of a track and the start of another, that might account for them? Later in the log, you can see a kind of cyclical increase and decrease of the amount of interpolation needed, with a periodicity of the order of five minutes or so. Just for reference, here is a log of an iPad playing an album using Apple Music to Shairport Sync running on a Raspberry Pi 3 all up-to-date. Here is the output from One anomaly in your log is that there are no drift samples registered. I'll have to think about why that is -- maybe the acceptance algorithm is too strict. In any case, the drift samples are diagnostic only -- they have no function apart from providing a little information. In my sample, it seems that there is a drift of about 5 parts per million between the iPad and the Pi's clocks, which seems reasonable. |
|
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. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
What happened?
There's a slight crackling sound during loud parts of some tracks. Not all tracks, but if I notice it with one track, it will do it consistently with that track. I notice it the worst when the source is my nixos desktop (pipewire), but I also notice it with my android phone with airmusic to a slightly lesser extent, and I also notice it with my M1 macbook air. Again it seems to be to different degrees with these three devices. And again I on't notice it on all tracks, it seems to happen is a track goes suddenly from being quiet to loud, though I'm not quite sure. It didn't always happen (I don't think... But I'm beginning to doubt myself because it's quite a subtle thing that I might have missed before), and seems to have started in the last month or so.
The crackling sound is similar to that you sometimes get in VMs when you don't pin cpu cores if that helps at all, though it's much less exaggerated.
The nature of the crackling changes when I switch between basic interpolation and soxr, but it happens either way. This makes me think it must be to do with lost packets?
I thought it might be a sign of my pi dying so I switched it out for an identical one but the problem persists.
The only other thing I can think of is that it is a problem with my network itself, but I'm not aware of any changes to my network in the last months/weeks.
I'm fairly certain it's not a problem with the dac because the problem goes away when I connect directly to the dac via bluetooth.
Relevant log output
output from shairport-sync -v when connecting from my nixos machine: 0.001293073 "shairport.c:2278" Startup in AirPlay 2 mode, with features 0x405c4a00,0x1c340 on device "b8:27:eb:93:75:07". 0.000131510 "shairport.c:2317" Version String: "4.3.4-1-g910264e5-AirPlay2-smi10-alac-OpenSSL-Avahi-ALSA-soxr-sysconfdir:/etc" 0.000025729 "shairport.c:2336" Command Line: "shairport-sync -v". 0.000466302 "shairport.c:2372" Log Verbosity is 1. 0.000059480 "audio_alsa.c:1082" alsa: alsa_maximum_stall_time of 0.200000 sec. 0.000075000 "audio_alsa.c:1371" alsa: disable_standby_mode is "never". 0.000018229 "audio_alsa.c:1375" alsa: disable_standby_mode_silence_threshold is 0.040000 seconds. 0.000018594 "audio_alsa.c:1377" alsa: disable_standby_mode_silence_scan_interval is 0.004000 seconds. 0.000029479 "audio_alsa.c:1417" alsa: output device name is "hw:Audio". 0.000236406 "shairport.c:2440" disable_resend_requests is off. 0.000029010 "shairport.c:2441" diagnostic_drop_packet_fraction is 0.000000. A value of 0.0 means no packets will be dropped deliberately. 0.000021250 "shairport.c:2445" statistics_requester status is 0. 0.000016407 "shairport.c:2450" rtsp listening port is 7000. 0.000045937 "shairport.c:2451" udp base port is 6001. 0.000038854 "shairport.c:2452" udp port range is 10. 0.000036823 "shairport.c:2453" player name is "Living Room". 0.000036771 "shairport.c:2454" backend is "alsa". 0.000036510 "shairport.c:2455" run_this_before_play_begins action is "(null)". 0.000037240 "shairport.c:2456" run_this_after_play_ends action is "(null)". 0.000036563 "shairport.c:2457" wait-cmd status is 0. 0.000036250 "shairport.c:2458" run_this_before_play_begins may return output is 0. 0.000037239 "shairport.c:2459" run_this_if_an_unfixable_error_is_detected action is "(null)". 0.000037448 "shairport.c:2461" run_this_before_entering_active_state action is "(null)". 0.000037292 "shairport.c:2463" run_this_after_exiting_active_state action is "(null)". 0.000037291 "shairport.c:2465" active_state_timeout is 10.000000 seconds. 0.000041615 "shairport.c:2466" mdns backend "(null)". 0.000036094 "shairport.c:2468" interpolation setting is "basic". 0.000036458 "shairport.c:2472" interpolation soxr_delay_threshold is 30000000. 0.000037188 "shairport.c:2473" resync time is 0.050000 seconds. 0.000038281 "shairport.c:2474" resync recovery time is 0.100000 seconds. 0.000037864 "shairport.c:2475" allow a session to be interrupted: 0. 0.000036302 "shairport.c:2476" busy timeout time is 120. 0.000036094 "shairport.c:2477" drift tolerance is 0.002000 seconds. 0.000038125 "shairport.c:2478" password is not set. 0.000035729 "shairport.c:2479" default airplay volume is: -24.000000. 0.000040417 "shairport.c:2480" high threshold airplay volume is: -16.000000. 0.000039167 "shairport.c:2482" check for higher-than-threshold volume for new play session is disabled. 0.000037239 "shairport.c:2488" ignore_volume_control is 0. 0.000036563 "shairport.c:2492" volume_max_db is not set 0.000035364 "shairport.c:2493" volume range in dB (zero means use the range specified by the mixer): 0. 0.000040000 "shairport.c:2495" volume_range_combined_hardware_priority (1 means hardware mixer attenuation is used first) is 0. 0.000038386 "shairport.c:2499" playback_mode is 0 (0-stereo, 1-mono, 1-reverse_stereo, 2-both_left, 3-both_right). 0.000037656 "shairport.c:2501" disable_synchronization is 0. 0.000036354 "shairport.c:2502" use_mmap_if_available is 1. 0.000036250 "shairport.c:2503" output_format automatic selection is enabled. 0.000036771 "shairport.c:2507" output_rate automatic selection is enabled. 0.000036510 "shairport.c:2511" audio backend desired buffer length is 0.200000 seconds. 0.000038386 "shairport.c:2513" audio_backend_buffer_interpolation_threshold_in_seconds is 0.120000 seconds. 0.000038854 "shairport.c:2515" audio backend latency offset is 0.000000 seconds. 0.000053385 "shairport.c:2517" audio backend silence lead-in time is "auto". 0.000036250 "shairport.c:2521" zeroconf regtype is "_raop._tcp". 0.000036146 "shairport.c:2522" decoders_supported field is 3. 0.000036407 "shairport.c:2523" use_apple_decoder is 1. 0.000036041 "shairport.c:2524" alsa_use_hardware_mute is 0. 0.000036354 "shairport.c:2528" no special mdns service interface was requested. 0.000070000 "shairport.c:2531" configuration file name "/etc/shairport-sync.conf" resolves to "/etc/shairport-sync.conf". 0.000042657 "shairport.c:2561" loudness is 0. 0.000036823 "shairport.c:2562" loudness reference level is -20.000000 0.002102812 "shairport.c:2689" NQPTP is online. 22.561277179 "rtsp.c:4543" Connection 1: Classic AirPlay connection from 192.168.1.13:20003 to self at 192.168.1.23:7000. 0.136114739 "rtp.c:811" Remote processing time greater than return time -- ignored. the last line there about the remote processing time didn't used to be there - but then I don't see that line when I connect from my phone (android) or my laptop (macbook) so I'm not sure how relevant it is.System Information.
I'm running shairport, compiled with Airplay 2 and soxr support, on a raspberry pi 3 model B with an ethernet connection. It's outputting to an SMSL SA300 DAC.
Configuration Information.
PulseAudio or PipeWire installed?
How did you install Shairport Sync?
Built from source
Check previous issues
The text was updated successfully, but these errors were encountered: