[PlanetCCRMA] FC2.1vP9 - jackstart just quits...

[Mark Knecht]

On Wed, 2004-09-29 at 09:45, Fernando Pablo Lopez-Lezcano wrote:

> This would seem to suggest some problem with interrupts coming from the
> soundcard. For some weird reasons moving the mouse must be enabling
> interrupts from the soundcard, stopping the movements stall the
> interrupts again and the jack watchdog timer kills everything. 

Yes, logically this makes sense.

With this distro I'm very unsure about ps aux showing me a process for
each interrupt. Is this exxected as part of IRQ threading?
> 
> This is definitely a problem with the P9 kernel in your hardware. 

Seems to be. I do not think it's specifically the hardware. I'm in
Gentoo running a standard kernel. I cannot run jackstart, but running
jackd gives reasonable results:

flash mark $ jackd -v -d alsa -r 44100 
getting driver descriptor from /usr/lib/jack/jack_dummy.so
getting driver descriptor from /usr/lib/jack/jack_alsa.so
getting driver descriptor from /usr/lib/jack/jack_oss.so
getting driver descriptor from /usr/lib/jack/jack_portaudio.so
jackd 0.98.1
Copyright 2001-2003 Paul Davis and others.
jackd comes with ABSOLUTELY NO WARRANTY
This is free software, and you are welcome to redistribute it
under certain conditions; see the file COPYING for details

JACK compiled with System V SHM support
registered builtin port type 32 bit float mono audio
required capabilities not available
capabilities: =
loading driver ..
new client: alsa_pcm, id = 1 type 1 @ 0x8057898 fd = -1
apparent rate = 44100
creating alsa driver ...
hw:0|hw:0|1024|2|44100|0|0|nomon|swmeter|-|32bit
control device hw:0
configuring for 44100Hz, period = 1024 frames, buffer = 2 periods
new buffer size 1024
registered port alsa_pcm:capture_1, offset = 4096
registered port alsa_pcm:capture_2, offset = 8192
registered port alsa_pcm:playback_1, offset = 0
registered port alsa_pcm:playback_2, offset = 0
++ jack_rechain_graph():
client alsa_pcm: internal client, execution_order=0.
-- jack_rechain_graph()
11004 waiting for signals
load = 0.0237 max usecs: 11.000, spare = 23208.000 <-start wiggling
load = 0.0226 max usecs: 5.000, spare = 23214.000
load = 0.0307 max usecs: 9.000, spare = 23210.000
load = 0.0433 max usecs: 13.000, spare = 23206.000
load = 0.0432 max usecs: 10.000, spare = 23209.000
load = 0.0539 max usecs: 15.000, spare = 23204.000
load = 0.0549 max usecs: 13.000, spare = 23206.000
load = 0.0684 max usecs: 19.000, spare = 23200.000
load = 0.0643 max usecs: 14.000, spare = 23205.000 <-Ctrl-C
jack main caught signal 2
stopping driver
detaching driver
unloading driver
freeing shared port segments
stopping server thread
stopping watchdog thread
freeing engine shared memory
engine deleted
flash mark $ 

Under this kernel IRQs are APIC basied and the sound chip is on 5 by
itself. No clue on priority since it's APIC:

flash mark $ cat /proc/interrupts 
           CPU0       
  0:    8399840    IO-APIC-edge  timer
  1:       2927    IO-APIC-edge  i8042
  5:        864   IO-APIC-level  ATI IXP
 12:       2836    IO-APIC-edge  i8042
 14:       9623    IO-APIC-edge  ide0
 15:         12    IO-APIC-edge  ide1
 16:      16378   IO-APIC-level  ohci_hcd, ohci1394
 18:          0   IO-APIC-level  ohci_hcd
 19:        970   IO-APIC-level  ohci_hcd, ohci_hcd, ehci_hcd, eth0
 21:      23346   IO-APIC-level  acpi
NMI:          0 
LOC:    8398932 
ERR:          0
MIS:          0
flash mark $ 

How do I get your kernel to set up APIC interrupts? Or have you disabled
that in your kernel build?

> 
> BTW, don't bother optimizing the number of services or processes running
> in your machine. If Jack runs with realtime priority it should not
> really matter. 

Good point.

> 
> > Now, there are a huge number of processes running. I've seen artsd
> > start a couple of times and block Jack. I have much to do to give KDE
> > a chance, I think, but I do not know what to think of this operation.
> > 
> > I did set the THREADED option to 0 as per the setup email. Seems like
> > possibly that's not a good idea? Not sure at all.
> 
> You could turn that to "1" just to test if it is a problem. 

Didn't help...

> 
> But I would try with the other experimental kernels if you are curious
> enough. Just yesterday I released R9, a more recent build with a more
> recent voluntary preemption patch. 
> 

Looking soon. Must pay some bills first...

thanks,
Mark