Real Time Kernel? (also libxml2 update)

Hi @Antoine -

Would there be any benefit to using the real time kernel with the OS on which the Audirvana Core Player is running, if I am playing via UPnP and the OS for the UPnP endpoint is already using the real time kernel?

Hi @Jud,

Is this an option you can enable on your OS?

Hi @Antoine, thank you so much for responding.

It is, and I have. I have not done any detailed listening comparisons, simply because I like the sound very much with the realtime kernel and see no particular reason to switch back to the “vanilla” or Zen kernels I was using before. So at least I have felt subconsciously the sound is just as good with the realtime kernel, perhaps a touch better.

1 Like

Hi @Jud,
I can’t achieve to install AS on real-time kernel (Arch Linux). I mean I installed it the same way I did on regular kernel but I cannot enable the service with either “./setAsService.sh start” command or “systemctl --user start audirvanaStudio”
This is what I got in both cases:

[jlb@audio studio]$ sudo ./setAsService.sh status
● audirvanaStudio.service - Run audirvanaStudio
Loaded: loaded (/etc/systemd/system/audirvanaStudio.service; enabled; preset: disabled)
Active: active (running) since Thu 2025-05-01 13:47:14 -04; 17ms ago
Invocation: 53ce3a37e0784d6184ccf119e9111079
Main PID: 1060 (audirvanaStudio)
Tasks: 1 (limit: 9348)
Memory: 592K (peak: 1.7M)
CPU: 6ms
CGroup: /system.slice/audirvanaStudio.service

may 01 13:47:14 audio systemd[1]: audirvanaStudio.service: Scheduled restart job, restart counter is at 9.
may 01 13:47:14 audio systemd[1]: Started Run audirvanaStudio.
may 01 13:47:14 audio audirvanaStudio[1060]: /opt/audirvana/studio/audirvanaStudio: error while loading shared libraries: libxml2.so.2: cannot open shared object file: No such file or directory
may 01 13:47:14 audio systemd[1]: audirvanaStudio.service: Main process exited, code=exited, status=127/n/a
may 01 13:47:14 audio systemd[1]: audirvanaStudio.service: Failed with result ‘exit-code’.

[jlb@audio studio]$ systemctl --user status audirvanaStudio
× audirvanaStudio.service - Run audirvanaStudio
Loaded: loaded (/usr/lib/systemd/user/audirvanaStudio.service; enabled; preset: enabled)
Active: failed (Result: exit-code) since Thu 2025-05-01 13:45:27 -04; 14min ago
Duration: 16ms
Invocation: 25069cf029524f4a8de824ecb6c4dd7d
Process: 917 ExecStart=/opt/audirvana/studio/audirvanaStudio (code=exited, status=127)
Main PID: 917 (code=exited, status=127)

may 01 13:45:26 audio systemd[586]: audirvanaStudio.service: Main process exited, code=exited, status=127/n/a
may 01 13:45:26 audio systemd[586]: audirvanaStudio.service: Failed with result ‘exit-code’.
may 01 13:45:27 audio systemd[586]: audirvanaStudio.service: Start request repeated too quickly.
may 01 13:45:27 audio systemd[586]: audirvanaStudio.service: Failed with result ‘exit-code’.
may 01 13:45:27 audio systemd[586]: Failed to start Run audirvanaStudio.

I reinstalled “libxml2” but no change.
I would appreciate any comment.
Thanks in advance…

Yes, I get the same result from this new (since yesterday) real time kernel on Arch, as well as the new regular and Zen Arch kernels, and the realtime long term support kernel. See
Linux 6.14.4 Zen & Vanilla Kernels Seem To've Broken Audirvana Core

I’ve asked the Audirvāna Studio package maintainer over at the Arch User Repository whether there might be a solution short of waiting for a kernel change. We’ll see if there’s an answer.

Hi @Jud, I have some experience with real-time kernels in medical devices and automotive. One of the most significant — if not THE most significant — aspects of a real-time kernel is interrupt handling. An RT kernel guarantees interrupt response within a fixed timeframe, critical in a system with external triggers.

I would not expect an RT kernel to make a difference in audio playback, especially given that we run Audirvana on extremely capable CPUs, as opposed to something like a low-power embedded microcontroller.

1 Like

Hi Press -

If you check the Linux docs on the kernels, they explicitly mention audio applications as potentially benefiting from the realtime kernel. Jussi Laako, developer of HQPlayer who worked for Intel, distributes a kernel with realtime aspects for use with his application.

I don’t know whether this means there is actually any benefit to Audirvāna from using a realtime kernel, but then what could it hurt?

IMO I am not particularly sure if the there is a noticeable listening difference between realtime kernel and low latency grub tweak suggested by @hlooman.

1 Like

That’s interesting, @Jud. I can certainly see advantages of an RT kernel in an audio endpoint, fwiw.

In any case, I was not implying any downside to an RT kernel. By all means, give a try and report back!

1 Like

I did. Completely subjectively and without doing any careful comparison, I liked it enough that I intend to keep using it when possible (as part of my favored OS for running Audirvana Core, a minimal Arch Linux install with no GUI).

Edit: And I’m also running a minimal Arch Linux install with no GUI on a RT kernel on my endpoint.

Caveat: I’m no Linux expert.

From my University of Google reading, status 127 can indicate a problem with permissions, so not surprising you got the same error when reinstalling libxml2. I did try explicitly creating the audirvana user and group and giving it ownership of various files and directories (though not libxml2), without success.

I got a response from the package maintainer, and your error message has identified the problem. Here’s what they say:

I think this could related to libxml2 update from version 2.13.8-1 to 2.14.2-2.1 Many packages are involved including ardour, sane, kmail etc. I hope this will be solved when all packages are updated to support the new libxml2

However here audirvanaStudio is starting without errors, maybe because libxml2 is still 2.13.8-1 (I cannot make a system update for dependency problems related to the above packages)

The two things I can think of in the meantime would be to restore the system to a previous point where Audirvana was working, or to attempt to downgrade everything involved in the libxml2 update. I would think the latter would be difficult if not impossible and might go quite wrong. I’ve done the former.

Edit: @Antoine, could this be addressed by an update to Audirvana Core, or would that cause problems on Debian/Ubuntu or Fedora?

I think it would be better for you to try to do the update on your end given what it adress:

1 Like

Yes, I saw that. I wonder, given the security implications, if the same change will be coming to other distributions soon (or whether nearly everything eventually has security implications and it will all happen in good time :slightly_smiling_face:).

Here is the solution (from the package maintainer and also the AudioLinux developer - AudioLinux is based on Arch):

Copy manually libxml2.so.2 (not the symbolic link but the corresponding library changing the name to libxml2.so.2) to /usr/lib from a previous version, for example 2.13.8.

BTW, if anyone needs the older version of libxml2.so.2, I have it. I would attach it but I don’t know if we’re allowed to attach binaries here. However I’m happy to email it.

Finally libxml2-legacy on the official Arch Linux repo fixes it.

1 Like