Closed ralph-ralph0 closed 12 months ago
Thanks for the post. Shairport Sync doesn't support the NTP variant of AirPlay 2, I'm afraid.
It seems that AirPlay 2 allows two different timing systems -- one based on a variant of PTP and one based on a variant of the NTP protocol (but not NTP itself). The still-in-use earlier version of of AirPlay (aka "Classic AirPlay", aka "AirPlay 1", aka "AirTunes 2") uses an NTP variant also.
Shairport Sync handles the PTP-based version of AirPlay 2 only. Until now, I had never actually come across an NTP variant of AirPlay 2, apart from (AFAIR) some support for it in OwnTone -- you might want to check with those guys.
FWIW, Shairport Sync does support Classic AirPlay in AirPlay 2 mode, so if you can persuade the Wiim Pro to use a Classic AirPlay link to Shairport Sync, it would work.
I don't know of a way to signal to the Wiim Pro to use another protocol.
Thank you for your reply!
I suspect (but don't know for sure) that the WiiM Pro isn't a MFi licensee, so it's likely they use something like OwnTone or other daap variant to "cast" AP1 and/or 2. Going with that assumption...
In issue #1710 it seems there's a work-around for the OwnTone/NTP problem (AFIU to enable _raop on OwnTone side) -- but the WiiM device's configs are closed. I'll try longer term to convince the WiiM Pro developers to consider this change if applicable (yet I don't know the unintended side-effects of that work-around).
Meanwhile on the shairport-sync end, are there any configs I can use to force shairport to only negotiate Classic AirPlay protocol with shairport-sync in AirPlay 2 mode? (I already tried advertising only _raop.tcp, port = 5000
for Airplay 1).
Else the only way to "force" Classic AirPlay is to build shairport-sync without AirPlay 2, correct?
Building shairport-sync in AirPlay1 mode, the device was not visible on the network to the WiiM Pro at all, so I couldn't test whether the exchange would revert to PTP (shairport-sync had previously been "visible" to WiiM in Airplay2 mode).
Shairport-sync in AP1 mode properly advertises as _raop._tcp on port 5000 (and I assume correctly with no _airplay._tcp service advertised); other Airplay devices could "see" shairport-sync via Avahi and stream to it no problem.
Fussing with variations of regtype on shairport-sync didn't enable WiiM to "see" it. Even though WiiM is claimed to be Airplay and Airplay 2 compatible.
Thanks for the update. Like you, I suspect that the WiiM Pro isn't a MFi licensee.
At this time, there aren't any plans to add AirPlay 2 functionality to Shairport Sync.
Am still puzzling over why shairport-sync in "Classic/Airplay 1" mode can't even be "seen" by WiiM during service discovery, but is "seen" by iPhone, AirMusic, etc.
I'll close this issue while I kick this over to WiiM devs. Will update if there's useful info.
What happened?
Question: is there a way to force an Airplay source to revert to different protocols (where NTP is not required?)
What I expected: WiiM Pro streaming device has a feature to "Airplay cast" its music output to an Airplay or Airplay 2 device. I expected that WiiM should connect to my RPi4 + Shairport-Sync instance as an end point.
What happened: Shairport-Sync is functioning properly with other source devices (e.g. I can play music to shairport-sync from iPhone, and an android app named "AirMusic" that can "cast" via Airplay and other protocols).
BUT, when attempting to connect WiiM device to shairport-sync, the WiiM device attemps to connect but does not complete a connection. Detailed logs from shairport-sync show that a connection is started but then quickly terminated. The shairport-sync service status reports simply:
Warning: Shairport Sync can not handle NTP streams.
What I did to debug/confirm:
More detailed log is attached below. (edited to remove some PII)
I used versions 4.2.1 and built
4.3.1-24-g7e0e3af6-AirPlay2-smi10-OpenSSL-Avahi-ALSA-soxr-sysconfdir:/etc.
I also built and installed latest NQPTP (also making sure to delete all instances of the service files anywhere on the system).the
shairport-sync.conf
configuration is simple, I mostly used the template with these changes:// regtype = "<string>"
regtype = "_airplay._tcp"
since I'd read an issue report related to NQPTP; alsoregtype = "_raop._tcp"
and then"regtype = "_raop._tcp, _airplay._tcp"
None of these solved the issue, although I found that keeping the DEFAULT regtype (or _raop" is needed for the AirMusic app to "see" the shairport-sync device.Relevant log output
System Information.
RPi4 (4GB) OS: debian Bookworm
uname -a:
Linux iot-rpi4-personal-enet 6.1.21-v8+ #1642 SMP PREEMPT Mon Apr 3 17:24:16 BST 2023 aarch64 GNU/Linux
Output = "hw:Loopback,0" and functions OK when source is iPhone or AirMusic app.
Configuration Information.
PulseAudio or PipeWire installed?
How did you install Shairport Sync?
Built from source
Check previous issues