Alpine Linux struggling toward a

[beate]

Wel, late in November i intended to write something on using Alpine Linux as basis for an Audio oriented system.

Alpine (currently) means to me: small and not bloated. Ideal to make the best out of old Hardware.

My machines:

1) EEE-PC, Atom 270, 2 cores, 1.6 GHz, 2 GB RAM, USB 1.1
2) HP ProBook 5310m, Intel Celeron, 2 cores, 2.27 GHz 4 GB RAM, USB 2

Interfaces, in addition to the internal sound card.

A&H ZEDi10, USB 2, 4 channels
A&H ZED 10, USB 1.1, 2 channels
Alesis Multimix4 USB, USB 1.1 2 channels, recording only (playback through the USB interface does not work correctly), same USB chip as ZED10.

Software environment

Alpine Linux, 32 bit (both machines, although the HP is IA64)
Archives: edge: main, community, testing
mainly because the software offered outside testing is a bit limited for my ideas of a system with overall small use of resources (windowmaker, xterm, xfe, claws-mail)
ALSO/Jack only, neither pulseaudio nor pipewire, but apulse is there.
hydrogen, vlc, mpg123, vorbis tools, audacity, ardour (7)

What do i want to achieve?

a) live drum machine:

Hydrogen, through internal sound card, into the ZEDi10 (which drives our PA speakers)
general audio, mostly through internal sound card.

b) multitrack recorder:

Goal: i would use the 4 channels of the ZEDi plus the 2 channels of the Alesis, the latter synchronized with the ZEDi by resampling.
playback

Because of some trouble with hydrogen after setting up everything i had to go back and make/keep hydrogen running.

(The EEEPC is set op mostly of curiosity what can be achieved on such old hardware, and as a backup.)

[beate]

The hydrogen implementation always seems to try to obtain realtime priority, and that will cause problems with the non-realtime kernel (alpine does not provide a low latency kernel)

Error message
H2Core::alsaAudioDriver_processCaller(void*) Can't set realtime scheduling for ALSA Driver

Setting the driver to something else than hw:0 appears to lead to massive xruns - i had to modify hydrogen's config file manually.

Outuput of rtcqs (not in the distro, must be installed locally, this is on the celeron)

rtcqs
rtcqs - version 0.5.3

Root User

[ OK ] Not running as root.

Audio Group

[ OK ] User beate is in the audio group.

CPU Frequency Scaling

[ WARNING ] The scaling governor of one or more CPU's is not set to 'performance'. You can set the scaling governor to 'performance' with 'cpupower frequency-set -g performance' or 'cpufreq-set -r -g performance' (Debian/Ubuntu). See also https://wiki.linuxaudio.org/wiki/system ... cy_scaling

Kernel Configuration

[ OK ] Valid kernel configuration found.

High Resolution Timers

[ OK ] High resolution timers are enabled.

Tickless Kernel

[ OK ] System is using a tickless kernel.

Preempt RT

[ WARNING ] Kernel 6.6.16-0-lts without 'threadirqs' parameter or real-time capabilities found. See also https://wiki.linuxaudio.org/wiki/system ... ime_kernel

Spectre/Meltdown Mitigations

[ WARNING ] Kernel with Spectre/Meltdown mitigations found. This could have a negative impact on the performance of your system. See also https://wiki.linuxaudio.org/wiki/system ... itigations

Traceback (most recent call last):
File "/usr/bin/rtcqs", line 8, in <module>
sys.exit(rtcqs.main())
^^^^^^^^^^^^
File "/usr/lib/python3.11/site-packages/rtcqs/rtcqs.py", line 425, in main
rt_prio_check()
File "/usr/lib/python3.11/site-packages/rtcqs/rtcqs.py", line 237, in rt_prio_check
os.sched_setscheduler(0, sched, param)
OSError: [Errno 38] Function not implemented

[bluebell]

The hydrogen implementation always seems to try to obtain realtime priority, and that will cause problems with the non-realtime kernel (alpine does not provide a low latency kernel)

Error message
H2Core::alsaAudioDriver_processCaller(void*) Can't set realtime scheduling for ALSA Driver

Do you have a file /etc/security/limits.d/audio.conf (or similar named) with the following contents

Code: Select all

@audio   -  rtprio     95
@audio   -  memlock    unlimited

and is your user in group audio?

[autostatic]

Code: Select all

Traceback (most recent call last):
File "/usr/bin/rtcqs", line 8, in <module>
sys.exit(rtcqs.main())
^^^^^^^^^^^^
File "/usr/lib/python3.11/site-packages/rtcqs/rtcqs.py", line 425, in main
rt_prio_check()
File "/usr/lib/python3.11/site-packages/rtcqs/rtcqs.py", line 237, in rt_prio_check
os.sched_setscheduler(0, sched, param)
OSError: [Errno 38] Function not implemented

Yikes! This probably means your system does not understand the os.sched_setscheduler call. Never seen that before. Does Alpine have chrt on board? Or a package that contains it? I'm curious what chrt has to say about this...

[beate]

The hydrogen implementation always seems to try to obtain realtime priority, and that will cause problems with the non-realtime kernel (alpine does not provide a low latency kernel)

Error message
H2Core::alsaAudioDriver_processCaller(void*) Can't set realtime scheduling for ALSA Driver

Do you have a file /etc/security/limits.d/audio.conf (or similar named) with the following contents

Code: Select all

@audio   -  rtprio     95
@audio   -  memlock    unlimited

and is your user in group audio?

Yes
(i reduced the rtprio to 80 which has no effect)

[autostatic]

Could you post the output of ulimit -a?

[beate]

Code: Select all

Traceback (most recent call last):
File "/usr/bin/rtcqs", line 8, in <module>
sys.exit(rtcqs.main())
^^^^^^^^^^^^
File "/usr/lib/python3.11/site-packages/rtcqs/rtcqs.py", line 425, in main
rt_prio_check()
File "/usr/lib/python3.11/site-packages/rtcqs/rtcqs.py", line 237, in rt_prio_check
os.sched_setscheduler(0, sched, param)
OSError: [Errno 38] Function not implemented

Yikes! This probably means your system does not understand the os.sched_setscheduler call. Never seen that before. Does Alpine have chrt on board? Or a package that contains it? I'm curious what chrt has to say about this...

This:

bea:~$ ps cx |grep hydrogen
2788 beate 0:00 hydrogen -d alsa
2789 beate 0:11 /usr/bin/hydrogen -d alsa --child
2801 beate 0:00 grep hydrogen
bea:~$ chrt -p 2788
pid 2788's current scheduling policy: SCHED_OTHER
pid 2788's current scheduling priority: 0
bea:~$ chrt -p 2789
pid 2789's current scheduling policy: SCHED_OTHER
pid 2789's current scheduling priority: 0

But this seems not to be the cause of the xruns. In my Devuan box i observed them when there was no soundcard available (wonder why ) - that one has the internal card disabled.

[autostatic]

Thanks! But could you try setting a different policy with chrt -f -p 85 <pid>?

[bluebell]

Do you use the correct commands? On my system with a lowlatency kernel I get the same results. But I CAN see realtime priorities with the ps command. One thread of Qtractor runs with realtime prio:

hm@bubu:~$ ps -eLo rtprio,tid,pid,cmd | head -n 1
RTPRIO TID PID CMD
hm@bubu:~$ ps -eLo rtprio,tid,pid,cmd | grep qtractor
- 22974 22974 /bin/bash /usr/local/bin/qtractor.sh
- 22980 22980 qtractor
- 22981 22980 qtractor
- 22982 22980 qtractor
- 22983 22980 qtractor
0 22984 22980 qtractor
- 22985 22980 qtractor
- 22986 22980 qtractor
- 22987 22980 qtractor
- 22988 22980 qtractor
65 22989 22980 qtractor
- 22990 22980 qtractor
- 22991 22980 qtractor
- 22992 22980 qtractor

[beate]

As expected: operation not permitted (85>80).
Setting the priority to something less than the current limit works. As it should.

But anyway: hydrogen usually works fine without being able to increase its realtime priority. The problem with the xruns seems to be that audio device was not available for some reason.

Now that i have a working configuration it seems helpful to have a backup copy of the config file at hand.

[sunrat]

These kernel options may help if your kernel supports them:

Code: Select all

threadirqs preempt=full mitigations=off

[beate]

I added the suggested kernel variables. I do not see the earlymost messages from the boot process, but the system appears to be stable.

Do you use the correct commands? On my system with a lowlatency kernel I get the same results. But I CAN see realtime priorities with the ps command.

As long as You use the standard ps command.
Alpine uses busybox and its somewhat limited version of ps, but the RTPRIO is visible in htop.

A little testing on the command line - my user belongs to group audio, and the rtprio limit is set to 80. PID 2766 has been hydrogen.

bea:~$ chrt -f -p 70 2766
chrt: failed to set pid 2766's policy: Operation not permitted

Same done as root is successful. Setting the rtprio as the root user to some value will work. Hydrogen will still remain to work fluently and without making XRUNs.

Apparently that will set an upper limit which i can lower as a normal user.
It also looks as if lowering the rtprio will immediately cause hydrogen to produce XRUNs and to fully load the CPU, and the system will react sluggishly (not surprising when real time prioritized processes eat all cpu time).

Again, for my purpose, real time and even low latencies on the output device are not important - i just want to play back drums through the default sound card. So everything is fine as long as this works without strange side effects.

[autostatic]

Maybe it's related to real-time group scheduling: https://webhook.site/f9fe18da-ba86-4ac0 ... 6a73eb0752

As a side note, prioritizing applications makes no difference, you want to prioritize threads, like IRQ threads or audio threads. The latter is being taken care of either by JACK or by the audio application itself.

[beate]

unfortunately not accessible anymore.

[beate]

Next topic: recording.

Two situations:

a) one USB device, ideally the ZEDi10 with its 4 channel interface
(which is buried in the rehearsal room, i can test with or maybe two 2-Channel USB devices)

b) two USB devices. I learnt that one plays the role of a master to which the 2nd has to be synchronised via resampling.

The USB interface of the EEEPC is too old. It cannot handle the ZEDi10. The HP machine is sufficiently modern.

a) can be handled in two ways:
aa) ALSA alone
ab) ALSA+jack.

Is there any advantage in using jack?

b) is there any possibility to synchonize with ALSA means alone or do i NEED to run jack+zita or something similar?

Regarding jack:

i can start it from the command line, with something like
JACK_NO_AUDIO_RESERVATION=1 /usr/bin/jackd -r -dalsa -dhw:CODEC -r48000 -p256 -n2
this is for one of the 2 channel USB interfaces.

I did not find a way to start this with qjackctl. I am not sure, but possibly this is caused by the need of the environment variable JACK_NO_AUDIO_RESERVATION correctly set.
But i am completly unexperienced with using jack.

Anyway, I can start ardour7. It does successfully connect to the jack daemon. And it seems to be able to record those 2 tracks correctly. Furthermore, hydrogen sends its output nicely to the internal sound card. Fine.

What about playback? At least in connection with the Alesis mixer i would like to route playback not through its USB interface (which is unusable for playback into the mixer), but instead to the internal sound card (which has dmix configured).