xrun on video update? Dual Nvidia's, x86_64, RT patched FC5

Short story:

I’m running two lovely apple 30" LCD’s on a pair of NVIDIA GFORCE 8xxx’s with the Nvidia driver (same problem with NV driver btw) and I get consistent xruns if the screen scrolls (in other words if I am zoomed all the way out I don’t get xruns.) Obviously this sort of works and mostly sucks. It also xruns if I move the mouse over any other windows or over buttons that flash when you mouse over them (basically if you make anything change on the screen.) I’ve dropped down to twm to rule out gnome/kde business. :frowning: I’m sort of feeling like it’s something to do with scheduling but I’m pretty close to the limits of my knowlefe. In other words… I’m at my wits end! Any thoughts?

Some Details:
2.6.20-rt8 #3 SMP PREEMPT (single processor Athalon 64)
jackd version 0.103.0 tmpdir /mnt/ramfs protocol 16
ardour-2.0beta12
RME Hammerfall HDSP 9652

~/software/cyclictest/cyclictest -t 1 -p 80 -n -i 10000 -l 10000
0.36 0.27 0.11 1/124 7346
T: 0 ( 7319) P:80 I:10000 C: 10000 Min: 9 Act: 12 Avg: 13 Max: 29 (not to bad!)

0: 130 IO-APIC-edge timer
1: 5326 IO-APIC-edge i8042
8: 0 IO-APIC-edge rtc
9: 0 IO-APIC-fasteoi acpi
12: 139848 IO-APIC-edge i8042
14: 37113 IO-APIC-edge ide0
15: 251435 IO-APIC-edge ide1
16: 5 IO-APIC-fasteoi ohci1394, ohci1394
17: 38026 IO-APIC-fasteoi hdsp
18: 362009 IO-APIC-fasteoi nvidia
19: 364780 IO-APIC-fasteoi nvidia
20: 0 IO-APIC-fasteoi ohci_hcd:usb1
21: 2224243 IO-APIC-fasteoi eth0
22: 118 IO-APIC-fasteoi libata, NVidia CK804
23: 5376 IO-APIC-fasteoi libata, ehci_hcd:usb2
NMI: 0
LOC: 22458943
ERR: 0

Unless I’m mistaken I’ve got this setup so that the the RME card clearly has priority.

./irq_check 17

pid 1300’s current scheduling policy: SCHED_FIFO
pid 1300’s current scheduling priority: 99

./irq_check 18

pid 3961’s current scheduling policy: SCHED_FIFO
pid 3961’s current scheduling priority: 5

./irq_check 19

pid 3950’s current scheduling policy: SCHED_FIFO
pid 3950’s current scheduling priority: 5

I’m also setting chrt -f -p (80 for jackd and 70 for ardour) once they start.

I’m fairly certain this is more of a jack w/ Nvidia problem than an Ardour problem but it’s close enough. :slight_smile:

Thanks in advance for any thoughts.

  1. What number of samples/period is jack running at?. -p 1024 would be good to try.

    How many periods? Try -n 3 rather than -n 2.

  2. With that much video to handle a dual processor would be good

  3. Try dropping the bitdepth on the display

  4. Try dropping the pci latency value for the nvidias to 64 or higher. (see the setpci and the lspci commands for details).

(in rough order of trial)

OMG I’m so happy! :slight_smile:

I managed to get keep it at 2 periods and even was able to drop the Frames/Period down to 128 and the latency to 32 and still record 4 live tacks while playing back 8 that already were recorded (plus a click!). I even got brazen and clicked over to firefox (which always caused xruns) and it just kept on cruisin with the DSP barely even working and plenty of room left.

So what did I do? Who knows… I’m an idiot. While I was waiting I decided to completely blow away jack and qjackctl and recompile them… somehow that did the trick… wtfk. anyway… :slight_smile: I’m going to try dropping the bitdepth and latency as well just to see exactly how much I can crack out of this thing but at this point it’s just screaming. Thanks for the ‘help’.

Boing Boing Boing!

hmm… perhaps you enabled SSE on the jack rebuild?

You should also NOT:

“I’m also setting chrt -f -p (80 for jackd and 70 for ardour) once they start.”

do that. jackd has several RT threads that are setup automatically correctly if you start with the -R option and the priority. Same goes for ardour. It will run it’s RT thread at rt privs, and nothing else.

Several threads in both programs are intended to run at a lower priority than everything else. Don’t make it all run at RT privs.

I HAVE noticed some improvement sometimes by starting ardour with nice -10, which
bumps the gui up above other processes in the system, but keeps it below all the rt processes…

Glad you are cookin with oil. Am very jealous of those 30 inch monitors.

Massive desktop space is a good thing!

Thanks for the tips. I tried NOT doing that and you are right that everything works just fine. I think you must be right about what happened during the recompiles, though I’m not sure how I managed to screw that up. No complaints though. Sometimes just asking for help is enough of a sign of humility that the computer will let things start working. :slight_smile:

Boing!

I had the same thing on an early version on 64studio on an Asus board (also on NVidia graphics btw)

I finally bought a graphics card. The only relatively cheap PCIe card I could find was a GeForce 6600 and I seriously doubted getting that - nVidia as well!) but all went well!
No problems for me anymore.