undefined | Better HN

0 pointsnyanpasu641y ago0 comments

How do you measure scheduling jitter of audio drivers and userspace? I hear real-time priority or kernels improve latency? (There was some controversy about Ubuntu Studio or something switching to RT kernels with more missed deadlines than RT-PREEMPT, but I don't know how to quantify this stuff.)

0 comments

raphlinus1y ago

That's actually a very good question. To some extent, performance analysis tools may be able to give you high-accuracy timestamps of things involving context switches and other things that can cause scheduling jitter. If you can get access to things like the fill level of FIFO buffers, even better. You may also be able to do experiments like cutting buffer sizes down to the bone to see how low they can go without glitching.

Of course, it's not unusual that the many layers of abstraction in modern systems actively frustrate getting real performance data. But dealing with that is part of the requirements of doing real engineering.

nyanpasu64OP1y ago

For context switch timestamps would I be using something like perf on Linux?

Would buffer level checking entail, eg. checking snd_pcm_avail() when my audio code begins and ends (assuming I'm talking directly to hardware rather than PipeWire)? Dunno if PipeWire has a similar API considering it's a delay-based audio daemon and probably checking snd_pcm_avail when a client requests would slow it down.

PaulDavisThe1st1y ago

Buffer level makes almost no sense.

All that matters is/are:

1. how soon after the device deadline (typically marked by an interrupt) until a kernel thread wakes up to deal with the device? (you have no control over this)

2. what is the additional delay until a user-space application thread wakes up to deal with the required data flow? (you have very little control over this, assuming you've done the obvious and used the correct thread scheduling class and priority)

3. does user space code read & write data before the next device deadline? (you have a lot of control over this)

As noted above, cyclictest is the canonical tool for testing the kernel side of this sort of thing.

PaulDavisThe1st1y ago

cyclictest(8) is the canonical tool for starting out down this pathway. That measures basic kernel stuff relevant to this area of inquiry.

However, since actual context switch times depend a lot on working set size, ultimately you can't measure this stuff accurately unless you instrument the actual application code you are working with. A sample playback engine is going to have very different performance characteristics than an EQ plugin, even if there is theoretically more actual computation going on in the latter.

binary1321y ago

also interested in the answer to this

j / k navigate · click thread line to collapse

0 comments

raphlinus1y ago

nyanpasu64OP1y ago

For context switch timestamps would I be using something like perf on Linux?

PaulDavisThe1st1y ago

Buffer level makes almost no sense.

All that matters is/are:

1. how soon after the device deadline (typically marked by an interrupt) until a kernel thread wakes up to deal with the device? (you have no control over this)

3. does user space code read & write data before the next device deadline? (you have a lot of control over this)

As noted above, cyclictest is the canonical tool for testing the kernel side of this sort of thing.

PaulDavisThe1st1y ago

cyclictest(8) is the canonical tool for starting out down this pathway. That measures basic kernel stuff relevant to this area of inquiry.

binary1321y ago

also interested in the answer to this

j / k navigate · click thread line to collapse