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

[Josh Green]

Unfortunately I don't think I have much useful to offer.  Sounds like
you have tried quite a lot of different things at this point.  I would
likely try and track down the exact source of that message with Jack.
I've seen that message before also, but don't recall what it was related
to.  I'm sure that direction might lead you to find out what is the real
cause.  Just did a rather quick search on the subject, but didn't come
up with anything real helpful.  Maybe try a different sound card, as
another user suggested (if possible).  Good luck!
        Josh


> 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-----
>