changes to mainline 4.10 scheduler vs 4.8? + RT patches relevance

[bschiett]

Hi all

I'm working on a realtime audio application running on a rk3288
platform. The application is written in the JUCE framework, and uses
ALSA for audio output. I build the application in a debian jessie
chroot since it needs a bunch of libraries compiled for armhf.

The application used to run fine on 4.8 mainline, without noticable
audio dropouts. I had to upgrade recently to 4.10 mainline to get the
audio gadget driver working, but now the application has audio
dropouts (pause in the audio output).

I have been using 44100 hz sample rate and 960 samples buffer size for
testing. I increased the buffer size to 1280 which seemed to improve
things a little, and then after googling around I changed the IO
scheduler to noop (it was set to CFQ), which further increases the
performance. I now only have occasional audio dropouts.

The application does a lot of I/O via HID and has 4 audio processing
threads for signal processing, besides other threads and callbacks for
HID I/O.

Questions:

1) Does anyone know if something has changed between kernel 4.8 and
4.10 with regard to the scheduler that might negatively impact
realtime audio or RT performance in general?
2) are there specific kernel settings I should check?
3) I am wondering if RT patches are still relevant for newer kernels
like 4.8 and 4.10?
4) I saw that the latest patches are for kernel 4.4, can they be
applied to later kernels and is that a good idea or not?

Thanks
B

[folderol]

Why are you using those buffer sizes. They seem very strange. People mostly use powers of two.

[bschiett]

Why are you using those buffer sizes. They seem very strange. People mostly use powers of two.

because when I query ALSA using my code in JUCE, I print all the supported sample rates and buffer sizes, and those buffer sizes are in the list, so they should work.

I didn't have a problem with buffer size 960 on kernel 4.8, but on kernel 4.10 I do. so I changed it to 1280 on kernel 4.10 and it is better but I still get occasional pauses in the audio. Changing the IO scheduler to noop also improved things, so there must be something that changed between 4.8 and 4.10 that has to do with the way threads are scheduled or with the priorities of threads, etc.

[GMaq]

Hi,

I'm still on kernel 4.4 so I don't know the latest features, however generally speaking...

A few years ago when IRQ threading entered the mainline kernel and there were basically only PCI, USB-1 and FireWire Audio devices as the main choices for Linux users the need for a kernel with full RT Preempt nearly disappeared completely, many people found that a 'lowlatency' kernel was sufficient to achieve very low latencies. In the recent past with the advent of many USB-2 Audio devices being supported under Linux by virtue of them being class compliant once again many (not all) people find certain USB-2 devices respond quite favorably to full RT Preempt as a means of getting latencies down.

Of course this varies with both the Audio device's hardware and the PC's hardware but in my own experience with 2 separate devices (Presonus 1818VSL and a Focusrite Scarlett 2i2) going full RT allows me to cut latency in half... YMMV

[folderol]

Just as a matter of interest, what happens if you try buffer sizes of 512 & 1024?