[Lmuse-user] ALERT: Recent kernels break ALSA support in MusE

[Tim]

Crap. Talk about bad timing, literally. Bad luck. Bad coincidence.
I'm putting out fires in one area and they're breaking out under my nose.

The story:
While investigating the frozen graphics issues, I installed openSuSE
on a spare partition to test. While there, I noticed MusE quits
if the ALSA support is enabled in the midi config dialog.

It quits because it can't set the ALSA HR timer frequency to
our desired value, default 1024Hz in the Global Settings.

In fact, no matter what I tried in the timer params
structure that we pass to snd_timer_params(), it failed.
Hmm...
I thought "Meh, another permissions thing, the user likely
has to poke some setting to allow changing the timer."

So I pushed a fix that allows MusE to continue with whatever
the HR timer wants to run at. That's 1000000000Hz by the way.
I warn the user that their system may need adjustment.

OK fine. So then I reboot and go back to the KUbuntu 16.04 LTS.
Now here's the crazy part:
I got the SAME problem: ALSA HR timer refusing our settings.
But the HR timer was FINE ever since I added it months ago !
But now all of a sudden, not working? WTF?
It broke across two different distros?
I thought "How? Did SuSE break something? Write to my
sound card or CMOS or something? Grub2 changed?"

Now the funny part:
It turns out, about a week ago, while my back was turned
working on this graphics stuff, a new kernel came down
for KUbuntu LTS 16.04:
kernel 4.4.0-77
And of course, in my shiny new SuSE installation it is
already way past that point:
kernel 4.10.13-1

Everything worked again when I back-peddled KUbuntu to:
kernel 4.4.0-72

Ah, now it all made sense. My bad luck.

***
Anyhow, bottom line, y'all are gonna need the latest
MusE git master to use it with ALSA midi !
***

Not crazy about the fixed 1000000000Hz. Too much?
Ha! Our problem used to be not enough Hertz.
I'm working on it. I may contact ALSA for answers.

Tim.

[Tim]

I noticed MusE quits if the ALSA support is enabled in the midi config dialog.
It quits because it can't set the ALSA HR timer frequency to
our desired value, default 1024Hz in the Global Settings.
In fact, no matter what I tried in the timer params
structure that we pass to snd_timer_params(), it failed.

Yikes!
It turns out I missed something.
There is now some kind of default limit at 1000Hz.
It works OK if I set it at 1000Hz, not 1024Hz.
Can't find any setting, kernel config or otherwise.
I emailed ALSA for help.
For now I may add 1000Hz as an option in Settings.
Also 250Hz and 100Hz would be good to have there.

Hmm...
I thought "Meh, another permissions thing, the user likely
has to poke some setting to allow changing the timer."
So I pushed a fix that allows MusE to continue with whatever
the HR timer wants to run at. That's 1000000000Hz by the way.
I warn the user that their system may need adjustment.

No, this is actually NOT working!
I neglected to test PLAYBACK. It does not work because the timer
refused our 'autostart' request in the timer params structure.
The timer fires once then stops. I tested this by starting it again
after each tick - it works! but this is NOT what we want.
See, the weird thing is, to set the 'autostart' flag you must supply
the desired frequency (ticks) at the same time in the structure.
How can we do that when we don't know the limit ???
I wish I knew where to find that info, this new limit...
The timer says it has waaay more resolution available than this.
We should be able to set it higher, but this new limit is
messing things up.
Tim.

OK folks, try this ALSA HR timer fix in git master.
Steps through several frequencies looking for the best one.
Starting from your requested value in Settings (default is 1024 Hertz),
all the way down to 100 Hertz. It gives up after that.

It should now find (at least) 1000 Hertz on a standard desktop system.
Likely not any higher, from what I've seen so far.
Midi PLAYBACK should work now.

Hmm.
Now we have a situation where, for higher rates the ancient RTC timer
is better for those who set it up correctly.
Or else, likely (waiting for alsa's reply) the user must now fool with the
system HR timer to get better timing out of it.
I really hope not. I hope it can be done in userland.
Either way would be bad, I don't want that users must fool with that stuff.

T.

[Tim]

Post by Tim

I noticed MusE quits if the ALSA support is enabled in the midi config dialog.
It quits because it can't set the ALSA HR timer frequency to
our desired value, default 1024Hz in the Global Settings.
In fact, no matter what I tried in the timer params
structure that we pass to snd_timer_params(), it failed.

Yikes!
It turns out I missed something.
There is now some kind of default limit at 1000Hz.
It works OK if I set it at 1000Hz, not 1024Hz.
Can't find any setting, kernel config or otherwise.
I emailed ALSA for help.
For now I may add 1000Hz as an option in Settings.
Also 250Hz and 100Hz would be good to have there.

Hmm...
I thought "Meh, another permissions thing, the user likely
has to poke some setting to allow changing the timer."
So I pushed a fix that allows MusE to continue with whatever
the HR timer wants to run at. That's 1000000000Hz by the way.
I warn the user that their system may need adjustment.

No, this is actually NOT working!
I neglected to test PLAYBACK. It does not work because the timer
refused our 'autostart' request in the timer params structure.
The timer fires once then stops. I tested this by starting it again
after each tick - it works! but this is NOT what we want.
See, the weird thing is, to set the 'autostart' flag you must supply
the desired frequency (ticks) at the same time in the structure.
How can we do that when we don't know the limit ???
I wish I knew where to find that info, this new limit...
The timer says it has waaay more resolution available than this.
We should be able to set it higher, but this new limit is
messing things up.
Tim.

OK folks, try this ALSA HR timer fix in git master.
Steps through several frequencies looking for the best one.
Starting from your requested value in Settings (default is 1024 Hertz),
all the way down to 100 Hertz. It gives up after that.
It should now find (at least) 1000 Hertz on a standard desktop system.
Likely not any higher, from what I've seen so far.
Midi PLAYBACK should work now.
Hmm.
Now we have a situation where, for higher rates the ancient RTC timer
is better for those who set it up correctly.
Or else, likely (waiting for alsa's reply) the user must now fool with the
system HR timer to get better timing out of it.
I really hope not. I hope it can be done in userland.
Either way would be bad, I don't want that users must fool with that stuff.
T.

Sorry for all this noise but I know some folks use MusE with ALSA midi.

In git master now: This should finally take care of everyone:

- Further to 22.05: [Sigh] More timer fixes:
Info: Alsa HR timer now has hard-coded 1000 Hz limit, unsettable,
unreadable :-o
As recommended by ALSA support, step through and try freqs as before.
Fixed div by 0 crash in ALSA timer if freq too high - set ticks to 1
if 0.

In view of the above, the RTC timer now takes priority. MusE tries it
first,
and falls back to ALSA (typically the HR timer or else the sytem timer).


Updated README with modern info about setting up systems for timers.

Read it. Tell me if anything raises eyebrows, or uni-brow as the case
may be.
For the lazy, here it is:

=========================
- Timer accuracy for ALSA support:

If ALSA support is enabled, a reliable source of timing is
desired for playback of midi notes.

By default, the timer is attempted to run at 1024 Hz
(ticks/second).

MusE will try the Real Time Clock (RTC) first.
If that fails it will try ALSA timers instead - typically the
ALSA High Resolution (HR) timer or the ALSA sytem timer.

The RTC is recommended, with sufficient permissions, for best
accuracy.

To ensure you have permissions to use the RTC, on modern systems
using udev rules, create this file if it does not exist:
"/etc/udev/rules.d/40-timer-permissions.rules"
and add the follwing lines to the file:
KERNEL=="rtc0",GROUP="audio"
KERNEL=="hpet",GROUP="audio"
and, as stated in "Recommended setup" above, ensure you are
part of the audio group.

(The hpet is not supported, but that line can help other
applications.)

It is possible to use the ALSA system timer instead of the RTC,
but it usually requires a kernel built with a 1000 Hz system timer
(low-latency, realtime, or custom kernel as in "Recommended
setup" above).
With most desktop kernels, the system timer is limited to 250 Hz,
while the HR timer is limited to 1000 Hz.
On such distros, without modification, MusE should end up picking
the 1000 Hz HR timer.

But if you set your RTC as above, you can run even higher rates.
See the Global Settings dialog for user-adjustable high rates.

Run MusE in a terminal to see what it picks. -D option gives
more info.


(The following is old information! But may work for those
without udev.)
Make sure you can acces the realtime clock (RTC)
chmod 660 /dev/rtc
chgrp audio /dev/rtc
Make sure MusE can set the rtc clock:
echo 8192 > /proc/sys/dev/rtc/max-user-freq
inspect with:
cat /proc/sys/dev/rtc/max-user-freq

=========================

Hope this helps.
Tim.

[Dennis Schulmeister-Zimolong]

Hi Tim,

Not using MusE with ALSA anymore but the instructions seem clear to me.
Thanks for looking into it.

Dennis