RPi | Pops in audio with Kernel 4.19.118-v7+ #1311 and Roon Bridge

[dsnyder0pc]

Creating a bug report/issue

Required Information

• DietPi version | 6.30.0
• Distro version | Buster
• Kernel version | Linux usbridge 4.19.118-v7+ #1311 SMP Mon Apr 27 14:21:24 BST 2020 armv7l GNU/Linux
• SBC model | RPi CM 3+ (armv7l)
• Power supply used | Allo Shanti LPS (5V, 3A - https://www.allo.com/sparky/shanti.html)
• SDcard used | SanDisk ultra

Additional Information (if applicable)

• Software title | Roon Bridge (build 171)
• Was the software title installed freshly or updated/migrated? Yes
• Can this issue be replicated on a fresh installation of DietPi? Yes

• Bug report ID | a5e9a68e-c247-485e-9b65-7cb9114b5756

Steps to reproduce

1. ...Play any music from Roon. I tested with standard 16-bit, 44.1 kHz CD resolution with no DSP
2. ...

Expected behaviour

• ...Music should sound great, assuming a reasonable external USB DAC

Actual behaviour

• ...I'm hearing pops and ticks with kernel 4.19.118, but when I switch to a different microSD card that was updated to DietPi 6.30.0 but has kernel 4.19.97, everything sounds fine.
• ...You can hear what I'm hearing by playing this file: https://www.dsnyder.ws-e.com/ts/linux_4.19.97_vs_4.19.118.mp3

Extra details

• ...I can only reproduce this problem while streaming the file from Roon and with kernel 4.19.118. When I play the file locally (eg., download it from here to the local microSD card and use the SoX play command), it sounds fine with both kernels.
  -...Others in the Roon community can reproduce this problem and say the workaround is to go back to the kernel that came with the January 26th DietPi image.
  -...Roon subscribers everywhere who use DietPi as their endpoint solution are sad. I'd love to tell them how to switch to the 4.19.97 kernel as a workaround, but I have not found an easy way to do that.

[dsnyder0pc]

I do realize that there's probably not much for maintainers of DietPi to do in this instance…not sure how you write a regression or integration test for this sort of thing. But when there are problems with a kernel for a given application, it would be nice to have a way for users to roll the kernel forward or back a release or two to help with isolating the source of the problem or just as a workaround. There's probably a way to do this, but I've not worked it out yet or found a reference.

[Joulinar]

Hi,

DietPi do not have an own kernel. It's using the given kernel of the underlying base image. In case of RPi devices, base image is Raspberry OS. There you can use rpi-update if you like to change the kernel.

https://github.com/Hexxeh/rpi-update

To upgrade/downgrade to a specific firmware revision, specify its Git hash (from the https://github.com/Hexxeh/rpi-firmware/commits/master repository) as follows:

sudo rpi-update fab7796df0cf29f9563b507a59ce5b17d93e0390

[MichaIng]

Take care with rpi-update since it introduces potential issues and is really a developer tool or to use when a developer asks you to test a certain build that fixes a certain issue you face.

Another method for downgrading kernel/firmware is to download the four related packages and install them: https://archive.raspberrypi.org/debian/pool/main/r/raspberrypi-firmware/

• raspberrypi-kernel + raspberrypi-bootloader + libraspberrypi0 + libraspberrypi-bin
• Take care that they must have the same date/version string.

Has it already been reported to the firmware bug tracker and exact commit identified? Else would be good to collect all related info and report here: https://github.com/raspberrypi/firmware/issues
Of course for testing an upstream fix, rpi-update is great then, just note that it likely includes the major upgrade to upcoming kernel 5.4.X 😉.

[dsnyder0pc]

Thanks for the suggestions, @MichaIng and @Joulinar . You guys are great!

I've opened a firmware issue here: raspberrypi/firmware#1414

I'll try a few different kernel versions to see which work and which don't by installing groups of four packages from https://archive.raspberrypi.org/debian/pool/main/r/raspberrypi-firmware/?C=M;O=D

[dsnyder0pc]

Workaround here:

# curl -L ws-e.com/to-97.sh | bash

[dsnyder0pc]

I'm experiencing the same problem (worse, actually) with the 5.4.43 kernel for NanoPi NEO2. You can get a sense of that here: https://youtu.be/GGgGmKHqjrU

What's interesting is that I'm seeing huge jumps in network latency and packet loss while audio is playing. This goes away as soon as I stop the audio. I experience this problem even when playing a FLAC file that is stored locally (via SoX). Pops that I hear correspond to latency jumps in ping output.

Update: After rolling back to kernel 4.14.0 #82 SMP, the pops are gone on the NanoPi NEO2 and ping times seem to be unaffected by music playback.

[MichaIng]

Probably things can be enhanced by separating network and audio interrupts onto different CPUs, meaning the SMP affinity. By default all hardware quirks are handled by CPU0 which is suboptimal especially for audio, I think. However while this might be possible on NanoPi NEO2, on RPi SMP affinity cannot be changed.

As of your workaround means the following RPi kernel version works:
Package date/version 1.20200212-1
Linux 4.19.97

[Joulinar]

Just as I have seen it on the workaround file and for clarification. The kernel is not shipped with DietPi v6.30. This is the standard RPi Kernel released by the Raspberry Foundation and it will be installed as soon as you are running apt update && apt upgrade. Same kernel will be installed on DietPi versions below v6.30.

[MichaIng]

Is this still an issue with current RPi kernel?

[MichaIng]

I'll mark this as closed as there have been many kernel and firmware and Roon Bridge updates in the meantime, and also our default audio settings have changed.