I have a linux device running shairport-sync for airplay emulation and this does not show up as a network source. The device is selectable on all my other computers and phones on the network without issue. Just wondering if anyone else is experiencing this
Hey @davezp25.
I am not deeply familiar with shairport-sync so correct me if I’m off base.
It looks like maybe shairport-sync doesn’t support the AirTunes2 protocol. Due to limited hardware support for the old protocol (basically only pre-2011 apple devices), we decided not to pursue support for it.
There are reverse-engineered AirTunes2 implementations out there–if shairport-sync isn’t running the latest protocol, maybe one of those is?
If you’re confident that shairport-sync is an Airtunes2 implementation, let me know and I’ll fire it up over here and see what the deal is.
Also, I should add, it’s in our near-term plans to release our own streaming protocol (RoonSpeakers) and we plan to do it in a DIY-friendly manner. Hopefully this AirPlay dependency can be a short-term solution for you with Roon.
Thanks for trying Roon!
Brian,
It might not be the AirTunes2 protocol, it is forked from the original Shairport 1.0, I will shoot the developer an email to confirm. I have a spare airport express so I just used that in the meantime, works great! Looking forward to RoonSpeakers, Are you considering a linux/arm version?
Enjoying the software!
1 Like
Yes! One of our most important targets is Raspberry Pi. We want people to have an inexpensive, high-quality and DIY friendly way to get audio out of the app and into other parts of the house. An rPi with a USB or i2S DAC should be capable of sounding very good.
1 Like
Awesome! Yes indeed!
Yes, same problem with volumio (which I think is standard shairport). Hey ho! I’ve got a short term fix in that Yosemite allows you to set the system audio output to be a remote airport and that works fine for now. Maybe not ideal but sufficient until the weekend when a better solution can be cobbled together.
Great idea! I did not think to do that, but works well.
Hi there. I’m the developer of shairport-sync, so maybe I can share some ideas.
From Unofficial AirPlay Protocol Specification, Section 2: “An AirPlay device such as the Apple TV publishes two services. The first one is RAOP (Remote Audio Output Protocol), used for audio streaming, and the other one is the AirPlay service, for photo and video content.”
Shairport Sync supports RAOP (including the synchronisation extensions) – see Section 2.1 in the document.
I guess that Roon is looking for the AirPlay services advertised on port 7000 (Section 2.2 in the document). Would that be right?
Hey @MikeBrady,
Our implementation is based on that document. I’m very familiar with it. The other reference we’ve found useful is this one.
We are not looking for AirPlay (_airplay._tcp) services–only AirTunes (_raop._tcp). We discover AirTunes servers using mDNS. We stream using the UDP transport.
Does that sound like it should work with your stuff? If so, I can fire it up over here and try to see what’s wrong. My gut is towards an mDNS/Discovery issue. Could be on our end–99% of our QA/testing happens with hardware products (Apple or BridgeCo).
Hi Brian. Yes indeed, really quite familiar with that document too 
. Shairport Sync works with raop.tcp alright. So, on the face of it, it should work. One thing is that shairport-sync won’t work without the standard synchronisation stuff coming from the audio source. I’d be interested to see how you get on with shairport sync, if you try it out.
1 Like
Ok, I took a look last night. Should be all set in our next build.
The technical details of why it wasn’t working:
- We were expecting SRV and TXT to show up in the “additional records” section (this is where current apple, bridgeco, airfoil speakers, and airserver put them), not the “answers” section. Moving forward, Roon will tolerate them being in either place.
- We were expecting that when “None” showed up as a supported encryption type in the TXT record, that the device would accept unencrypted content–this does not seem to be the case with Shairport-sync. We’ve changed to doing the “conventional” hack where an “Apple-Response” header indicates that encryption should be used.
This second workaround seems to have improved our compatibility with Airfoil Speakers as well. The world would be a better place if AirPlay were a well documented protocol and not just a bunch of reverse engineers butting heads against the hardware and each other.
Thanks for dropping by and helping with this!
2 Likes
Awsome! The technical details are over my head on this, but looking forward to test in next build. Thanks to all involved!
1 Like
Super, thanks. I’ll have a look at the stuff you mentioned – I might learn something!
Amazing! Next build then?
Yup, that’s the plan.
Just to report back, shairport-sync is showing up as as source and working well on build 16, Thanks!
Closed due to inactivity. If you are still seeing this issue, please open a new support thread.