NixOS and music: Experiences?

What other apps and distros do you use to round out your studio?

Moderators: MattKingUSA, khz

Jamesf
Established Member
Posts: 70
Joined: Tue May 28, 2019 12:23 pm
Location: Madrid
Has thanked: 51 times
Been thanked: 13 times

Re: NixOS and music: Experiences?

Post by Jamesf »

s3ej3s wrote: Tue Dec 07, 2021 6:01 pm
Jamesf wrote: Sun Dec 05, 2021 5:31 pm
s3ej3s wrote: Sun Dec 05, 2021 4:18 pm Bump

Has there been anymore progress made on any of this? How are we doing?
Progress on what, in particular? Do you have some expectation that somebody's working on a specific task for you?
Oh, no. Certainly not. I didn't mean to give that impression. I just wondered if anyone, anywhere was currently successful doing pro-audio under NixOS.
Ah, OK. I can't vouch for "pro," but I've definitely been doing the "audio" part. It's never really _not_ worked for me, hence my bemusement.
s3ej3s wrote: Tue Dec 07, 2021 6:01 pm Before switching to NixOS, I had many years of success and relatively smooth sailing on Debian. When I moved to NixOS, things got hard. I was able to make pretty good progress until about February of 2020, at which point everything stopped working for me altogether. I'm still running at a pinned version of nix as a result. As it is, I'm unable to get anything working at all on an up-to-date version of nixos and it seems like a moving target. The particular problems I have depend on how new the nix version I'm working with is.
Interesting.
I switched from Ubuntu. Once I got past the initial learning curve for NixOS, the audio side was relatively smooth. Musnix makes it a little simpler, though I've learned to skip the realtime part. Firstly, a realtime kernel isn't really necessary, and secondly it's not compatible with running VirtualBox, which I use for a Windows VM on which I run apps to configure some of my outboard gear.
s3ej3s wrote: Tue Dec 07, 2021 6:01 pm One problem I'm having is that I can't even determine how it's *expected* to work under NixOS. Normally, I've run jackd as a user, starting and stopping it either with a script or qjackctl. The NixOS way is that it's part of the system config. I'm guessing that the service is continually running and meant to be controlled by user tools. I can't tell which though -- I seem to have a combination of Jack1 and Jack2 utilities, although I've only install jack2Full. At the old pinned version, qjackctl had a lot of controls greyed out. The newer version doesn't but they clearly have no effect on the running jackd (which is really jackdmp, apparently aliased to jackd). I've tried killing the jackd service and running it as a normal user. But I'm not privileged to do so, despite having added myself to the jackuser group. The way jackd is installed, that group itself is not privileged to execute it -- it's strictly root.
That's just weird. I'm using qjackctl and jackd, and the worst ongoing problem I have is that I have to manually use `kill -9 <pid>` to get jackd to actually stop running. I've yet to encounter jackdmp.

I'm using the packages jack2, qjackctl and a2jmidid, and it's doing exactly what I expect.
s3ej3s wrote: Tue Dec 07, 2021 6:01 pm I should say that I'm on unstable and I suspect that the story is very different depending on what nix version you're using. How do you have things configured yourself?
That's the even odder part: I'm on unstable, too. I've even added a tower-style workstation, and the same configuration is working on both.

That said, this configuration is the product of a series of changes over time, and I've had to read various manuals pretty closely. I've added the Musnix channel so as not to have to maintain a local git copy, and I do enable it to get access to its contents, but I also specifically set musnix.kernel.optimize and musnix.kernel.realtime to false. FWIW, this is the current content of /etc/nixos/musnix.nix, which I include from configuration.nix (my config is split over a bunch of files):

Code: Select all

{ config, pkgs, ... }:

{
  imports = [
    # Musnix = optimisations specific to music production
    # See https://github.com/musnix/musnix
    #/home/james/sourcery/musnix   # Local copy
    <musnix>                      # Channel
    ];

  musnix = {
    enable = true;
    # Not using any of Musnix' inbuilt optimisations, because they depend on a
    # realtime kernel, which is
    # a) not required for sufficient responsiveness
    # b) incompatible with running VMs via Virtualbox.
    kernel = {
      optimize = false;
      realtime = false;
      # Confirm _actual_ latest available kernel at:
      # https://github.com/musnix/musnix/blob/master/modules/kernel.nix
      #packages = pkgs.linuxPackages_5_9_rt;
    };
  };

  # Kernel configuration
  # Do it the hard way, because Musnix assumes the RT kernel is wanted
  nixpkgs.overlays = [
      (self: super: {
        linuxDAW = pkgs.linuxPackagesFor (pkgs.linux_daw.override {
          structuredExtraConfig = with pkgs.lib.kernel; {
            PREEMPT = yes;
            HPET_TIMER = yes;
          };
          #ignoreConfigErrors = true;
        });
      })
    ];
  # As-yet unused, but potentially useful kernel configs:
  #          #IOSCHED_DEADLINE y
  #          MQ_IOSCHED_DEADLINE y
  #          CONFIG_1000_HZ y   # Seems to be obsolete; was explicitly ignored last I tried it.

  #boot.kernelPackages = pkgs.linuxPackages_5_10;

  # Enable user `james` to use realtime audio
  users.users.james.extraGroups = [ "audio" ];


  # Enable the RealtimeKit system service,
  # which hands out realtime scheduling priority to user processes on demand.
  security.rtkit.enable = true;

  # Use an appropriate CPU performance governor
  # Often used values: "ondemand", "powersave", "performance"
  powerManagement.cpuFreqGovernor = "performance";

  # System limits for Ardour, esp. realtime scheduling.
  # Seems obsolete as at 2020/03/28, but keeping this here for reference in case I was wrong.
  #systemd.extraConfig = "DefaultLimitNOFILE=4096\nDefaultLimitMEMLOCK=4G:16G\nDefaultLimitRTPRIO=40";
  systemd.extraConfig = "DefaultLimitNOFILE=4096\nDefaultLimitMEMLOCK=24G:16G\nDefaultLimitRTPRIO=40";

  # JACK configuration
  boot.kernelModules=["snd-seq" "snd-rawmidi" ];
  hardware.pulseaudio.package = pkgs.pulseaudio.override { jackaudioSupport = true; };
  hardware.pulseaudio.enable = true;  
}
There's a bit to digest in here, but hopefully it includes some helpful content.

As far as plugins go, I use a bunch of processing ones - especially the ACM suite - but the only actual sound-generating one I regularly use is Surge. Most of it comes from external hardware, and Renoise is mostly there to drive the drum machines. I'm 99% sure I've successfully tried Guitarix and Carla in the last couple of months

Given NixOS's wonderful and occasionally butt-saving ability to roll back to a previous generation, I can recommend using git to manage the contents of /etc/nixos (because I do that myself) and using branches to experiment with changes. If a change works, its branch gets merged into main; if it doesn't, I roll back if necessary, delete the branch and try something else.

As the 21.11 branch/channel is now live, it might be worth trying that for something that's both up-to-date and reasonably stable in terms of its rate of change.
I'm slow, but I get there eventually.
s3ej3s
Established Member
Posts: 15
Joined: Thu Jan 19, 2017 11:00 am
Has thanked: 9 times
Been thanked: 2 times
Contact:

Re: NixOS and music: Experiences?

Post by s3ej3s »

Jamesf wrote: Tue Dec 07, 2021 6:41 pm
Ah, OK. I can't vouch for "pro," but I've definitely been doing the "audio" part. It's never really _not_ worked for me, hence my bemusement.
Um, yeah. It's admittedly awkward, but "pro-audio" seems to be how people are distinguishing between typical desktop audio functions and audio production / music making. You're firmly in the camp that I meant. :wink:
Interesting.
I switched from Ubuntu. Once I got past the initial learning curve for NixOS, the audio side was relatively smooth. Musnix makes it a little simpler, though I've learned to skip the realtime part. Firstly, a realtime kernel isn't really necessary, and secondly it's not compatible with running VirtualBox, which I use for a Windows VM on which I run apps to configure some of my outboard gear.
All my machines have been NixOS for a while and, frankly, audio has been the only thing that's given me *much* trouble.
That's just weird. I'm using qjackctl and jackd, and the worst ongoing problem I have is that I have to manually use `kill -9 <pid>` to get jackd to actually stop running. I've yet to encounter jackdmp.
Interesting, so you *do* kill it. Is that a normal part of your workflow or something exceptional that you do. And how do you restart it? With the usual systemd stuff? I think jackd and jackdmp are actually aliases. If you reference external jack docs and talk, jackd seems to be a jack1 thing and jackdmp the newer jack2 equivalent, I think.
There's a bit to digest in here, but hopefully it includes some helpful content.
Oh, I'm very grateful. Once I get things basically squared away, this will be very helpful to me for optimizing things. I've really not bothered with musnix yet.
As far as plugins go, I use a bunch of processing ones - especially the ACM suite - but the only actual sound-generating one I regularly use is Surge. Most of it comes from external hardware, and Renoise is mostly there to drive the drum machines. I'm 99% sure I've successfully tried Guitarix and Carla in the last couple of months

Given NixOS's wonderful and occasionally butt-saving ability to roll back to a previous generation, I can recommend using git to manage the contents of /etc/nixos (because I do that myself) and using branches to experiment with changes. If a change works, its branch gets merged into main; if it doesn't, I roll back if necessary, delete the branch and try something else.
Yes, absolutely. I could never go back to a conventional distro. I currently have branches for each of the three main approaches I'm trying to run down: "pulse", "nopulse", and "pipewire". When I switch, I use the '-p' flag to maintain three grub submenus for each of those, respectively. I'm not sure how I'd keep it straight otherwise. And I can boot into one of the alternatives to try something if I don't otherwise need to build.

At any rate, I made a small breakthrough. Rubber ducking here was very helpful. It occurred to me that one major difference in my thinking was that I was accustomed to stopping and starting jackd to try different hardware configs or tweak things, either at the command line or with qjackctl. I thought qjackctl was actually doing that for me, but it was silently doing nothing at all. So I realized I needed to hardcode those type of changes in the configuration.nix. Having specified my audio device that way worked perfectly, so I'm a step closer. It's a bit more awkward to iterate that way than the way I'm used to. But it's progress! I have a long list of utilities from my old pinned config to move over. Since I'm now maintaining the userland stuff in home-manager, that should go more quickly. We'll see.

My first goal is to dedicate a laptop to this kind of thing, so I don't really care about pulse at the moment; not there. Eventually, I'll want to reconcile the two and then I can apply that to more general purpose boxes.

Thanks very much for all the help!
Jamesf
Established Member
Posts: 70
Joined: Tue May 28, 2019 12:23 pm
Location: Madrid
Has thanked: 51 times
Been thanked: 13 times

Re: NixOS and music: Experiences?

Post by Jamesf »

s3ej3s wrote: Tue Dec 07, 2021 7:42 pm
Jamesf wrote: Tue Dec 07, 2021 6:41 pm That's just weird. I'm using qjackctl and jackd, and the worst ongoing problem I have is that I have to manually use `kill -9 <pid>` to get jackd to actually stop running. I've yet to encounter jackdmp.
Interesting, so you *do* kill it. Is that a normal part of your workflow or something exceptional that you do. And how do you restart it? With the usual systemd stuff? I think jackd and jackdmp are actually aliases. If you reference external jack docs and talk, jackd seems to be a jack1 thing and jackdmp the newer jack2 equivalent, I think.
systemd isn't involved in my setup; I just use qjackctl.

Killing jackd has become part of my workflow, because that's just how I get the sodding thing to let go. I'd prefer that qjackctl actually killed it properly, but I'm like the sleepy dog lying on a nail sticking out of the porch: it's annoying, but not _quite_ annoying enough for me to do something lasting about it.
s3ej3s wrote: Tue Dec 07, 2021 7:42 pm I currently have branches for each of the three main approaches I'm trying to run down: "pulse", "nopulse", and "pipewire". When I switch, I use the '-p' flag to maintain three grub submenus for each of those, respectively. I'm not sure how I'd keep it straight otherwise. And I can boot into one of the alternatives to try something if I don't otherwise need to build.

At any rate, I made a small breakthrough. Rubber ducking here was very helpful. It occurred to me that one major difference in my thinking was that I was accustomed to stopping and starting jackd to try different hardware configs or tweak things, either at the command line or with qjackctl. I thought qjackctl was actually doing that for me, but it was silently doing nothing at all. So I realized I needed to hardcode those type of changes in the configuration.nix. Having specified my audio device that way worked perfectly, so I'm a step closer. It's a bit more awkward to iterate that way than the way I'm used to. But it's progress! I have a long list of utilities from my old pinned config to move over. Since I'm now maintaining the userland stuff in home-manager, that should go more quickly. We'll see.
Yeah, it's definitely a change in mindset, to run `sudo nixos-rebuild switch` for even the tiniest changes to those files, but I find it a worthwhile tradeoff to know that it's repeatable and documented (enough).

Useful note: I've discovered that if I make a change to qjackctl's setup and click on "OK", it'll reload jackd with the new configs, and restore all the connections. So I only actually kill jackd when I want it gone altogether. However, I'm _not_ using home-manager, and don't really intend to, so that's definitely a point of difference between our approaches.

It's also worth being aware that Pulse and JACK have some kind of get-out-of-the-way protocol. I learned this from discussion about Pipewire on the Ardour forum.

Now that I think about it, I _have_ had to restart Pulse for some things, and that _is_ managed via systemd. However, it's a user-level thing, not a system-wide one, so I do that with `systemctl --user restart pulseaudio`. That's mostly to get it to recognise a change in the environment, like realising it has to use jack-sink instead of trying to connect directly to the outboard audio interface.
I'm slow, but I get there eventually.
Post Reply