Low Latency Kernel ?


Kev2442

Kev2442

Still French
Joined
Nov 4, 2014
Messages
646
Location
42 (Loire) is the answer.
I remember the OpenPandora's audio circuit has been designed by an audiophile, such as using Burr-Brown chips. The Pyra inherits this attention with a good TI DAC and a case optimised for the included speakers. But what about the software ?
Low latency kernel is a must for many Linux audio enthusiasts (especially when you're recording or live mixing), and while it would be quite a bit overkill to run a full real-time OS when you're just a multimedia device running on a battery, I don't know what the harm would be using the linux-lowlatency version while keeping power management in check - average user media playback is not critical enough to justify keeping all cores at max speed for the little benefit in responsiveness.
So here I am asking the question :D

Also, would there be a performance benefit to compiling every package to make use of the OMAP5's instruction set ? I guess most would not be worth the effort, but how about system packages, main dependencies, and demanding or common software ?
 
I'm not sure how necessary a real time kernel is for audio playback. Most audio system have buffers, such that as long as the kernel can service the buffer every few hundred milliseconds it all works out fine. A real time kernel would mean you could reduce those buffers and make audio more controllable, but as it is with a general purpose kernel, you can still generally time sound effects to happen concordate with the video frame or the next one, which is close enough to feel right to me at least.

There's is a slight potential benefit for compiling stuff to the ARMv7 architecture the OMAP 5 uses rather than ARMv5 that debian usually targets or a kind of rPI thing (the ARM11 in the first rPI was an ARMv6 thing). But luckily for us, the kernel coming from the letux project is built specifically for our CPU. On debian you should be free to rebuild other packages if you want.
 
Are low latency kernels still a thing even?
I thought they went obsolete since multi core cpus went mainstream.
 
levi said:
There's is a slight potential benefit for compiling stuff to the ARMv7 architecture the OMAP 5 uses rather than ARMv5 that debian usually targets or a kind of rPI thing (the ARM11 in the first rPI was an ARMv6 thing). But luckily for us, the kernel coming from the letux project is built specifically for our CPU. On debian you should be free to rebuild other packages if you want.
Click to expand...

Pretty sure Debian armhf (unlike the older softfloat arch) is already ARMv7. The main improvement for a Pyra-specific build (i.e. ARMv7VE) would be the hardware integer divide. A small - but non-zero - percentage of applications would probably see a noticeable speedup from using that. There are also some VFP/NEON improvements, but I suspect the benefit from those will be even smaller unless stuff uses intrinsics/assembly.
 
daveshah said:
Pretty sure Debian armhf (unlike the older softfloat arch) is already ARMv7. The main improvement for a Pyra-specific build (i.e. ARMv7VE) would be the hardware integer divide. A small - but non-zero - percentage of applications would probably see a noticeable speedup from using that. There are also some VFP/NEON improvements, but I suspect the benefit from those will be even smaller unless stuff uses intrinsics/assembly.
Click to expand...

For audio mixing and whatnot, a person would still want to run multiple USB mic controllers - likely through a powered hub connected the Pyra's USB 3.0 OTG port - which is a lot of cables and wires going to a tiny screen - which means that said audio engineer should likely get themselves a big touch screen laptop to handle those duties. Alternatively, putting a big touchscreen HDMI / USB monitor on the Pyra - at some point it becomes more trouble than it is likely worth.

Personally I'm way more interested in getting H.264 running for DVD (and DVD.iso) playback.
 
daveshah said:
Pretty sure Debian armhf (unlike the older softfloat arch) is already ARMv7. The main improvement for a Pyra-specific build (i.e. ARMv7VE) would be the hardware integer divide. A small - but non-zero - percentage of applications would probably see a noticeable speedup from using that. There are also some VFP/NEON improvements, but I suspect the benefit from those will be even smaller unless stuff uses intrinsics/assembly.
Click to expand...
Yeah, Exo and Ptitseb got memorable speedup from rewriting busy bits of code using NEON assembly, but that's not exactly portable code any more, so I doubt debian would be shipping a lot of that.
 
levi said:
Commercial DVD video discs are written in H.262 or MPEG1-part 2. Any film data using H.264 is either transcoded by the user, or maybe has come from a later disc format.
Click to expand...
Which, as I understand it, is included under the H.264 that the OMAP5432 "supports", though there is likely a kernel mismatch by now.
 
levi said:
I'm not sure how necessary a real time kernel is for audio playback. Most audio system have buffers, such that as long as the kernel can service the buffer every few hundred milliseconds it all works out fine. A real time kernel would mean you could reduce those buffers and make audio more controllable, but as it is with a general purpose kernel, you can still generally time sound effects to happen concordate with the video frame or the next one, which is close enough to feel right to me at least.
Click to expand...
Well for playback it's not in anyway preventing an audio player from working, but it could help with jitter and global responsiveness. I think what hurts an underpowered device (not specifically the Pyra) is more applications lagging and hanging than them taking some more time to finish. I find it much better to work with software you can predict rather than random lag spikes.

Also, on the topic of sound latency : you probably shouldn't underestimate people with OCD. Trust me, if something isn't right, they'll know.
 
Elw3 said:
Are low latency kernels still a thing even?
I thought they went obsolete since multi core cpus went mainstream.
Click to expand...
Its needed in every application where the PC is controlling something.
Like for example a CNC-mill
Its critical to prevent the PC to take its meditation-seconds because this would lead to short stops of the mill which leads to visible marks or broken tools.

There are manny other aplications where soft RT is needet.
 
Linux-SWAT said:
RT kernels for audio are mostly useful for real time monitoring/effects.
Click to expand...
Low latency has nothing to do with realtime, though - a surprisingly common misconception.

Realtime is just about the possibility to guarantee that things are finished in a set time frame, which involves special scheduling algorithms and usually somewhat fixed schedule tables as you have to plan things in advance to guarantee the realtime properties of your application software. A high latency is fine, as long as the schedule table takes it into account it's still a fully functional realtime system. Soft realtime only means that the system may implement some leeway to "catch up" if it's missing a deadline, on a hard realtime system missing a deadline would declare the system to be broken. It's all just about determinism.
 
Last edited:
Right so, hard real time is guaranteed latency. Low latency is not guaranteed, but as low as you can get it. And soft real time isn't guaranteed either, but scheduled the way hard real time is and whenever it slips it tries hard to get back on track.

I don't really see what this has to do with the Pyra. The linux kernel has lots of stuff to do in the background, maintaining your filesystem, responding to USB and network events, and logging amongst others. You could try something like RISC OS, and ensure it's not connected to any network, since that kernel's written more alike the old 8bit computers. Disc access still won't be real time, but that's a limitation of flash devices on the Pyra; no seek time, but the device might still need to mark dead bits and if you write less than a page to it, it'll need to copy the existing page, modify it in RAM then write it back, which will take a few ns I guess. But RISC OS gives you more RAM to play around with than the behemoth linux kernel, so you can do more before you need to save anything.
 
I vaguely wondered about that sort of thing on the Pandora, back when I was trying to output infrared remote control signals. The GPIO control wasn't precise enough. (Frustratingly, the SoC has a dedicated pin for Consumer IR which wasn't brought out to the EXT connector. The UART was very precise, and somehow seemed able to output a continuous stream at sufficient frequency with no gaps, but the rules of UART weren't compatible with the required output patterns. Using the AND of a UART and a GPIO, or 2 UARTs, wasn't going to work either - GPIO wasn't even precise enough for that.)
 
I guess trying to do that kind of precision stuff in userspace is unlikely to succeed. IR subsystems usually are kernel modules, and I guess that's why at least.
 
Right, I might have been able to do it with a kernel module if I'd been dedicated enough to learn how to do that ;)

Even if the CIR pin had been brought out, it would have needed kernel support too. I remember the PWM registers weren't available from userspace.
 
Last edited:
You must log in or register to reply here.

Similar threads

j0e
How will the Pyra be for low-latency audio? (for music games)
Replies
3
Views
2K
canseco
canseco
bsp
Pandora Open Pandora Super Low Latency Audio (mini howto)
Replies
4
Views
4K
bsp
bsp
C
Digital Audio Production
Replies
1
Views
1K
torpor
torpor
rSl
BMC64, a bare metal C64 emulator for the Raspberry Pi
Replies
5
Views
4K
levi
levi
notaz
beefy kernel update
2 3
Replies
40
Views
10K
uniacc24
U
Back
Top