[linux-audio-user] Is everyone sick of interrupts yet?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [Linux Sound]     [ALSA Users]     [Pulse Audio]     [ALSA Devel]     [Sox Users]     [Linux Media]     [Kernel]     [Photo Sharing]     [Gimp]     [Yosemite News]     [Linux Media]

  Powered by Linux