Objective

This Gide aims at outputting aes67 audio streams from the Raspberry Pi, using pipewire. Our hope is to get the score sequencer running on the pi and streaming to aes67 compatible hardware.
Tested on the Raspberry Pi 5 running Arch Linux, and streaming to Innosonix LP2 amps.

Tree

/etc 
├── /linuxptp
│       └── /ptp4l.conf
├── /netctl
│       └── /ethernet-static
├── /systemd
│       ├── /system
│       │       ├── /aes67-proxy@.service
│       │       └── /linuxptp.ptp4l@.service
│       └── /user
│                 └── /pipewire-aes67.service
/home
└──/<user>
         └── /.config/
                   └── pipewire-aes67.conf

Arch arm

The Raspberry Pi 5 does not support Arch Linux installation out of the box at the moment. Sven Kiljan blog post explains the necessary workaround.

Network

Connecting the pi and the amp to an unmanaged switch is currently our preferred approach. Without DHCP, all IP addresses were set statically in 169.254.14.0/16 range. The gateway being the IP address of the unmanaged switch. .
Netctl is used to set the static Ethernet connection. The ForceConnect=yes had to be set, but this could have been an issue while running concurrently with a DHCP connection. More tests needed.

PTP

In our setup, the amp will be used as the PTP clock grand master. An Ethernet connection is first required, so the linuxptp.ptp4l@.sevice is set to start after the network-online.target.
@jcelerier suggested the ptp4l invocation.
the ptp4l.conf file is required, as well as this udev rule

Pipewire-aees67

As pipewire does not like to run as root, the pipewire-aes67.service will be enabled as with the --user flag. To that effect, The chosen user needs to be set to linger: loginctl enable-linger <user>
Unfortunately, user side services can not depend on system-wide services. For pipewire-aes67 to work, we require a network connection, and therefore, require starting this user service after the system network service. The aes67-proxy@.service is used to circumvent this issue, so that a user service can be started on boot.
To make audio connections, we use qpwgraph, as it gives us graphical feedback useful for debugging. If the system work as desired, we may revert to simply using pw-link. Since qpwgraph is written with the qt framework, it can be invoked with QT_QPA_PLATFORM=vnc, which makes its UI available from a VNC client. This is useful for our purposes, running the Raspberry Pi "headless" (without any peripherals).