[LAU] anyone running 4.13.15-300.rt5.1.fc27.ccrma.x86_64+rt + snd_usb yet?

Fernando Lopez-Lezcano nando at ccrma.Stanford.EDU
Mon Dec 4 06:31:48 UTC 2017


On 12/02/2017 10:05 PM, Len Ovens wrote:
> 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.

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



More information about the Linux-audio-user mailing list