18 Jul
2020
18 Jul
'20
10:28 p.m.
Hi list,
I have a Focusrite Scarlett 3rd Gen interface that is producing audio
glitches with a Raspberry Pi 4 running a realtime kernel (or not). I had
similar problems on a laptop and on a desktop. On the laptop however it
now runs perfectly with the very latest Linux Mint and the standard
kernel. On my desktop I get acceptable results with AV Linux although
haven't tried it with the latest Mint. There are no error messages
reported or overruns, just glitches which are independent of buffer
sizes and sample rates.
The kernel installation procedure that I used for the Pi 4 is here:
https://lemariva.com/blog/2019/09/raspberry-pi-4b-preempt-rt-kernel-419y-pe…
and the actual kernel that I built is: 4.19.71-rt24-v7l+
Can suggest some things to try?
Thanks a lot.
Iain
19 Jul
19 Jul
10:41 a.m.
On 7/18/20 8:28 PM, Iain Mott wrote:
Hi list,
I have a Focusrite Scarlett 3rd Gen interface that is producing audio
glitches with a Raspberry Pi 4 running a realtime kernel (or not). I had
similar problems on a laptop and on a desktop. On the laptop however it
now runs perfectly with the very latest Linux Mint and the standard
kernel. On my desktop I get acceptable results with AV Linux although
haven't tried it with the latest Mint. There are no error messages
reported or overruns, just glitches which are independent of buffer
sizes and sample rates.
Hi,
on a rpi 4 and with a "RT-PREEMPT-FULL y" kernel you also want to change
the IRQ thread priority of the xhci (usb host controller). I think it's
always on the same irq line (at least it's for me on two different rpi4s).
This should do the trick:
schedtool -F -p 90 $(pidof irq/38-xhci_hcd)
This seems to make the audio processing on my rpi4 *much* more robust to
SD-card accesses. Before my daily borgbackup job at 6am caused a storm
of xruns. Now none at all anymore.
You mentioned no xruns reported by the software so in principle this
_should_ have no effect. Possibly the software xrun reporting is broken
though, so give it a shot.
Also make sure that you run your audio processing threads with a realtie
priority higher than 50 (the default priority for irq handler threads in
the kernel). With jack I'd recommend running it with
jackd -R -P 80 ...
Regards,
FPS
--
https://fps.io
3:36 p.m.
Thanks Florian. I tried using the schedtool line that you suggest and
changing the priority value in Jack but the problem continues. I believe
the 3rd generation Scarlett interfaces are a special case with many
Linux users giving up on them entirely. Yesterday evening I found a
thread which reports a solution and a patch for the kernel file
sound/usb/pcm.c. I've not yet managed to apply the patch, for some
reason, but I'll keep trying and report back if i get anywhere. The
patch is attached in the 3rd message on this page (you need to be logged
in to see it): https://linuxmusicians.com/viewtopic.php?f=6&t=21163&start=60
Cheers,
Iain
Em 19/07/2020 03:41, Florian Paul Schmidt escreveu:
On 7/18/20 8:28 PM, Iain Mott wrote:
Hi list,
I have a Focusrite Scarlett 3rd Gen interface that is producing audio
glitches with a Raspberry Pi 4 running a realtime kernel (or not). I had
similar problems on a laptop and on a desktop. On the laptop however it
now runs perfectly with the very latest Linux Mint and the standard
kernel. On my desktop I get acceptable results with AV Linux although
haven't tried it with the latest Mint. There are no error messages
reported or overruns, just glitches which are independent of buffer
sizes and sample rates.
Hi,
on a rpi 4 and with a "RT-PREEMPT-FULL y" kernel you also want to change
the IRQ thread priority of the xhci (usb host controller). I think it's
always on the same irq line (at least it's for me on two different
rpi4s).
This should do the trick:
schedtool -F -p 90 $(pidof irq/38-xhci_hcd)
This seems to make the audio processing on my rpi4 *much* more robust to
SD-card accesses. Before my daily borgbackup job at 6am caused a storm
of xruns. Now none at all anymore.
You mentioned no xruns reported by the software so in principle this
_should_ have no effect. Possibly the software xrun reporting is broken
though, so give it a shot.
Also make sure that you run your audio processing threads with a realtie
priority higher than 50 (the default priority for irq handler threads in
the kernel). With jack I'd recommend running it with
jackd -R -P 80 ...
Regards,
FPS
--
https://fps.io
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-user
1930
days inactive
1931
days old
linux-audio-user@lists.linuxaudio.org
2 comments
2 participants
participants (2)
-
Florian Paul Schmidt -
Iain Mott