Audible Pops Between Tracks with Different Formats

Core Machine (Operating system/System info/Roon build number)
ROCK Version 1.0 (build 186) stable on Roon-spec Intel NUC; music on USB SSD on NUC
Server Version 1.7 (build 528) stable

Network Details (Including networking gear model/manufacturer and if on WiFi/Ethernet)
Asus Dark Knight and Gigabit Ethernet to 3 Roon Endpoints

Audio Devices (Specify what device you’re using and its connection type - USB/HDMI/etc.)
My listening relies upon 3 Roon Endpoints (all at the latest Roon software rev):

  1. RPi3 with Hifiberry DAC Hat: Analog stereo audio via RCA to powered speakers (Audible Pops)

  2. RPi3 with Hifiberry Amp Hat: 16/4 speaker wire to dual-tweeter in-wall speaker (Audible Pops)

  3. RPi3 with Hifiberry Digi Hat: S/PDIF via TOSLINK to Yamaha Aventage AVR (No Audible Pops)

Description Of Issue
Title says it all. I can repeat this without fail. When the track (regardless of it being a local or a file streamed via Tidal) format is the same, there is silence between the tracks. However, if the format is different (96/24 to RedBook 44.1/16 for example, or the reverse), there is a very loud pop - but only on two of the three endpoints, as noted above.

I have reviewed other posts on the subject, and have adjusted the resync delay to be 500ms on all of the Endpoints, as suggested. But that setting change has had no impact.

I have no way that I am aware of to test the hardware only, with Roon removed from the equation.

Any advice will be appreciated.

Hi @Dean_Clough,

  • Your endpoints are three separate RPi3’s (and not the same RPi with different hat’s) correct?
  • What OS do you have on the RPis in this setup? Are you using Ropieee, DietPi, ect?
  • Are these Pis connected directly to the router or do you have any switches/range extenders in between?

Hello and thank you. Feels silly complaining about things like this in these times, but I do appreciate your help. In response:

  1. Yes, they are 3 separate RPi3’s - sorry if that wasn’t clear.

  2. Yes - two are running a current version Ropieee and the other, DietPi

  3. The DAC (audible pop) is connected via a TrendNet gigabit switch which in turn is wired to my router; the Digi (no audible pop) is connected via a different TrendNet gigabit switch, which is also wired to my router; and the Amp (audible pop) uses WiFi (no other choice in my case).

1 Like

Hi @Dean_Clough,

Thanks for the clarification.

If you try connecting this zone to the other TrendNet switch, does it resolve the issue? Sometime switches can become defective and slowly fail, so it would be a good way to eliminate one potential aspect.

OK - I’ve finally had some time to do some troubleshooting.

First, I have determined the issue (very audible pops between tracks on different albums and when a track stops) is only happening on my endpoints that are performing DAC functionality. The pops are happening on two of my four endpoints, one an RPi3 running Ropieee with a HiFiBerry DAC connected to powered speakers, and another RPi3 running DietPi with a HiFiBerry Amp connected to a traditional passive speaker. My other two endpoints, each RPi3’s with HiFiBerry Digi boards using external DAC’s (Yamaha AVR and Parasound DAC), make zero unwanted sound.

Second: The problem does not occur between tracks of an album being played, only on playlists with tracks from mixed albums, and as above, also when playback of any kind is stopped or paused - the pop happens approx. 3 -5 seconds after playback ceases.

Third: how the endpoints are connected to my LAN does not seem to matter. I have tried the Core and relevant endpoints connected to the same physical LAN switch via Ethernet, and also with an endpoint connected via WiFi (100% signal) - the problem is consistent.

I have also reached out to HiFiBerry, with frankly disappointing results. They claim this is not a bug at all:

“Small pops when skipping or stopping tracks are normal as the system will shut down the audio circuit during these operations. I don’t know if RooPie does additional things that might make this worse. You might try HiFiBerryOS as a player and see if this works better.”

Do you guys have any experience with their OS and Roon? Or any other suggestions overall, apart from starting to use different audio HAT’s?

How do you have Resync Delay set under device setup? (I have that option for my Ropieee connecting my Devialet Phantom). If it is set to zero, have you tried increasing the delay to 50msec, for example?

Thanks - I actually have it set to 500 milliseconds. I’ll try other settings and see if it has any impact.

I can confirm that changing the Resync Delay to any setting (0 msec, 50 msec, 500 msec, or 8,000 msec) has no impact on the problem - when changing tracks in a playlist (not an album), or stopping playback of a track (in an album or playlist) results in a pop 5 seconds after the event (track changed or music stops) each and every time.

Can @danny or anyone else at Roon comment on the OS being the issue?? That doesn’t make sense to me, but HiFiBerry says their only suggestion is using their Linux variant.

You need the big hitters. I’ll step aside and let @dylan and the Support guys do their work.
Good luck!

Hi @Dean_Clough,

Thanks for the update here. I’ll forward your findings over to QA and we will attempt to reproduce your findings in the lab. If we are successful, we’ll reach out to HiFiBerry on your behalf and see what can be done to improve this behavior.

You are great - thank you very much. Please let me know if I can provide any further info.

1 Like

Hello @Dean_Clough,

We have only tested the HiFi Berry DAC with HiFiBerryOS. It is possible that different operating systems could impact the behavior here.

The Roon Bridge application running on Raspberry PI accepts audio from the Roon Core using the RAAT transport mechanism and then re-routes the audio to the selected ALSA audio device. Changes to the sample rate and bit-depth are also relayed via standard ALSA methods.

Various Linux distros/builds could have different timing characteristics in response to these ALSA calls that could change how the audio device reacts to a given command.

-John

Thank you John. So I am clear, can you confirm that, in your tests at Roon and using the HiFiBerry OS with their DAC HAT, there is no audible pops between tracks of different formats, and when a track of any format is stopped?

Hello @Dean_Clough,

Using the HiFiBerry DAC+ running the latest version of HiFiBerryOS, we are not experiencing any pops when changing sample rates between during Roon playback.

-John

Thank you - I appreciate the follow-up. This problem still exists for me
on one of two endpoints, each with a RPi4, HifiberryOS, and a Hifiberry Amp
HAT.

The endpoint with the older Amp HAT pops when there’s a format change, and
whenever a track of any kind is paused or stopped. These endpoints are
identical in every other sense - both connect via WiFi, for instance, but
one works in complete silence, while the other has the annoying and very
audible pop.

Important for Roon, though: interestingly, the endpoint that pops does so
at the moment the Roon interface’s “quality” indicator (the
round-ish purple, yellow, green, etc. icon that shows whether what’s being
played is lossless, lossy, etc.) goes away when a track stops playing - the
pop happens exactly at the moment the Roon quality icon disappears.

I’ll reach out to Hifiberry, as well, but any help would be appreciated - I would think
Roon has nothing to do with it if it weren’t the coincidence of the pop
occurring with the quality indicator icon going away.

Hello @Dean_Clough,

When a track is “paused” in Roon, it actually continues to play digital silence to the output for ~5 seconds. When the “light” indicator disappears, Roon has stopped outputting digital silence and released its hold on the ALSA device.

-John

Are there any settings changes from Roon that I could make that you think might help this? I am also working with HifiBerry tech support.

A post was split to a new topic: Pops when switching songs or stopping music

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.