Re: anyone running 4.13.15-300.rt5.1.fc27.ccrma.x86_64+rt + snd_usb yet?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@xxxxxxxxxxxxxxxxxxxx
https://lists.linuxaudio.org/listinfo/linux-audio-user



[Index of Archives]     [Linux Sound]     [ALSA Users]     [Pulse Audio]     [ALSA Devel]     [Sox Users]     [Linux Media]     [Kernel]     [Photo Sharing]     [Gimp]     [Yosemite News]     [Linux Media]

  Powered by Linux