Update to kernel 6.1.x breaks recording/streaming from HifiBerry #5709
Comments
|
Hi, I can concur and I am also seeing exactly the behaviour described above, also for kernel 6.1.21-v8+. |
|
Hi, I happen to have a DAC+ ADC and a quick test showed no issues at least on kernel 6.1.21 / Bullseye. Sometimes having a success case can help. Pipeline Here's some console output. |
|
@moodeaudio Would you mind trying to reproduce my FFmpeg example instead of an ALSA loop? |
|
Sure, no prob. As a data point the arecord command below worked fine with the DAC+ ADC and MPD was able to play the generated wav file. This suggests the ALSA plumbing is prolly ok. Bullseye ffmpeg is 4.3.6 while Bookworm includes newer version 5.1.3. Maybe this version is ok with 6.1 kernel? We are still at the beginning of Bookworm builds and so I'm not able to test much yet. |
|
Hi, After this, I get a compiled ffmpeg binary, but when I use that one, I get identical result: |
|
This is my script for compilation: |
|
Thank you for the script @dcabri. I have compiled it by hand and can confirm the issue with the latest FFmpeg on Bullseye 64-bit on a Pi 4. With the latest FFmpeg master it still only works on kernel |
|
I have a HifiBerry DAC+ ADC Pro and am using ALSA through PortAudio in my application which works with a USB sound card but cannot record nor playback anything through the HifiBerry. ALSA lists the device and aplay works. PortAudio only shows the HifiBerry after setting the environment variable PA_ALSA_PLUGHW=1. But when I select the HifiBerry as the device to use for recording and/or playback I get no sound at all! I'm on a Raspberry Pi 5 4GB running 64-bit Raspberry Pi OS Bookworm, Linux 6.1.0-rpi6-rpi-2712 aarch64. |
|
Hoping this thread is being looked at, just making a comment because some places auto-close if there are no more comments... |
|
I'm not sure if this has a relation to the issue you are experiencing, but in the meanwhile my issue got fixed. I can now record and playback from and to the same device on the RPi 5 running Bookworm. Here is the solution. Perhaps the patch also works for you: #5747 |
|
#5747 is purely Pi 5-specific, and @dcabri is using a Pi 4. I have to admit to being skeptical that a kernel bump would cause an issue that affected ffmpeg but not arecord (one of several reasons this hasn't received much attention yet), but that indeed appears to be the case. Starting with the February 2023 Bullseye release and rpi-updating to the most recent 6.1 kernel gives the same results using an old IQaudIO Pi-Codec+ board (which acts like a large form-factor rpi-codeczero board). Test commands: |
yes that’s why I asked so many people here to reproduce it |
|
Small update: ffmpeg is unable to read from the Alsa input device 'hw:CARD=sndrpihifiberry,DEV=0', however ffmpeg is able to write to the Alsa output device 'hw:CARD=C2,DEV=0'. Seems writing is easier than reading :) |
|
Not that it might matter but I have a DacBerry board I try to get running on a pi400. I setup it up and I used the default .dtbo and /lib files regmap_i2c 16384 1 snd_soc_tlv320aic3x_i2c Kernel: Linux raspberrypi 6.1.0-rpi7-rpi-v8 #1 SMP PREEMPT Debian 1:6.1.63-1+rpt1 (2023-11-24) aarch64 GNU/Linux |
|
Include a reasonable number of complete error messages, not just a fragment. |
|
Just ran rpi-update, it updated the kernel to |
|
I apologize for my earlier conclusion; it was premature. The issue is solved when testing with kernel 6.6 on a Raspberry Pi 5, but it still persists on a Raspberry Pi 4. Could you please reopen this issue @popcornmix? |
|
The issue is still persisting on 6.6.51-v8-16k+ ... I thought I'd let this be known, so this thread doesn't die... |
|
Can confirm. I've been holding back the kernel on my Pi 4 ever since opening this issue. It's not very future proof. |
|
Well, I've found the culprit: 300689f, which first appeared in Linux 5.18. Prior to this commit, the minimum PERIOD_BYTES value was 256, and with this is drops to 16. This isn't a problem for arecord which chooses a period of quarter the buffer size, which equates to 32KB). However, ffmpeg chooses the minimum possible, only falling back to a quarter buffer if no minimum is set (https://github.com/FFmpeg/FFmpeg/blob/master/libavdevice/alsa.c#L260). There should be a way of overriding that minimum somewhere in the kernel's sound subsystem - it's just a case of finding the best hook to hang it on. |
Commit [1] set the minimum PERIOD_BYTES value to the product of the DMA burst size and 8. For the I2S interface on BCM2835 that equates to 16 where it used to be 256. ffmpeg uses the minimum value as its preferred value, leading to many, many very small periods, which affects performance and leads to complaints about DTS timestamps. Restore the previous behaviour and performance by making the bcm2835-i2s driver set a minimum PERIOD_BYTES value of 256. Link: raspberrypi#5709 [1] 300689f ("ASoC: soc-generic-dmaengine-pcm: set period_bytes_min based on maxburst") Signed-off-by: Phil Elwell <phil@raspberrypi.com>
|
#6386 is a small patch that restores the minimum of 256. In about 40 minutes, once the autobuilds have completed, you will be able to install a trial kernel using |
Commit [1] set the minimum PERIOD_BYTES value to the product of the DMA burst size and 8. For the I2S interface on BCM2835 that equates to 16 where it used to be 256. ffmpeg uses the minimum value as its preferred value, leading to many, many very small periods, which affects performance and leads to complaints about DTS timestamps. Restore the previous behaviour and performance by making the bcm2835-i2s driver set a minimum PERIOD_BYTES value of 256. Link: #5709 [1] 300689f ("ASoC: soc-generic-dmaengine-pcm: set period_bytes_min based on maxburst") Signed-off-by: Phil Elwell <phil@raspberrypi.com>
Commit [1] set the minimum PERIOD_BYTES value to the product of the DMA burst size and 8. For the I2S interface on BCM2835 that equates to 16 where it used to be 256. ffmpeg uses the minimum value as its preferred value, leading to many, many very small periods, which affects performance and leads to complaints about DTS timestamps. Restore the previous behaviour and performance by making the bcm2835-i2s driver set a minimum PERIOD_BYTES value of 256. Link: #5709 [1] 300689f ("ASoC: soc-generic-dmaengine-pcm: set period_bytes_min based on maxburst") Signed-off-by: Phil Elwell <phil@raspberrypi.com>
Commit [1] set the minimum PERIOD_BYTES value to the product of the DMA burst size and 8. For the I2S interface on BCM2835 that equates to 16 where it used to be 256. ffmpeg uses the minimum value as its preferred value, leading to many, many very small periods, which affects performance and leads to complaints about DTS timestamps. Restore the previous behaviour and performance by making the bcm2835-i2s driver set a minimum PERIOD_BYTES value of 256. Link: #5709 [1] 300689f ("ASoC: soc-generic-dmaengine-pcm: set period_bytes_min based on maxburst") Signed-off-by: Phil Elwell <phil@raspberrypi.com>
|
Thanks. I have access to test hardware after the weekend. Will test with the trial kernel then. |
|
Tested with |
Commit [1] set the minimum PERIOD_BYTES value to the product of the DMA burst size and 8. For the I2S interface on BCM2835 that equates to 16 where it used to be 256. ffmpeg uses the minimum value as its preferred value, leading to many, many very small periods, which affects performance and leads to complaints about DTS timestamps. Restore the previous behaviour and performance by making the bcm2835-i2s driver set a minimum PERIOD_BYTES value of 256. Link: #5709 [1] 300689f ("ASoC: soc-generic-dmaengine-pcm: set period_bytes_min based on maxburst") Signed-off-by: Phil Elwell <phil@raspberrypi.com>
Commit [1] set the minimum PERIOD_BYTES value to the product of the DMA burst size and 8. For the I2S interface on BCM2835 that equates to 16 where it used to be 256. ffmpeg uses the minimum value as its preferred value, leading to many, many very small periods, which affects performance and leads to complaints about DTS timestamps. Restore the previous behaviour and performance by making the bcm2835-i2s driver set a minimum PERIOD_BYTES value of 256. Link: #5709 [1] 300689f ("ASoC: soc-generic-dmaengine-pcm: set period_bytes_min based on maxburst") Signed-off-by: Phil Elwell <phil@raspberrypi.com>
Commit [1] set the minimum PERIOD_BYTES value to the product of the DMA burst size and 8. For the I2S interface on BCM2835 that equates to 16 where it used to be 256. ffmpeg uses the minimum value as its preferred value, leading to many, many very small periods, which affects performance and leads to complaints about DTS timestamps. Restore the previous behaviour and performance by making the bcm2835-i2s driver set a minimum PERIOD_BYTES value of 256. Link: #5709 [1] 300689f ("ASoC: soc-generic-dmaengine-pcm: set period_bytes_min based on maxburst") Signed-off-by: Phil Elwell <phil@raspberrypi.com>
Commit [1] set the minimum PERIOD_BYTES value to the product of the DMA burst size and 8. For the I2S interface on BCM2835 that equates to 16 where it used to be 256. ffmpeg uses the minimum value as its preferred value, leading to many, many very small periods, which affects performance and leads to complaints about DTS timestamps. Restore the previous behaviour and performance by making the bcm2835-i2s driver set a minimum PERIOD_BYTES value of 256. Link: #5709 [1] 300689f ("ASoC: soc-generic-dmaengine-pcm: set period_bytes_min based on maxburst") Signed-off-by: Phil Elwell <phil@raspberrypi.com>
|
Just tested with a fresh Raspberry Pi OS 12 install that contains kernel 6.6.51+rpt-rpi-v8 after updating. It works flawlessly now on a Pi 4 and 5. Closing this. Many thanks! |
Commit [1] set the minimum PERIOD_BYTES value to the product of the DMA burst size and 8. For the I2S interface on BCM2835 that equates to 16 where it used to be 256. ffmpeg uses the minimum value as its preferred value, leading to many, many very small periods, which affects performance and leads to complaints about DTS timestamps. Restore the previous behaviour and performance by making the bcm2835-i2s driver set a minimum PERIOD_BYTES value of 256. Link: #5709 [1] 300689f ("ASoC: soc-generic-dmaengine-pcm: set period_bytes_min based on maxburst") Signed-off-by: Phil Elwell <phil@raspberrypi.com>
Commit [1] set the minimum PERIOD_BYTES value to the product of the DMA burst size and 8. For the I2S interface on BCM2835 that equates to 16 where it used to be 256. ffmpeg uses the minimum value as its preferred value, leading to many, many very small periods, which affects performance and leads to complaints about DTS timestamps. Restore the previous behaviour and performance by making the bcm2835-i2s driver set a minimum PERIOD_BYTES value of 256. Link: #5709 [1] 300689f ("ASoC: soc-generic-dmaengine-pcm: set period_bytes_min based on maxburst") Signed-off-by: Phil Elwell <phil@raspberrypi.com>
Commit [1] set the minimum PERIOD_BYTES value to the product of the DMA burst size and 8. For the I2S interface on BCM2835 that equates to 16 where it used to be 256. ffmpeg uses the minimum value as its preferred value, leading to many, many very small periods, which affects performance and leads to complaints about DTS timestamps. Restore the previous behaviour and performance by making the bcm2835-i2s driver set a minimum PERIOD_BYTES value of 256. Link: #5709 [1] 300689f ("ASoC: soc-generic-dmaengine-pcm: set period_bytes_min based on maxburst") Signed-off-by: Phil Elwell <phil@raspberrypi.com>
Commit [1] set the minimum PERIOD_BYTES value to the product of the DMA burst size and 8. For the I2S interface on BCM2835 that equates to 16 where it used to be 256. ffmpeg uses the minimum value as its preferred value, leading to many, many very small periods, which affects performance and leads to complaints about DTS timestamps. Restore the previous behaviour and performance by making the bcm2835-i2s driver set a minimum PERIOD_BYTES value of 256. Link: #5709 [1] 300689f ("ASoC: soc-generic-dmaengine-pcm: set period_bytes_min based on maxburst") Signed-off-by: Phil Elwell <phil@raspberrypi.com>
Describe the bug
I have a Hifiberry DAC ADC that I use to stream audio with ffmpeg. This worked great with
2023-02-21-raspios-bullseye-arm64-lite. After doing an OS update and going from kernel5.15.84to kernel6.1.0the streaming stopped working with ALSA errors and ffmpeg can't read from the device any more. The ffmpeg version stayed the same so that's not it.Steps to reproduce the behaviour
2023-02-21-raspios-bullseye-arm64-liteand don't upgrade, ensure you have kernel5.15.84-v8+ffmpeg -f alsa -channels 2 -sample_rate 48000 -hide_banner -re -y -i default:CARD=sndrpihifiberry /tmp/test.wav6.1.0Device (s)
Raspberry Pi 4 Mod. B
System
Logs
Kernel 5.15
Kernel 6.1.0-rpi6-rpi-v8
Additional context
This is reproduced on the exact same Pi, with the exact same hardware, the exact same audio input and the exact same ffmpeg version. I could also reproduce this with another card: the HiFiBerry Digi+ I/O.
Also tried this with Ubuntu which has the same problem. Ubuntu 22.04 LTS has kernel 5.15 which works. Ubuntu 23.10 has kernel 6.1.x and has the same problem.
When installing
2023-02-21-raspios-bullseye-arm64-liteand holding back theraspberrypi-kernelpackage in apt but upgrading everything else, it keeps working. I'm pretty sure this is kernel related.The text was updated successfully, but these errors were encountered: