| View previous topic :: View next topic |
| Author |
Message |
musicman
n00b
Joined: 13 Jun 2004
Posts: 66
|
 Posted: Fri May 09, 2008 7:52 pm Post subject: Latest about rt-sources and realtime preemption |
 |
|
I have two computers that I'm trying to get functioning more reliably at lower latencies for audio work. One is an amd64 1.8ghz (3000+) box I built myself, and the other is a MacBook 3,1 (Santa Rosa). My audio interface is the Edirol FA-101, a firewire interface supported by Freebob.
I'm having trouble getting things running smoothly, especially with Pd (http://puredata.info), which hiccups when I so much as move the mouse to the widgets on the window's title bar (minimize, maximize, close, etc) or drag the Pd window around or bring it to the foreground or background.
I'm using 32-bit gentoo-sources-2.6.24-r4 on both machines, and the Macbook's kernel has a couple of patches to make the keyboard and trackpad work correctly.
Programs I'm using:
Ardour
Pd
seq24
Hydrogen
Specimen
possibly LinuxSampler and Rosegarden
qjackctl
It was not until recently that I realized that my system was not running at its potential. I have changed my kernel config options to | Code: | | Preemptible Kernel (Low-Latency Desktop) |
and set | Code: | | Timer frequency (1000 HZ) |
, as described in http://proaudio.tuxfamily.org/wiki/index.php?title=Howto_RT_Kernel and somewhat in http://tapas.affenbande.org/wordpress/?page_id=40.
Running Pd with helps Pd's stability a little bit, but I don't think it's the right solution.
So I have 2 things to ask:
- It looks like rt-sources (from the pro-audio overlay) is still at version 2.6.16. Is it still necessary to use this patched kernel, or does the newest gentoo-sources have the necessary capabilities? This is especially important because 2.6.16 doesn't support the new Macbook very well, plus it's a pretty old kernel. Is there anything I can do to improve the situation without using the realtime patched kernel? It would be better than nothing.
- The articles talk about setting interrupts and realtime priorities for your sound card. Since I use a Firewire sound card, should I apply these things about interrupts to my Firewire controller?
I also looked up my pci latencies using lspci -v, as per the Linux hardware stability guide, pt 2 (http://www.gentoo.org/doc/en/articles/hardware-stability-p2.xml). Everything has latency 0, except for my Firewire controller and Atheros wifi card, which have latency 32. |
|
| Back to top |
|
 |
pappy_mcfae
Watchman
Joined: 27 Dec 2007
Posts: 5999
Location: Pomona, California.
|
| Posted: Sun May 11, 2008 7:48 am Post subject: |
|
|
You need to do a little more research. There are current patches for real time for just about every kernel version that exists. Just go here, and you'll find that for which you search. You can find a patch for 2.6.16 through 2.6.24.
As far as using a firewire sound device, I get the feeling that increases latency, which doesn't help your system. If you're going to play with interrupt latencies, make sure you set the sound device so it gets the lion's share of processor time. Set everything else, including the wireless to zero. Even at that, I think you'll find a problem with the setup.
Good luck.
Blessed be!
Pappy
_________________
This space left intentionally blank, except for these ASCII symbols. |
|
| Back to top |
|
|
musicman
n00b
Joined: 13 Jun 2004
Posts: 66
|
| Posted: Sun May 11, 2008 6:47 pm Post subject: |
|
|
Pappy,
Thanks a lot - I did end up finding the patch for vanilla-sources-2.6.24.4.
As far as the interrupt latencies, would you set the Firewire card to somewhere in the hundreds? The stability guide says that this would allow the Firewire card to monopolize the PCI bus for longer stretches of time. Would this be a problem if it keeps the SATA controller from having its share of time? Could it cause dropouts because the disk couldn't keep up?
Also, I'm also using rtirq to set the priorities of the IRQ-* processes. How does this relate to and interact with the interrupt latencies?
The current order in conf.d/rtirq is:
rtc usb sata_nv ohci1394 snd
This is because I read up on it and people were suggesting that rtc was the most important. USB is second because I'm using USB MIDI controllers, and I read that split-second timing is even more important for MIDI signals than for audio (i.e. when you hit a key on a keyboard, it needs to go through immediately). SATA is third because I didn't want any dropouts because the disk was not given enough priority. ohci1394 is fourth - it is the firewire controller that my sound device is going through. Finally, snd is last because it's the on-board sound card and is not really used.
Should I move ohci1394 to the top of the list?
Thanks! |
|
| Back to top |
|
|
pappy_mcfae
Watchman
Joined: 27 Dec 2007
Posts: 5999
Location: Pomona, California.
|
| Posted: Sun May 11, 2008 8:42 pm Post subject: |
|
|
| musicman wrote: | Pappy,
Thanks a lot - I did end up finding the patch for vanilla-sources-2.6.24.4.
As far as the interrupt latencies, would you set the Firewire card to somewhere in the hundreds? The stability guide says that this would allow the Firewire card to monopolize the PCI bus for longer stretches of time. Would this be a problem if it keeps the SATA controller from having its share of time? Could it cause dropouts because the disk couldn't keep up? |
Theoretically, no. Even with all the time allocated to the sound card, sound is processed slowly in comparison to other things. I've never actually played with this setting since my recording maching is a Core2 with 2 Gigs of RAM 130 Gigs of hard drive space, and an M-Audio Delta-66 pro sound card. Even though you are using firewire, the system is still going to be able to keep up. If I were you, I'd do a little experimenting using 96kHz 24-bit while recording, and listen to the playback carefully for dropouts. If you don't hear them at that extreme, you won't here them at 44.1kHz 16-bit.
| Quote: | Also, I'm also using rtirq to set the priorities of the IRQ-* processes. How does this relate to and interact with the interrupt latencies?
The current order in conf.d/rtirq is:
rtc usb sata_nv ohci1394 snd
This is because I read up on it and people were suggesting that rtc was the most important. USB is second because I'm using USB MIDI controllers, and I read that split-second timing is even more important for MIDI signals than for audio (i.e. when you hit a key on a keyboard, it needs to go through immediately). SATA is third because I didn't want any dropouts because the disk was not given enough priority. ohci1394 is fourth - it is the firewire controller that my sound device is going through. Finally, snd is last because it's the on-board sound card and is not really used.
Should I move ohci1394 to the top of the list?
Thanks! |
I really doubt you'll have a problem. I don't know about rtirq. If you aren't having problems now, I doubt you'll have them further on down the line. Do some experimentation, and if you do have problems, deal with them at that point.
Good luck.
Blessed be!
Pappy
_________________
This space left intentionally blank, except for these ASCII symbols. |
|
| Back to top |
|
|
musicman
n00b
Joined: 13 Jun 2004
Posts: 66
|
| Posted: Mon May 12, 2008 6:05 am Post subject: |
|
|
I actually am having an issue with dropouts. Puredata isn't the most stable of programs, so I use
| Code: | | $ chrt -f -p XX `pidof pd` |
where XX is a number between 00 and 99, to try and give it as high a priority as possible to get rid of dropouts when I move windows around, switch desktops, etc.
This seems to work okay for Puredata, although I still experience dropouts, even when I crank up Pd to a higher priority than almost anything else on the system.
Because I want to run Pd and Ardour at the same time, and move audio between the two applications while running jackd at as low a latency as possible, I am trying to set Ardour's priority really high too. The thing is, when I move Ardour's priority higher than 49, I get regularly spaced dropouts from Ardour (I'd say about 10 a second). Coincidentally, all of the IRQ-* processes that I haven't bumped higher with rtirq have priorities right around 50. That leads me to believe that one of the IRQ's that I didn't mess with actually is important.
Here are the first few lines of output from top (without any of the audio stuff running, sorted in ascending order by the Priority "PR" field):
| Code: |
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
3 root RT -5 0 0 0 S 0.0 0.0 0:00.00 migration/0
4 root RT -5 0 0 0 S 0.0 0.0 0:00.00 posix_cpu_timer
842 root -96 -5 0 0 0 S 0.0 0.0 0:00.00 IRQ-8
937 root -94 -5 0 0 0 S 0.0 0.0 0:00.00 IRQ-19
946 root -94 -5 0 0 0 S 0.0 0.0 0:04.32 IRQ-16
911 root -92 -5 0 0 0 S 0.0 0.0 0:00.00 IRQ-17
916 root -91 -5 0 0 0 S 0.0 0.0 0:00.28 IRQ-18
2258 root -90 -5 0 0 0 S 0.7 0.0 0:37.00 IRQ-20
5 root -51 -5 0 0 0 S 0.0 0.0 0:00.00 softirq-high/0
6 root -51 -5 0 0 0 S 0.3 0.0 0:16.51 softirq-timer/0
7 root -51 -5 0 0 0 S 0.0 0.0 0:00.01 softirq-net-tx/
8 root -51 -5 0 0 0 S 0.0 0.0 0:00.24 softirq-net-rx/
9 root -51 -5 0 0 0 S 0.0 0.0 0:00.36 softirq-block/0
10 root -51 -5 0 0 0 S 1.0 0.0 0:43.28 softirq-tasklet
11 root -51 -5 0 0 0 S 0.0 0.0 0:02.53 softirq-sched/0
12 root -51 -5 0 0 0 S 0.0 0.0 0:01.05 softirq-hrtimer
13 root -51 -5 0 0 0 S 0.0 0.0 0:02.44 softirq-rcu/0
83 root -51 -5 0 0 0 S 0.0 0.0 0:00.00 IRQ-9
847 root -51 -5 0 0 0 S 0.0 0.0 0:00.00 IRQ-7
858 root -51 -5 0 0 0 S 0.0 0.0 0:00.00 IRQ-6
887 root -51 -5 0 0 0 S 0.0 0.0 0:00.20 IRQ-14
889 root -51 -5 0 0 0 S 0.0 0.0 0:00.00 IRQ-15
974 root -51 -5 0 0 0 S 0.0 0.0 0:00.00 IRQ-12
975 root -51 -5 0 0 0 S 0.0 0.0 0:00.00 IRQ-1
15 root -2 -5 0 0 0 S 0.0 0.0 0:00.25 events/0
237 root -2 -5 0 0 0 S 0.0 0.0 0:00.00 krcupreemptd
|
And here are my interrupts (to match up with the IRQ-* processes shown in top):
| Code: |
$ cat /proc/interrupts
CPU0
0: 868 IO-APIC-edge timer
1: 2 IO-APIC-edge i8042
7: 1 IO-APIC-edge lpptest
8: 2 IO-APIC-edge rtc
9: 0 IO-APIC-fasteoi acpi
12: 4 IO-APIC-edge i8042
14: 27137 IO-APIC-edge ide0
15: 487 IO-APIC-edge ide1
16: 701995 IO-APIC-fasteoi ohci_hcd:usb2, eth0
17: 703 IO-APIC-fasteoi sata_nv, NVidia CK804
18: 56639 IO-APIC-fasteoi sata_nv
19: 2 IO-APIC-fasteoi ehci_hcd:usb1
20: 10068200 IO-APIC-fasteoi ohci1394
NMI: 0 Non-maskable interrupts
LOC: 59265497 Local timer interrupts
RES: 0 Rescheduling interrupts
CAL: 0 function call interrupts
TLB: 0 TLB shootdowns
TRM: 0 Thermal event interrupts
SPU: 0 Spurious interrupts
ERR: 1
MIS: 0
|
|
|
| Back to top |
|
|
pappy_mcfae
Watchman
Joined: 27 Dec 2007
Posts: 5999
Location: Pomona, California.
|
| Posted: Mon May 12, 2008 6:12 am Post subject: |
|
|
How fast of a machine are we talking here? How much memory? How big of a hard drive? There are numerous factors that can affect the performance over and above going for fancy things like determining IRQ timings. That seems an awful lot of effort just to lay down a track.
Blessed be!
Pappy
_________________
This space left intentionally blank, except for these ASCII symbols. |
|
| Back to top |
|
|
musicman
n00b
Joined: 13 Jun 2004
Posts: 66
|
| Posted: Mon May 12, 2008 6:28 am Post subject: |
|
|
Pappy,
amd64 3000+ (1.8 GHz), 1 gig of ram, 250 GB SATA hard drive (Samsung SpinPoint), 5 GB IDE hard drive (to hold /usr/portage/distfiles and /usr/portage/packages - spends most of its time spun down). Running 32-bit system.
I'm doing a bit more than just laying down a track. I do "contemporary music" (whatever that really means, anyway), so the couple of projects I've done have involved many different tracks with different plugins applied to each, different groups of tracks that I use for different sections of a piece, etc., and I'd like to integrate work I've done in Pd, and possibly some things with seq24/hydrogen/specimen (although they aren't as fickle as Pd), into the creation of my Ardour projects.
Come to think of it, I wasn't necessarily having any trouble before when I was using only Ardour - high latencies didn't even matter that much. It is just a nuisance to have Pd drop samples if I tried to do so much as bring a hidden window to the front, so I started reading up on doing using the realtime patches, chrt, rtirq, PCI latency, etc.
Thanks,
Jake |
|
| Back to top |
|
|
arnvidr
l33t
Joined: 19 Aug 2004
Posts: 629
Location: Oslo, Norway
|
| Posted: Mon May 12, 2008 8:42 am Post subject: |
|
|
Is the realtime patch to the kernel the right way to do realtime now? I'm using 2.6.25 kernel, and there's no patch at the link provided earlier in this thread. I've read something about using PAM for realtime too, and I'm not sure what to use...
_________________
|
|
| Back to top |
|
|
musicman
n00b
Joined: 13 Jun 2004
Posts: 66
|
| Posted: Mon May 12, 2008 7:04 pm Post subject: |
|
|
I started another thread that has to do with a related issue in getting audio to work with some stability for me. Some of these issues are being dealt with there (at least a little).
https://forums.gentoo.org/viewtopic-t-691787-highlight-.html
The realtime patches and the PAM realtime setup are somewhat related but different.
(here's the link to the realtime patchset: http://www.kernel.org/pub/linux/kernel/projects/rt/)
It doesn't look like there are patches for 2.6.25 yet.
You can (and probably should?) use PAM realtime and the realtime kernel patches at the same time. Note that PAM realtime replaces the older realtime-lsm kernel module that you used to have to emerge.
The words realtime and priority get thrown around so much and mean different things in different contexts. Perhaps someone who really, really knows all the related issues inside and out could tie everything together? |
|
| Back to top |
|
|
arnvidr
l33t
Joined: 19 Aug 2004
Posts: 629
Location: Oslo, Norway
|
| Posted: Mon May 12, 2008 7:08 pm Post subject: |
|
|
Okay, that PAM replaces the realtime-lsm module at least answers a few questions, thanks  Will look at the thread you linked too!
_________________
|
|
| Back to top |
|
|
musicman
n00b
Joined: 13 Jun 2004
Posts: 66
|
| Posted: Tue May 13, 2008 12:03 am Post subject: |
|
|
This in an important point (substitute PAM for realtime-lsm in this message):
http://lists.puredata.info/pipermail/pd-list/2004-12/024925.html
Frank Barknecht says:
| Quote: | Though that is not the gain of the realtime-lsm module: It just allows
ordinary users to do things, normally only root is allowed to. It does
not give better realtime performance itself. The module has a
misleading name, there's not much "realtime" about it.
|
|
|
| Back to top |
|
|
pappy_mcfae
Watchman
Joined: 27 Dec 2007
Posts: 5999
Location: Pomona, California.
|
| Posted: Tue May 13, 2008 5:34 am Post subject: |
|
|
| musicman wrote: | Pappy,
amd64 3000+ (1.8 GHz), 1 gig of ram, 250 GB SATA hard drive (Samsung SpinPoint), 5 GB IDE hard drive (to hold /usr/portage/distfiles and /usr/portage/packages - spends most of its time spun down). Running 32-bit system. |
Have you considered moving to 64 bit? You have the machine to do it, although another Gig of RAM wouldn't hurt in the least. 64 bit gives great multimedia functionality.
| Quote: | I'm doing a bit more than just laying down a track. I do "contemporary music" (whatever that really means, anyway), so the couple of projects I've done have involved many different tracks with different plugins applied to each, different groups of tracks that I use for different sections of a piece, etc., and I'd like to integrate work I've done in Pd, and possibly some things with seq24/hydrogen/specimen (although they aren't as fickle as Pd), into the creation of my Ardour projects.
Come to think of it, I wasn't necessarily having any trouble before when I was using only Ardour - high latencies didn't even matter that much. It is just a nuisance to have Pd drop samples if I tried to do so much as bring a hidden window to the front, so I started reading up on doing using the realtime patches, chrt, rtirq, PCI latency, etc.
Thanks,
Jake |
In that case, I'd figure out how better to use ardour to achieve your goals. While I am less than impressed with the shaky stability of ardour, I can say that it's problems are no more irritating or profuse than the problems I encounter when I use Cool Edit Pro. The biggest thing with ardour is learning its interface. Once I got that down, it was only a matter of changing what I know from CEP to ardour.
One other thing; did you compile jack using the jack-tmpfs USE flag? If not, do so. It really helps jack move a little more quickly to have it doing its thing in memory than on a hard drive.
Blessed be!
Pappy
_________________
This space left intentionally blank, except for these ASCII symbols. |
|
| Back to top |
|
|
musicman
n00b
Joined: 13 Jun 2004
Posts: 66
|
| Posted: Wed May 14, 2008 12:33 am Post subject: |
|
|
I am using Jack compiled with jack-tmpfs.
I actually just switched to 32-bit because I've had some problems compiling and using stuff on 64-bit. Especially things in the pro-audio overlay, which are marked x86 or at least ~x86 but are sometimes not marked for amd64 at all.
About just using Ardour to do what I want: there are certain things that Ardour is just not well-suited to do (i.e. laying down algorithmically generated rhythm tracks), so in certain situations I'd rather be able to reliably move information between the two programs. Plus, I would love if Ardour had MIDI sequencing built in, but it doesn't as of 2.4.1, so that's another reason to get various programs working together with some degree of stability.
I find Ardour very straightforward and powerful, and I feel that I know its limitations pretty well.
Peace,
Jake |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Multimedia
