[PlanetCCRMA] priority, etc.

Tue Oct 6 10:59:52 PDT 2009

On Mon, 2009-10-05 at 18:59 -0400, Elliott Chapin wrote:
> 
> On 10/04/2009 11:48 PM, Fernando Lopez-Lezcano wrote:
> 
> >> Then I was probably using kernel 2.6.29.6-1.16fc11.ccrma.i586.rt;
> >> current jack is jack-audio-connection-kit-1.93-1.rt23.2.fc11.ccrma(i586)
> >
> > Hmmm, those numbers (the jack ones) don't seem right at all. Probably
> > jack 1.9.2? If you truly have 1.93 (rpm -q jack-audio-connection-kit to
> > find out) then that is probably the problem, very old version. I don't
> > think that is possible at all. But if that is the case (please confirm)
> > you should:
> 
> typo - should have written 1.9.3. I had hoped that adding the testing 
> repo would help.
>
> >>>> There seem to be various problems now, and I am not sure whether
> >>>> they come from the rt kernel, CCRMA Jack or alsa; or that they are just
> >>>> out of sync.
> >>>
> >>> It'd be good to have a list of problems. This is too generic a
> >>> description to try to answer.
> >>>
> >>>> As a starter, the other day F. questioned priority of 89 but did not
> >>>> give a good lower number.
> >>>
> >>> I think a good number would be 72. For some reason I found that the
> >>> default priority of the latest Planet CCRMA jack builds is incorrect
> >>> (too low at 10), I have to look at that - something is not being patched
> >>> correctly.
> >>>
> >>> If you are running the rt kernel, check the output of:
> >>>
> >>> /etc/rc.d/init.d/rtirq status
> >>
> >> With the current setup except changing to priority=72 I get
> >>
> >>     PID CLS RTPRIO  NI PRI %CPU STAT COMMAND	
> >>      73 FF      80   - 120  0.0 S<    IRQ-8	rtc0
> >>      66 FF      75   - 115  0.0 S<    IRQ-16	ehci_hcd:usb1, uhci_hcd:usb2,
> >> i915, HDA Intel
> >>      67 FF      69   - 109  0.1 S<    IRQ-17	uhci_hcd:usb3
> >>      68 FF      68   - 108  0.0 S<    IRQ-18	uhci_hcd:usb4, ath
> >>      69 FF      67   - 107  0.0 S<    IRQ-19	uhci_hcd:usb5
> >>      71 FF      65   - 105  0.0 S<    IRQ-1	i8042
> >>      70 FF      64   - 104  0.0 S<    IRQ-12	i8042
> >>      43 FF      50   -  90  0.0 S<    IRQ-9	acpi
> >>      62 FF      50   -  90  0.0 S<    IRQ-14	ata_piix
> >>      63 FF      50   -  90  0.0 S<    IRQ-15	ata_piix
> >>    1713 FF      50   -  90  0.0 S<    IRQ-28	PCI-MSI-edge      eth0
> >
> > Do you have an usb soundcard only? I don't see anything else that might
> > be a soundcard. What do you see if you do:
> 
> I am using only the Acer's internal sound card.  There are no other 
> sound cards.
> >
> > cat /proc/asound/cards
> 
>   0 [Intel          ]: HDA-Intel - HDA Intel
>                        HDA Intel at 0x58540000 irq 16
> 
> >
> > After you see there is a soundcard you could try to start jack from a
> > terminal:
> >
> > jackd -R -d alsa -d hw:0
> >
> > and see what it tells you.
> 
>   jackd -R -d alsa -d hw:0
> jackwrapper: pacmd suspend 1
> jackdmp 1.9.3
> Copyright 2001-2005 Paul Davis and others.
> Copyright 2004-2009 Grame.
> jackdmp 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
> could not open driver .so '/usr/lib/jack/jack_firewire.so': libffado.so: 
> cannot open shared object file: No such file or directory
> could not open component .so '/usr/lib/jack/jack_firewire.so': 
> libffado.so: cannot open shared object file: No such file or directory
> JACK server starting in realtime mode with priority 10
> creating alsa driver ... hw:0|hw:0|1024|2|48000|0|0|nomon|swmeter|-|32bit
> Using ALSA driver HDA-Intel running on card 0 - HDA Intel at 0x58540000 
> irq 16
> configuring for 48000Hz, period = 1024 frames (21.3 ms), buffer = 2 periods
> ALSA: final selected sample format for capture: 32bit integer little-endian
> ALSA: use 2 periods for capture
> ALSA: final selected sample format for playback: 32bit integer little-endian
> ALSA: use 2 periods for playback
> alsa_driver_xrun_recovery
> 
> 
> **** alsa_pcm: xrun of at least 0.413 msecs
> 
> 
> JackAudioDriver::ProcessAsync: read error, skip cycle
> 
> -------------------------
> 
> To me this looks pretty normal - suggests that Qjackctl might be the 
> culprit, now tentatively confirmed by being able to open zynaddsubfx 
> after starting jack as you recommended. Kernel is rt23.4; jack is 
> 1.9.3-1. Hope no typo's left :)

Well, qjackctl does not do anything but call jackd. Most likely the
options in qjackctl are not set correctly and/or differ from what you
were doing in the command line. 

What are the options you are currently using in qjackctl? For starters
make sure "Interface" is pointing to "hw:0" and not just "default". 

"Frames/Period", I'd start with 1024 (and if it works try with lower
values if you need lower latency), and "Periods/Buffer" possibly 2 or 3.
Do _not_ set "Input Channels" or "Output Channels". For "Priority" use
72 as outlined before. "Realtime" should already be set. 

-- Fernando