Silent playback with Marshall Woburn Multi-Room (AirPlay 1, vn=65537)

[outofsight]

Silent playback with Marshall Woburn Multi-Room (AirPlay 1, vn=65537)

Device

Marshall Woburn Multi-Room (Gen1?)
Firmware: ns-mmi-FS5332-0000-0044_1.3.26-41
No firmware updates available for this device.

Zeroconf discovery records

_airplay._tcp (WoburnBlack32e4, port 56525)

deviceid = 30:58:90:26:32:xx
features = 0x444F0A00
flags    = 0x4f
vp       = 8.0.0
model    = Minuet_1.0
srcvers  = 211.1.p8

_raop._tcp (3058902632xx@WoburnBlack32e4, port 56525)

cn = 0,1
da = true
et = 0,4
ft = 0x444F0A00
fv = p8.0.0
md = 0,2
am = Minuet_1.0
sf = 0x4
tp = UDP
vn = 65537
vs = 211.1.p8

cliraop invocation (from Music Assistant)

cliraop-linux-x86_64 -ntpstart ... -port 57939 -latency 1000 -volume 20
  -if <source_IP> -encrypt -alac -et 0,4 -md 0,2 -am Minuet_1.0
  -debug 5 -dacp ... -activeremote ... -cmdpipe ...
  -udn 3058902632xx@WoburnBlack32e4._raop._tcp.local. <marshall_IP> -

cliraop correctly picks up et, md and am from the discovery record.

Symptom

cliraop establishes the session successfully — the device appears as playing, and bidirectional control works correctly (volume, play/pause reflected on both sides). A high-bitrate stream is sent to the device throughout the session. However, the Marshall produces no audio output.

Key observation

The same Marshall plays audio correctly when used with TuneBlade (Windows native AirPlay stack) from another host in the network. This confirms the device is functional and capable of receiving AirPlay streams remotely. The issue is specific to how cliraop negotiates the session with this firmware.

Hypothesis

This device advertises vn=65537, which indicates a very old AirPlay 1 protocol version, and cn=0,1 (PCM and ALAC only, no AAC). It is possible that the device accepts the session setup but silently discards the audio stream due to some incompatibility in the RTSP negotiation emitted by cliraop versus what this firmware expects.

Question

Is there any known issue with devices advertising vn=65537 or features=0x444F0A00? Would it be possible to support more conservative or legacy-compatible negotiation parameters for older AirPlay 1 receivers?

[philippe44]

It's more probable that you need to enable encryption of the audio stream.

[outofsight]

Thanks for the quick feedback!

From what I can see, MA does invoke cliraop with -encrypt and -et 0,4, so I assumed an encrypted stream was already being sent. Am I misreading this?

If the issue is about the specific encryption type, is there a way for me to explicitly force suitable type (4-MFiSAP?) in cliraop or should MA team work on his side?

[outofsight]

I did some manual testing using cliraop directly from the command line, piping audio via ffmpeg, in the effort to isolate the effect of individual parameters.

Manual cliraop testing

With the device's native latency (1250ms as reported by the player) or lower values (1000ms as of MA provider defaults), the Marshall produces no audio at all — the session is established and the stream is sent, but nothing comes out.

Above approximately 2500ms latency, the Marshall produced noise rather than audio — the stream is clearly reaching the device but is being decoded incorrectly I suppose.

Testing via MA settings

On the MA side, I found AirPlay settings I had not previously explored. Forcing AirPlay 1 and increasing latency to around 1500ms allowed music to play occasionally, but results were not fully deterministic — sometimes it worked, sometimes not. A reboot of the player and/or the addon appear necessary sometimes to restore the ability to play after a failed test.