Horrific jackd xrun behaviour after upgrade from US 10.04 to 12.04 ( R: Audio issues in 10.04)
 

Am Mon, 17 Sep 2012 15:30:49 +0200
schrieb Thomas Orgis <thomas-forum@orgis.org>:

> > Please post the output of
> > $ /etc/init.d/rtirq status
>
> Will try to get to that tonight.

Well ... this is interesting. I tried AVLinux and this also showed
massive xruns, with the added twist of ffado giving up on the device
after some time. I then thought that maybe swapping the firewire card
to another slot might help. It shared IRQ with some USB ports. I shoved
it into the x16 slot (using onboard graphics).

Now, would I have been properly awake at that time, I'd have thought
that the generally abysmal performance cannot have something to do with
the firewire card, as it also shows for internal audio and a USB card.
But, perhaps it was a step towards the final goal.

Thing is, the machine did not want to start after swapping the firewire
card. Pulling the card out, waiting, connecting/disconnecting power ...
and the machine boots again. To shorten it a bit: I must have had
something funky with the power connection to the card. On the same wire
branch s a SATA power adapter for the 3rd hard disk and I suspect it
having had some bad insulation, causing flaky current / shorting out.
That would explain the box dying on moving said branch about a bit, and
some protection circuit preventing powering on again (for some time).

I managed to get the thing running again after adding insulation to the
supposedly faulty adapter, and what might play a part: The BIOS got
reset. I'm with defaults there now. I'm leaving the box running for the
day with JACK on firewire under UbuntuStudio (my partial KXStudio).
During the first minutes I did not see one underrun and could record a
bit with Ardour. II faintly remember that I checked internal audio,
too, and it seemed to be fine.

So it could be down to flaky power to the firewire card / the system at
all (but how could that subtly influence the machine without killing it
outright?) or, what I think is more probable, some BIOS setting. I'll
check that later, if the test is successful. Anoter remote possibility
would be that the machine freaks out generally when the first PCIe slot
is occupied --- I'll move the firewire card back to see if that makes a
change.

Anyhow, here's the current interrupts (see how the one for firewire is
the most populated?):

CPU0 CPU1 CPU2
0: 124 0 1 IO-APIC-edge timer
1: 465 0 25 IO-APIC-edge i8042
7: 1 0 0 IO-APIC-edge parport0
8: 0 0 1 IO-APIC-edge rtc0
9: 0 0 0 IO-APIC-fasteoi acpi
12: 12464 19 1858 IO-APIC-edge i8042
14: 0 0 0 IO-APIC-edge pata_atiixp
15: 0 0 0 IO-APIC-edge pata_atiixp
16: 0 2 838 IO-APIC-fasteoi ohci_hcd:usb3, ohci_hcd:usb4, snd_hda_intel
17: 1 1682 2187 IO-APIC-fasteoi ehci_hcd:usb1
18: 50797 4 975 IO-APIC-fasteoi ohci_hcd:usb5, ohci_hcd:usb6, ohci_hcd:usb7, radeon, firewire_ohci
19: 0 5 1747 IO-APIC-fasteoi ehci_hcd:usb2
22: 1442 60 15896 IO-APIC-fasteoi ahci
42: 0 0 0 PCI-MSI-edge eth3
NMI: 0 0 0 Non-maskable interrupts
LOC: 215017 224583 218795 Local timer interrupts
SPU: 0 0 0 Spurious interrupts
PMI: 0 0 0 Performance monitoring interrupts
IWI: 0 0 0 IRQ work interrupts
RES: 38575 50657 61704 Rescheduling interrupts
CAL: 498 451 613 Function call interrupts
TLB: 759 889 843 TLB shootdowns
TRM: 0 0 0 Thermal event interrupts
THR: 0 0 0 Threshold APIC interrupts
MCE: 0 0 0 Machine check exceptions
MCP: 1 1 1 Machine check polls
ERR: 1
MIS: 0

rtirq:

PID CLS RTPRIO NI PRI %CPU STAT COMMAND
302 FF 90 - 130 0.6 S irq/18-firewire
994 FF 83 - 123 0.0 S irq/16-snd_hda_
84 FF 80 - 120 0.0 S irq/17-ehci_hcd
88 FF 80 - 120 0.0 S irq/16-ohci_hcd
86 FF 79 - 119 0.0 S irq/19-ehci_hcd
90 FF 79 - 119 0.0 S irq/16-ohci_hcd
99 FF 75 - 115 0.0 S irq/1-i8042
98 FF 74 - 114 0.1 S irq/12-i8042
23 FF 50 - 90 0.0 S irq/9-acpi
73 FF 50 - 90 0.4 S irq/22-ahci
92 FF 50 - 90 0.1 S irq/18-ohci_hcd
94 FF 50 - 90 0.1 S irq/18-ohci_hcd
96 FF 50 - 90 0.1 S irq/18-ohci_hcd
100 FF 50 - 90 0.0 S irq/8-rtc0
287 FF 50 - 90 0.0 S irq/14-pata_ati
288 FF 50 - 90 0.0 S irq/15-pata_ati
295 FF 50 - 90 0.1 S irq/18-radeon
965 FF 50 - 90 0.0 S irq/7-parport0
1212 FF 50 - 90 0.0 S irq/42-eth3
3 TS - 0 19 1.0 R ksoftirqd/0
9 TS - 0 19 1.0 S ksoftirqd/1
13 TS - 0 19 1.0 S ksoftirqd/2

One relevant BIOS setting could concern the SATA ports ... presence of
pata_ati means that they're running in ATA mode, not AHCI, right? I
remember switching them to AHCI before because, well, I want proper
SATA operation. Could that bork up interrupt behaviour? If that's it,
fine, whatever makes the system stable ... but it would still feel
wrong to not run SATA disks in AHCI mode in 2012.


Alrighty then,

Thomas

PS: Oh, in case you wonder, my recording device is a FA-101 ... though
I do test internal audio and a simple USB sound card, too. And the
firewire card is actually a TI one, not VIA (I confused it with a PCI
VIA card I also have ... and which I could test in this box if need
arises).
--
Ubuntu-Studio-users mailing list
Ubuntu-Studio-users@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-users