30 Nov
2016
30 Nov
'16
10:07 a.m.
Hello, again!
Another Computer - another problem. :)
Seems like my HDSP is no longer catched by rtirq-init. At least htop
doesn't list this card in the "priority-view". And I get a lot of
xruns... Wonder, if this has sth to do with systemd?
Using Debian Testing with KXstudio-overlay.
There was a handy tool to list the priority of Interrupts (and devices)
but I can't find it anymore and I forgot it's name. (Sth like
"rtprio"?)
Or is using rtirq-init the old way and I should use rtkit instead? If
yes, how?
Greets!
Mitsch
30 Nov
30 Nov
10:34 a.m.
On Wed, 30 Nov 2016 10:06:57 +0100, Michael Jarosch wrote:
Seems like my HDSP is no longer catched by rtirq-init.
At least htop
doesn't list this card in the "priority-view". And I get a lot of
xruns... Wonder, if this has sth to do with systemd?
What has got systemd to do with it?
Sometimes Debian and Ubuntu provide rtirq version that don't fit to
the used kernel. I noticed this several times and reports were always
ignored. I never experienced this inconsistency for my Arch Linux install.
Seldom upstream, IOW Rui needs to fix an issue, if e.g. kernel names
change. Happened years ago, that's why "snd_ice1" is for
"ice1712".
[weremouse@moonstudio ~]$ grep NAME_LIST /etc/default/rtirq | grep -v "#"
RTIRQ_NAME_LIST="snd_hdsp snd_ice1"
[weremouse@moonstudio ~]$ /etc/init.d/rtirq status | grep hdsp
392 FF 90 - 130 0.0 S irq/18-snd_hdsp
[weremouse@moonstudio ~]$ uname -r
4.4.0-47-lowlatency
[weremouse@moonstudio ~]$ lsb_release -d
Description: Ubuntu 16.04.1 LTS
[weremouse@moonstudio ~]$ dpkg -l rtirq-init | grep ii
ii rtirq-init 20150216-1 all startup script for realtime-preempt enabled
kernels
Sure that Debian and Ubuntu still use init scripts instead of units is
ridiculous. But systemd-sysv-generator hybrids don't cause issues in
regards to rtirq. I don't know why they pseudo migrated to systemd.
[weremouse@moonstudio ~]$ dpkg -L rtirq-init
/.
/etc
/etc/init.d
/etc/init.d/rtirq
/etc/default
/etc/default/rtirq
/usr
/usr/share
/usr/share/doc
/usr/share/doc/rtirq-init
/usr/share/doc/rtirq-init/copyright
/usr/share/doc/rtirq-init/changelog.Debian.gz
10:43 a.m.
PS:
Did you check, if systemd-sysv-generator works?
Run
systemctl status rtirq
if you use the tab key it will become
systemctl status rtirq.service
but you don't need to add ".service".
[weremouse@moonstudio ~]$ systemctl status rtirq.service
● rtirq.service - LSB: Realtime IRQ thread tunning.
Loaded: loaded (/etc/init.d/rtirq; bad; vendor preset: enabled)
Active: active (exited) since Wed 2016-11-30 09:39:16 CET; 1h 1min ago
Docs: man:systemd-sysv-generator(8)
Process: 737 ExecStart=/etc/init.d/rtirq start (code=exited, status=0/SUCCESS)
Nov 30 09:39:14 moonstudio systemd[1]: Starting LSB: Realtime IRQ thread tunning....
Nov 30 09:39:16 moonstudio rtirq[737]: Setting IRQ priorities: start [snd_hdsp] irq=18
pid=392 prio=90: OK.
Nov 30 09:39:16 moonstudio systemd[1]: Started LSB: Realtime IRQ thread tunning..
5:09 p.m.
On Wed, 30 Nov 2016, Michael Jarosch wrote:
Another Computer - another problem. :)
Seems like my HDSP is no longer catched by rtirq-init. At least htop
doesn't list this card in the "priority-view". And I get a lot of
xruns... Wonder, if this has sth to do with systemd?
Using Debian Testing with KXstudio-overlay.
There was a handy tool to list the priority of Interrupts (and devices)
but I can't find it anymore and I forgot it's name. (Sth like
"rtprio"?)
Or is using rtirq-init the old way and I should use rtkit instead? If
yes, how?
/etc/init.d/rtirq status
If you think it is a problem with systemd, try
sudo /etc/init.d/rtirq restart
/etc/init.d/rtirq status
and see if that changes anything. If it does, systemd is running rtirq too
soon before the card driver is running. Maybe get rc.local to run it again
with a delay in front (sleep 10 or something).
Also check (with cat /proc/interrupts) if your Audio card still shows up
as snd-something. If not change the "RTIRQ_NAME_LIST=" in
/etc/default/rtirq to use whatever does show up... or if not it is
possible to use irq/17 in that line if you know which irq it uses and it
has it's own irq (it should, change the slot it is in if not) In any case,
I have found using just snd in "RTIRQ_NAME_LIST=" generally puts the
internal audio ahead of the card. I always use the full driver name or at
least enough to be unique. ("snd_ice snd_ens enp3s0" is my line)
--
Len Ovens
www.ovenwerks.net
9:17 p.m.
Hi,
since I needed to delete around 10,500 spam mails, I also needed to
delete a few mails I received from this list, so the thread is
semi-broken. This mail isn't in reply to the OP, but in reply to Len's
mail. I read it in the archive.
Len wrote:
"If you think it is a problem with systemd, try
sudo /etc/init.d/rtirq restart"
If this should be required, then something is fishy with
systemd-sysv-generator.
Run
systemctl status rtirq
to check if systemd-sysv-generator has generated a unit and ask your
distro to completely migrate to systemd or to completely switch back to
init scripts. Hybrid distros are a PITA. It's idiotic to mix systemd
with init scripts.
Regards,
Ralf
3 Dec
3 Dec
1:30 a.m.
Sorry for the delay.
Am Mittwoch, den 30.11.2016, 21:17 +0100 schrieb Ralf Mardorf:
Len wrote:
"If you think it is a problem with systemd, try
sudo /etc/init.d/rtirq restart"
Works:
:/home/mitsch# /etc/init.d/rtirq status
PID CLS RTPRIO NI PRI %CPU STAT COMMAND
321 FF 90 - 130 0.0 S irq/19-snd_hda_
149 FF 85 - 125 0.0 S irq/17-ehci_hcd
171 FF 85 - 125 0.0 S irq/16-ohci_hcd
165 FF 84 - 124 0.0 S irq/19-ehci_hcd
172 FF 84 - 124 0.0 S irq/16-ohci_hcd
173 FF 84 - 124 0.0 S irq/18-ohci_hcd
175 FF 83 - 123 0.0 S irq/18-ohci_hcd
176 FF 82 - 122 0.0 S irq/18-ohci_hcd
77 FF 80 - 120 0.0 S irq/1-i8042
76 FF 79 - 119 0.0 S irq/12-i8042
55 FF 50 - 90 0.0 S irq/9-acpi
78 FF 50 - 90 0.0 S irq/8-rtc0
133 FF 50 - 90 0.0 S irq/6-floppy
139 FF 50 - 90 0.0 S irq/22-firewire
140 FF 50 - 90 0.0 S irq/14-pata_ati
141 FF 50 - 90 0.0 S irq/15-pata_ati
150 FF 50 - 90 0.4 S irq/22-ahci[000
328 FF 50 - 90 0.0 S irq/18-radeon
336 FF 50 - 90 2.7 S irq/21-snd_hdsp
810 FF 50 - 90 0.0 S irq/25-eth0
3 TS - 0 19 0.1 S ksoftirqd/0
22 TS - 0 19 0.1 S ksoftirqd/1
31 TS - 0 19 0.1 S ksoftirqd/2
40 TS - 0 19 0.1 S ksoftirqd/3
As one can see: The HDSP is recognised, but the card with highest
priority is the hda-intel, followed by USB- and Firewire-Devices. The
hdsp is relatively low on priority (50).
systemctl status rtirq
Also works (if you autocomplete rtirq ro rtirq.service), but it doesn't
print that nice output of /etc/init.d/rtirq status:
:/home/mitsch# systemctl status rtirq.service
● rtirq.service - LSB: Realtime IRQ thread tunning.
Loaded: loaded (/etc/init.d/rtirq; generated; vendor preset:
enabled)
Active: active (exited) since Sat 2016-12-03 00:50:51 CET; 15min ago
Docs: man:systemd-sysv-generator(8)
Tasks: 0 (limit: 4915)
CGroup: /system.slice/rtirq.service
When using journalctl one can see that snd_hdsp isn't set - only the
first ten devices listed in /etc/init.d/rtirq status (which differ from
priority 50) are.
That's strange. I remember that using "snd" as an item in
RTIRQ_NAME_LIST of /etc/default/rtirq usually made every sound-device
at least priority 80.
I should try to set the priority of snd_hdsp manually - how do I do
this, again?
It's idiotic to mix systemd with init scripts.
Yes, maybe. But you'll remember how heatened the discussion about
systemd was and you know, they had to handle the situation. The mix-
systemd-with-sysv-init-sollution works for vast majority of scripts
which hasn't been ported, yet. So, it's a good compromise and maybe
when the next debian stable is ready, all sysv-init-related stuff is
already history... No need to get angry, they've done a good job in my
opinion.
Greets!
Mitsch
10:18 a.m.
On Sat, 03 Dec 2016 01:29:58 +0100, Michael Jarosch wrote:
'systemctl status' doesn't run rtirq, it displays the status of the
service. If you run 'rtirq status' it doesn't show the status of the
service.
However, everything is ok with the generated unit, so the culprit most
likely is, that you need another release of rtirq or another release of
the kernel.
There are no issues with
[rocketmouse@archlinux ~]$ uname -r
4.8.11-1-ARCH
[rocketmouse@archlinux ~]$ pacman -Q rtirq
rtirq 20150216-1
[rocketmouse@archlinux ~]$ rtirq status | head -3
PID CLS RTPRIO NI PRI %CPU STAT COMMAND
292 FF 90 - 130 0.0 S irq/18-snd_hdsp
I don't understand why you call it a good job. Upstream provides rtirq
for systemd usage.
They don't need to "port" the script, they only need to package a unit.
It's even not required to write the 10 simple lines of the unit, since
it's already provided by upstream,
http://www.rncbc.org/jack/rtirq-20150216.tar.gz .
IOW your distro migrated to systemd and packages software from
upstream as an init script, while it already is for usage with systemd.
This is idiotic, since it takes extra work to package it as an init
script, while it is no extra work, to simply copy it from upstream.
I'm not discussing systemd here, I discuss irrational package
maintenance.
How could you call this a good job? I call it sabotage to package
software from upstream, providing everything for systemd usage, as an
init script, for a distro that migrated to systemd. AFAIK you won't find
it for other distros, I suspect that this is an issue for Debian and
Ubuntu only.
Arch Linux:
[rocketmouse@archlinux ~]$ pacman -Ql rtirq
rtirq /etc/
rtirq /etc/conf.d/
rtirq /etc/conf.d/rtirq
rtirq /usr/
rtirq /usr/bin/
rtirq /usr/bin/rtirq
rtirq /usr/lib/
rtirq /usr/lib/systemd/
rtirq /usr/lib/systemd/system/
rtirq /usr/lib/systemd/system/rtirq.service
Regards,
Ralf
Am Mittwoch, den 30.11.2016, 21:17 +0100 schrieb Ralf
Mardorf:
:/home/mitsch# /etc/init.d/rtirq status
336 FF 50 - 90 2.7 S irq/21-snd_hdsp
systemctl
status rtirq
doesn't print that nice output of /etc/init.d/rtirq status It's
idiotic to mix systemd with init scripts.
Yes, maybe. But you'll remember how heatened the discussion about
systemd was and you know, they had to handle the situation. The mix-
systemd-with-sysv-init-sollution works for vast majority of scripts
which hasn't been ported, yet. So, it's a good compromise and maybe
when the next debian stable is ready, all sysv-init-related stuff is
already history... No need to get angry, they've done a good job in my
opinion.
4:17 p.m.
On Sat, 3 Dec 2016, Ralf Mardorf wrote:
On Sat, 03 Dec 2016 01:29:58 +0100, Michael Jarosch
wrote:
I don't understand why you call it a good job. Upstream provides rtirq
for systemd usage.
I don't recall seeing Ralf submitting a patch to the package.... Try
looking at the number of packages any one maintainer deals with. Try doing
some of your own packaging before you call others down. If it's bad fix it
instead of grumble. Packaging debian packages to be satisfactory for the
debian archives can be painful and time intensive. Certainly packages that
don't work will get priority. Rtirq still works, so I imagine it is not
going to get done for a while.
... still dealing with sysinit, upstart and systemd all in one distro.
--
Len Ovens
www.ovenwerks.net
It's
idiotic to mix systemd with init scripts.
Yes, maybe. But you'll remember how heatened the discussion about
systemd was and you know, they had to handle the situation. The mix-
systemd-with-sysv-init-sollution works for vast majority of scripts
which hasn't been ported, yet. So, it's a good compromise and maybe
when the next debian stable is ready, all sysv-init-related stuff is
already history... No need to get angry, they've done a good job in my
opinion.
10:51 a.m.
On Sat, 3 Dec 2016 10:18:45 +0100, Ralf Mardorf wrote:
There are no issues with
[rocketmouse@archlinux ~]$ uname -r
4.8.11-1-ARCH
[rocketmouse@archlinux ~]$ pacman -Q rtirq
rtirq 20150216-1
[rocketmouse@archlinux ~]$ rtirq status | head -3
PID CLS RTPRIO NI PRI %CPU STAT COMMAND
292 FF 90 - 130 0.0 S irq/18-snd_hdsp
PS:
RTIRQ_NAME_LIST="snd_hdsp snd_ice1"
I suspect that if "snd" doesn't work for you, then "snd_hdsp"
won't
work, too, but you never know, configure with "snd_hdsp" to see if it
makes a difference. Don't restart rtirq! I noticed several times, that
a reboot could be required, so restart the computer.
5:05 p.m.
On Sat, 3 Dec 2016, Michael Jarosch wrote:
... If you are not using USB for audio, I would suggest removing usb from
your driver list in rtirq. Right now your mouse has a higher priority than
you audio card.
Len wrote:
"If you think it is a problem with systemd, try
sudo /etc/init.d/rtirq restart"
Works:
:/home/mitsch# /etc/init.d/rtirq status
PID CLS RTPRIO NI PRI %CPU STAT COMMAND
321 FF 90 - 130 0.0 S irq/19-snd_hda_
149 FF 85 - 125 0.0 S irq/17-ehci_hcd
171 FF 85 - 125 0.0 S irq/16-ohci_hcd 336 FF 50 - 90 2.7 S irq/21-snd_hdsp
Hm did you try running sudo /etc/init.d/rtirq restart some time after
loggin in? Just because /etc/init.d/rtirq status shows snd_hdsp after
login does not mean it was there at the time init ran during startup,
priority of 50 is just the system default when the module does finally
load.
You may wish to temporarily edit /etc/init.d/rtirq right down at the
bottom of the file you will find start) and status). As you can see,
status is really just a fancy ps command piped through egrep and awk.
rather than copy paste the whole thing up to just under start) a simpler line
for this:
ps xa |grep snd
should work just as well. (I don't know if the xa is needed in this case,
it is needed when running as a non-root user)
If you find irq/21-snd_hdsp is not there in the logs, maybe put
sleep 20 in in there.
So add these three lines:
start)
ps xa | grep snd
sleep 20
ps xa | grep snd
(the "start)" is already there)
And look at the logging from start up for those lines lines. You should
see snd_hdsp twice, but if you only see it once from the second ps then it
is a timing issue and you can reduce the number 20 (20 seconds is a long
delay in your boot :) till snd_hdsp no longer shows up at all at boot and
then add seconds till it does. Once you know the length of time required,
you can remove the ps lines and just keep the sleep. ( a sleep 1 may even
be enough)
Perhaps a WAIT_FOR="snd_whatever" or PREDELAY="<time>" could be
added to
the rtirq config for things like this. (yes this could be done with a
systemd config too)
--
Len Ovens
www.ovenwerks.net
5 Dec
5 Dec
11:50 p.m.
New subject: RME HDSP 9652 priority issue [solved]
Thanks Ralf, thanks Len!
I think, I solved the problem - although I don't know what went
wrong...
Added "rtc" (really don't know, why I ever removed it from the
list?!?), "hdsp" and "firewire" ('cause sometimes I use a Bebop-
Device). I removed "snd" and "usb".
Now, everything is on it's place: I got the rtc back on priority 90,
the hdsp is on 85, firewire 80 and both the i8042 - which caused
temporary freezes because they also weren't touched by rtirq - has 75
and 74.
Guess, this will work much better!
I rebooted twice before I wrote this mail, to make sure it's not a
timing issue. Still, I can't really say what was going on. Maybe the
hda- and usb-stuff blocked other devices from being reprioritised or
they were simply too many.
There is just one thing to do: Add the firewire-device, once I plug it.
I forgot the exact name of the module...
Greets!
Mitsch
6 Dec
6 Dec
4:31 a.m.
New subject: RME HDSP 9652 priority issue [solved]
On Mon, 05 Dec 2016 23:50:10 +0100, Michael Jarosch wrote:
Thanks Ralf, thanks Len!
Btw. I forgot that I reported this issue a long time ago. Len confirmed
it, https://bugs.launchpad.net/ubuntu/+bug/1482347
( https://aur.archlinux.org/packages/rtirq/ ).
Also see
http://lists.linuxaudio.org/pipermail/linux-audio-user/2015-August/102254.h…
Rui suspects the culprit is a string mismatch. Is there such a mismatch
for your hdsp device, too?
I always use
RTIRQ_NAME_LIST="snd_hdsp snd_ice1"
but noticed it when I temporarily used the default.
Btw., if it's solved for you, you should post RTIRQ_NAME_LIST to help
other users.
Added "rtc" (really don't know, why I
ever removed it from the
list?!?)
It's removed by upstream, since it's not required anymore.
"# RTIRQ_NAME_LIST="rtc snd usb i8042" # old
RTIRQ_NAME_LIST="snd usb i8042"" -
http://www.rncbc.org/jack/rtirq-20150216.tar.gz
Regards,
Ralf
--
"Pull a Homer -- to succeed despite idiocy." - The Simpsons
5:58 a.m.
New subject: RME HDSP 9652 priority issue [solved]
On Tue, 2016-12-06 at 04:31 +0100, Ralf Mardorf wrote:
> On Mon, 05 Dec 2016 23:50:10 +0100, Michael Jarosch wrote:
> > Thanks Ralf, thanks Len!
>
> Btw. I forgot that I reported this issue a long time ago. Len
> confirmed it, https://bugs.launchpad.net/ubuntu/+bug/1482347
> ( https://aur.archlinux.org/packages/rtirq/ ).
Oops, no he might not confirm the same issue. There might be two
unrelated issues. However, "eth0" isn't a snd device, it might suffer
from some mismatch issue, too, or it might be a timing issue or
something else.
> Also see
>
> http://lists.linuxaudio.org/pipermail/linux-audio-user/2015-August/
> 02254.html
>
> Rui suspects the culprit is a string mismatch. Is there such a
> mismatch for your hdsp device, too?
Please post the output of
cat /proc/asound/cards
[rocketmouse@archlinux ~]$ cat /proc/asound/cards
0 [HDSPMx579bcc ]: HDSPM - RME AIO_579bcc
RME AIO S/N 0x579bcc at 0xfddf0000, irq 18
6:08 a.m.
New subject: RME HDSP 9652 priority issue [solved]
"eth0" seemingly doesn't suffer from a string mismatch issue, since a
restart solved the issue for Len.
Yes, I'm aware that it's unwanted by this list to correct a reply, by
another reply :p.
9:59 a.m.
New subject: RME HDSP 9652 priority issue [solved]
If you're using the RTC on a modern computer, you're doing something wrong.
Just FYI.
On Mon, Dec 5, 2016 at 10:50 PM, Michael Jarosch <riotsound(a)riotmusic.de>
wrote:
Thanks Ralf, thanks Len!
I think, I solved the problem - although I don't know what went
wrong...
Added "rtc" (really don't know, why I ever removed it from the
list?!?), "hdsp" and "firewire" ('cause sometimes I use a Bebop-
Device). I removed "snd" and "usb".
Now, everything is on it's place: I got the rtc back on priority 90,
the hdsp is on 85, firewire 80 and both the i8042 - which caused
temporary freezes because they also weren't touched by rtirq - has 75
and 74.
Guess, this will work much better!
I rebooted twice before I wrote this mail, to make sure it's not a
timing issue. Still, I can't really say what was going on. Maybe the
hda- and usb-stuff blocked other devices from being reprioritised or
they were simply too many.
There is just one thing to do: Add the firewire-device, once I plug it.
I forgot the exact name of the module...
Greets!
Mitsch
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-user
3076
days inactive
3082
days old
linux-audio-user@lists.linuxaudio.org
14 comments
4 participants
participants (4)
-
Len Ovens -
Michael Jarosch -
Paul Davis -
Ralf Mardorf