Fedora - Anyone use it for music?

[Death]

The only things I think is missing is, as a root user:
$ usermod -a -G audio <username>
Logout and login to apply group change.

I have already added myself to the audio group!

The thing I need help with is the realtime audio privileges which I detailed a couple of posts back in this thread.

Cheers.

[NarendraU]

The only things I think is missing is, as a root user:
$ usermod -a -G audio <username>
Logout and login to apply group change.

I have already added myself to the audio group!

The thing I need help with is the realtime audio privileges which I detailed a couple of posts back in this thread.

Cheers.

Just add

Code: Select all

@audio - rtprio 95
@audio - memlock unlimited

into

Code: Select all

/etc/security/limits.conf

as stated here: https://jackaudio.org/faq/linux_rt_config.html

Edit: Correction about the filename

[MattKingUSA]

Thanks for the post. I use Fedora on my main system but I've never used it for audio. I mean, I've used Fedora based distros for audio but never fedora. Helpful post, thanks!

[Death]

Just add

Code: Select all

@audio - rtprio 95
@audio - memlock unlimited

into

Code: Select all

/etc/security/limits.conf

as stated here: https://jackaudio.org/faq/linux_rt_config.html

Edit: Correction about the filename

Thankyou for the info

I read the Jack article you linked and it says:

"1. Editing the configuration file

If your system has no directory called /etc/security/limits.d then you will need to edit /etc/security/limits.conf. If /etc/security/limits.d does exist on your machine, then you will need to create and edit a file called /etc/security/limits.d/audio.conf. The file must contain (at least) the following two lines:

@audio - rtprio 95
@audio - memlock unlimited
"

/etc/security/limits.d does already exist and I definitely didn't create it myself.

Also, my already existing 'limits.conf' file says:

"#Also note that configuration files in /etc/security/limits.d directory,
#which are read in alphabetical order, override the settings in this
#file in case the domain is the same or more specific.
#That means, for example, that setting a limit for wildcard domain here
#can be overridden with a wildcard setting in a config file in the
#subdirectory, but a user specific setting here can be overridden only
#with a user specific setting in the subdirectory."

So, I have done as the article says and created the 'audio.conf' file in /etc/security/limits.d/

I installed QjackCtl temporarily just to check and it appears to have worked so hopefully that was the right way to do it on my system..

But now I am wondering about something.. I previously mentioned something in the repos called 'realtime-setup'. The description for this is:

Code: Select all

Configure details useful for low-latency environments.

Installation of this package results in:
  - creation of a realtime group
  - adds realtime limits configuration for PAM
  - adds udev specific rules for threaded irqs and /dev/rtc access
  - adds /usr/bin/slub_cpu_partial_off to turn off cpu_partials in SLUB
  - adds net-socket timestamp static key daemon (realtime-entsk)

The slub_cpu_partial_off script is used to turn off the SLUB slab allocator's
use of cpu-partials, which has been known to create latency-spikes.

The realtime-entsk program is a workaround for latency spikes caused when the
network stack enables hardware timestamping and activates a static key. The
realtime-entsk progam is activated by the systemd service included and merely
enables the timestamp static key and pauses, effectively activating the static
key and never exiting, so no deactivation/activation sequences will be seen.

Neither the slub script or realtime-entsk are active by default.

Links: 
  https://gitlab.com/rt-linux-tools/realtime-setup.git 
  https://apps.fedoraproject.org/packages/realtime-setup 

I don't fully understand what it does but I'm wondering if that might be a better way of setting things up for audio, or is that overkill?

Cheers.

[Death]

https://en.wikipedia.org/wiki/Fedora_Linux#cite_ref-27

Security
Fedora Linux uses Security-Enhanced Linux by default, which implements a variety of security policies, including mandatory access controls, which Fedora adopted early on.[27] Fedora provides a hardening wrapper,

I guess this means, there is more latency involved - everything takes time.
if time is endless, everything is possible:

use fedora on your internet machine, on a system that should be configured towards latency and realtime and not towards internet:
keep that machine away from any network.
keep it freezed.
be cool

I'm not really sure what post you're replying too but I'm just trying to make sure I setup RT properly..

I don't have multiple computers so one has to do it all..

[Death]

first, there is no realtime - we have something called as good as realtime which, as the name suggests is as good as realtime.
Secondly, when you can't get realtime but you still want it, you surely don't want to involve further latencies.
I really hope that you can understand what I tried to explain, now.
good luck with Fedora realtime.
peace.

Yeh I get that but I was just trying to make sure I was setting things up in the best way. Creating a configuration file manually is one way but there was also that package I mentioned in previous posts 'realtime-setup'; I thought that might be the better way to do it, but maybe no one here can answer that question..

Cheers.

[GuntherT]

Pretty much all that is needed to setup realtime audio on a modern Linux distribution is the following:

Create and edit a file called /etc/security/limits.d/audio.conf. The file must contain (at least) the following two lines:
@audio - rtprio 95
@audio - memlock unlimited

Add your user to the audio group.
$ sudo usermod -a -G audio <username>

Edit /etc/default/grub and look for this line:
GRUB_CMDLINE_LINUX=" "

Add 'threadirqs' between the quotation marks so it looks like this:
GRUB_CMDLINE_LINUX="threadirqs"

Update your GRUB configuration.
$ sudo update-grub

Install the rtirq-init package using the distro's package manager.
$ sudo apt install rtirq-init
(This is the Debian/Ubuntu command; I'm not familiar with Fedora's package manager)

Edit /etc/default/rtirq and look for this line:
RTIRQ_NAME_LIST="snd usb i8042"

Here, 'snd' is for internal sound cards, 'usb' is for USB audio interfaces, and 'i8042' is for Firewire interfaces. I use a USB audio interface while recording, and I do not own a Firewire device, so my name list looks like this, which prioritizes the USB interface:
RTIRQ_NAME_LIST="usb snd"

Reboot.

---

Doing nothing but these steps on a Ubuntu 22.04 derivative, I can record two tracks at a time on a 2X2 USB audio interface in Ardour while simultaneously playing back all recorded tracks with a 64 buffer setting at 48kHz and not get a single xrun while recording until tracks 23 and 24, at which point the DSP is hitting 100%. I did this a few days ago on a laptop equipped with a Celeron processor, 4GB of soldered RAM, and a 64GB eMMC drive, i.e. the crappiest hardware currently on the market.

I think all the realtime group setup stuff you came across is perhaps outdated or for realtime applications that extend beyond audio software use. During the experiment above, I was using the stock, non-preemptive kernel, the ondemand CPU governor, and I was actively connected to a WiFi network during recording. Could I have reached a higher number of tracks with no xruns using a lowlatency or rt kernel, reduced swappiness, disabled networking, mitigations off, noatime filesystem mount, etc... Maybe, but in my personal experience, I haven't seen significant returns after the basic steps outlined above are completed. Unless you have a specific problem and know why you are making further changes, I wouldn't bother going down the Linux audio configuration rabbit hole. You may find yourself chasing ghosts.

Prior to wiping Windows 11 off this cheapo laptop, I tried the same recording experiment with Ardour on Windows. I made it up to 24 tracks with a 64 buffer setting at 48kHz and did not have a single xrun while recording, but the DSP was hitting 100%, so I knew I was at the limit of this machine. What setup configuration steps did I take on Windows? I installed the device's ASIO driver from the manufacturer's website. That was it. Seriously.

I think the era of endless tweaking trying to squeeze every bit of audio performance from a computer is behind us. Even a $119.99 Black Friday laptop special is capable of performance I couldn't get from a mid-grade laptop 10 years ago that was using a realtime kernel, noatime filesystem mount, reduced swappiness, disabled networking, performance governor...all the decade-and-a-half-old recommendations. There is little need to fuss with things these days, in my opinion.

[Death]

@GuntherT Thankyou for that detailed and easy to follow description I've noted that down and will likely end up running through all of those steps one day this week.

However, I became curious about what that 'realtime-setup' package would do and so I gave it a go because if that's all I have to do then my life is simpler.

Again, here's its description

Code: Select all

Configure details useful for low-latency environments.

Installation of this package results in:
  - creation of a realtime group
  - adds realtime limits configuration for PAM
  - adds udev specific rules for threaded irqs and /dev/rtc access
  - adds /usr/bin/slub_cpu_partial_off to turn off cpu_partials in SLUB
  - adds net-socket timestamp static key daemon (realtime-entsk)

The slub_cpu_partial_off script is used to turn off the SLUB slab allocator's
use of cpu-partials, which has been known to create latency-spikes.

The realtime-entsk program is a workaround for latency spikes caused when the
network stack enables hardware timestamping and activates a static key. The
realtime-entsk progam is activated by the systemd service included and merely
enables the timestamp static key and pauses, effectively activating the static
key and never exiting, so no deactivation/activation sequences will be seen.

Neither the slub script or realtime-entsk are active by default.

Links: 
  https://gitlab.com/rt-linux-tools/realtime-setup.git 

I installed it and rebooted. It had created a file called 'realtime.conf' in /etc/security/limits.d/ which contained the following

Code: Select all

# This file specifies reasonable default limits for users
# who should be able to run realtime processes.
#
# Such users must be added to group 'realtime' to be
# affected by these limits.

@realtime       soft    cpu             unlimited
@realtime       -       rtprio          99
@realtime       -       nice            -20
@realtime       -       memlock         unlimited

• I've no idea what 'soft cpu unlimited' does or whether it's beneficial for me..?
• It has 'rtprio 99' instead of 'rtprio 95'; Is that bad?
• According to that Jack article (https://jackaudio.org/faq/linux_rt_config.html), adjusting 'nice' is not necessary so I'm thinking I don't want that line?

As for GRUB, I have

Code: Select all

GRUB_CMDLINE_LINUX="rhgb quiet"

and it does not have 'threadirqs' as you suggested to put there. What do you make of that?

I could not find 'rtirq-init' in the repos but I did find 'rtirq' which has this description

Code: Select all

Start-up scripts for tuning the realtime scheduling policy and priority
of relevant IRQ service threads, featured for a realtime-preempt enabled
kernel configuration.

Links: 
  http://www.rncbc.org/jack/ 
  https://apps.fedoraproject.org/packages/rtirq 

Is that the same thing? I have not installed it yet..

After installing and rebooting, I ran the 'realtime-tests' package based on its instructions

Code: Select all

### Run tests

To run one test thread per CPU or per CPU core, each thread on a separate
processor, type

sudo ./cyclictest -a -t -n -p99

On a non-realtime system, you may see something like

T: 0 ( 3431) P:99 I:1000 C: 100000 Min:      5 Act:   10 Avg:   14 Max:   39242
T: 1 ( 3432) P:98 I:1500 C:  66934 Min:      4 Act:   10 Avg:   17 Max:   39661

The rightmost column contains the most important result, i.e. the worst-case
latency of 39.242 milliseconds. On a realtime-enabled system, the result may
look like

T: 0 ( 3407) P:99 I:1000 C: 100000 Min:      7 Act:   10 Avg:   10 Max:      18
T: 1 ( 3408) P:98 I:1500 C:  67043 Min:      7 Act:    8 Avg:   10 Max:      22

and, thus, indicate an apparent short-term worst-case latency of 18
microseconds.

and here's a snapshot of the terminal during those tests

Code: Select all

T: 0 ( 4446) P:99 I:1000 C: 110133 Min:   1500 Act:    1804 Avg:    2167 Max: 1183157
T: 1 ( 4447) P:99 I:1500 C:  73423 Min:   1528 Act:    1839 Avg:    2133 Max:  654327
T: 2 ( 4448) P:99 I:2000 C:  55067 Min:   1572 Act:    1804 Avg:    2289 Max:  386091
T: 3 ( 4449) P:99 I:2500 C:  44053 Min:   1575 Act:    1838 Avg:    2142 Max:  337103
T: 4 ( 4450) P:99 I:3000 C:  36711 Min:   1597 Act:    1803 Avg:    2188 Max:  396818
T: 5 ( 4451) P:99 I:3500 C:  31467 Min:   1584 Act:    1809 Avg:    2068 Max:  361927
T: 6 ( 4452) P:99 I:4000 C:  27533 Min:   1619 Act:    1932 Avg:    2072 Max:  280272
T: 7 ( 4453) P:99 I:4500 C:  24474 Min:   1573 Act:    1803 Avg:    2192 Max:  301621
T: 8 ( 4454) P:99 I:5000 C:  22026 Min:   1549 Act:    1662 Avg:    2251 Max:  360713
T: 9 ( 4455) P:99 I:5500 C:  20024 Min:   1523 Act:    1802 Avg:    2162 Max:  370693
T:10 ( 4456) P:99 I:6000 C:  18355 Min:   1590 Act:    2441 Avg:    2312 Max:  800493
T:11 ( 4457) P:99 I:6500 C:  16943 Min:   1570 Act:    2026 Avg:    2297 Max:  393055
T:12 ( 4458) P:99 I:7000 C:  15733 Min:   1606 Act:    2062 Avg:    2267 Max:  329066
T:13 ( 4459) P:99 I:7500 C:  14684 Min:   1570 Act:    1852 Avg:    2164 Max:  380290
T:14 ( 4460) P:99 I:8000 C:  13766 Min:   1632 Act:    1850 Avg:    2101 Max:  227208
T:15 ( 4461) P:99 I:8500 C:  12956 Min:   1619 Act:    1839 Avg:    2142 Max: 1129491

It looks like my latency might be a little high..?

Sorry, I know that's a lot of stuff I'm asking about but I'm taking notes on everything so this is all easier for me to understand and configure next time around I hope you can help.

Cheers.

[GuntherT]

@GuntherT Thankyou for that detailed and easy to follow description I've noted that down and will likely end up running through all of those steps one day this week.

However, I became curious about what that 'realtime-setup' package would do and so I gave it a go because if that's all I have to do then my life is simpler.

Again, here's its description

Code: Select all

Configure details useful for low-latency environments.

Installation of this package results in:
  - creation of a realtime group
  - adds realtime limits configuration for PAM
  - adds udev specific rules for threaded irqs and /dev/rtc access
  - adds /usr/bin/slub_cpu_partial_off to turn off cpu_partials in SLUB
  - adds net-socket timestamp static key daemon (realtime-entsk)

The slub_cpu_partial_off script is used to turn off the SLUB slab allocator's
use of cpu-partials, which has been known to create latency-spikes.

The realtime-entsk program is a workaround for latency spikes caused when the
network stack enables hardware timestamping and activates a static key. The
realtime-entsk progam is activated by the systemd service included and merely
enables the timestamp static key and pauses, effectively activating the static
key and never exiting, so no deactivation/activation sequences will be seen.

Neither the slub script or realtime-entsk are active by default.

Links: 
  https://gitlab.com/rt-linux-tools/realtime-setup.git 

I installed it and rebooted. It had created a file called 'realtime.conf' in /etc/security/limits.d/ which contained the following

Code: Select all

# This file specifies reasonable default limits for users
# who should be able to run realtime processes.
#
# Such users must be added to group 'realtime' to be
# affected by these limits.

@realtime       soft    cpu             unlimited
@realtime       -       rtprio          99
@realtime       -       nice            -20
@realtime       -       memlock         unlimited

• I've no idea what 'soft cpu unlimited' does or whether it's beneficial for me..?
• It has 'rtprio 99' instead of 'rtprio 95'; Is that bad?
• According to that Jack article (https://jackaudio.org/faq/linux_rt_config.html), adjusting 'nice' is not necessary so I'm thinking I don't want that line?

I cannot recall having seen 'soft cpu unlimited' before, so like you, I do not know what it does or if it is beneficial. My assumption would be it correlates to the SLUB script mentioned in the package description, but I have never heard of that either. Per the package description the script is not activated by default, so it is likely a moot point and can be commented out or left as-is.

July 12th, 2019 is the commit date when falkTX revised the JACK FAQ website, changing the 'rtprio 99' value to 'rtprio 95' and '@realtime' to '@audio'. At that time, the 'nice -19' line ('nice -20' in this setup) wasn't present in the FAQ, just a note stating that 'niceness' was irrelevant. I have seen some configs where the 'nice -19' line was still in the file but commented out by default. Here, it is not commented out, so this setup appears to me to be working off some fairly old assumptions.

I have never used a Fedora system for realtime audio, just Debian/Ubuntu and Arch, so it is possible there are some differences between the distros for which this setup is accounting, but I tend to doubt it. If you decide to use this setup, keep in mind you will need to add your user to the 'realtime' group instead of the 'audio' group. My personal recommendation would be to nix this and follow the recommendations outlined on the JACK FAQ, but you should do what feels best.

As for GRUB, I have

Code: Select all

GRUB_CMDLINE_LINUX="rhgb quiet"

and it does not have 'threadirqs' as you suggested to put there. What do you make of that?

It does not surprise me that the 'realtime-setup' package you installed did not edit and update your grub file. Doing so is not mentioned in the package description and would also require root privileges. You will need to add 'threadirqs' to that config line manually and then 'update-grub'.

I could not find 'rtirq-init' in the repos but I did find 'rtirq' which has this description

Code: Select all

Start-up scripts for tuning the realtime scheduling policy and priority
of relevant IRQ service threads, featured for a realtime-preempt enabled
kernel configuration.

Links: 
  http://www.rncbc.org/jack/ 
  https://apps.fedoraproject.org/packages/rtirq 

Is that the same thing? I have not installed it yet..

Yes, that's the same script. It looks like your distro names it differently than Debian/Ubuntu does.

After installing and rebooting, I ran the 'realtime-tests' package based on its instructions

Code: Select all

### Run tests

To run one test thread per CPU or per CPU core, each thread on a separate
processor, type

sudo ./cyclictest -a -t -n -p99

On a non-realtime system, you may see something like

T: 0 ( 3431) P:99 I:1000 C: 100000 Min:      5 Act:   10 Avg:   14 Max:   39242
T: 1 ( 3432) P:98 I:1500 C:  66934 Min:      4 Act:   10 Avg:   17 Max:   39661

The rightmost column contains the most important result, i.e. the worst-case
latency of 39.242 milliseconds. On a realtime-enabled system, the result may
look like

T: 0 ( 3407) P:99 I:1000 C: 100000 Min:      7 Act:   10 Avg:   10 Max:      18
T: 1 ( 3408) P:98 I:1500 C:  67043 Min:      7 Act:    8 Avg:   10 Max:      22

and, thus, indicate an apparent short-term worst-case latency of 18
microseconds.

and here's a snapshot of the terminal during those tests

Code: Select all

T: 0 ( 4446) P:99 I:1000 C: 110133 Min:   1500 Act:    1804 Avg:    2167 Max: 1183157
T: 1 ( 4447) P:99 I:1500 C:  73423 Min:   1528 Act:    1839 Avg:    2133 Max:  654327
T: 2 ( 4448) P:99 I:2000 C:  55067 Min:   1572 Act:    1804 Avg:    2289 Max:  386091
T: 3 ( 4449) P:99 I:2500 C:  44053 Min:   1575 Act:    1838 Avg:    2142 Max:  337103
T: 4 ( 4450) P:99 I:3000 C:  36711 Min:   1597 Act:    1803 Avg:    2188 Max:  396818
T: 5 ( 4451) P:99 I:3500 C:  31467 Min:   1584 Act:    1809 Avg:    2068 Max:  361927
T: 6 ( 4452) P:99 I:4000 C:  27533 Min:   1619 Act:    1932 Avg:    2072 Max:  280272
T: 7 ( 4453) P:99 I:4500 C:  24474 Min:   1573 Act:    1803 Avg:    2192 Max:  301621
T: 8 ( 4454) P:99 I:5000 C:  22026 Min:   1549 Act:    1662 Avg:    2251 Max:  360713
T: 9 ( 4455) P:99 I:5500 C:  20024 Min:   1523 Act:    1802 Avg:    2162 Max:  370693
T:10 ( 4456) P:99 I:6000 C:  18355 Min:   1590 Act:    2441 Avg:    2312 Max:  800493
T:11 ( 4457) P:99 I:6500 C:  16943 Min:   1570 Act:    2026 Avg:    2297 Max:  393055
T:12 ( 4458) P:99 I:7000 C:  15733 Min:   1606 Act:    2062 Avg:    2267 Max:  329066
T:13 ( 4459) P:99 I:7500 C:  14684 Min:   1570 Act:    1852 Avg:    2164 Max:  380290
T:14 ( 4460) P:99 I:8000 C:  13766 Min:   1632 Act:    1850 Avg:    2101 Max:  227208
T:15 ( 4461) P:99 I:8500 C:  12956 Min:   1619 Act:    1839 Avg:    2142 Max: 1129491

It looks like my latency might be a little high..?

I have not completed similar tests on my laptop, so I cannot comment on how these values compare to mine. I am a solo hobbyist who overdubs one or two tracks at a time while playing back previous tracks. The way I test if latency is acceptable or not is by recording audio and looking for the lowest buffer size the hardware can manage before xruns are generated. Using a 64 buffer size, latency is imperceptible to me, so that is where I start. I will increase it to 128 if xruns show up in the recordings. A 256 buffer setting throws me off a bit while recording with headphones, but if I can record at 64 or 128 with no xruns causing audible glitches, that is when the configuration stops and the music making begins. I am not concerned with my system's measured values, only the practical outcome, so I have never checked this.

Doing my best to interpret the data you supplied, it does appear high. I do not think your system is setup for realtime audio yet. This could be due to you not having added the 'threadirqs' option to grub yet, not having your user in the 'realtime' group, or both. Try completing those steps and running the test again. Let us know if it improves. Another thing to consider is this particular test may be designed to test a realtime kernel, not realtime audio. Realtime audio does not require a realtime kernel, but if this test does, the results could look bad while the audio performance of your system be quite good.

Sorry, I know that's a lot of stuff I'm asking about but I'm taking notes on everything so this is all easier for me to understand and configure next time around I hope you can help.

Cheers.

I'm happy to help when I can, and I hope this is useful.

[Impostor]

It has 'rtprio 99' instead of 'rtprio 95'; Is that bad?

99 is the highest possible prio. Maybe that should be reserved for critical system processes only.

[Death]

I uninstalled that package in the end and reverted the changes.

I did make new notes based on the advice here so I'll have to find a day to play around with that some time.

Thanks again. I really appreciate the help!

[TheYke]

I'm on Fedora since several months now, and I love it. Wasn't making more actual music with any other distro in my 3 year long linux journey.

Although pipewire seemed to work fine at first I discovered that the latency when doing a recording-loop-back-test wasn't staying the same, so I switched back to legacy jack as I need mostly sample accurate recording.

Other than that: it is awesome.