fluid-dev
[Top][All Lists]
Advanced

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

Re: [fluid-dev] Crazy non-Xrun Xruns


From: Ken Restivo
Subject: Re: [fluid-dev] Crazy non-Xrun Xruns
Date: Thu, 28 Dec 2006 13:02:39 -0800
User-agent: Mutt/1.4i

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Thanks! I discovered the -n3 trick a while ago.

I've been using "/usr/bin/jackd -R -P90 -dalsa -dhw:0,0 -r48000 -p256 -n3 -H" 
with good-sounding results.

The above works fine on 2.6.18 Debian kernel, with DESKTOP preemption, very few 
ALSA xruns, but gives me those odd "delay of xxx usecs exceeds estimated spare 
time of xxxx; restart" messages, which qjackctl interprets as xruns.

It gives even *more* of those messages on on 2.6.19.1, with or without rt 
patches and REALTIME preemption. No audible defets, it's still very usable, but 
I want to either be rid of these messages or at least understand what's causing 
them and what they mean, or if they may be ignored.

The only obvious difference I can see between 2.6.18 and 2.6.19 appears to be 
the way interrupts are processed.

On 2.6.18, I get:

           CPU0       CPU1       
  0:   25242627          0    IO-APIC-edge  timer
  8:          0          0    IO-APIC-edge  rtc
  9:          1          0   IO-APIC-level  acpi
 14:     214536          0    IO-APIC-edge  ide0
 50:    5356767          0   IO-APIC-level  HDA Intel
177:    1434892          0   IO-APIC-level  uhci_hcd:usb4
209:          6          0   IO-APIC-level  uhci_hcd:usb1, ehci_hcd:usb5
217:      40109          0   IO-APIC-level  uhci_hcd:usb2, ohci1394, libata
225:     296277          0   IO-APIC-level  uhci_hcd:usb3
233:     537467          0         PCI-MSI  sky2
NMI:          0          0 
LOC:   24848628   24848607 
ERR:          0
MIS:          0


On 2.6.19.1 (vanilla) I get:

           CPU0       CPU1       
  0:    1240520          0   IO-APIC-edge      timer
  8:          0          0   IO-APIC-edge      rtc
  9:          1          0   IO-APIC-fasteoi   acpi
 14:      12621          0   IO-APIC-edge      libata
 15:          0          0   IO-APIC-edge      libata
 17:      72662          0   IO-APIC-fasteoi   uhci_hcd:usb4, 
address@hidden:0000:00:02.0
 18:          6          0   IO-APIC-fasteoi   uhci_hcd:usb1, ehci_hcd:usb5
 19:       5963          0   IO-APIC-fasteoi   uhci_hcd:usb2, libata, ohci1394
 20:      11097          0   IO-APIC-fasteoi   uhci_hcd:usb3
 21:      31200          0   IO-APIC-fasteoi   HDA Intel
221:       8445          0   PCI-MSI-edge      eth1
NMI:          0          0 
LOC:    1225369    1225399 
ERR:          0
MIS:          0


On 2.6.19.1-rt15, I get:

           CPU0       CPU1       
  0:     770912          0   IO-APIC-edge      timer
  8:          0          0   IO-APIC-edge      rtc
  9:          1          0   IO-APIC-fasteoi   acpi
 14:       7822          0   IO-APIC-edge      libata
 15:          0          0   IO-APIC-edge      libata
 17:       6185          0   IO-APIC-fasteoi   uhci_hcd:usb4
 18:       6591          0   IO-APIC-fasteoi   uhci_hcd:usb3
 19:       5368          0   IO-APIC-fasteoi   libata, uhci_hcd:usb2, ohci1394
 20:          6          0   IO-APIC-fasteoi   uhci_hcd:usb1, ehci_hcd:usb5
 21:     257216          0   IO-APIC-fasteoi   HDA Intel
221:      13032          0   PCI-MSI-edge      eth1
NMI:          0          0 
LOC:     760192     760070 
ERR:          0
MIS:          0


Which is strange and I have no idea if it is related to this problem. The HDA 
Intel is a high interrupt priority on 2.6.18, but gets bumped to the back of 
the bus on 2.6.19. Also, without the RT patches, the i915 video chip has a PCI 
interrupt, and with the RT patches, doesn't appear to have any interrupts at 
all (I thought it as AGP, not PCI, anyway).


The chip, BTW, is this one:
00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High Definition 
Audio Controller (rev 02)
        Subsystem: Unknown device 8384:7680
        Flags: bus master, fast devsel, latency 0, IRQ 21
        Memory at 90440000 (64-bit, non-prefetchable) [size=16K]
        Capabilities: [50] Power Management version 2
        Capabilities: [60] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 
Enable-
        Capabilities: [70] Express Unknown type IRQ 0
        Capabilities: [100] Virtual Channel
        Capabilities: [130] Unknown (5)
00: 86 80 d8 27 06 00 10 00 02 00 03 04 40 00 00 00
10: 04 00 44 90 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 84 83 80 76
30: 00 00 00 00 50 00 00 00 00 00 00 00 0b 01 00 00

The best performance I've gotten to date has been with Debian 2.6.18 kernel 
with DESKTOP. I tried to apply ingo's patches to vanilla 2.6.18, but that 
kernel does not boot: it panics at dealing with HPET. I tried to rebuild 2.6.18 
with no HPET, then it crashes at preempt_irq handler. *sigh*.

Anyway, I'm baffled and at this point it's very frustrating because I don't 
know what tools to use to isolate *where* exactly this problem is coming from. 
Taking random stabs in the dark (try a new kernel, try latest version of foo, 
tweak kernel config, etc.) and going down blind alleys, is, predictably, not 
getting me anywhere.

- -ken
- ------------
On Thu, Dec 28, 2006 at 07:37:21PM +0000, Josh Green wrote:
> Hello Ken,
> 
> I have a sound card that uses the same driver and also have problems
> with Jack and very bad audio output (I don't get continuous xrun errors,
> but it sounds like the effect of lots and lots of xruns, clicks/pops
> etc).  I believe I got things working in the past by messing with the
> frames and period sizes.  I just tested this, and found that the default
> of 2 periods and 1024 frames per period was messed up (as mentioned),
> but if I change it to 3 periods, it works fine.  I was even able to
> reduce it to 512 frames without problems, as long as it is set to 3
> periods.  You can do this by starting jack like so:
> 
> jackd -d alsa -n 3 -p 512
> 
> Maybe that helps?  If not, I would look into other things, like make
> sure jackd is using the hw:0 device (that is the default, so not sure
> why it wouldn't be).  Best regards,
>       Josh
> 
> 
> On Thu, 2006-12-28 at 02:41 -0800, Ken Restivo wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> > 
> > I don't expect any answer to this, but it's making me very sad.
> > 
> > Advanced Linux Sound Architecture Driver Version 1.0.14rc1.
> > Compiled on Dec 28 2006 for kernel 2.6.19.1-rt15-1-ingo (SMP).
> > 
> > And an ugly hda-intel sound card, on a Mac Mini.
> > 
> > jackd starts up fine, in realtime mode.
> > 
 > > But then. 
> > 
> > If I launch any fluidsynth, I get endless reams of:
> > 
> >             delay of 5099.000 usecs exceeds estimated spare time of 
> > 4982.000; restart ...
> > 
> > No combination of parameters to jackd appears to fix it.
> > 
> > If I kill the fluidsynths, the error messages persist. qjackctl interprets 
> > them as Xruns, even though I don't actually get Xrun messages, just the 
> > above.
> > 
> > Any ideas?
> > 
> > 
> > - -ken
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1.4.1 (GNU/Linux)
> > 
> > iD8DBQFFk59xe8HF+6xeOIcRApqGAKDPKhQ0uQTkUBmnFPMFcPG3yxxxHACg7kys
> > je7XDA6+SlFKBhNFgDYPEzs=
> > =2qFY
> > -----END PGP SIGNATURE-----
> > 
> > 
> > _______________________________________________
> > fluid-dev mailing list
> > address@hidden
> > http://lists.nongnu.org/mailman/listinfo/fluid-dev
> > 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFFlDDve8HF+6xeOIcRAjqoAKCjQSVvDj7BdEVN2Tyx7lN2vlzVcwCg3oUC
vnYwKADRiaM0sYXH4rU1PSc=
=hgRy
-----END PGP SIGNATURE-----




reply via email to

[Prev in Thread] Current Thread [Next in Thread]