Since I gave such a glowing review of my testing the other night that I thought I'd report back my not so stellar results from last night. I left all the services running on a fully loaded machine (http, iptables, sendmail, samba, etc...) and started jack at 128/44100/2 in real time. I started a 20 minute recording session with ardour (no jamin yet). While ardour was recording I dialed into the internet with my modem, opened evolution, read email and poked around a bit with konqueror. I got zero, nada, nil, none, no xruns whatsoever. Then I introduced jamin - 4 xruns in 8 mins. Shut down jamin and go back to only ardour - more xruns. Shut down all but essential services and only use ardour - more xruns. Seems that a bottle of xruns was opened and I can't put the cap back on. I then changed jack settings to 256/44100/2 and the xruns went away while only using ardour. Back to tweaking..... Anyone know of a twelve step program for a tweak-a-holic? Brad ----- Original Message ----- From: "Mark Knecht" <mknecht@xxxxxxxxxxxxxx> To: "A list for linux audio users" <linux-audio-user@xxxxxxxxxxxxxxxxxx> Sent: Wednesday, September 29, 2004 8:55 AM Subject: Re: [linux-audio-user] Is everyone sick of interrupts yet? > Lee Revell wrote: > > On Tue, 2004-09-28 at 20:52, Mark Knecht wrote: > > > >>On Tue, 2004-09-28 at 17:05, Lee Revell wrote: > >> > >> > >>>Correct. I have measured the delay, is it a matter of a few > >>>nanoseconds. > >> > >>I don't mean to be argumentative but it cannot be. A single PCI clock > >>cycle is 30nS @33MHz. It takes dozens of PCI cycles for the chipset to > >>ensure access to the bus (removing PCI grant and waiting until all > >>devices are off, then sending a PCI address, getting a target hit > >>response and starting the read. At that point you can read a single > >>register, or possibly multiple registers if the chip supports it. This > >>is not a few nanosecond. A few micro seconds to read a single Interrutp > >>register in a PCI chip to see if it's involved, but not nanoseconds. > >>Most North Bridges cannot access the PCI bus for fewer than about 15 > >>clocks by the time you look at their bus operations. We do this stuff > >>all the time in our PCI 1394 drivers looking at IO's/Sec. PCI-Express > >>maybe, but not PCI. > >> > >>If you're talking about the speed reading the PCI itself, then I'd buy > >>that this is much shorter as it's in the chipset. However, the processor > >>still has to cross the front side bus. There are latencies that arise > >>there dependign on what the processoris doing physically. Certainly this > >>time is much shorter though. > > > > > > Oops, sorry, I meant microseconds. I was actually looking at a trace > > when I wrote this, and Ingo's tracer prints milliseconds, and I screwed > > up the conversion. It looks like 2-3 usecs to determine where the > > interrupt came from if two devices share an irq. > > > > Lee > > > > > Thanks Lee. That's very compatible with my back-of-the-envelope > calculations. However, I believe that number assumes that the leading > interrupt device is not interrupting and you only had to determine that > the real interrupt came from the sound card. Assuming a shared > interrupt, and assuming that a USB controller is the first and the sound > card is the second device, what delay is encountered by the sound card > when both devices interrupt at the same time? > > I understand that there is probably a few microseconds extra delay as > the system determines that there are two interrupt devices pending. How > long is it, however, before the UCB interrupt handler does all it's work > and hands off to the sound card interrupt handler (or sound card driver) > so that it can get started? > > I grant you that this will should not amount to 500uS worth of delay, > but then we need to add in the possibilities of other, higher priority > interrupts coming along during that window and further delaying the > sound card getting it's work don before the Jack frame runs out. > > For me this is not a mere curiosity. Yesterday I brought up FC2 and > then, with much help from Steve Harris and Fernando, got a new Planet > kernel installed. No sooner than I had started Jack I then started using > my USB mouse and getting huge xruns. Since USB is shared with the sound > chip I think it's an example of what we ae talking about here. > > to be clear I do not think the results are completely valid as the > machine has not yet been optimized, it's running KDE, arts is trying to > start at odd times, etc., but clearly there was a relationship between > my mouse and my xruns. > > (Some xruns were on the order of 100-500mS!! This cannot be truly > real...I hope) > > Thanks much, > Mark
