Hello,
I'm facing an issue during audio playback with GStreamer (but also happens with aplay).
The audio stream is somehow corrputed with a high frequency ringing. It seems like scambled data on the audio stream. It lasts from several hunderds of ms to some seconds. The audio stream is flowing right and this noise seems overimpressed.
Context: custom CM4 board, 32 OS built with yocto (kirkstone) and kernel is on version 5.10.110
The audiocards on which this happens are 16 or 24 channel USB 2.0 HS audio cards. There are no errors, from alsa or from usb stack (also tried to dump the full log of isochronous transfer, nothing strange appears).
After lot of investigations I found that the issue happens when a video is played concurrently (both on the same Gstreamer pipeline and on two different applications), and seems linked to the seek operation in the video playback (jsut like an overload of the H.264 system/ memory access).
This issue has been partually addressed with an hack - midifying the affinity of xhci irq kernel thread to a different cpu than 0. However, this issue sometimes pops up.
Is this an already know issue, or does someone have an idea?
Note: some CM4 devices show this behaviour more than others.
I'm facing an issue during audio playback with GStreamer (but also happens with aplay).
The audio stream is somehow corrputed with a high frequency ringing. It seems like scambled data on the audio stream. It lasts from several hunderds of ms to some seconds. The audio stream is flowing right and this noise seems overimpressed.
Context: custom CM4 board, 32 OS built with yocto (kirkstone) and kernel is on version 5.10.110
The audiocards on which this happens are 16 or 24 channel USB 2.0 HS audio cards. There are no errors, from alsa or from usb stack (also tried to dump the full log of isochronous transfer, nothing strange appears).
After lot of investigations I found that the issue happens when a video is played concurrently (both on the same Gstreamer pipeline and on two different applications), and seems linked to the seek operation in the video playback (jsut like an overload of the H.264 system/ memory access).
This issue has been partually addressed with an hack - midifying the affinity of xhci irq kernel thread to a different cpu than 0. However, this issue sometimes pops up.
Is this an already know issue, or does someone have an idea?
Note: some CM4 devices show this behaviour more than others.
Statistics: Posted by ballscrew — Mon May 06, 2024 8:14 am
