kernel 6.6

[wintpe]

I use muse4 on fedora 39, and they have just updated to kernel 6.6.2.
something has changed that means journalctl shows issues with permissions on the /dev/rtc0 device and as a result
muse is not able to start jack audio.

the error recorded from journalctl is as follows

plasmashell[5332]: precise timer not available, check file permissions and allowed RTC freq (/sys/class/rtc/rtc0/max_user_freq)
musicbox plasmashell[5332]: Trying ALSA timer...
plasmashell[5332]: AlsaTimer::initTimer(): best available ALSA timer: system timer
plasmashell[5332]: got timer = 26

reverting to previous kernel fixed issue ie 6.5.12

i also tried latest appimage just in case but same.

some old advise of echoing 3072 into the above device file and also

cat /etc/sysctl.d/50-muse4.conf
dev.hpet.max-user-freq=3072

does not help either

muse still works ok if i start it with -t, but terrible latency that way....

regards peter

[Impostor]

muse is not able to start jack audio.

Has MusE ever been able to start Jack? I think you have to start Jack before MusE.

the error recorded from journalctl is as follows

plasmashell[5332]: precise timer not available, check file permissions and allowed RTC freq (/sys/class/rtc/rtc0/max_user_freq)
musicbox plasmashell[5332]: Trying ALSA timer...
plasmashell[5332]: AlsaTimer::initTimer(): best available ALSA timer: system timer
plasmashell[5332]: got timer = 26

That's not really an error though, just a message. Alsa timer* should work fine (defaults to 1000 Hz I think). Lack of access to RTC shouldn't prevent MusE from functioning.

Edit: I was thinking of the HR timer. Maybe a kernel module is not installed/loaded?

[autostatic]

Highly doubt any DAW or sequencer still uses /dev/rtc0 these days, most if not all rely on the snd-hrtimer kernel module. Make sure it's loaded. You can check with

Code: Select all

grep timer /proc/asound/timers

It should return something like this

Code: Select all

G0: system timer : 4000.000us (10000000 ticks)
G3: HR timer : 0.001us (1000000000 ticks)

[Impostor]

Highly doubt any DAW or sequencer still uses /dev/rtc0 these days, most if not all rely on the snd-hrtimer kernel module. Make sure it's loaded. You can check with

Code: Select all

grep timer /proc/asound/timers

It should return something like this

Code: Select all

G0: system timer : 4000.000us (10000000 ticks)
G3: HR timer : 0.001us (1000000000 ticks)

snd-hrtimer gets loaded here whenever jack is started. But MusE indeed uses rtc if it has access to it. It tries rtc>hr>system in order.
@OP, you can also manually load the hr timer with "sudo modprobe snd_hrtimer".

[wintpe]

normaly muse never complains about jack not running or its unable to talk to rtc,
which is the two dialog boxes i have to dismiss when i start it under 6.6
and then you cant get it to play anything it just wont play.

i think thats because its pw-jack and it runs all the time as part of pipewire.

just a reminder , under 6.5 and prior kernels it works as it has since i joined this forum,
under 6.6 problem......
i will try modprobe snd_hrtimer, see if it makes any difference , and report back,

i dont use sudo, ever, why is it people always shove sudo in front of everything,
its a hack for priverlage escalation, just say "as root".

but my gut feeling this has something to do with 6.6 change in schedular, ie eevdf, rather than cfs.
thats the big change since a 2.6 era kernel.

thanks for the hints though.

regards peter

[Impostor]

i dont use sudo, ever, why is it people always shove sudo in front of everything,
its a hack for priverlage escalation, just say "as root".

So what's your MO when you need to run a command "as root"?

[wintpe]

su -

su has been around since around 1970.

i started on unix in 1989.

sudo started apearing around same time i started in unix, but i never saw it used as a way to enable anyone to su
until i came across debian systems, prior to that it was used stricly for enabling scripts to escalate.
we also used kinit root

at least thts been my expirience in sysadmin world

regards peter

[Tim E. Real]

Using latest kernel here on openSUSE tumbleweed:
Linux localhost.localdomain 6.6.2-1-default #1 SMP PREEMPT_DYNAMIC Mon Nov 20 11:22:36 UTC 2023 (263a855) x86_64 x86_64 x86_64 GNU/Linux

No trouble due to kernel here.

MusE needs a timing source.
So MusE tries the Real Time Clock (RTC) first if it is available.
Usually it is not, these days, at least without effort.

So MusE then tries the ALSA timers.
It appears MusE was able acquire an ALSA timer correctly.

I don't think this has much to do with the issue.
I would tend to point to Jack/pipewire/Pulse problems.

Are you using a packaged version of MusE?
Are you comfortable attempting to build MusE yourself?
Or maybe try the latest AppImage just to see if it works.

Try running MusE with the -D command line option for more output info.
Did you say that MusE just won't start? Or does it freeze? Or does it crash?
Recall that the combination of Jack and Pulse caused freezing from day one.
Thus special QJackCtl scripts were usually required to carefully start and stop Pulse.
However pipewire is new to me. I'm not sure how much that statement still applies today.
Pipewire is now the audio system here on Tumbleweed. I just finished installing the latest Tumbleweed.
So I am just getting used to Pipewire.

Thanks.
T.

[wintpe]

thanks tim, so its gotta be a fedora 6.6 issue then

im using latest master, but a i was using standard 4.2 when i fisrt discovered the issue.

its the same version of pipewire , i just switch the kernal, under 6.6 it chucks up two dialogs about jack and time source
and the loads project, but hitting play wont start.

booted from 6.5 it just works as perfectly as it has since i started using it.

ive never expirienced any crashes........

ill try the debug tomorow, its just past 1am in freezing uk, here so bedtime.

regards peter

[wintpe]

well thats a wierd one, rebooted back to kernel 6.6.2 today,
and it just worked.
no idea why that happened.
but thanks again for all your support.

just as feedback about muse4, as I know it does not appear (if google is anything to go by) to get the kudos its should with all the other choices out there
I love it......
my equipment is:
A beringer X2222, but I dont use its USB interface as its just rubbish, instead I use my XLR inputs on my
M-Audio 1010LT for the mixer.
I use a Roland UM-2 for both of my Roland JV-2080 synths, and I use the USB in on my XV2020.
Into my X2222 are 3 mikes, A guitar amp via a Beringer DI Box, and the outputs of my 3 Romplers above.
The XV2020 is also driven by a UMX610.
Muse4 menus, and ways of doing things just make sense, (unlike Ardour, which just baffles me).

Ive mentioned this before, but ill bring it up again, the only thing that does not make sense is the numbering given to the
bank selections. While I accept the adding of a 1 to program, adding a 1 to the MSB does not make sense.
all the roland docs say that for example it should be 84:5 say for the SR-JV80 001-128, EXP-C, yet you add one and make it show as 85.
so this is the only niggly thing about the app, that I would like to see addressed.
even if its an optional thing like a tick box for roland bank addressing.
regards peter

[Impostor]

su -

That explains why "everybody" uses sudo: in Ubuntu and derivatives the root account is disabled by default. You can enable it but why go through the trouble if you can just use sudo if you temporarily need root privilege?

[Tim E. Real]

OK Good to hear. Hope everything works out. Let us know if any trouble.

The patch numbering scheme is my, er, fault.
I did it because real-world midi equipment tends to number everything starting at 1.
For example I have a midi foot patch selector pedal. The LED bank and program numerical readouts all start at 1.
So I was trying to make MusE match what would likely be shown on such hardware.

Yes I've had a few comments about that.
It's a tough call since other software (or even hardware?) might actually start numbering at 0.
Sigh. What to do...

[sunrat]

su -

That explains why "everybody" uses sudo: in Ubuntu and derivatives the root account is disabled by default. You can enable it but why go through the trouble if you can just use sudo if you temporarily need root privilege?

One may go to the trouble of initiating a root terminal if one has several commands to run with elevated privileges, then it saves typing by not having to put sudo in front of every damn command.
I use both depending on how many root commands I wish to run, and also what mood I'm in. Does that make me one of "everybody"?

[Loki Harfagr]

Since the OT is open that'll be the perfect time to suggest to people dearing/needing to use sudo to use /OpenDoas/ instead of /sudo/
(for many reasons|pulsions that are on offtopicerest magnitude there)

[erlkönig]

in Ubuntu and derivatives the root account is disabled by default.

...sorry for nitpicking, but the root account is always there, it's not like other OSes where there is a "system" account, that's unreachable under a running os. You just don't know the password for root. This means you wipe it in /etc/shadow to become root without password, or you simply do a

Code: Select all

user> sudo -s

for being root. But iirc, you still have the paths from your user with sudo. So, for executing one command with su, you do a

Code: Select all

su -c 'best_command_of_all_times'

, which has (depending on the environment you are currently working in) the effect, that you don't keep an open root access for a few minutes in the terminal.
Stroopwafels for all!