Test pipewire-jack for alpha3 release

changed milestone to %1.0-alpha3 — Playful Platypus

added Doing P1 + 1 deleted label

assigned to @chrizz

Installation according to docs and make run succeeded without errors.

But could not find the USB audio interface via pw-link:

➜  engine-core git:(feat-jack-support) ✗ pw-link -o                       
lineout_0:out_0
lineout_0:out_1
➜  engine-core git:(feat-jack-support) ✗ pw-link -i                       
➜  engine-core git:(feat-jack-support) ✗

After logging into the desktop environment, I noticed the same output in qpwgraph:

Prior tests succeeded using the Focusrite device - at least using the docker setup - trying to recover...

It turned out that wireplumber was disabled due to my prior ALSA testing setup - after enabling that service, everything worked as described in the docs.

Playback started successfully using make run.

To test the docker setup, I logged in as user aura and repeated the installation. (I was surprised that liquidsoap and related ocaml-stuff needed to be downloaded and installed again for this user but it succeeded.)

I made sure to enable pipewire and wireplumber aura and to stop these services for the previous user, but the audio device couldn't be discovered:

➜  engine-core git:(feat-jack-support) ✗ docker compose run engine-core wpexec /etc/wireplumber/scripts/ls-ports.lua

{ ["object.id"] = 31,
["port.alias"] = lineout_0:out_1,
["object.serial"] = 174,
["node.id"] = 32,
["port.direction"] = out,
["port.name"] = out_1,
["port.id"] = 1,
["format.dsp"] = 32 bit float mono audio,
}


{ ["object.id"] = 34,
["port.alias"] = in_line_0:in_0,
["object.serial"] = 169,
["node.id"] = 36,
["port.direction"] = in,
["port.name"] = in_0,
["port.id"] = 0,
["format.dsp"] = 32 bit float mono audio,
}


{ ["object.id"] = 37,
["port.alias"] = in_line_0:in_1,
["object.serial"] = 170,
["node.id"] = 36,
["port.direction"] = in,
["port.name"] = in_1,
["port.id"] = 1,
["format.dsp"] = 32 bit float mono audio,
}


{ ["object.id"] = 38,
["port.alias"] = lineout_0:out_0,
["object.serial"] = 173,
["node.id"] = 32,
["port.direction"] = out,
["port.name"] = out_0,
["port.id"] = 0,
["format.dsp"] = 32 bit float mono audio,
}

Assuming a similar wireplumber-issue as before but couldn't recover yet...

Did you have to install OCaml/Liquidsoap on your host? If yes, there seems to be something wrong with the setup. Let's clarify with @Loxbie.

Also, it would be good if you perform tests with the fro user in addition. This user should be part if the aura group.

I needed to install some components which were missing for user aura; but not sure if it was ocaml/liquidsoap by itself - I just repeated the installation procedure as dome before for user fro.

I think we need to execute the docker file with user aura because of the shared pipewire-file (?); otherwise we must adapt docker-compose.yaml. So pipewire must be started with this user too.

but not sure if it was ocaml/liquidsoap by itself

Please, let's clarify. It must not be needed.

Regarding users: AURA containers should be started by either user aura or fro. The latter should therefore be added to the group aura.

My first try was indeed to execute the docker container with my "regular" fro-user:

➜  engine-core git:(feat-jack-support) who
fro      pts/0        Jan 30 23:36 (fe80::8fd:2149:2c77:5a4b%enp3s0)
➜  engine-core git:(feat-jack-support) docker compose up
[+] Running 1/0
 ✔ Container engine-core  Created                                                                                                                                                              0.0s
Attaching to engine-core
engine-core  | Auto connecting PipeWire ports...
engine-core  | Starting pw-jack...
engine-core  | Failed to connect to PipeWire
engine-core exited with code 69
➜  engine-core git:(feat-jack-support)

The reason might be the shared pipewire-file - this worked in the testing repo where I ran and shared fro's file. In the deployment, we're using the aura uid (docker-compose.yaml#64):

- /run/user/${AURA_USER_ID}/pipewire-0:/tmp/pipewire-0

So I tried the same by logging in as aura and repeated the setup steps. Most packages were already installed, except ocaml/liquidsoap. But that was part of the dev setup and not required by docker.

I couldn't get the docker setup running neither as the fro-, nor aura-user.

As said, @Loxbie 's pw-jack test setup works if it's executed by the current user (1000) and I'm not sure how/if the shared pipewire socket file can be passed between fro and aura / the container in this scenario (or if there's a permission error I'm not aware of, etc.).

NB: I enabled/disabled pipewire, wireplumber and alsa-related stuff many times due to my prior testing, so I'm not sure if I broke something and if I ran into a special edge case.

Maybe @martina could verify this...

The control to the PipeWire server is handled by mapping the socket into the container. This needs the current user id because the socket is located unter /run/user/${uid}/pipewire-0. I will rename the current AURA_USER_ID to something which makes clear that this is the user running the pipewire server. I will also add a hint in the README.

@chrizz please check if there is a pipewire socket for the user you want to run the docker setup with. Set the AURA_USER_ID to that uid and see if it works.

A little bit more information on this matter can be found here.

I already tried to change the AURA_USER_ID to 1000, which worked during the pw-jack testing sessions; but there's no socket file in /run/user/${uid}/pipewire-0. So it really looks like a special issue due to turning on/off pipewire multiple times.

I think pipewire can/must be ran using the systemctl --user flag, while wireplumber needs the --global flag.

But again, there's usually no need to configure that and it worked out-of-the-box after a fresh installation. So apt remove ... && apt install ... might be a quick fix for that - trying to recover...

Unfortunately no luck on the docker front for me so far, can't get it running due to a confusing permissions problem (See #65 (closed)).

Running it engine-core without docker works fine for me as well.

You could try to prune the related images/volumes

Already did that multiple times, also un- and reinstalled everything completely once. A bit stumped at the moment

For resolution see #65 (comment 14349)

mentioned in commit 66091200

mentioned in issue aura#285 (closed)

66091200 solved the issue above.

Audio output worked, but I needed to call pw-link manually:

pw-link "lineout_0:out_0" "alsa_output.usb-Focusrite_Scarlett_2i2_USB_Y854J11063A637-00.analog-stereo:playback_FL"

I used this output of ls-ports.lua:

{ ["object.path"] = alsa:pcm:1:front:1:playback:playback_0,
["node.id"] = 40,
["port.physical"] = true,
["port.id"] = 0,
["format.dsp"] = 32 bit float mono audio,
["audio.channel"] = FL,
["object.serial"] = 44,
["port.direction"] = in,
["object.id"] = 44,
["port.terminal"] = true,
["port.name"] = playback_FL,
["port.alias"] = Scarlett 2i2 USB:playback_FL,
}

{ ["object.path"] = alsa:pcm:1:front:1:playback:playback_1,
["node.id"] = 40,
["port.physical"] = true,
["port.id"] = 1,
["format.dsp"] = 32 bit float mono audio,
["audio.channel"] = FR,
["object.serial"] = 46,
["port.direction"] = in,
["object.id"] = 46,
["port.terminal"] = true,
["port.name"] = playback_FR,
["port.alias"] = Scarlett 2i2 USB:playback_FR,
}

{ ["object.path"] = alsa:pcm:1:front:1:capture:capture_0,
["node.id"] = 41,
["port.physical"] = true,
["port.id"] = 0,
["format.dsp"] = 32 bit float mono audio,
["audio.channel"] = FL,
["object.serial"] = 48,
["port.direction"] = out,
["object.id"] = 48,
["port.terminal"] = true,
["port.name"] = capture_FL,
["port.alias"] = Scarlett 2i2 USB:capture_FL,
}

{ ["object.path"] = alsa:pcm:1:front:1:capture:capture_1,
["node.id"] = 41,
["port.physical"] = true,
["port.id"] = 1,
["format.dsp"] = 32 bit float mono audio,
["audio.channel"] = FR,
["object.serial"] = 49,
["port.direction"] = out,
["object.id"] = 49,
["port.terminal"] = true,
["port.name"] = capture_FR,
["port.alias"] = Scarlett 2i2 USB:capture_FR,
}

...for these audio settings in .env:

AURA_ENGINE_OUTPUT_DEVICE=Scarlett 2i2 USB:playback
AURA_ENGINE_OUTPUT_CHANNEL_LEFT=FL
AURA_ENGINE_OUTPUT_CHANNEL_RIGHT=FR
AURA_ENGINE_INPUT_DEVICE=Scarlett 2i2 USB:capture
AURA_ENGINE_INPUT_CHANNEL_LEFT=FL
AURA_ENGINE_INPUT_CHANNEL_RIGHT=FR

This matches the sample config https://gitlab.servus.at/aura/engine-core/-/tree/feat-jack-support?ref_type=heads

The auto-connect is working now 🥳 but I needed to place the lua script on the host machine (the one I created for local testing).

Don't know if that's acceptable for a docker deployment...

As said, the docker setup works but the lua-script which handles the connections must be located on the host machine (or the connection must be done manually via pw-link). For me, that's a sufficient solution; but it might be preferrable to find a way to handle this via docker as well.

The docs are clear to me but note I'm already familiar with this topic.

I noticed a typo in the .env Settings at the bottom of the readme - "playback" and "capture" seem to be mixed-up.

The only confusing point is the device naming - there are some "_" and ":" in the name string and it's not fully clear how to derive the config from that; e.g.: "alsa_output.usb-Focusrite_Scarlett_2i2_USB_Y854J11063A637-00.analog-stereo:playback_FL". Since pw-link and the lua script report different names, I needed to research and play around a while to find the correct strings.

So I think we can go with this but I'd really appreciate a confirmation and further testing on a different machine.

@martina Could you verify this or any news on that?

Yeah I got playback and capture mixed up. I will fix this.

The only confusing point is the device naming - there are some "_" and ":" in the name string and it's not fully clear how to derive the config from that; e.g.: "alsa_output.usb-Focusrite_Scarlett_2i2_USB_Y854J11063A637-00.analog-stereo:playback_FL". Since pw-link and the lua script report different names, I needed to research and play around a while to find the correct strings.

Did you use the docker command for the auto connect solution?

docker compose run engine-core wpexec /etc/wireplumber/scripts/ls-ports.lua

But I do agree, the setup is not that easy and simple as I would like it to be.

Yes I used the docker command to request the device names; then I changed the .env file according to that info.

Currently the script that dumps the information, including the device name, is very simple. Maybe we could improve the way we print the device information. I don't have much experience with lua and the wireplumber api, sadly the documentation is spare.

Another possibility could be to move away from device names (strings) and move to node ids. These are uniformly across pw-link and wireplumber but the downside is that you don't know which device is behind a node id.

I can now confirm, that it works for me as well.

The device names are a bit confusing (a lot of information is printed, I agree with maybe simplifying it by reducing the lines printed because most are unnecessary), but I managed to get it running so it's a win for me and I think the example in the README is sufficient.

Great - thanks

marked this issue as related to aura#247 (closed)

mentioned in commit d3dee262

@david why is this related to aura#247 (closed)?

According to today exchange with @fm_margarethem I got the info, that you are currently blocked/having issues with aura#247 (closed) and that it also relates to #64 (closed).

After personal clarification it turned out there is no relation between those tickets.

removed the relation with aura#247 (closed)

mentioned in issue #50 (closed)

marked this issue as related to #62 (closed)

I think we can close this ticket due to the successful results.

The lua script and device names are indeed confusing but I/we could refactor and simplify it as an upcoming task for alpha4.

That's great. May I kindly ask to create such improvement ticket for alpha-4?

Sure, I think we can simplify/clarify the device/node connection stage.

The reason for the lua-script was that I needed to use a graphical desktop environment in order to run pw-link (which does the same but with easier usage, such as simplified device names). So the script might be obsolete on desktops anyhow.

Since @Loxbie integrated pw-jack into engine-core, pw-link works also via ssh. But I need to verify this during testing alpha3...

It works also using the latest aura-playout deployment, so closing this ticket.

closed

removed Doing label

Test pipewire-jack for alpha3 release

Designs

Child items ...

Activity