You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When using the CX31993 USB sound card on a Raspberry Pi Zero 2W with application running in KMSDRM mode, the audio is choppy, even when selecting a low sampling rate. However, the same USB sound card works without interruptions on a Raspberry Pi 4B. Additionally, using a different USB sound card on the Raspberry Pi Zero 2W does not result in audio issues.
This problem has been observed for a long time ago and remains unresolved, even with the latest updates.
It is suspected that the issue is related to the USB device driver, as the interruptions only occur with this specific device RPI02W and CX31993 USB sound card combination.
Steps to reproduce the behaviour
Use Raspberry Pi Zero 2W with the default clock speed, running on latest Raspi-OS lite aarch64.
Connect an HDMI display (using a 1280x1024@60 resolution).
Connect a USB hub with a keyboard and a CX31993 USB sound card.
Run sudo reboot to restart the system.
Create a test directory and navigate to it: mkdir TEST && cd TEST
This bug is not related to the ffplay code. I initially encountered this issue in my own SDL application that uses the librtaudio-dev library for audio playback. Upon further investigation, I found that the same problem occurs in ffplay when running in KMSDRM mode. Therefore, to simplify reproducing the issue, I used the standard ffplay program.
The text was updated successfully, but these errors were encountered:
qrp73
changed the title
[rpi zero 2w][KMSDRM] CX31993 USB sound card; crackle sound; USB driver issue; ALSA lib pcm.c:8570:(snd_pcm_recover) underrun occurred 0B f=0/0 #265
[rpi zero 2w][KMSDRM] CX31993 USB sound card; crackle and choppy sound; USB driver issue; ALSA lib pcm.c:8570:(snd_pcm_recover) underrun occurred 0B f=0/0 #265
Oct 5, 2024
You would probably be better off with a 32-bit install.
32-bit kernel uses the FIQ to improve performance of the dtw_otg usb driver.
There is not FIQ support on the 64-bit kernel, which reduces USB performance.
I prefer a 64-bit kernel as it enables 64-bit integer computations with reduced overhead. I experimented with a 32-bit kernel, but encountered significant performance bottlenecks for my algorithms and additional issues.
Regarding memory usage, I'm utilizing swap in zram because running tasks like apt update on Raspi-OS Lite with only 512 MB of RAM is nearly impossible without it. However, for my needs, 100 MB of memory for user code is sufficient, speed is more important to me.
Describe the bug
When using the CX31993 USB sound card on a Raspberry Pi Zero 2W with application running in KMSDRM mode, the audio is choppy, even when selecting a low sampling rate. However, the same USB sound card works without interruptions on a Raspberry Pi 4B. Additionally, using a different USB sound card on the Raspberry Pi Zero 2W does not result in audio issues.
This problem has been observed for a long time ago and remains unresolved, even with the latest updates.
It is suspected that the issue is related to the USB device driver, as the interruptions only occur with this specific device RPI02W and CX31993 USB sound card combination.
Steps to reproduce the behaviour
Use Raspberry Pi Zero 2W with the default clock speed, running on latest Raspi-OS lite aarch64.
Connect an HDMI display (using a 1280x1024@60 resolution).
Connect a USB hub with a keyboard and a CX31993 USB sound card.
Run
sudo reboot
to restart the system.Create a test directory and navigate to it:
mkdir TEST && cd TEST
Download the test audio file:
Expected result: The sound is played correctly, without issues.
ffplay
withSDL_VIDEODRIVER=kmsdrm
:Expected result: The sound should be played correctly.
Actual result: The sound is played choppy with crackling noises, and multiple errors appear in the console output:
Device (s)
Raspberry Pi Zero 2 W
System
Logs
Additional context
This bug is not related to the
ffplay
code. I initially encountered this issue in my own SDL application that uses thelibrtaudio-dev
library for audio playback. Upon further investigation, I found that the same problem occurs inffplay
when running in KMSDRM mode. Therefore, to simplify reproducing the issue, I used the standardffplay
program.The text was updated successfully, but these errors were encountered: