Linux Audio/MIDI System Setup
Introduction
I figured i documented some thoughts on using a realtime preemption system for use as a audio/midi system, so i can refer to them instead of typing them out over and over in discussions :)
All the following refer to -rt kernels with the “Complete Preemption” model. This is the IMHO superior mode to operate a -rt kernel in, if you want the tightest control over latencies, priorities, etc. Watch out, that binary only drivers as the nvidia modules are probably incompatible with -rt kernels. Use the X11 nv driver instead. Even if the binary only module was compatible, it is not guaranteed that it fits into the model of the -rt kernel well and thus might destroy the low latency guarantees we get from the rest of the kernel.
Audio/Midi System
In a typical linux audio/midi system setup one finds several key components:
- The jack audio connection kit. It provides audio services and thus makes use of the soundcard. The soundcard IRQ needs to get special treatment (a.k.a. a high priority) to be undisturbed by other (i.e. disk or network) load. Jack is the premier choice for this job as it allows to connect audio apps to each other. Plus it’s designed for realtime operation from the ground up. If your system is setup right you can acieve ridicously low latencies with it (i.e. 16 or 8 samples buffersize at 48khz sampling rate).
- ALSA: providing audio services to jack and midi interfacing capabilities via alsa-seq
- Some midi sequencer (as rosegarden, muse, seq24, etc..) using jack and alsa-seq
- Some softsynths (ultimatevily being jack clients) driven by above sequencer
- Other hardware that need IRQ’s to function (disk, net, etc..)
- All kinds of other software like window managers, desktop environments, and other useful stuff :)
The -rt kernels in combination with the realtime lsm or rt_limits provide the user with great tools to make all this stuff work nicely together to make sure we get:
- Undisturbed audio operation. And when i say “undisturbed audio operation” i mean it. As an example it is no problem for me to compile a kernel while running with a buffersize of 32 samples.
- Tight midi timing
But we have to tweak the system somewhat to get this nice result. Especially some aplications need to be modified as well.
Audio setup
We can (albeit oversimplifying) say that the higher the priority of a task the more likely it is to run undisturbed. With -rt kernels we have the option of making IRQ handlers run with a lower priority than certain user space applications. It is, for example, possible to run jackd with a priority greater then all IRQ’s which might disturb audio operation (like disk or network). We need the jackd -P switch for that.
In a default -rt kernel all IRQ handler threads have default priorities in the range of 40-60, so making jackd run with a priority of 70 is a good choice here:
But we also want the soundcard IRQ handler run at a higher prio than jack, as the soundcard irq is what ultimately drives jackd. Thus we can use the chrt utility to change this (my soundcard is on IRQ 4 in my system - make sure you check in /proc/interrupts what’s yours):
A priority of 82 is well above jackd. jackd also runs threads besides its main loop. Namely a watchdog at priority 10 above its main loop (80 in this example), and all clients’ process() threads will run with a priority 1 smaller than the main loop (69).
So this has the audio part of the system covered. With this kind of settings i can achieve ridiculously low buffer sizes with jackd and my M-Audio delta 66 (even down to 8 samples/period though context switching overhead gets a bit costly here) :) But what about midi? How does it fit in?
Midi setup
Well, we need to know a thing or two on how realtime scheduling works to finetune this part. The scheduling class used by most linux audio stuff is SCHED_FIFO. This is a special scheduling class that has static priority levels (from 1 to 99) and guarantees to tasks using it that they can keep the CPU as long as they want to themselfes, given that no higher priority SCHED_FIFO task claims it (this also means that a nasty program can lock the system by simply using up all CPU time, as long as there is no other task with a higher priority to look out for runaway taks). So the tasks that have the highest priority in our system up to now are the soundcard IRQ handler thread and jackd’s threads.
Audio processing is done in chunks and to illustrate the point let us assume that we use a very large buffersize, say 1 second (i don’t know of any soundcard actually offering this buffersize, but for the sake of the gedankenexperiment let’s assume it does), which is 48000 samples at a samplerate of 48000hz. Let’s further assume our jack clients are putting quite a bit of work onto the system. Let’s say jack’s dsp meter reads 50%. This means, that every second the complete system is stopped in favour of jackd and its clients which will take ca. one half of a second to do their processing thing. This clearly tells us that this does have a nasty effect on midi handling.
Midi is of an even more “realtime” nature than audio. Audio processing is done in chunks with a pretty large size (around 1 to 50ms, depending on the buffer size setting used), but when a midi sequencer needs to send an event to a midi port, it needs to do it now to make sure it gets to its destination in time (there’s kind of an exception to this rule, as the ALSA midi sequencer implementation allows scheduling of events at a certain later time, but this shifts the problem to the ALSA midi stuff). Also midi processing is lightweight compared to audio processing. A main loop of a midi sequencer needs to run many many times a second to be able to process midi events with a really fine time resolution. So the midi part of a sequencer app needs to run with a higher priority than jackd. The alsa-seq interface, in principal, allows for midi events to be scheduled for delivery at a certain time which softens up the “need to send now” requirement a bit, but that stuff is quite complex to handle and not many app writers make use of it. So it makes much more sense to get the system up to the task of doing immediate delivery.
There’s different timing sources midi sequencers might use on a linux system. The two most common ones are
RTC,
The realtime clock every pc compatible has. This timer runs at a programmable frequency (i.e. 1024 hz) and thus enables the application to get run very often very regularly. To get RTC based timing to work nicely the rtc IRQ handler (which is # 8 on an XT-PIC system. Check /proc/interrupts to find out its IRQ) needs to get a priority above jackd and all the rest, so 98 is a good choice:
And if RTC is not used, this setting doesn’t do any harm either. IF you want ordinary users to be able to make use of the RTC at reasonably high frequencies, make sure that
is set to i.e. 8192. You can do that by executing (as root):
To inspect what its current value is, use
sleep() based/system timer
In this case the application runs regularly by putting itself to sleep for short intervals. It then measures how long it slept to be able to make its timing work properly. I am not exactly sure about how sleep() (and its relatives like nanosleep or usleep) are implemented on linux, so i can only guess.
When a task puts itself to sleep it really tells the scheduler that it gives up the CPU and doesn’t want to get run again until the sleep time has expired. The system timer is a special timer interrupt in every PC system that runs at a frequency of 250 hz in a default linux kernel configuration. This system timer runs the linux kernel “main loop” - the scheduler. So if it has only the system timer available, the smallest time a task could sleep would be 4 ms (1/250 sec). This is very grainy, so i would recommend to change the default system timer frequency from 250hz to 1000hz. This provides millisecond resultion to this way of timing with sleep()’s, so i suppose it’s a “good thing”. It will cost some system load, but it is rather minimal.
The system timer always runs at the highest possible SCHED_FIFO priority on current -rt kernels, so no need for extra setup.
BZZZT wrong! You might have to give some timer threads a high RT prio, too, so sleep() functions right. The most important one here is “softirq-timer/0″. So make that one prio 99, too.
BZZZZT wrong again! It seems this holds only for kernels that have been compiled without high resolution timer support. I hope to clear up this issue in more detail by asking Ingo Molnar directly. So if you have high-res timers enabled in your config it should not be nessecary to give “softirq-timer/0″ a high prio.
Right now it looks as if setting a high prio for softirq-timer/0 actually hurts system performance. So for the time being it is recommended to use high-res timers and leave softirq-timer/0 alone.
Other timing mechanisms
- POSIX high resolution timers: ???
Midi Application midi threads
So, our timing sources are setup, but what about the applications using them? Having a high priority set for a timer interrupt is not all that’s needed. The userspace applications making use of these interrupts (either directly or indirectly), need to be running with high priorities, too. A priority above jackd and all the audio stuff.
Softsynths
Softsynths generally have an extra thread that receives midi events, timestamps them (i.e. via jack_frametime()) and puts them in a queue (ideally a lockless ringbuffer), where the audio process() callback then consumes from. The process() callback can determine where exactly inside the period to render the corresponding audio data by making use of jackd’s jack_last_frametime() (simple method: add one period to the midi events timestamp and then substract the jack_last_frametime from that. The resulting difference is the offset into the currently to-be-processed period). The midi receiving and timestamping thread needs to run at a higher priority than jackd and all the audio stuff. A priority of 90 is a suitable choice.
I wrote a little softsynth that numerically evaluates the wave equation that uses this scheme and it works very well:
Beware though, it’s quite heavy on the cpu usage side (50% dsp load on my 1.2 ghz athlon).
Midi sequencers
Midi sequencers generally have at least one thread to handle their midi timing. Some use the RTC, others use sleep based timing. The only sequencer i know that can setup its realtime priority is seq24, but afaik the priority is still hardcoded into it. So to adjust that you’ll need to do some digging :)
I don’t know much about other midi sequencers and how they handle this. Rosegarden for example has different options for its timing source (RTC, system timer (sleep based)), but i haven’t found the time to look into it in detail . Maybe it would be possible to get this added as runtime configurable via the GUI (that would be ideal).
Test code
I also have written a small test app bundle:
which includes two small applications that try to produce a stream of midi note-ons. One is based on the RTC (running at a frequency of 2048 hz which should be pretty good). And the other is sleep() based. Both run at a prio of 95 (above jackd) and serve as test cases.
Summarized priority setup
99 System timer IRQ 98 RTC IRQ 95 . . Midi threads of softsynths/midi sequencers . 85 - 82 Soundcard IRQ 80 Jackd watchdog thread 70 Jackd main loop 69 Jackd client (softsynths/midi sequencers) audio process callbacks 60 . . Other IRQ handlers (disk, network, USB, GFX) . 40
On allowing normal users to run realtime processes
See the realtime-lsm and rtlimits pages in the menu on the left
This what I’ve been looking for! Thanks!
You say “Rosegarden … has different options for its timing source” — actually Rosegarden does not manage the fine timing of its MIDI events at all; it uses the ALSA sequencer queue from the snd-seq kernel driver. The options Rosegarden shows you for the timing source are simply the options that the ALSA sequencer queue exposes for its own timing source, plus an “auto” option which makes Rosegarden choose whichever one looks best and then keep tweaking its skew value for as close as possible sync with JACK.
This means that Rosegarden has no control over the scheduling priority of the code that actually timestamps and delivers the MIDI events; it’s all down to the priority of the kernel softirq-timer or the equivalent for whichever timing source the ALSA sequencer is using.
Chris
You are, of course correct. My description of this was very unprecise. Thanks for the comment :)
Thank you for this site. I have an M-Audio Delta 66 and running the latest (7.04) Ubuntu. I have the lowlatency kernel, I’m running jackd in realtime mode. My system is fast (enough) at 2ghz and 1gb ram. I can either get no Xruns, OR low latency but not both! It’s making me nutty. In your post you have a line about your jackd setup as:
jackd -R -P 70 -d alsa …
It’s the “…” I’m desperate to know!! :-) Any chance you might post yoru full jackd line? Or, is that it and you’re taking the defaults for the rest? With my setup, I expect I should be able to have no xruns AND low latency.
Thanks for any help.
Hi
the “lowlatency” kernel in ubuntu is not a “real” lowlatency kernel. It’s just a kernel with the default system timer frequency set back to 1000Hz (someway along 2.6.x linus decided that it makes sense to use a default of 200 here)..
To get ridicolously low latencies, you will need a kernel with the realtime preemption patches applied..
Aaahhhh…. I’m learning. :) Thanks a lot. I’m going to have to bite the bullet then and get into the guts. I’ve been hoping to avoid it because whenver I try, other things stop working that I need. Anyway, thanks again!
BTW: the best place to learn about this stuff is the channel #lad on irc.freenode.org..
Ubuntu now does have a real RT kernel:
https://wiki.ubuntu.com/RealTime
cool, just an apt-get away :)
only for X86 32bit system at this time
Using your guide above and the ubuntu realtime-kernel, I am able to have 1,33 ms latency without xruns.
Jack setup:
Frames/period 64
Samplerate 96000
Periods/buffer: 2
Hardware:
Soundcard: maudio 2496 audiophile
2.5 GHz Celeron + 512RAM
I am unable to get a lower number of frames/periods without xrun problems, But, 1.33 ms is quite nice.
Thanks for the guide. I too am running a Delta 66.
One thing I’m not clear on is verifying JACK’s priority.
Top reports a priority of 20 for jackd, despite specifying realtime and a priority of 70.
Also, the priorities listed by top are very different from those reported by chrt.
Would you explain these differences in reported priorities?
I am using a realtime kernel, realtime lsm, and rtirq via the gentoo pro audio overlay. If it matters, it’s a 64-bit build.
In any event, reordering IRQ priorities reduced the number xruns. Thanks.
After installing htop, I’m in the process of answering my own question.
When JACK is running via qjackctl there are a number of jack threads.
In htop, I see the following when JACK is configured for RT and priority 70.
qjackctl 20
qjackctl -70
jackd 20
jackd 20
jackd 20
jackd -71
jackd -81
The negative signs would seem to indicate FIFO scheduling.
It’s interesting that the IRQ processes show up in top (with slightly altered priorities), but they do not show up in htop at all.
@Cello:
You can configure htop a bit.
- Press F2 for “Setup”
- Navigate to “Display Options”
- uncheck “Hide kernel threads” which i suspect to be checked in your case
Thanks, tapas. That did the trick.
Tapas, Thanks for this. Every time I look at it, the Linux low latency way of doing things seems to change :-)
Having the hard RT patches in easily available standard distro Kernels is much better than special distros like DeMuDi (great though it is/was), but I was not getting particularly good results until I found this and some other configuration pages.
I have always been able to get no JACK Xruns at about 2ms latency, but still got some annoying crackle, particularly with high polyphony (usually from long decay/release). Following the principles here I have managed to get some sessions of crackle-free audio, but it is not particularly stable; after a while the machine locks up totally, which suggests that some process with an elevated FIFO priority is in a tight loop.
I suppose that it is going to be a problem, as a lot of code would have been written expecting to get bumped out of the way rather than voluntarily relinquishing the processor - though a tight loop is still probably not particularly good practice.
My set-up is somewhat different from yours, though. I am playing a CME UF8 through a USB-MIDI connection, hooking it up to a qsynth or zynaddsubfx (through JACK, sometimes also through Rosegarden) and putting the result out of an Intel HDA chipset on the Motherboard.
This has a couple of obvious problems:
- first that the keyboard MIDI feed occurs no more often that 1ms (USB1.0 : a USB2.0 keyboard could reduce that to 0.33ms)
- second that the IRQ for the Intel HDA is shared with the SATA controller and IEEE1394, with no apparent way of changing it - probably serves me right for not using a proper soundcard!
Anyway thanks for your site, the input and insight are appreciated.
Rog.
Hi Roger,
intel HDA is notorious for suckage. I had a cs46xx card once and no matter how well tuned the system was, the driver would produce an xrun every 10 seconds or so..
Got a proper soundcard with a good driver [M-Audio Delta-66] and it works like a charm down to periodsizes of 8 frames..
About the lockups: jackd has a watchdog thread which should kill the offending application in case of a lockup.. You might also try extra watchdogs like my own or das_watchdog.
If these don’t help then the lockup is not caused by userspace but rather a problem in the kernel [some driver, etc..]
Hello Tapas,
Thanks for the further missive. With a bit more experimenting using different priority numbers I’m inclining towards the shared IRQ between the HDA and SATA disk being the cause of lockups; with a lower priority for this IRQ (low 70s), I still lose the crackle, but get only a response slowdown rather than total lockups.
I think I need to read more about the way the RT FIFO sheduling works to get a better understanding of what is actually going on. And perhaps a less sucky audio output :-)
Regards,
Rog.
Excuse me…
I’m a newbie to linux audio (though not quite to linux). I’m having trouble with jack,, and I’m confused by some of the above discussion. I’m running Ubuntu Studio 7.10. Do I have a “real” rt kernel? do I need to compile my own? Right now I’m getting out of control xruns (and I honestly don’t know what that’s supposed to mean). No matter what frame/period setting I use, buffer, realtime or no, same problem. Sometimes I camn make it through xruns faster, and that’s about it. I really need a little help!
Hi Tapas,
I’ve been trying to make Jack and Ardour work without xruns for quite a long with no results. And finally I’ve found your guide. Thank you!
After an intense research with Google, the following sources about setting real time priorities in a Linux audio system seem pretty reliable too:
1) The ALSA Project Low Latency How-to (http://alsa-project.org/main/index.php/Low_latency_howto);
2) Rui Nuno Capela rtirq script (http://www.rncbc.org/jack/rtirq-20071012.tar.gz);
3) The Ubuntu studio preparation page (https://help.ubuntu.com/community/UbuntuStudioPreparation);
4) The Linux-audio-user Archives (http://lists.linuxaudio.org/pipermail/linux-audio-user/);
5) The Ardour forum (http://www.ardour.org/forums);
All those sources agree with you about most of the settings, but it’s still not clear to me if it is useful or not rising the softirq-timers FIFO priorities (softirq-timer/0, softirq-timer/1, softirq-hrtimer in my system) to 99. In the default status in my system there are also a number of items that have rtprio set to 99 (migration, posix_cpu_timer, watchdog). I’m not sure if it would be better to decrease those priorities too.
The kernel I’m using is a stock Linux 2.6.22-14-rt from Ubuntu 7.10 repositories.
Following you guide I’ve been able to use Ardour with the internal HDA Intel card of my laptop (notorious for suckage) for more than two hours without any xruns with a 4ms latency. I’ve also tried the rtirq script with similar results.
I run Jack with the following command (or equivalent qjackctl settings):
jackd -R -P70 -p128 -dalsa -dhw:0 -r48000 -p64 -n3 -i2 -o2
Another important setting was in my case to add at the end of /etc/modprobe.d/alsa-base the following line
options snd-hda-intel model=ref position_fix=1
Unfortunately I’m still experiencing sporadic xruns. They do not seem related neither to the Frames/Period I choose, nor to the CPU load (six chained LADSPA plugin do not create any xrun). Sporadic xruns even happen without Ardour or any other program running except Jack.
I know I should buy a better sound card (and I’m going to do it), but It seems to me that the sporadic xrun issue is not a audio card problem and it could be sorted out with a better sistem tuning.
Another thing I’ve tried with no luck is playing with the PCI latency timer (see http://www-128.ibm.com/developerworks/library/l-hw2.html)
setpci -v -s “*:*.*” latency_timer=b0
setpci -v -s 00:1b.0 latency_timer=ff
Any help would be highly appreciated.
Regards,
Marco
Hardware:
DELL Inspiron 6400 laptop, Intel Dual Core CPU (T2130 @ 1.86GHz), 2.0GB RAM, internal HDA Intel sound card (Chipset: SigmaTel STAC9200)
$ cat /proc/asound/version
Advanced Linux Sound Architecture Driver Version 1.0.14 (Thu May 31 09:03:25 2007 UTC).
$ lspci -v | grep Audio
00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller (rev 01)
$ cat /proc/interrupts
CPU0 CPU1
0: 576 0 IO-APIC-edge timer
1: 350 0 IO-APIC-edge i8042
8: 19 0 IO-APIC-edge rtc
9: 2 0 IO-APIC-fasteoi acpi
12: 74943 0 IO-APIC-edge i8042
14: 8019 49540 IO-APIC-edge libata
15: 3241 0 IO-APIC-edge libata
16: 13337 0 IO-APIC-fasteoi ipw3945, i915@pci:0000:00:02.0
17: 3 0 IO-APIC-fasteoi ohci1394
18: 0 0 IO-APIC-fasteoi uhci_hcd:usb1, ehci_hcd:usb5
19: 185 395 IO-APIC-fasteoi uhci_hcd:usb2, HDA Intel
20: 0 0 IO-APIC-fasteoi uhci_hcd:usb3
21: 0 0 IO-APIC-fasteoi uhci_hcd:usb4
22: 0 0 IO-APIC-fasteoi eth0
23: 0 0 IO-APIC-fasteoi sdhci:slot0
NMI: 0 0
LOC: 97050 100467
ERR: 0
MIS: 0
Default status
$ ps H -eo pid,class,rtprio,ni,pri,pcpu,stat,cmd –sort=-rtprio | grep FF
3 FF 99 - 139 0.0 S
zak
this command when run from the terminal is a good way to find out quickly which version you have:
$ uname -a
it should output something similar to
2.6.20-XX-rt (blah, blah)
The ‘rt’ stands for ‘realtime’. Other possible outputs would be ‘lowlatency’, ‘generic’, etc.
Sorry for any ommisions, still pretty new myself ; )
bookmark you thx
BnwV74 great site man thx http://peace.com
The 10 second xrun issue may be caused by speed stepping in the processor. There are sevral ways to fix this that are different for each distro. But you can Google speed stepping or cpu freq and get an explination of how to disable this for your distro. Jackd hates speed stepping…
I suspect from my poking around that in addition to PCI latency there are other tweaks needed for USB audio cards. I’ve been able to achieve usable latency with a Fast Track USB by M-Audio but I’ve heard of people doing better with less computer. It’s something to investigate and get back to you on…
[...] interesting links might be: http://tapas.affenbande.org/wordpress/?page_id=40 [...]
Hi Florian,
I have a Presonus FP10 working great in Linux Ubuntu Studio 7.10. I also have a Sunix Firewire card with Texas Instruments chipset. However when I type lspci -v in the shell it details my card with “latency 32″. And that’s true because I can’t reach less than 34.8 ms in jack without hearing clicks & pops. I have to set the jack preferences to 512 frames to get good sound. And that’s sad because this audio card is under 2ms of latency.
I tried to type: chrt -f -p 82 `pidof “IRQ-11″` but I get sched_getscheduler: No such process
failed to get pid 82’s policy
Any suggestion? Do I have forgotten something? I’ve tried a lot of things (like changing PCI slot, booting with noapic kernel option to set my preferred IRQ) but nothing changes.
Thanks for your time.
Does it make a difference running the kernel with the noapic and nolapic options so IRQs assigned by BIOS are respected and thus i.e. IRQ 10 can be assigned to the soundcard?
Hi,
I’m running Suse 10.3 with a realtime kernel, the latest Jack, and Ardour2. Having plenty of xruns, even when jack is running by itself. Does anyone know what causes xruns, and is there a list of things to turn off to avoid xruns?
I’ve had Ardour and Jack running smoothly on this machine before (Fedora and Ardour 0.99) so the hardware is fine. Usually recorded at 96000 with around 10ms latency…
Many thanks,
Will
willjknoxfr@yahoo.fr
Hi! Great guide, except it’s not working. :P
I’ve followed the guide except the midi part, as I don’t use midi.
I run jackd with this line: “jackd -R -P 70 -d alsa -C hw:1 -P hw:0 -p 256 -r 48000″
but i still get alot of xruns!
I must have latency below 10 ms or else its not good enough for me.
Hi Xecuter88, without telling us about your specific IRQ priority setup, there’s nothing i can tell you except above guide ;)
I can’t seem to get the realtime priority to work. I’m using kernel version 2.6.24.4-rt4, and I have all the appropriate options selected (so I think, according to http://proaudio.tuxfamily.org/wiki/index.php?title=Realtime_%28RT%29_Kernel ).
But I run this:
$ jackd -R -P 70 -d freebob -r 44100
… and I get this:
$ chrt -p `pidof jackd`
pid 8129’s current scheduling policy: SCHED_OTHER
pid 8129’s current scheduling priority: 0
There is only one instance of jackd running, so there’s no way I’m getting the readout of a different jackd.
Thanks!
Update:
Doing this:
$ chrt -f -p 70 `pidof jackd`
causes this to be correct:
$ chrt -p `pidof jackd`
pid 8129’s current scheduling policy: SCHED_FIFO
pid 8129’s current scheduling priority: 70
clar:
jackd has 4 threads. The main thread must run SCHED_OTHER. Take a more appropriate tool like htop to take a look at all 4 jackd threads..
Hello!
I have a strange issue - I get xruns ONLY when I try to use Rosegarden.
My OS is: Debian (unstable) with kernel 2.6.24.7 + real time patches (-rt17) applied; software raid1 is used for all partitions.
Hardware is AMD64 x2 6400+, 4 GB RAM, and Edirol FA-66 as the sound unit.
I usually start QSynth (witch four engines), ZynAddSubFX, Hydrogen, Muse, Ardour, and JACK in the following way:
jackd -R -P70 -t2000 -dfreebob -dhw:0 -r48000 -p128 -n3 -D
Then I have no issues, I can work for several hours without an xrun. But when I try to use Rosegarden instead of Muse,
I start getting xruns, more less one per a minute. It happens to hear a click/crackle then (not at every xrun), and additionally Rosegarden somehow
looses its synchronization (or BPM measurement, I don’t know how to call it), and starts playing noticeably slower - for example, Hydrogen starts playing
a beat at 57th bar while Rosegarden reaches a 50th bar then. This synchronization loss does not happen at every xrun neither, just sometimes,
but often enough to make Rosegarden unusable for me.
I have followed instructions/suggestions about real time kernel preparation, mainly from your site:
http://tapas.affenbande.org/wordpress/?page_id=40
My interrupts are:
daemon:~/bin# cat /proc/interrupts
CPU0 CPU1
0: 149 27 IO-APIC-edge timer
1: 0 3301 IO-APIC-edge i8042
4: 0 1 IO-APIC-edge
8: 4387 4605172 IO-APIC-edge rtc
9: 0 0 IO-APIC-fasteoi acpi
16: 339745 9307 IO-APIC-fasteoi nvidia
19: 3979385 78 IO-APIC-fasteoi ohci1394
20: 67599 2670 IO-APIC-fasteoi sata_nv, HDA Intel
21: 117173 2744 IO-APIC-fasteoi sata_nv
22: 0 29 IO-APIC-fasteoi ehci_hcd:usb2
23: 1 64256 IO-APIC-fasteoi ohci_hcd:usb1, sata_nv
505: 686520 1715 PCI-MSI-edge eth0
NMI: 0 0 Non-maskable interrupts
LOC: 4103774 4101798 Local timer interrupts
RES: 7526734 7904732 Rescheduling interrupts
CAL: 797 855 function call interrupts
TLB: 3268 4503 TLB shootdowns
TRM: 0 0 Thermal event interrupts
THR: 0 0 Threshold APIC interrupts
SPU: 0 0 Spurious interrupts
ERR: 0
I also set the FIFO sch., and high prio to the IRQ-8 & IRQ-19 processes:
chrt -f -p 98 `pidof IRQ-8`
chrt -f -p 82 `pidof IRQ-19`
echo 8192 > /proc/sys/dev/rtc/max-user-freq
Next I start JACK, and other audio software. In the htop processes look like this then:
http://picasaweb.google.com/tgrzelak/Audio/photo#5235864409871263538
[you can see there are quite many xruns reported]
Now… what I have tried before asking you for help:
1. Starting JACK with larger buffer:
jackd -R -P70 -t2000 -dfreebob -dhw:0 -r48000 -p512 -n3 -D
2. Having used the ‘nv’ driver instead of the binary ‘nvidia’ one (I have GeForce 8800GTX if that matters),
and some light window manager - Window Maker.
3. Rosegarden 1.7.1 compiled from source (currently I have 1.7.0 in Debian repositories).
4. JACK 0.112.1 compiled from svn repositories.
5. JACK 0.112.1 with FFADO backend instead of FreeBoB.
No matter what I have tried, the situation looked the same every time - not possible to work with Rosegarden, no problems with Muse.
I must say I’m running out of ideas. I don’t know what to check/try more, especially xruns happen ONLY while using Rosegarden!
Rosegarden seems to be a great environment with lots of useful features, and convenient usage, and I’d like to have it as the main MIDI seq software,
but somehow it is unusable for me.
I’d be thankful for help with this issue.
Cheers!
Dear all Delta66 user on linux.
I have a problem, i can’t get any audio of my delta 66. I can se the audio bars en envy24 program moving, both for input and output, but there isn’t coming any sound out :( i have googled thes issue with out any solution. Any one knows to this problem and got a solution to it ???
I’m gurrently running Fedora 8, with Planet CCRMA realtime kernel. Tried Fedora 7,9, ubuntu as well, but with the same result.. Its working under windows :( What am i doing wring :( ???????????????
comment5,
Soft, zoo sex porn, :-DDD,
cheap last minute airfares
[...] en Linux Audio/MIDI System Setup publicado en Ugh! - Software, Music and [...]
why ASUS mother boards doesn’t support linux on them
4
Разное
Разное