@oxij The only sad thing is that I have not found a way to make jack1 work correctly in promiscuous mode:
http://lists.jackaudio.org/pipermail/jack-devel-jackaudio.org/2019-March/001876.html
jackaudio/jack1#87

@oxij

Thank you! Applied changes.

you can't use createHome there, the home directory needs to be created on every startup if it does not exist, else things are very easy to break

Tor module uses createHome too.

I would also add services.jack.a2jmidid.package option for completeness

We only have one version and also JACK1 has this functional builtin

Hm, I had it working before, I'll play with it sometime later.

Would be really glad if you let me know how to make it work (no necessity to test this PR, just an instruction on how to kick it will be enough). For me only control functions do work with jack1 in promiscuous mode. If I try to use programs there are errors "subgraph starting at ADLplug timed out (subgraph_wait_fd=9, status = 0, state = Triggered, pollret = 0 revents = 0x0)". If I run jack client from the same user as jack server user then everything works.

• you can't use createHome there, the home directory needs to be created on every startup if it does not exist, else things are very easy to break.

Just a hint (hope that helps): The systemd directives StateDirectory and StateDirectoryMode can be used to create a "home" directory for a service in /var/lib (or in the user's home directory if it is a user service). The directory will be owned by the user account that is used for the service and it persists when the service or the machine is restarted. See systemd.exec(5) for details. If the service actually needs a $HOME environment variable, it must be defined with the Environment systemd directive.

@Yarny0 applied, thanks!

@oxij Hi! Did you get a chance to look into jack1 promiscuous mode?
Meanwhile I've reworked this module to make it more robust and simpler to maintain.

1. Removed user service. Because of systemd user-units can't be easily enabled/disabled per user #21460 and also for simplicity and maintainability
2. Added loopback device option in addition to ALSA PCM plugin. Makes setup work in sandboxed environments like Steam
3. Added session option so user could do initialization here. Default session just starts a2jmidid if JACK2 is used
4. Used jack_wait and jack_lsp to check for server/port availability instead of unreliable delays in services
5. JACK service is now brought not by sound.target but by udev rule when real sound card appears in order not to trigger on loopback device availability

@infinisil Thank you for review! Could you please tell me more about moving defaults to config?
What if user wants to drop these defaults? Should he use lib.mkForce then?
I personally keep defaults with options like this

  services.xserver.windowManager.i3.extraPackages = with pkgs;
    options.services.xserver.windowManager.i3.extraPackages.default ++ [ spectacle ];

  programs.sway.extraPackages = with pkgs;
    options.programs.sway.extraPackages.default ++ [ qt5.qtwayland grim ];

Just can't conclude which approach is better:

• to set defaults in config, so user likely needs mkForce if he wants to overwrite them
• or to set defaults in options and let user use options...default is he wants to extend defaults

I think if the default makes sense to always be present, because otherwise the module doesn't properly work, then setting it in the config section and requiring the user to use mkForce if they really want to remove that is good.

On the other hand for defaults that aren't necessary for the module to work, and users are encouraged to change them, then assigning a default in the option makes more sense. Note that the users could still keep those defaults by assigning their values with mkOptionDefault, which is a bit weird, but simpler than using the options argument, but sometimes also doesn't work.

(The option value gets determined with a priority system, the assignments of highest priority get merged together to result in the final value, mkForce has high priority, mkOptionDefault very low priority, mkDefault low priority, and without any of those it gets a default priority in the middle).

I've written down something similar for NixOS/rfcs#42: https://github.com/Infinisil/rfcs/blob/config-option/rfcs/0042-config-option.md#defaults

In this case I'd think putting the defaults in the config section always makes more sense, because these default values encode part of the functionality of this module, and without them certain options couldn't do their thing.

The biggest annoyance is that these defaults don't show up in the manual. In the future this might get fixed.

@infinisil Got it, thank you! I've applied requested changes.

Hm I just wanted to test this, but I'm not sure it works as intended. I enabled services.jack.jackd.enable = true;, but because there's no wantedBy = [ "multi-user.target" ] or so for the jackd service, it doesn't even start. Is that right? How do I test this?

@infinisil for test you could start it manually. Automatically it will start only on reboot by udev rule, when real sound card will be added, sound.target is not suitable, since that way loopback device could be initialized before real sound card, and so service will fail. udev rule doesn't trigger on loopback device.

Could someone finally merge this?

While I'd have liked for another person to test it, especially somebody who wants to use jack, you seem to have tested it well enough already, so let's merge.

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/firewire-audio-not-working/3976/4