3 Dec
2017
3 Dec
'17
7:05 a.m.
On Sat, 2 Dec 2017, Chris Caudle wrote:
I thought perhaps jackd would give useful error
messages, but I see no
errors when starting, but "no callback" messages begin showing up right
away. I'm stopped at the moment, I do not know how to proceed without
finding some kind of error message to point me in the right direction. Is
there any other location to find status information on USB audio devices?
This is the rtirq configuration in use:
RTIRQ_NAME_LIST="usb enp3s4f1 i8042"
RTIRQ_PRIO_HIGH=95
RTIRQ_PRIO_DECR=2
Is "usb" enough there, or should it be snd_usb in place of usb?
In my experience, usb is not enough. Think of it another way, do you want
your mouse, web cam, whatever to have a higher priority than your audio? I
have found that the high priority usb device needs to be unique (use3 used
to work for me) and that the rest of the usb needs to be less than all
other high priority things example "usb3 enp3s4f1 i8042 usb".
As an aside, I found that the IRQ priorities were not
set automatically, I
had to manually run rtirq, but that is probably a fedora package problem.
I have found this too, it means that rtirq was run before one or more of
the devices you are interested in being ready. rtirq really needs to run
as a daemon setting priorities as devices show up. (even reordering them
if needed) the change is hot plugable devices have become a thing. It may
be better to not have rtirq not run at startup but after the audio device
has been detected.
Getting USB interrupt priority set to a high priority
made no difference
This is the startup output from jackd:
Acquire audio card Audio1
creating alsa driver ...
hw:Lambda|hw:Lambda|1024|3|48000|0|0|nomon|swmeter|-|32bit
configuring for 48000Hz, period = 1024 frames (21.3 ms), buffer = 3 periods
ALSA: final selected sample format for capture: 24bit little-endian
ALSA: use 3 periods for capture
ALSA: final selected sample format for playback: 24bit little-endian
ALSA: use 3 periods for playback
At this point I would expect a line for each port on the audio interface
like:
graph reorder: new port 'system:capture_1'
Jack: JackSocketServerChannel::Open
Jack: JackServerSocket::Bind : addr.sun_path /dev/shm/jack_default_1000_0
Jack: JackSocketServerChannel::BuildPoolTable size = 1
Jack: JackEngine::Open
Jack: JackClientSocket::Connect : addr.sun_path /dev/shm/jack_default_1000_0
Jack: JackEngine::ClientInternalOpen: name = freewheel
Jack: JackEngine::AllocateRefNum ref = 1
Jack: JackPosixSemaphore::Allocate name = jack_sem.1000_default_freewheel
val = 0
Jack: JackEngine::NotifyAddClient: name = freewheel
Jack: JackDriver::ClientNotify ref = 1 driver = system name = freewheel
notify = 0
Jack: JackDriver::ClientNotify ref = 0 driver = freewheel name = system
notify = 0
Umm, driver = freewheel? If jack is in freewheel and also connected to the
sound card that does not make sense. Unless I am mixing up this freewheel
with another one, jack freewheel means advance to the next block/graph
when this one is finished regardless of when the audio card is ready
without calling it an xrun. That would distort things for sure.
Thats all that sticks out for me.
Which version of jackd? with or without dbus, what command to start? I use
jackdbus and the startup config is in ${HOME}/.config/jack/conf.xml
jackd stores its command line in ${HOME}/.jackdrc. also check /etc/jackdrc
to see if the distro has set that odd.
--
Len Ovens
www.ovenwerks.net