real time linux audio

I’d like to get an opinion on this howto I just put the finishing touches on. It fills the basic need of having everything the new linux audio user needs to know about for configuring his/her system for real time work. Or at least that is the point, If i’ve missed something, please let me know and if possible give me a reference to where I can find more info and I’ll add it. Thanks, the links are below.

Open Office Text:
http://silenceisdefeat.org/~atomic/realtime-audio-howto.odt

PDF:
http://silenceisdefeat.org/~atomic/realtime-audio-howto.pdf

nice work… some of the things in there i am yet to try on my system (rt prio of irq threads mainly).

just a question: what exactly does the card-options=seq-rtctimer-default for alsa config do? i have a custom compiled kernel (with rt etc) but left alsa etc as is on ubuntu gutsy. any ideas if i should recompile alsa? i’d only do it if it gave definite improvements, as i don’t want to risk stuffing any packaging things up.

porl

Great guide, I just set mine up, and to save time finding the PID’s, i did this:

ps -e | grep timer

It will only list the PID’s that have ‘timer’ in the description.

mm0

I’ve been screwing around with the elusive “linux low latency” for so long I forgot how to play music. I’m beginning to think it’s a myth. Can’t. Achieve. Low. Latency. Okay, enough complaining… Thanks to dcsimon for taking the time with the posted guide. Everything in this guide corresponds with my setup, save the following:

• kernel config: how important is setting default IO scheduler to CFQ?
• I’m running a dual processor. could this be hurting things?
• my audio card is sharing an IRQ with an unused USB port and ahci. Is that killing me?
• I did not recompile my own ALSA stuff, but I’m pretty sure it’s been compiled with the correct flags (got it from CCRMA)

I’m running:
Planet CCRMA’s RT kernel on Fedora 7: 2.6.22.6-1.rt9.3.fc7.ccrmart
1 GB Ram
Dual Intel 2.1 GHz

Different guides have recommended setting priority for IRQs and timers to different ways, I feel like I’ve tried them all. Even with setting high priority for chosen IRQs, jack, and timer threads, if I configure jack to get down to sub 20msec, I get choppy audio, Xruns, the whole crap. and mousing around with the UI clearly affects the XRuns directly, so it’s as if setting priorities hasn’t changed anything.

Any suggestions on how to determine what it is that is going wrong? a checklist?

Thanks,
-cmaren

question is : do you need sub 10ms latency ? unless you’re doing software monitoring with plugins active when recording on top of things, I don’t think this is really necessary. I managed to get down to a nominal 1.3ms but I realized in the end that it is useless to me. Because it makes the system a bit more unstable, I tried the default #frames, i.e. 1024 (still with realtime priority of course), and it is just flawless. Thanks to h/w monitoring, I have no practical latency … no that’s not true in fact. I have some issue when I forget to bypass jamin (I have jamin plugged to ardour most of the time) and I record a new track on top of my session. The track waveform is delayed by a few tens of milliseconds. Maybe there’s a way to compensate for jamin’s latency ? But pressing the jamin bypass button is enough. The only xruns I get now are when a jack client crashes miserably :smiley: and my system is up for days, haven’t rebooted for … a long time … since I switched back to kernel 2.6.22 I think … (2.6.23 turned out not so good for me).

by the way, I have an Intel Core 2 Duo (E6600 or 2x2.4 GHz). No issue with this.

I took a shower while considering this carefully. With hardware monitoring, I’ll be able to record comfortably. But regardless of jamin, doesn’t this mean the track always hits disk 30-40msec behind? I gathered from a product review for the M-Box for example, that part of the recording workflow involves a hot key that nudges your track back 30msec. Maybe this is a standard practice for anyone who doesn’t have a mac and doesn’t want to grind on the low latency thing? I’m interested though that you got it down so low and still decided you would rather just roll with hardware monitoring. But I’m curious how most people do. Thanks for posting.

But regardless of jamin, doesn’t this mean the track always hits disk 30-40msec behind?

not to my knowledge. I would have noticed that from the start. No, everything is on the beat. Of course, when I record say a bass line, I get random errors (I am human :)), but the error distribution is not systematically delayed by a few tens of milliseconds. When I record a software like HG sync’ed with jack transport, it’s right on. Really, when I came to think of it, h/w monitoring was all I needed. In fact, the ardour option I chose is “external monitoring”, I don’t try to use the h/w monitoring option that comes with jack or ardour, the hdspmixer app doing all the job (my system is based on the RME Hammerfall DSP). And now that I found near perfect stability, I won’t change my setup for a long while I think, except for bug fixes …

About the 1.3ms latency I reached, yeah that was a great achievement since I’ve been fiddling around linux-rt, jack and others for years. But I got some instability (mainly triggered by the GUI, or so it seemed) and were too frequent to my taste …

But after all, it could be that ardour automatically compensates. An ardour dev could confirm. If so, it works great because I never noticed any delay :slight_smile:

I’m not and ardour dev, but I have talked through this issue with them and yes Ardour does compensate. It compensates for latency both from your live recordings and from plugins (if they report their latency of course). I wish someone had put this as a big note somewhere…maybe a dev could write a brief and clear explanation and make it a sticky in the forums! So many people spend hours trying to get their latency down, when in reality they will never be performing live and have absolutely no need for it. I have the same setup as you Thorgal, use RME HDSP 9652 and the hdspmixer to route my monitoring. It’s correct to ignore the H/W monitoring options in JACK. Still don’t know the difference between HW and external monitoring option in ardour…I can’t hear any difference personally…The only time where I have found software monitoring helpful is when I am playing something like a guitar clean into my pc and want to add a VST preamp and cabinet emulator, other than that I always use hardware monitoring.

Hey! that was it :slight_smile: nice job, I couldn’t care less about latency in the way I do things in my studio :slight_smile:
Solv, I can’t either tell you the exact difference in philosophy between h/w monitoring and external monitoring but I can describe the diff empirically :

when I choose option “h/w monitoring” in jack, each time I start or stop jack, my hdspmixer setting is affected. For example, I have a few mono sources that I pan dead-center for monitoring in hdspmixer. This setting is lost when I start or stop jack. It’s like an internal reset of the HDSP setting (default is pan-left or pan-right, depending on the input number). Clicking on the preset buttons of hdspmixer brings back my normal setups. Not using this jack option has no affect whatsover on my hdsp system (I realized this after … a few days toying around with my system! … what do you know! embarassing … ;).

oy - thanks everyone for all this helpful input. Much appreciated.

thanks for writing this. it is helpful. :slight_smile:

I’m not following the section on using chrt on threads 100%.

for example, on my system, with ps -e I see:

# ps -e PID TTY TIME CMD 1 ? 00:00:00 init 2 ? 00:00:00 kthreadd 3 ? 00:00:00 migration/0 4 ? 00:00:00 ksoftirqd/0
so I would apply: chrt -f -p 99 4

but I’m not following the section on cat /proc/interrupts

On mine, I getthe following. My sound card that Ic are about is EMU10K1.
I do not see how to apply the chrt command to this…

thanks!

cat /proc/interrupts

       CPU0       

0: 877 IO-APIC-edge timer
1: 1653 IO-APIC-edge i8042
6: 3 IO-APIC-edge floppy
8: 2 IO-APIC-edge rtc
9: 0 IO-APIC-fasteoi acpi
14: 29854 IO-APIC-edge ide0
16: 8141 IO-APIC-fasteoi eth0
17: 3 IO-APIC-fasteoi ohci1394, SiS SI7012
18: 4 IO-APIC-fasteoi ehci_hcd:usb1
19: 15417 IO-APIC-fasteoi ohci_hcd:usb2
20: 0 IO-APIC-fasteoi ohci_hcd:usb3
21: 85 IO-APIC-fasteoi ohci_hcd:usb4
22: 43760 IO-APIC-fasteoi nvidia
23: 76389 IO-APIC-fasteoi EMU10K1
NMI: 0
LOC: 260515
ERR: 0
MIS: 0

I’m starting jackd with the following:

jackd --realtime -R -dalsa -r48000 -p512 -n2 -D -Chw:0,2 -Phw:0,3

and in top, it still has a priority of 20, not RT. …

I can manually set jackd to RT with chrt. then it shows up as RT in top.

I still seem to get as many xruns as I did before… too many! :frowning:

thank you for making this document, though.

  • Edit, double post *

card-options=seq-rtctimer-default was an error on my part, after some benchmarking this has only been shown to cause problems. The pdf will be updated when the site comes back online and in the future please refer to Alsa Wiki: Realtime HowTo

-dcsimon

For what it’s worth, to follow up on my previous efforts: this weekend I built a recording setup on a 7r old 1.4 Ghz machine. Same setup as on my current super hotshot gaming box:Fedora 8 with the Planet CCRMA low-latency kernel/rtprio RPMs. I wasn’t even really trying to get the RT stuff working, I just wanted another recording box. Right after booting with the RT kernel, I was running Jackd at 1.3msec easy, no XRuns. couldn’t believe it.

All I’m saying is when the low latency kernel works, it just works. cool. I have a feeling my sweet gaming box is not working nicely because the audio is sharing IRQ with like a billion other things (USBs, sata shtuff, etc).

Alllll that said, to thorgal’s original point, practical recording scenarios don’t necessarily call for low latency at all. so whatevs.

Thorgal’s point is a good one, but I need low latency. I’m running VST instruments under dssi. They actually run very well but without low latency they are of course unuseable. I’ve got mine down to 10ms which is low enough, but I always want more… :slight_smile:

So I read this excellent and helpful document (I wish I’d read it a couple of months ago… :-)) but it left me with some questions…

I’m running a 2.6.22 kernel which I’ve built myself using a Mandriva source RPM. As far as I can tell this already has the realtime patch applied - my ‘make xconfig’ allows me to set the Preemption type as ‘Preemptible Kernel (Low Latency Desktop)’. I made the changes to limits.conf and I am able to start jack in realtime mode. So I think I have low latency and realtime working and I don’t need to apply the patch. Am I right? My confusion comes from the fact that I have no hrtimer or softirq-timer threads or anything like that when I run ps -e | grep timer. The only recommended kernel option I’ve not set is ‘Enhanced Real-Time Clock Support’, because I didn’t understand the instructions (it talked about having to create something in /dev).

Finally, I’m running a firewire sound ‘card’. /proc/interrupts is slightly confusing. Am I right in assuming that the IRQ thread for my card is the one running ohci1394?

       CPU0

0: 433050 XT-PIC-XT timer
1: 3300 XT-PIC-XT i8042
2: 0 XT-PIC-XT cascade
5: 31525 XT-PIC-XT uhci_hcd:usb3, VIA8233
6: 5 XT-PIC-XT floppy
9: 0 XT-PIC-XT acpi
10: 8983 XT-PIC-XT ohci1394, uhci_hcd:usb2
11: 189967 XT-PIC-XT uhci_hcd:usb1, eth0, nvidia
12: 1771 XT-PIC-XT ehci_hcd:usb4
14: 12194 XT-PIC-XT ide0
15: 35629 XT-PIC-XT ide1
NMI: 0
LOC: 0
ERR: 8
MIS: 0

As far as I can tell this already has the realtime patch applied - my ’make xconfig’ allows me to set the Preemption type as ’Preemptible Kernel (Low Latency Desktop)’.

Nope, you need to apply the real time kernel patch to get your latency any lower. Take another look at the document at the top of this thread. You want “Complete Preemption (Real Time)”, and the other options listed.

OK thanks, that clears up my confusion. It’s wierd, I have all the options listed except Complete Preemption, and I’m able to start jack in real time mode (although top never shows it as having a priority higher than 20). Unfortunately I get errors when I try to apply the real time patch - things like some files don’t exist and others I didn’t understand at all. The Mandriva kernel source I’m using already contains some patches, so perhaps there is a conflcit between the Mandriva patches and the real-time patch.

Mandriva actually supply a kernel with the rt patch already applied, but this doesn’t have any of their other patches, or third pary drivers, and doesn’t work at all on my machine.

I think I’ll stick with my 10ms, it’s low enough. I think I’m getting too deeply into things I don’t understand, and when that happens it usually results in me re-installing my machine :smiley:

you just need a vanilla kernel (from kernel.org). Don’t use the mandriva source with the rt patch, you will only get weird patching.

Yeah actually I’ve just seen another post that I think explains my problem… Mandriva’s RT kernel didn’t work on my machine at all (it crashed). I’ve just read another post that says to avoid VIA hardware… yep, I’ve got VIA hardware… (Well I did get it for practically nothing) :-)… so I think my realtime experiments end here until I can afford a proper computer :slight_smile:

Just FYI the guy who is the ArchLinux rt kernel maintainer has hacked it so you can use latencytop. Good stuff for rt kernel hackers. I thought the rt patches had to be exclusive but I guess not. I’ll provide info if requested.