This is on an
ARM embedded system, with a single core 1MHz processor.
Is that a typo or are you really running on a 1MHz processor? If so that
would be a really slow clock. That would be two orders of magnitude
slower than most M class microcontrollers.
Big typo! I am running on a TI 1GHz AM3358 processor.
I have a
custom compiled 4.14 kernel with omap2plus_defconfig with the
following config settings:
I would not consider CONFIG_PREEMPT_VOLUNTARY appropriate for low latency
use, and especially if you are really running a 1MHz processor. Using the
full RT patch set would be recommended, or at the very least
I've been using CONFIG_PREEMPT also in other places, I have been
wondering whether the full RT patch will cause less throughput for the
Both jack and my application are requesting SCHED_FIFO, I am not sure
of the priority of the application but I am thinking of setting them
both to 70-80.
What about HZ, I currently have this set to HZ_100. Would HZ_1000 be any better?
Currently I have CONFIG_NO_HZ_IDLE set. Would CONFIG_HZ_PERIODIC be
any better? I doubt it, as my processor is never idle :-).
Can you suggest any other options that may improve things?
What audio hardware are you running?
Are you using an ALSA driver from the current kernel tree?
It's an 6-channel in, 6-channel out card with a simple ALSA driver
written by me. The driver just binds the codecs to the CPU, nothing
latent in there. All of the FIFO stuff is taken care of by the TI
Currently the driver reads & writes to 8 channels but two of the out
channels are unused, I can possibly try to gain some performance here.
$ jackd -R
-P95 -dalsa -dhw:0 -r48000 -p64 -n2
> JackPosixProcessSync::LockedTimedWait error usec = 5000000 err =
> Connection timed out
> Driver is not running
> Cannot create new client
> CheckSize error size = 32 Size() = 12
> CheckRead error
> CheckSize error size = -1 Size() = 4
> CheckRead error
> CheckSize error size = 0 Size() = 12
> CheckRead error
If those messages all came right at
startup from jack it would seem that the parameters don't match something,
but jack usually gives better error messages than that. There were never
any messages indicating that the requested sample rate was actually used,
word length used, etc?
Sorry, I missed out the first part of the log. The LockedTimedWait
error came when my client tried to connect. I think it's to do with
the Kernel scheduling.
Missing those messages could perhaps indicate that
jackd was not able to
open the ALSA device at all.
It manages to open and all performs fine at 128 frames.
higher buffer sizes sometimes I get xruns.
You are running PREEMPT_VOLUNTARY on a 1MHz processor, a more typical
configuration for low latency use is running PREEMPT or PREEMPT_RT on an
1800MHz to 3000MHz processor, so it is a little bit hard to know where to
If you are really running a 1MHz processor, there is only time for 667
instructions for each 32 sample buffer at 48kHz rate. That is not very
much for a general purpose OS.
Sorry, typo'd again here!
alsa debugging, the error is:
> ALSA: PCM: [Q] Lost interrupts?: (stream=0, delta=221,
> new_hw_ptr=181343, old_hw_ptr=181122)
I would start with a better scheduler, PREEMPT or preferably PREEMPT_RT.
The usual advice these days is that you don't really need PREEMPT_RT, but
that is usually for someone running a multi GHz processor and running at a
period size 256 samples or larger. For 64 or 32 sample period size on a
slow processor you are going to have to get aggressive with optimizing.
Thanks. This is a good starting point.
Really I need to choose whether I run PREEMPT or PREEMPT_RT, I will
probably just go for PREEMPT_RT.
I've not had much luck with PREEMPT_RT in the past, I don't think I've
set the priorities of interrupts properly.
I think I need to chrt the soundcard IRQ highest, then JACK, then my
AFAIK, jack already does this with the -R argument & sets the
scheduler priority to SCHED_FIFO.
Have you got any links to information, books etc on RT patch? I've
read a few and most just seem to discuss how to patch the kernel,
without any real-life examples!
Thanks again for the very useful comments,