4 Dec
2017
4 Dec
'17
7:32 a.m.
On 12/02/2017 10:05 PM, Len Ovens wrote:
No need for a daemon. The version of "rtirq" that is part of Planet
CCRMA (and I presume the current one if there is a newer version)
includes a udev rule to trigger on soundcard insertion. This was working
at some point, but it looks like something changed in the naming of
processes as it seems it does not seem to work now. Argh. Oh well...
-- Fernando
On Sat, 2 Dec 2017, Chris Caudle wrote:
...
> 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?
(I think that rtirq does a grep or something like that so usb should be
enough - but it is not enough, obviously - see below).
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
(usb3 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".
That is the best, of course. But I have not found this to be a deal
breaker. Usually (I imagine not always) it is possible to connect the
sound card to its own USB hub. And then you can up the priority of its
interrupt and have no interaction with other peripherals. "lsusb -t"
will show what uses each usb hub. But even when sharing it has been (so
far) ok.
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.