[LAU] rtirq failure

Ralf Mardorf ralf.mardorf at alice-dsl.net
Sat Aug 8 20:15:01 UTC 2015

On Sat, 8 Aug 2015 20:46:17 +0100, Rui Nuno Capela wrote:
>On 08/08/2015 05:05 PM, Ralf Mardorf wrote:
>> On Sat, 8 Aug 2015 15:35:28 +0100, Rui Nuno Capela wrote:
>>> On 08/07/2015 11:11 PM, Ralf Mardorf wrote:
>>>> On Fri, 07 Aug 2015 22:58:36 +0200, Robin Gareus wrote:
>>>>> On 08/07/2015 11:47 AM, Ralf Mardorf wrote:
>>>>>> https://bugs.launchpad.net/ubuntu/+bug/1482347
>>>>> does
>>>>>    sudo /etc/init.d/rtirq restart
>>>>> on a running system fix this?  If so this is a startup-order issue
>>>>> (systemd related). rtirq is executed before the hdsp module
>>>>> (firmware) is loaded.
>>>> No, rtirq restart didn't fix it for RTIRQ_NAME_LIST="snd usb
>>>> i8042".
>>>> With RTIRQ_NAME_LIST="snd_hdsp snd_ice1" the order is ok after
>>>> startup.
>>> and what stands for snd_hdsp anyway?
>>> is it an ALSA device on its own, which correctly appears under
>>> /proc/asounds/cards as a PCI sound-card device? because the "snd"
>>> particle in RTIRQ_NAME_LIST stands only for ALSA PCI devices, USB
>>> and FW ones don't apply there--the correct procedure is about having
>>> "snd_hdsp" literally on RTIRQ_NAME_LIST, something you've already
>>> come around.
>>> just in case, please `cat /proc/asound/cards` on reply.
>> Hi Rui,
>> the HDSP is a HDSPe, IOW a PCIe card, an ALSA device.
>> [rocketmouse at archlinux ~]$ cat /proc/asound/cards
>>   0 [HDSPMx579bcc   ]: HDSPM - RME AIO_579bcc
>>                        RME AIO S/N 0x579bcc at 0xfdff0000, irq 18
>>   1 [EWX2496        ]: ICE1712 - TerraTec EWX24/96
>>                        TerraTec EWX24/96 at 0xbf00, irq 20
>>   2 [EWX2496_1      ]: ICE1712 - TerraTec EWX24/96
>>                        TerraTec EWX24/96 at 0xbb00, irq 21
>indeed it is.
>problem seems to be like strings "RME AIO_579bcc" on first line
>doesn't match exactly with the longer "RME AIO S/N 0x579bcc" on 2nd
>line and so that makes rtirq skip the respective entry altogether,
>when processing for the "snd" particle.
>it looks like previous kernels snd_hdsp module exposed exact strings, 
>not any longer.
>so you're left with the RTIRQ_NAME_LIST="snd_hdsp"... workaround for

Rui, thank you for the explanation.

It's not a workaround for me, I anyway would add snd_hdsp to ensure
that it gets a higher priority, than the Envy24 cards. I just worried
about it, because I didn't know, if it could become an issue for other
set-ups, used by others or maybe used by me in the future.

Without a script that works around this issue, for this card and perhaps
other cards, a default config to provide usable priorities for all
snd devices isn't ensured. That's a pity.


More information about the Linux-audio-user mailing list