Open AirPlay 2 Receiver | Hacker News Reader

Open AirPlay 2 Receiver

github.com

422 pointsazalemeth112 comments

It's worth stating that the actual crypto code itself is "moderately insane" – https://github.com/openairplay/airplay2-receiver/blob/master... contains the warning:

    """
    GPLv2
    Python implementation by systemcrash 2022
    Original C implementation of OmgHax by (credit to original author and Foxsen)
    If you want this to work, don't touch anything. It's a steaming hot
    rats nest of crypto mess which works. It's quite performant.
    Resist the urge to refactor. :)
    Avoid +=, -=, ^= etc operators in Garble: they don't account for overflow.
    """

before going into lovely detail, containing lines (e.g. in a method appropriately called Garble) such as

    buffer1[15] = ((3 * (((buffer1[72] >> (buffer4[buffer1[190] % 21] & 7)) ^ (buffer1[72] << ((7 - (buffer4[buffer1[190] % 21] - 1) & 7)))) - (3 * buffer4[buffer1[126] % 21]))) ^ buffer1[15]) & 0xff
        print(f'buffer1[15]:{hex(buffer1[15])}')

Really, really hats off to whoever worked this out. I have no idea where you'd start.

This looks like someone decompiling Apple's code and basically putting output of that into their project.

This method can have some legal risk attached to it (INAL).

Are you saying that because you have knowledge of Apple’s code?

This is generally how you’d make this kind of encryption/decryption work for apps that don’t have documented/open interfaces.

In fact, it’s what I’ve done to reverse engineer the encryption for Zwift for example (and a ton of other apps)

No knowledge of Apple's code here, but looks like they simply gave up trying to reformat decompiler/disassembler output in that Garble class. Humans don't write code like that, optimizers do

AFAIK, DMCA allows reverse engineering for compatibility purposes. IANAL, though.

If it was decompiled, that's not really reverse engineering though. So I'm not confident that the DMCA carve out would apply here.

Decompilation is very much part of reverse engineering. The two are not the same, but disassembling and decompiling code are extremely common techniques used to reverse engineer a program, algorithm, or protocol.

That's clearly "hacker true". I wonder if it's "lawyer true" as well? It could very well not be.

Algorithms alone don't cross the threshold for copyrightability, and code which only implements those (specially non-creatively as seen here) is not copyrightable.

It's true that algorithms alone don't cross the threshold for copyrightability, but just decompiling copyright code and using that is extremely risky.

The carve-outs for interoperability might be useful here though.

On other hand, there are no carve-outs for DRM, so this could still run afoul of that if it supports DRM'd playback.

Edit: this explicitly does not support FairPlay DRM'd playback, so the lack of DRM carve-outs shouldn't matter, as awful as the lack of carve-outs is.

FWIW, on the "non-creatively" angle, this is almost certainly some really simple algorithm that only looks really complicated as this is a direct translation of the obfuscated binary, and so I'm not sure you can analyze it using so simple a framework.

(Apple uses an obfuscation technique that converts functions into massive switch loops, threading a control variable through on which math is done to figure out the next block of code to switch-jump through; they then use a duality between the bitwise logic and algebraic rings to turn what might be one instruction into five instructions in a different order, and often broken up by the inverted looping. I believe--but am not sure, as most of my knowledge of this stuff is from trailblazing myself over the years... I wrote the first decompiler for .NET a couple decades ago and have done a lot of work in the iPhone jailbreaking ecosystem on static analysis and runtime modification--that the literature-searchable terms for these are "parameterized control flow flattening" and "mixed-boolean-arithmetic".)

So like, in some sense, this is not at all how someone else who understands how the algorithm works would implement it: it isn't like "oh yeah, there's one semi-obvious way to do it, and I did it that way", and one might definitely argue this is "creative".

(I've personally avoided ever just copying and redistributing--even in translated form--logic from Apple like this, and that's part of the reason. It might still be OK, due to some fair use -styled exemptions relating to software interoperability, but the only ones I explicitly know about are with relation to reverse engineering to obtain that interop, not the part where you directly copy the resulting logic instruction-by-instruction.)

> So like, in some sense, this is not at all how someone else who understands how the algorithm works would implement it: it isn't like "oh yeah, there's one semi-obvious way to do it, and I did it that way", and one might definitely argue this is "creative".

But the resulting output is automatically produced by an obfuscator. There's no creative human involvement in the process itself of how the obfuscated code came to be. Hell, the Copyright Office wrote extensive articles on why AI art can't be copyrighted.

Would you thereby claim (fwiw, you might, and you might even be right about it: I'm just trying to understand if you have a boundary) that extracting the underlying binary code and embedding it in this program with an emulator--instead of laundering it through rewriting the assembly instruction-by-instruction in Python--would be fair game?

If the binary code involved was only the machine code which dealt with the encryption algorithm itself and not any sort of functionality or sequence, then yes. Courts have placed the burden on the program's "structure, sequence and organization".

If one were to take a small sample out of a copyrighted binary which only implemented functionality and had no remains of the creative process behind it, I'd wager they would be in the clear.

That said, I feel like machine code copyrightability is questionable on its face. A packaged binary with resources and assets such as text would be, but the machine code itself is a more complicated issue. Admittedly this would jeopardize libraries, since they don't contain any expressive elements like interactive programs do.

That file is intense… seems like half of it is a declaration of a list with a BUNCH of hex addresses. I don’t know anything about crypto so no idea if that’s fairly typical or not.

This file is also interesting: https://github.com/openairplay/airplay2-receiver/blob/master...

In particular:

AIRPORT_PRIVATE_KEY = ( "-----BEGIN RSA PRIVATE KEY-----\n" "MIIEpQIBAAKCAQEA5..."

Is that intentional? Surely it is, being a public repo, etc.

Looks like that same key is found elsewhere on the web, so I assume it's intentional:

[1] https://www.theiphonewiki.com/wiki/AirPlay

[2] https://www.google.com/search?q=MIIEpQIBAAKCAQEA59dE8qLieIts...

That is a key that someone extracted from an Apple Airport Express back in 2011: https://mafipulation.org/blagoblig/reversing/index.html#shai...

The iTunes key was found by DVD Jon. The Airport Express key was found by James Laird. https://en.wikipedia.org/wiki/Remote_Audio_Output_Protocol

It is result of decompilation/disassembling Apple's binaries. I have done this in past. Apple uses some sort of thirdparty whitebox crypto and code obfuscation tool, that hides underlying algorithm into a mess. Underlying algorithm is typically very simple, and standard crypto.

I wonder if the intentionally obtuse and custom cryptography is a form of DRM.

With DRM, since the data itself isn't secret (in fact you want to decode it at the end so you can play the media), the strength of the cryptography itself doesn't matter and the objective is to frustrate and slow down any reverse-engineering attempts, so homebrew cryptography may actually make sense here as to prevent usage of any common cryptographic libraries and force the reverse-engineers to implement it from scratch.

There are two lists buffer1 and buffer4. So these two lines assign a value to the 16th item in buffer1 and prints it with its hex value. The value is determined by arithmetic and bitwise operations.

For example, if buffer1[72]=107343, buffer1[190] = 25, and buffer[4]=18 (buffer1[72] >> (buffer4[buffer1[190] % 21] & 7)) (buffer1[72] >> (buffer4[25 % 21] & 7)) (buffer1[72] >> (buffer4[4] & 7)) (buffer1[72] >> (18 & 7)) (107343 >> 10) 104

https://docs.python.org/3/reference/expressions.html#shiftin...

  >> and << operators accept integers as arguments. They shift the first argument to the left or right by the number of bits given by the second argument 
  i = 14; // Bit pattern 00001110
  j = i >> 1; // here we have the bit pattern shifted by 1 thus we get 00000111 = 7 which is 14/2

https://docs.python.org/3/reference/expressions.html#binary-...

  & operator yields the bitwise AND of its arguments (*If both bits are 1, the corresponding result bit is set to 1. Otherwise, the corresponding result bit is set to 0. so 1100 & 1010 is 1000*)
  ^ operator yields the bitwise XOR (exclusive OR) of its arguments (*so 0101 ^ 1111 is 1010*)

https://docs.python.org/3/tutorial/inputoutput.html#fancier-...

  To use formatted string literals, begin a string with f or F before the opening quotation mark or triple quotation mark. Inside this string, you can write a Python expression between { and } characters that can refer to variables or literal values.

Bitwise examples from:

https://en.wikipedia.org/wiki/Bitwise_operations_in_C

https://docs.microsoft.com/en-us/cpp/cpp/bitwise-exclusive-o...

What I really want is for someone to crack the Sonos S1 protocol — the one that allows for low-latency P2P sharing - and then to use one of these Airplay 2 bridges with it. Right now the best I can do is to pipe an icecast stream to one which adds seconds of latency. That would allow my older S1 Sonos gear (which I spent thousands on) to have basically unlimited life.

> That would allow my older S1 Sonos gear (which I spent thousands on) to have basically unlimited life

2 years ago, I bought some used Yamaha (not "smart") speakers and AVR. They are 8 years old now and work flawlessly. My solution to making them "smart" was to just Cast to my Android TV that's plugged into the AVR.

That entire set up cost me <$200 and has no end in sight with a very clean upgrade path. It's unfortunate that so much modern hardware is paperweight in a few years just because the company can't be bothered to maintain the software.

> the company can't be bothered to maintain the software.

or open source it and let enthusiasts maintain it.

In my experience AirPlay equipped receivers are also a pretty decent bet for long term support. My receiver is a 7 year old midrange Marantz model and its AirPlay has always worked great. It still gets software updates occasionally too which is nice. If I upgrade it’ll be due to changing HDMI standards (it can’t handle high framerate 4K video), not protocol support.

As I understand Airport Express models from the 2000s still work with AirPlay from modern Apple devices too, though I don’t own any and can’t vouch for them personally.

AirPlay 1 doesn't have the nice multi-room audio support that AirPlay 2 does. It only has a much hackier version that works from iTunes, but not from your iPhone's media controller.

But if you only ever want to play to 1 device, then you're set.

The 3rd generation AirPort Express (A1392; the flat/non-wall wart 2012 version) supports AirPlay 2. All generations of the AirPort Express also have a mini-TOSLINK output allowing for a pure digital audio stream from the source to the receiver/amplifier.

Not only would that require me to buy an AirPort Express per speaker, many Sonos speakers don’t have an audio in jack. Thus my desire to bridge this purely in software.

It’s a bit janky for what you want do to, but if you have any Sonos S1 device with an input, you should be able to group that device with whatever other speakers you want playing the audio input. (And if that input device is a speaker that you don’t want playing, you can turn the volume all the way down.)

While probably not an ideal solution for the parent poster, who understandably wants to make things work with their existing Sonos gear, the A1392 is an outstanding value at this point because there are absolute truckloads of them on eBay for ~$20.

Assuming you're okay with AirPlay (which, admittedly, rules a lot of HN folks out) this is a $20-per-room device that gives you full lossless multiroom streaming including your choice of analog or optical out. Really great.

I have two Chromecast Audio devices which similarly provide both analogue and optical digital outputs, but they seem to be much more expensive second hand than the Airplay alternative.

I'm not sure if Chromecast Audios support lossless, if that matters.

Shame there’s nothing similar for video airplay. I needed to add airplay to an old/cheap dumb tv just for apple fitness in my partner’s workout room, and the only cost-sensible thing was an ad-infested roku device.

    Shame there’s nothing similar for video airplay.

Isn't there? You can pick up 3rd/4th gen AppleTVs on eBay for $20 all day long.

I had a 3rd gen Apple TV, but it had grown nearly unusably buggy. Still-supported apps would randomly crash or fail to stream, AirPlay would randomly fail entirely or fail to play video, streams/AirPlay would randomly stop, various operations would randomly take minutes to complete or time out.

Basically the issues as detailed here, though I had it more recently than the 7.6 software update: https://tidbits.com/2020/09/28/third-generation-apple-tvs-su...

If the receiver is turned off, do you ever have to try multiple times (2-3) to wake and begin playing music via Airplay? I'm sure my slimline Marantz is just misconfigured.

I haven't had that trouble, but I have found that mine (NR1606 model) is more fussy about things like that when it's on WiFi. It definitely "prefers" to be on hardwired ethernet.

Might have to start pulling cable.

FYI my ~9y/o marantz is also hardwired, but I cannot get airplay to work unless I explicitly go to Net/USB and even then it's the same 2-3 attempt (switching inputs) to get the device to appear on the airplay list. After that it's flawless, but the UX pretty much means I'm the only one airplaying to that device. I have since upgraded 3 years ago to a newer slimline model and that has no problem being found regardless of the input used and regardless of wifi/ethernet.

My friend with a ~5 year old denon also has no problem. So possible this is a discontinued firmware issue. YMMV

Yup. Happens a lot with my Denon. It also likes to disconnect a lot, while my TV (right above it) is streaming YouTube at the same time with no problem.

My issue is less that it drops connection (seems pretty solid once I have music playing), but that the initial connection can take several tries.

My guess is that when the receiver is awoken by Airplay, it is then attempting to connect to the “Last Used” input (or something) which disconnects Airplay.

Hard to say what's going. My denon is my first "real" receiver, it's been underwhelming.

As I understand Airport Express models from the 2000s still work with AirPlay from modern Apple devices too

Can confirm. I stream from my iPhone to a 2012 Airport Express hooked up to the aux in of a Sony HD radio.

Sonos has done a pretty decent job at keeping hardware alive. IIRC they still have S1 products alive but created S2 in the last few years because people wanted new features that required more CPU than their old devices could handle.

They still maintain an old S1 app for older devices and I think those devices should still all work. I don’t think there’s a plan to “turn them off”. A lack of new features is something that may or may not be a problem.

Actually, I think audio companies in general have been pretty good about keeping products alive. Even the old Amazon Echo Gen 1 I think still works… and that’s a full-on smart device that exists for the smarts not the audio quality.

> They still maintain an old S1 app for older devices…

Their current app now supports S1 devices as well.

Most S1 devices but not all of them. Some really old S1 devices aren't supported, I think the most popular one would be the Play:5 Gen1

https://support.sonos.com/s/article/4786?language=en_US

Ah! That's annoying, thanks for clarifying.

I love my Arc system as a "point in time" purchase, but I don't have high trust in or loyalty to Sonos in general.

The problem here is the wildly different expectations. It's an audio system, and normally audio systems are expected to work for >30 years. But it's a "smart" system controlled through an app, and apps need to be maintained to keep working on new hardware.

Yea I agree. I personally still come to the conclusion that it’s probably worth it assuming the business continues to operate as they have been. But eWaste does suck to generate knowingly.

I have a record player (and DAC) and an amp and passive speakers. I have the full HiFi setup - the record player is setup to avoid vibrations and the speakers are properly distanced from the wall etc. I can tell you without any hesitation that the price-per-minute-listened of my Sonos system is a small fraction of the HiFi (which will last 30 years). If I upgrade the Sonos every decade I’m sure it’ll still “make sense”. That’s excluding the cost of media for which records cost a lot more than streaming. Personally, I think the Sonos sound “more than good enough” to enjoy without missing anything from the record player.

That said, I don’t love the generation of eWaste, and I hope the Sonos lasts for more than a decade. And every day that Amazon/google keep their smart speakers alive is a good day for eWaste. I can only dream they’ll allow you to update the firmware when they finally EOL them. (I know they won’t though).

Buy a raspberry pi zero with an audio hat, throw max2play on it!

https://www.max2play.com/en/

> because the company can't be bothered to maintain the software.

Ironically (considering that you're using Yamaha) their MusicCast system have had a reasonable lifespan (seven years on the third generation, although they no longer support their 2003 stuff).

But yes, I'm looking at dabbling with HifiBerry (https://www.hifiberry.com/) for streaming duties for my older stereo gear.

Not sure if you mean that, but the Sonos S1 interface has been reverse-engineered, see here:

https://github.com/SoCo/SoCo

https://github.com/jishi/node-sonos-http-api

This allows you to e.g. set the Sonos speakers to play any audio URI.

And that audio URI is then an ice cast with seconds of latency. This is different for the protocol that the speakers use to pipe audio to each other which is near real time.

It might not be as realtime as you think, especially if it's buffered. You just need to sync timestamps and buffer for at least the slack in your system. I wouldn't be surprised if it was using NTP/PTP under the hood to sync up system clock time and then just playing back a buffer that's shared across all speakers (or just the channel for that speaker with a timestamp). The actual audio transfer probably gets buffered and only the relative timestamp and simple instructions like "play from this timestamp in the buffer" is actually being used to sync up between speakers. It's probably a limitation of the hardware or the lower-level wireless protocol (bluetooth or wifi) that causes that delay. I'm just speculating though, all of my realtime experience is in hard-realtime scientific control systems.

It's probably a mixture of things. Just tried some of mine with the sonos app and there's always a slight 1-2s delay on play and seeking. But actions like pausing or adjusting the volume are instant. I can pump the volume slider in tempo with the music and there has to be only a few ms of latency.

I'd hope so. One of those things (initiating music playback or seeking outside of the playback buffer) involves realtime sequential data transmission, and the other (modifying local settings or playback state remotely without leaving the buffer) is just a byte or two in a packet, if that.

It’s more than a byte or two — Sonos uses SOAP for RPC.

If you have a Sonos amp with an input plug, you can play that in near real time. There isn’t much buffering there. It’s low enough latency you can watch video and the lips looks like they match. There’s actually a setting where you can tell it the priority of the audio, which I assume just controls the buffer size.

It's not Sonos, but I use a few of these and they are amazing - https://www.amazon.com/Up2stream-amp-Bluetooth-2-0-Speaker-A...

Low latency, linkplay, HTTP API, you can join multiple of them together for whole home audio. Integrates into Home Assistant. Can play random URLs, can play spotify, airplay, etc. Wifi, ethernet, bluetooth.

By far the best product I've found. What I like the most is that it plays whatever I throw at it and I can turn any speaker into a smart speaker. It's also all local.

You should check the connections it makes. From the review of a sister product:

“Now for the bad news. In the last 24 hours my network security blocked: 6,936 calls to AMS ("The Cloud"); 9,523 calls to s000.linkplay.com, 6,050 calls to www.yahoo.com; 6,050 calls to www.microsoft.com; 9,650 calls to Amazon Technologies; 6,049 calls to Aliyun Computing - Beijing China;3,468 calls to Google; That was 94% of the attempted connections outside of LAN.”

Yeah that's if you want stuff like spotify to work and all the streaming sites.

You can block those from your router and keep it all local and play MP3s if you like (or air play)

I don't think blocking something is an accurate measure. Of course the box is going to retry if it got blocked the first time. What else would it do?

There’s no valid reason for something running in my home to be contacting a server in Beijing. Period.

I think you are not the target market for cloud services.

Companies often buy services based on cost. If the cost is less to get a server in Beijing, many will choose to get one there.

The country in which the server is located has little to do with the privacy or security posture of the service.

That makes zero sense to anyone who’s ever worked on hosting things in China.

Their Great Firewall makes it a no-go for practically everything and everyone. At the best of times the latency and packet loss are hideous, with abysmal throughput. And then you get cut off randomly for hours, days, or decades at a time on the whim of random CCP members with no recourse.

Paying them is a giant pain in the arse as well.

It is quite literally never the best option.

Hosting sites in Russian — in the middle the current war — would make more sense!

Are you okay with it contacting servers in the US? Other countries? If so, which? Where do you draw the line?

Personally, I run my smart home fully locally, but it's interesting to me to see the geographic location of the server emphasized so strongly.

Let's be realistic. We're in a complicated time.

If you're in the western world, you really should consider avoiding IoT devices that call home to Chinese servers. You could be turning yourself into a potential botnet member if things go geopolitically sideways by keeping these products on your network. If you have access to other networks from home, you're inviting access into those networks from a box that should only be there for streaming music.

Better if things don't call home at all, but second best is choosing western servers under control of western actors.

I hope that one day we no longer have to consider the political origin of servers our devices to call back to, but that's a few years away at least. In the meantime, devices that call back to noone are still the best.

I don't disagree with what you posted, but I find it naive to believe that a "western" server doesn't expose you to the same risk.

https://en.wikipedia.org/wiki/Room_641A

Same risk, different rule of law

* you could be turning yourself into a potential botnet member

wherever the server is

* you're inviting access into those networks

wherever the server is

Apparently those requests weren’t necessary for using the device, so arguably it shouldn’t do them without user consent in the first place, and certainly not retrying multi-thousand times per day. It just shows that data economy and privacy wasn’t a design consideration of the software, which should be a red flag.

I’ve been looking for a version of this with 2.1 for a passive subwoofer with bookshelf speakers. Everything I’ve seen is only two channels.

Unless maybe I set the sub as a second airplay or Bluetooth device and run one of these [1]? I’m not really sure how all of that works.

https://pimylifeup.com/raspberry-pi-airplay-receiver/

2.1 systems generally use powered subs, not passive subs.

For use with higher-quality bookshelf speakers, you can send the stereo line level signal to a 2-channel amp and pass the high-level speaker lines through your sub. I do this with Belkin AirPlay 2 receivers and it works well.

Not all subs have high-level passthrough though.

I'm building my own subwoofer, so I'm assuming you mean the sub has a plate amplifier in the back? Like this:

https://www.daytonaudio.com/product/776/sa70-70w-subwoofer-p...

Yes, exactly. And that plate amp has the passthrough I mentioned, which not all plate amps do.

This is amazing! For many years, I've been a happy customer (no other affiliation) of Rogue Amoeba, whose (closed-source, commercial) Airfoil software: https://rogueamoeba.com/airfoil/mac/ does all this & more (MacOS and iOS only). I've had a multi room audio setup with Airport Expresses and dumb powered M-Audio bookshelf speakers for the past 10 years going strong!

I love this project, but for folks who use MacOS and want something that simply works, I can't recommend Airfoil highly enough.

Do they license AirPlay from Apple? Or did they also reverse engineer the protocol?

Reverse engineered.

Apple doesn't have AirPlay licensing for software products, just for hardware.

+1 to airfoil, the only thing I wish they would do is reduce the pricetag and update the interface. Software works great though!

> […] Airfoil software does all this & more […]

Not quite; Airfoil Satellite does not implement an AirPlay 2 receiver which is what this is all about. See https://weblog.rogueamoeba.com/2018/06/25/current-notes-on-a... :

> Can Airfoil Satellite receive AirPlay 2 audio? Airfoil Satellite receives audio via the AirPlay 1 protocol. Because of this, it can’t currently be part of a multi-speaker group receiving audio from iOS.

Still a great piece of software (that I also can recommend).

Great to see some movement on that front.

shairport-sync had it long brewing, I think it's currently still in a dev branch but does work to some extent.

https://github.com/mikebrady/shairport-sync/issues/535#issue...

EDIT: details here https://github.com/mikebrady/shairport-sync/blob/development...

Adding on, the AirPlay 2 implementation by Shairport-sync works very well. I have approximately 6 different Rpis/thin clients around the house I use as AirPlay 2 receivers and can vouch for how well the system works. NQPTP is built by the same team.

shairport-sync also has the option to output to FIFO/stdout, which I couldn't see details of in this Open AirPlay 2 implementation. Indispensable for tying in to SnapCast!

Could you hypothetically run this on two different Pi’s, one for bookshelf and one for a separate sub, but synchronized?

I’m trying to avoid a bulky receiver and want something more custom, with the option to turn the sub off digitally.

> FairPlay (v3) authentication and decryption of AES keys - the first and only Python implementation. Credit to @systemcrash for implementation.

Damn... that took a lot longer to extract the keys that AirPlay 1 did. I'd love to know more about this story.

I often wonder how DRM systems obfuscate the keys. They must be in memory, right?

That's the point of all these TPM chips/subprocessors Apple and Microsoft are sticking into their computers. The key can stay on the TPM chip which does the decrpytion

If the key was extracted from the Secure Enclave, that's huge.

Probably not, there are a bunch of products out there that support Airplay 2 like LG and Samsung TVs that don’t have a Secure Enclave

I don't know they did it. But one approach I (badly) tried was to use the firmware image for the old AirPort Express that got AirPlay 2 support.

Someone had already extracted the key which was used to encrypt the firmware, so you could download the firmware from Apple and look at the unencrypted firmware blob.

Perhaps even boot it using something like QEMU? But I never got anywhere with that...

FWIW, a number of other AirPlay 2 repos that I have been tracking:

* https://github.com/openairplay/goplay2

* https://github.com/openairplay/airplay2-receiver

I've been using shairport-sync to receive audio from my iPad while working. It has proven a really convenient means to turn my iPad into a 2nd display for watching videos. I've been wanting to use this on Windows as well but had no luck getting sound to work with WSL last time I tried.

This new app looks like a promising cross-platform replacement.

For all the audiophiles out there, M1 Mac Mini is an incredible digital player. You can basically play lossless audio over iTune/Apple Music and it’s well-integrated with the rest of the Apple ecosystem.

I’m having a great time with my Apple TV 4K -> Topping E30 -> Aiyima A07 -> Wharfedale 4.1s. Only thing lacking is more power/bass but I can’t get past 2/10 volume without annoying the neighbours anyway.

Install Roon on it

Also see https://github.com/badaix/snapcast which also supports AirPlay: https://github.com/badaix/snapcast/blob/master/doc/player_se...

This is why I will replace my phone with an iPhone. The chromecast protocols are so locked down, it makes casting really suck, and chromecast audio pucks are no more.

Chromecast works differently. Casting something causes the receiving device to load a web app that then plays whatever you were playing. Yes, that tiny thing actually runs a cut-down version of Chrome OS. In other words, it's not merely an audio/video streaming protocol. Your phone/computer acts as a remote, and it's the Chromecast itself that does the streaming.

That's only for apps that support doing that, though, like Netflix, YouTube, Spotify, Twitch, etc. If you're casting a game or something that's local content, then it will obviously still stream it directly.

AirPlay does this for some apps as well.

Arguably, this is about just as locked down.

Aside from specialty DoD-type phones, iPhones (and Apple devices in general) are the most locked down devices on the market. You can't even install an open source app without going through hoops. On Android you download the APK and click the "accept risk" button.

This was not about the devices, but the protocol.

Does this play the AP2 audio directly? Or is it possible to redirect that to an HTTP stream?

It plays directly. It is possible to capture the audio data directly with a little hacking. For instance, something like

    with open("data.dat", "ab") as f:
        f.write(frame.planes[0].to_bytes())

in Audio's process() does indeed dump out the captured data to something that can be replayed.

Can you elaborate on the PTP requirement part of the next steps?

How does one get this to run on an Android TV?

Can't wait to have this in Kodi!

If only I could get my airport expresses to stay connected to my wifi. When they do, the multiroom audio is magic.

Reply on news.ycombinator.com