Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Stereo HomePods show as two devices and switch playback between eachother. #1291

Closed
shauder opened this issue Aug 4, 2021 · 74 comments
Closed

Comments

@shauder
Copy link

shauder commented Aug 4, 2021

Version: 28.1
Platform: Same problems when running from my x86_64 Arch box running in docker and my Raspberry Pi4 also running in docker

I have 4 stereo pair OG HomePods and when I try and use this it discovers them all individually and it also discovers them and assigns them AirPlay1 instead of AirPlay2, which I can see it doing in the logs.

If I start music and then I select one of the HomePods in a stereo pair then it will play through the one HomePod. When I select the second one in the pair then it will start switching back and forth between the two in the pair automatically.

I unpaired them and then I was able to select both of them and stream to them, then I paired them back and I am back to the same behavior. I captured lots of debug logs with all the steps I talked about above.

owntone.log

@shauder shauder changed the title HomePods Recognized as AirPlay1 and not Airplay2 Stereo HomePods show as two devices and switch playback between eachother. Aug 5, 2021
@shauder
Copy link
Author

shauder commented Aug 5, 2021

I compiled the latest version from source and I edited the config to force two HomePods to use AirPlay2 instead. I can see they are added as AirPlay2 now but they still show as two devices. When I select both of them in the UI before playing a song they appear to be selected. Once I start playback it looks like it drops both of them and then starts playback on one of the pair. This seems to play out of the one speaker until I try and enable the second one. After that it will continue to switch back and forth between the two every couple of seconds. I uploaded a new log from the version compiled from master and my doing what I described above.
owntone.log

@ejurgensen
Copy link
Member

Thanks for reporting this and sharing logs. I had a look at them, and they show that the speakers are disconnecting quickly after the playback session is started. Owntone perceives this as a connection failure and then tries to restart the session, which results in the switching back and forth that you experience.

It is interesting that this also seems to happen with Airplay 1, which to my knowledge doesn't have the concept of grouped speakers. If you have a Windows PC I would like to hear if iTunes works better? I think iTunes also still only has Airplay 1.

I can't offer much with regard to actually solving the issue. It seems like starting playback in this scenario needs to be done in a specific way, but since I don't even have a single Homepod I won't be able to pursue this.

@shauder
Copy link
Author

shauder commented Aug 5, 2021

Yeah I definitely understand and I have actually been following this and Shairport-sync for some time to keep up with the progress of AirPlay2.

While I love these, it's been frustrating because macOS (until BETA Monterey now finally) doesn't even list the pairs as a single destination. The only app that did was the Music app, but now in Monterey you can finally select a stereo pair as an output for all system sounds.

I never messed with iTunes on Windows but I just fired it up and it also lists them as individual HomePods instead of grouping them. It actually can't even find or populate all of my AirPlay devices and most of them are missing and it changes which ones it shows every song I play lol.

With Monterey finally showing them as a single target (and working) for system wide sound, do you think there is networking traffic/logs I can capture on my Macbook that may help?

@shauder
Copy link
Author

shauder commented Aug 5, 2021

I installed Wireshark on my M1 MPB on the beta and captured logs for my selecting the stereo pair as an output and successfully playing a YouTube video, changing the volume, then pausing it by touching the HomePod. Do you think this would be useful for me to send to you?

@aleszczynskig
Copy link

aleszczynskig commented Aug 6, 2021

Hi.

The latest versions of Mac OS do support HomePod stereo pairs natively outside of the music app. You do not need the beta version of Monterey. Which version of Mac OS are you running?

@shauder
Copy link
Author

shauder commented Aug 6, 2021

I am using Monterey, I don't have anything on Big Sur and maybe I just didn't notice the short time I was on Big Sur but that is good to know. I know it was not like that on Catalina.

@ejurgensen
Copy link
Member

Do you think this would be useful for me to send to you?

I don't think so. The captures would be encrypted, and capturing in cleartext is complicated.

One thing you might try is disabling ipv6 in owntone.conf, just to see if it makes a difference.

@shauder
Copy link
Author

shauder commented Aug 8, 2021

Thanks for a reply. I tried IPv6 disabled and it seems to behave the same way it has been. I also tried out AirFoil since they support AirPlay2 now but they also show all the homepods individually so they also do not support stereo homepods. Might have to try and come up with another solution until someone figures out how to detect and send audio to them as "one" device.

@aleszczynskig
Copy link

I don't think Airfoil supports Airplay 2 at least they don't advertise it that way. Airfoil supports streaming to multiple HomePods in sync but this is using AirPlay 1 the same way that Owntone does it.

I would be happy to be corrected as that would be a big feature for Airfoil.

@aleszczynskig
Copy link

FYI. I use a pair of Homepods in a stereo pair, actually they are also paired with an Apple TV, and I am able to use them as a stereo pair when using Airplay 2 from iOS/macOS or watching anything on my Apple TV and also when using Owntone when they are both selected as separate outputs. I do this everyday and have never experienced this issue. Is it worth trying to reset your HomePods?

@shauder
Copy link
Author

shauder commented Aug 8, 2021

Yeah I guess they say that they support sending to AirPlay2 devices but not that they are using AirPlay2, so I think you are right. I can maybe try resetting one pair of HomePods but I get this behavior for all 4 of my stereo pairs. It could be that they are on the beta audioOS that causes them to behave differently.

One of my pairs is also paired with the latest 4k AppleTV with ARC enabled and I do not have any success with that pair either. I don't have any issues using them with any Apple device to send audio, just been trying to find something to control them within Home Assistant.

@aleszczynskig
Copy link

aleszczynskig commented Aug 9, 2021

That is interesting. I would hedge my bets that it's because of the beta versions.

Did this work successfully on the last production release? I am all up to date on production versions and haven't had the issue as I mentioned.

It's concerning though. I hope this is fixed in the next beta if this turns out to be the root cause.

@shauder
Copy link
Author

shauder commented Aug 9, 2021

Unfortunately the last time I tried forked-dappd was over a year ago, I know it didn't work great with them either but I cannot remember the specifics. I do not use OwnTone normally, was just taking another look again since AirPlay2 has been somewhat hacked/implemented. I'd be willing to send a pair of mini's to anyone that is willing to figure it out but not expecting anyone to do it =D. I'll see if I can make some time to completely wipe a pair and see if it makes any difference. Would be nice to at least have audio coming out of both and stop switching back and forth lol.

@shauder
Copy link
Author

shauder commented Aug 9, 2021

I went ahead and reset one pair and then added them back into HomeKit as a stereo pair and I still have the same behavior. They are still on the beta versions since the reset does not revert the version they are on.

@aleszczynskig
Copy link

If you break the stereo pair (just for testing) are you able to play to both devices simultaneously from Owntone?

@shauder
Copy link
Author

shauder commented Aug 10, 2021

Yeah, if I break the pair then they work just fine being both selected.

@aleszczynskig
Copy link

Hmmm. I'm out of ideas then. Hopefully it will be fixed in the next beta.

@snoopbird
Copy link

Don't update to HomePod 15. I have now the same Problem...

@shauder
Copy link
Author

shauder commented Sep 21, 2021

Yeah I have been on the developer beta so that answers my previous questions that it was because of audioOS 15. I installed it when it first came out before I tried owntone.

@aleszczynskig
Copy link

Very annoyingly my HomePods have auto updated to HomePod 15 overnight and I have the same problem. I will calling Apple as I am super unhappy about this.

@aleszczynskig
Copy link

@ejurgensen - is there anything we can do to try and investigate this further, even if very complicated. Unfortunately this HomePod update has completely broken my home setup and I'm very keen to try and resolve it.

Thanks

@ejurgensen
Copy link
Member

Sorry to hear about this, for starters I will reopen the issue.

Just to make sure I understand: The issue here is that when two Homepods are grouped, but are selected individually in Owntone, playback is switching back and forth, right? And is it so that if only one Homepod is selected it plays normally?

I think the path to solving this would be to analyze a working configuration, e.g. when an Apple device is acting as sender. Historically, iTunes has been the go-to reference sender, but I understand from @shauder that that won't work here. Is there another sender that is able to play where each HomePod is selected individually?

It is not directly possible to analyze the traffic with Wireshark, since it is encrypted, but it is possible to do it by running a "proxy" that pretends to be a speaker but in fact transciphers and forwards traffic to/from the actual HomePods. So in this case traffic could be analyzed by setting up two such proxies. It is, however, pretty tricky, because the proxy does not fully work as a HomePod. And as mentioned the basis must be a working configuration, which I at least don't have.

If there are no senders that can send with speakers selected individually, but only to the group, then it is even more complicated, because the proxy is not able to act as a group. Thus it would be necessary to first figure out how groups even work, and then modify the proxy to take that role.

@ejurgensen ejurgensen reopened this Sep 24, 2021
@aleszczynskig
Copy link

aleszczynskig commented Sep 24, 2021

@ejurgensen - thank you for your response and reopening the issue. I have done some further investigation this evening and have documented my findings below, but first here is my setup.

I have two HomePods running HomePodOS 15, they are stereo paired and also paired to my Apple TV 4K (the latest one) as the default output. At present my AppleTV is running OS 14.7. Playback on the AppleTV and from an iOS device using Airplay2 seems to work perfectly.

I also have a raspberry pi 3 running raspbian os and the latest version of Owntone specified from your repo. I use Owntone to play internet radio streams to both HomePods (selected as top separate output devices) as well as hosting my ripped CD collection and assessing Spotify. This had been working perfectly until the HomePods updated yesterday. The behaviour I get is as follows.

When selected a new radio station and selecting both HomePods I initially get no sound and the owntone log (set to INFO debug level) shows the following outputs.

Sep 24 21:21:15 music-pi owntone[13633]: [2021-09-24 21:21:15] [ INFO] airplay: Setting up AirPlay session 3241451419 (192.168.1.231 -> 192.168.1.170)
Sep 24 21:21:15 music-pi owntone[13633]: [2021-09-24 21:21:15] [ INFO] airplay: Setting up AirPlay session 345110158 (192.168.1.231 -> 192.168.1.171)
Sep 24 21:21:15 music-pi owntone[13633]: [2021-09-24 21:21:15] [ LOG] airplay: Device 'Living Room Right' closed RTSP connection
Sep 24 21:21:15 music-pi owntone[13633]: [2021-09-24 21:21:15] [ WARN] player: The AirPlay 2 device 'Living Room Right' failed
Sep 24 21:21:15 music-pi owntone[13633]: [2021-09-24 21:21:15] [ LOG] airplay: Device 'Living Room Left' closed RTSP connection
Sep 24 21:21:15 music-pi owntone[13633]: [2021-09-24 21:21:15] [ WARN] player: The AirPlay 2 device 'Living Room Left' failed
Sep 24 21:21:17 music-pi owntone[13633]: [2021-09-24 21:21:17] [ INFO] airplay: Adding AirPlay device 'Living Room Left': features 0x4A7FCA00,0xBC354BD0, type HomePod, address 192.168.1.171:7000
Sep 24 21:21:17 music-pi owntone[13633]: [2021-09-24 21:21:17] [ INFO] airplay: Adding AirPlay device 'Living Room Right': features 0x4A7FCA00,0xBC354BD0, type HomePod, address 192.168.1.170:7000
Sep 24 21:21:17 music-pi owntone[13633]: [2021-09-24 21:21:17] [ INFO] raop: Disabling AirPlay 1 (RAOP) for device 'Living Room Right' as set in config
Sep 24 21:21:17 music-pi owntone[13633]: [2021-09-24 21:21:17] [ INFO] raop: Disabling AirPlay 1 (RAOP) for device 'Living Room Left' as set in config
Sep 24 21:21:19 music-pi owntone[13633]: [2021-09-24 21:21:19] [ INFO] airplay: Adding AirPlay device 'Living Room Left': features 0x4A7FCA00,0xBC354BD0, type HomePod, address 192.168.1.171:7000
Sep 24 21:21:19 music-pi owntone[13633]: [2021-09-24 21:21:19] [ INFO] raop: Disabling AirPlay 1 (RAOP) for device 'Living Room Left' as set in config
Sep 24 21:21:20 music-pi owntone[13633]: [2021-09-24 21:21:20] [ INFO] raop: Disabling AirPlay 1 (RAOP) for device 'Living Room Right' as set in config
Sep 24 21:21:20 music-pi owntone[13633]: [2021-09-24 21:21:20] [ INFO] airplay: Adding AirPlay device 'Living Room Right': features 0x4A7FCA00,0xBC354BD0, type HomePod, address 192.168.1.170:7000
Sep 24 21:21:42 music-pi owntone[13633]: [2021-09-24 21:21:42] [ INFO] airplay: Setting up AirPlay session 4225861207 (192.168.1.231 -> 192.168.1.171)
Sep 24 21:21:42 music-pi owntone[13633]: [2021-09-24 21:21:42] [ INFO] airplay: Setting up AirPlay session 3086203240 (192.168.1.231 -> 192.168.1.170)
Sep 24 21:21:42 music-pi owntone[13633]: [2021-09-24 21:21:42] [ WARN] airplay: Response to SET_PARAMETER (volume) from 'Living Room Right' was negative, proceeding anyway (0 (null))
Sep 24 21:21:42 music-pi owntone[13633]: [2021-09-24 21:21:42] [ LOG] airplay: Device 'Living Room Right' closed RTSP connection
Sep 24 21:21:42 music-pi owntone[13633]: [2021-09-24 21:21:42] [ WARN] player: The AirPlay 2 device 'Living Room Right' failed
Sep 24 21:21:42 music-pi owntone[13633]: [2021-09-24 21:21:42] [ LOG] airplay: Device 'Living Room Left' closed RTSP connection
Sep 24 21:21:42 music-pi owntone[13633]: [2021-09-24 21:21:42] [ WARN] player: The AirPlay 2 device 'Living Room Left' failed
Sep 24 21:21:44 music-pi owntone[13633]: [2021-09-24 21:21:44] [ INFO] airplay: Adding AirPlay device 'Living Room Left': features 0x4A7FCA00,0xBC354BD0, type HomePod, address 192.168.1.171:7000
Sep 24 21:21:47 music-pi owntone[13633]: [2021-09-24 21:21:47] [ INFO] airplay: Adding AirPlay device 'Living Room Left': features 0x4A7FCA00,0xBC354BD0, type HomePod, address 192.168.1.171:7000
Sep 24 21:21:51 music-pi owntone[13633]: [2021-09-24 21:21:51] [ INFO] airplay: Setting up AirPlay session 355842199 (192.168.1.231 -> 192.168.1.171)
Sep 24 21:21:51 music-pi owntone[13633]: [2021-09-24 21:21:51] [ INFO] airplay: Setting up AirPlay session 1290396328 (192.168.1.231 -> 192.168.1.170)
Sep 24 21:21:51 music-pi owntone[13633]: [2021-09-24 21:21:51] [ LOG] airplay: Device 'Living Room Right' closed RTSP connection
Sep 24 21:21:51 music-pi owntone[13633]: [2021-09-24 21:21:51] [ WARN] player: The AirPlay 2 device 'Living Room Right' failed
Sep 24 21:21:51 music-pi owntone[13633]: [2021-09-24 21:21:51] [ LOG] airplay: Device 'Living Room Left' closed RTSP connection
Sep 24 21:21:51 music-pi owntone[13633]: [2021-09-24 21:21:51] [ WARN] player: The AirPlay 2 device 'Living Room Left' failed
Sep 24 21:21:53 music-pi owntone[13633]: [2021-09-24 21:21:53] [ INFO] airplay: Adding AirPlay device 'Living Room Right': features 0x4A7FCA00,0xBC354BD0, type HomePod, address 192.168.1.170:7000
Sep 24 21:21:53 music-pi owntone[13633]: [2021-09-24 21:21:53] [ INFO] raop: Disabling AirPlay 1 (RAOP) for device 'Living Room Right' as set in config
Sep 24 21:21:54 music-pi owntone[13633]: [2021-09-24 21:21:54] [ INFO] raop: Disabling AirPlay 1 (RAOP) for device 'Living Room Left' as set in config
Sep 24 21:21:54 music-pi owntone[13633]: [2021-09-24 21:21:54] [ INFO] airplay: Adding AirPlay device 'Living Room Left': features 0x4A7FCA00,0xBC354BD0, type HomePod, address 192.168.1.171:7000
Sep 24 21:21:55 music-pi owntone[13633]: [2021-09-24 21:21:55] [ INFO] airplay: Adding AirPlay device 'Living Room Right': features 0x4A7FCA00,0xBC354BD0, type HomePod, address 192.168.1.170:7000
Sep 24 21:21:55 music-pi owntone[13633]: [2021-09-24 21:21:55] [ INFO] raop: Disabling AirPlay 1 (RAOP) for device 'Living Room Right' as set in config
Sep 24 21:22:04 music-pi owntone[13633]: [2021-09-24 21:22:04] [ INFO] airplay: Adding AirPlay device 'Living Room Left': features 0x4A7FCA00,0xBC354BD0, type HomePod, address 192.168.1.171:7000
Sep 24 21:22:04 music-pi owntone[13633]: [2021-09-24 21:22:04] [ INFO] raop: Disabling AirPlay 1 (RAOP) for device 'Living Room Left' as set in config
Sep 24 21:22:04 music-pi owntone[13633]: [2021-09-24 21:22:04] [ INFO] airplay: Setting up AirPlay session 26748416 (192.168.1.231 -> 192.168.1.171)
Sep 24 21:22:04 music-pi owntone[13633]: [2021-09-24 21:22:04] [ LOG] airplay: Response to SETUP (stream) from 'Living Room Right' was negative, aborting (0 (null))
Sep 24 21:22:04 music-pi owntone[13633]: [2021-09-24 21:22:04] [ LOG] player: The AirPlay 2 device 'Living Room Right' failed to activate

Eventually however I do get audio playing consistently but only from one of the HomePods.

I have done some testing this evening using iTunes for Windows 12.8 in a Windows 11 Parallels VM running on my M1 MacBook and the behaviour from iTunes is exactly the same despite selecting both HomePods on the output. This leads me to believe this is purely a HomePod OS issue as Apple have broken their own product with this update. So I guess the best option will be to raise a ticket with Apple to try and get them to look into it.

Having said this, I am still willing to try and investigate this in the unlikely event that we can resolve it.

In response to your questions above.

Just to make sure I understand: The issue here is that when two Homepods are grouped, but are selected individually in Owntone, playback is switching back and forth, right? And is it so that if only one Homepod is selected it plays normally?

Yes, it is correct that when I select the second HomePod from the Owntone UI, the audio stream switches away from the already selected HomePod to the newly selected device. Yes, it appears to work correctly if only 1 HomePod is selected.

@raufis27
Copy link

I have the same problem after upgrading to 15 :(

@shauder
Copy link
Author

shauder commented Sep 28, 2021

@ejurgensen if you by chance can provide some guidance I can probably set something up to capture what is needed if it's possible. I am in the middle of moving but this weekend I could sit down and see what I can do.

If you have not seen it, there is also this with lots of AirPlay2 examples.

@aleszczynskig
Copy link

@shauder - is there a link missing from your previous post?

@shauder
Copy link
Author

shauder commented Sep 28, 2021

@ma-ku
Copy link

ma-ku commented Jan 30, 2022

HI @ejurgensen, i collected the information and stripped the other devices.

  • "Links"/"Rechts" are the Big HomePods, forming a stereo group in room "Büro 2"
  • "KLinks"/"KRechts are the HomePod Minis in room "Büroküche"

Here the dump (hope I do not disclose anything sensitive):

+  wlan0 IPv6 KRechts                                       _airplay._tcp        local
+  wlan0 IPv6 KLinks                                        _airplay._tcp        local
+  wlan0 IPv6 Links                                         _airplay._tcp        local
+  wlan0 IPv6 Rechts                                        _airplay._tcp        local
+  wlan0 IPv4 KLinks                                        _airplay._tcp        local
+  wlan0 IPv4 KRechts                                       _airplay._tcp        local
+  wlan0 IPv4 Links                                         _airplay._tcp        local
+  wlan0 IPv4 Rechts                                        _airplay._tcp        local

=  wlan0 IPv6 KRechts                                       _airplay._tcp        local
   hostname = [KRechts.local]
   address = [192.168.178.49]
   port = [7000]
   txt = ["vv=2" "osvers=15.3" "srcvers=605.1" "pk=ec12c623fbcc82ba197fd77714bbfff63045b13482487e8a5ffda60bef6148ef" "psi=A683442A-A5B4-44FB-ADBF-136625DF40AC" "pi=7ee13959-a6df-48e3-a38b-7fff4fdca20c" "protovers=1.1" "model=AudioAccessory5,1" "tsm=1" "tsid=E6BA6732-F25E-5687-BDBC-558FBA5F76ED" "gpn=Büroküche" "gcgl=1" "igl=1" "gid=E6BA6732-F25E-5687-BDBC-558FBA5F76ED" "flags=0x1a404" "features=0x4A7FCA00,0xBC356BD0" "fex=AMp/StBrNbw" "deviceid=E0:2B:96:96:FB:77" "btaddr=6F:1F:F4:F2:C6:98" "acl=0"]
=  wlan0 IPv6 KLinks                                        _airplay._tcp        local
   hostname = [KLinks.local]
   address = [192.168.178.41]
   port = [7000]
   txt = ["vv=2" "osvers=15.3" "srcvers=605.1" "pk=5a14d439edf3ad0926f0c96c3059be33861df97c6f72380ab54ea18478e425c0" "psi=7E5AF368-C056-43BF-953B-7C7EA3B9D27F" "pi=01c6816f-3347-4ddd-8cab-e6a735c9b5a9" "protovers=1.1" "model=AudioAccessory5,1" "tsm=1" "tsid=E6BA6732-F25E-5687-BDBC-558FBA5F76ED" "gpn=Büroküche" "gcgl=1" "igl=1" "gid=E6BA6732-F25E-5687-BDBC-558FBA5F76ED" "flags=0x18404" "features=0x4A7FCA00,0xBC356BD0" "fex=AMp/StBrNbw" "deviceid=E0:2B:96:89:74:9C" "btaddr=59:C6:BA:90:C0:D8" "acl=0"]

=  wlan0 IPv6 Links                                         _airplay._tcp        local
   hostname = [Links.local]
   address = [192.168.178.46]
   port = [7000]
   txt = ["vv=2" "osvers=15.4" "srcvers=610.14.1" "pk=40e4f71d4e7153f65b5b906e5c2e5a0011b89dd1b5bf598e939fae406e7d34f0" "psi=3CF62C5C-9249-47F0-98A7-6FA451CA53B1" "pi=3af67dea-4913-441e-898f-0ae9e675ab4a" "protovers=1.1" "model=AudioAccessory1,1" "tsm=0" "tsid=EAFA36AA-9785-54B2-A537-D9EE2A55CF1C" "gpn=Büro 2" "gcgl=1" "igl=1" "gid=EAFA36AA-9785-54B2-A537-D9EE2A55CF1C+0+CCDE6117-686A-4C46-8123-432044A6743C" "flags=0x9a404" "features=0x4A7FCA00,0xBC354BD0" "fex=AMp/StBLNbw" "deviceid=D4:A3:3D:7A:28:D8" "btaddr=42:60:B7:8E:D1:7E" "acl=0"]
=  wlan0 IPv6 Rechts                                        _airplay._tcp        local
   hostname = [Rechts.local]
   address = [192.168.178.56]
   port = [7000]
   txt = ["vv=2" "osvers=15.4" "srcvers=610.14.1" "pk=44398512772475964d6156e8a68485325ae773ee23a4698239412b3b407bedef" "psi=85195D3E-AA83-4C5C-A20E-CD309C8C33AD" "pi=0d39b4ce-fd53-4203-b272-efa6fc68d825" "protovers=1.1" "model=AudioAccessory1,1" "tsm=0" "tsid=EAFA36AA-9785-54B2-A537-D9EE2A55CF1C" "gpn=Büro 2" "gcgl=1" "igl=1" "gid=EAFA36AA-9785-54B2-A537-D9EE2A55CF1C+1+ACE6D9D3-CD97-40A9-B3E4-1924E0649F44" "flags=0x98404" "features=0x4A7FCA00,0xBC354BD0" "fex=AMp/StBLNbw" "deviceid=50:BC:96:07:E8:6D" "btaddr=4D:F0:4A:C6:75:F4" "acl=0"]

=  wlan0 IPv4 KLinks                                        _airplay._tcp        local
   hostname = [KLinks.local]
   address = [192.168.178.41]
   port = [7000]
   txt = ["vv=2" "osvers=15.3" "srcvers=605.1" "pk=5a14d439edf3ad0926f0c96c3059be33861df97c6f72380ab54ea18478e425c0" "psi=7E5AF368-C056-43BF-953B-7C7EA3B9D27F" "pi=01c6816f-3347-4ddd-8cab-e6a735c9b5a9" "protovers=1.1" "model=AudioAccessory5,1" "tsm=1" "tsid=E6BA6732-F25E-5687-BDBC-558FBA5F76ED" "gpn=Büroküche" "gcgl=1" "igl=1" "gid=E6BA6732-F25E-5687-BDBC-558FBA5F76ED" "flags=0x18404" "features=0x4A7FCA00,0xBC356BD0" "fex=AMp/StBrNbw" "deviceid=E0:2B:96:89:74:9C" "btaddr=59:C6:BA:90:C0:D8" "acl=0"]
=  wlan0 IPv4 KRechts                                       _airplay._tcp        local
   hostname = [KRechts.local]
   address = [192.168.178.49]
   port = [7000]
   txt = ["vv=2" "osvers=15.3" "srcvers=605.1" "pk=ec12c623fbcc82ba197fd77714bbfff63045b13482487e8a5ffda60bef6148ef" "psi=A683442A-A5B4-44FB-ADBF-136625DF40AC" "pi=7ee13959-a6df-48e3-a38b-7fff4fdca20c" "protovers=1.1" "model=AudioAccessory5,1" "tsm=1" "tsid=E6BA6732-F25E-5687-BDBC-558FBA5F76ED" "gpn=Büroküche" "gcgl=1" "igl=1" "gid=E6BA6732-F25E-5687-BDBC-558FBA5F76ED" "flags=0x1a404" "features=0x4A7FCA00,0xBC356BD0" "fex=AMp/StBrNbw" "deviceid=E0:2B:96:96:FB:77" "btaddr=6F:1F:F4:F2:C6:98" "acl=0"]

=  wlan0 IPv4 Links                                         _airplay._tcp        local
   hostname = [Links.local]
   address = [192.168.178.46]
   port = [7000]
   txt = ["vv=2" "osvers=15.4" "srcvers=610.14.1" "pk=40e4f71d4e7153f65b5b906e5c2e5a0011b89dd1b5bf598e939fae406e7d34f0" "psi=3CF62C5C-9249-47F0-98A7-6FA451CA53B1" "pi=3af67dea-4913-441e-898f-0ae9e675ab4a" "protovers=1.1" "model=AudioAccessory1,1" "tsm=0" "tsid=EAFA36AA-9785-54B2-A537-D9EE2A55CF1C" "gpn=Büro 2" "gcgl=1" "igl=1" "gid=EAFA36AA-9785-54B2-A537-D9EE2A55CF1C+0+CCDE6117-686A-4C46-8123-432044A6743C" "flags=0x9a404" "features=0x4A7FCA00,0xBC354BD0" "fex=AMp/StBLNbw" "deviceid=D4:A3:3D:7A:28:D8" "btaddr=42:60:B7:8E:D1:7E" "acl=0"]
=  wlan0 IPv4 Rechts                                        _airplay._tcp        local
   hostname = [Rechts.local]
   address = [192.168.178.56]
   port = [7000]
   txt = ["vv=2" "osvers=15.4" "srcvers=610.14.1" "pk=44398512772475964d6156e8a68485325ae773ee23a4698239412b3b407bedef" "psi=85195D3E-AA83-4C5C-A20E-CD309C8C33AD" "pi=0d39b4ce-fd53-4203-b272-efa6fc68d825" "protovers=1.1" "model=AudioAccessory1,1" "tsm=0" "tsid=EAFA36AA-9785-54B2-A537-D9EE2A55CF1C" "gpn=Büro 2" "gcgl=1" "igl=1" "gid=EAFA36AA-9785-54B2-A537-D9EE2A55CF1C+1+ACE6D9D3-CD97-40A9-B3E4-1924E0649F44" "flags=0x98404" "features=0x4A7FCA00,0xBC354BD0" "fex=AMp/StBLNbw" "deviceid=50:BC:96:07:E8:6D" "btaddr=4D:F0:4A:C6:75:F4" "acl=0"]

@ma-ku
Copy link

ma-ku commented Jan 30, 2022

Just for the sake of completeness, the following records are for two airplay2-receiver instances that show up as a stereo pair in iOS and macOS:

=  wlan0 IPv4 myap2-rechts                                  _airplay._tcp        local
   hostname = [001c421af59b\064myap2-rechts._airplay.local]
   address = [192.168.178.138]
   port = [7000]
   txt = ["igl=1" "tsid=5dccfd20-b166-49cc-a593-6abd5f724ddb" "vv=2" "tsm=0" "gpn=Airplay Test" "sf=0x20004" "pk=aabffef7b8c9d819ca925d67c8d8d58816cbb016a465a4de53a9993ae16268fe" "pi=aa5cb8df-7f14-4249-901a-5e748ce57a91" "cn=0,1,2" "ch=2" "srcvers=366.0" "rsf=0x0" "protovers=1.1" "name=myap2-rechts" "model=Airplay2-Receiver" "gid=5dccfd20-b166-49cc-a593-6abd5f724ddb" "gcgl=1" "flags=0x1a404" "features=0x405f4200,0x1c300" "deviceid=00:1c:42:1a:f5:9b" "acl=0"]
=  wlan0 IPv4 myap2-links                                   _airplay._tcp        local
   hostname = [001c42fc9fcc\064myap2-links._airplay.local]
   address = [192.168.178.142]
   port = [7000]
   txt = ["pgid=5dccfd20-b166-49cc-a593-6abd5f724ddb" "pgcgl=1" "igl=0" "tsid=5dccfd20-b166-49cc-a593-6abd5f724ddb" "vv=2" "tsm=0" "gpn=Airplay Test" "sf=0x20004" "pk=cf73ae9bd8bc69202582058ee468e214dfc61ced1eb9a3fe3fd1f7cef71e74d3" "pi=aa5cb8df-7f13-4249-901a-5e758ce57a9" "cn=0,1,2" "ch=2" "srcvers=366.0" "rsf=0x0" "protovers=1.1" "name=myap2-links" "model=Airplay2-Receiver" "gid=5dccfd20-b166-49cc-a593-6abd5f724ddb" "gcgl=1" "flags=0x38c04" "features=0x405f4200,0x1c300" "deviceid=00:1c:42:fc:9f:cc" "acl=0"]

Playback from owntone also works fine.

@aleszczynskig
Copy link

I'm a little confused. Do people have this working with 15.3? I was working on the assumption that the fix from Apple was in 15.4 whenever that maybe released.

@aleszczynskig
Copy link

aleszczynskig commented Jan 30, 2022

HI @ejurgensen, i collected the information and stripped the other devices.

  • "Links"/"Rechts" are the Big HomePods, forming a stereo group in room "Büro 2"

  • "KLinks"/"KRechts are the HomePod Minis in room "Büroküche"

Here the dump (hope I do not disclose anything sensitive):


+  wlan0 IPv6 KRechts                                       _airplay._tcp        local

+  wlan0 IPv6 KLinks                                        _airplay._tcp        local

+  wlan0 IPv6 Links                                         _airplay._tcp        local

+  wlan0 IPv6 Rechts                                        _airplay._tcp        local

+  wlan0 IPv4 KLinks                                        _airplay._tcp        local

+  wlan0 IPv4 KRechts                                       _airplay._tcp        local

+  wlan0 IPv4 Links                                         _airplay._tcp        local

+  wlan0 IPv4 Rechts                                        _airplay._tcp        local



=  wlan0 IPv6 KRechts                                       _airplay._tcp        local

   hostname = [KRechts.local]

   address = [192.168.178.49]

   port = [7000]

   txt = ["vv=2" "osvers=15.3" "srcvers=605.1" "pk=ec12c623fbcc82ba197fd77714bbfff63045b13482487e8a5ffda60bef6148ef" "psi=A683442A-A5B4-44FB-ADBF-136625DF40AC" "pi=7ee13959-a6df-48e3-a38b-7fff4fdca20c" "protovers=1.1" "model=AudioAccessory5,1" "tsm=1" "tsid=E6BA6732-F25E-5687-BDBC-558FBA5F76ED" "gpn=Büroküche" "gcgl=1" "igl=1" "gid=E6BA6732-F25E-5687-BDBC-558FBA5F76ED" "flags=0x1a404" "features=0x4A7FCA00,0xBC356BD0" "fex=AMp/StBrNbw" "deviceid=E0:2B:96:96:FB:77" "btaddr=6F:1F:F4:F2:C6:98" "acl=0"]

=  wlan0 IPv6 KLinks                                        _airplay._tcp        local

   hostname = [KLinks.local]

   address = [192.168.178.41]

   port = [7000]

   txt = ["vv=2" "osvers=15.3" "srcvers=605.1" "pk=5a14d439edf3ad0926f0c96c3059be33861df97c6f72380ab54ea18478e425c0" "psi=7E5AF368-C056-43BF-953B-7C7EA3B9D27F" "pi=01c6816f-3347-4ddd-8cab-e6a735c9b5a9" "protovers=1.1" "model=AudioAccessory5,1" "tsm=1" "tsid=E6BA6732-F25E-5687-BDBC-558FBA5F76ED" "gpn=Büroküche" "gcgl=1" "igl=1" "gid=E6BA6732-F25E-5687-BDBC-558FBA5F76ED" "flags=0x18404" "features=0x4A7FCA00,0xBC356BD0" "fex=AMp/StBrNbw" "deviceid=E0:2B:96:89:74:9C" "btaddr=59:C6:BA:90:C0:D8" "acl=0"]



=  wlan0 IPv6 Links                                         _airplay._tcp        local

   hostname = [Links.local]

   address = [192.168.178.46]

   port = [7000]

   txt = ["vv=2" "osvers=15.4" "srcvers=610.14.1" "pk=40e4f71d4e7153f65b5b906e5c2e5a0011b89dd1b5bf598e939fae406e7d34f0" "psi=3CF62C5C-9249-47F0-98A7-6FA451CA53B1" "pi=3af67dea-4913-441e-898f-0ae9e675ab4a" "protovers=1.1" "model=AudioAccessory1,1" "tsm=0" "tsid=EAFA36AA-9785-54B2-A537-D9EE2A55CF1C" "gpn=Büro 2" "gcgl=1" "igl=1" "gid=EAFA36AA-9785-54B2-A537-D9EE2A55CF1C+0+CCDE6117-686A-4C46-8123-432044A6743C" "flags=0x9a404" "features=0x4A7FCA00,0xBC354BD0" "fex=AMp/StBLNbw" "deviceid=D4:A3:3D:7A:28:D8" "btaddr=42:60:B7:8E:D1:7E" "acl=0"]

=  wlan0 IPv6 Rechts                                        _airplay._tcp        local

   hostname = [Rechts.local]

   address = [192.168.178.56]

   port = [7000]

   txt = ["vv=2" "osvers=15.4" "srcvers=610.14.1" "pk=44398512772475964d6156e8a68485325ae773ee23a4698239412b3b407bedef" "psi=85195D3E-AA83-4C5C-A20E-CD309C8C33AD" "pi=0d39b4ce-fd53-4203-b272-efa6fc68d825" "protovers=1.1" "model=AudioAccessory1,1" "tsm=0" "tsid=EAFA36AA-9785-54B2-A537-D9EE2A55CF1C" "gpn=Büro 2" "gcgl=1" "igl=1" "gid=EAFA36AA-9785-54B2-A537-D9EE2A55CF1C+1+ACE6D9D3-CD97-40A9-B3E4-1924E0649F44" "flags=0x98404" "features=0x4A7FCA00,0xBC354BD0" "fex=AMp/StBLNbw" "deviceid=50:BC:96:07:E8:6D" "btaddr=4D:F0:4A:C6:75:F4" "acl=0"]



=  wlan0 IPv4 KLinks                                        _airplay._tcp        local

   hostname = [KLinks.local]

   address = [192.168.178.41]

   port = [7000]

   txt = ["vv=2" "osvers=15.3" "srcvers=605.1" "pk=5a14d439edf3ad0926f0c96c3059be33861df97c6f72380ab54ea18478e425c0" "psi=7E5AF368-C056-43BF-953B-7C7EA3B9D27F" "pi=01c6816f-3347-4ddd-8cab-e6a735c9b5a9" "protovers=1.1" "model=AudioAccessory5,1" "tsm=1" "tsid=E6BA6732-F25E-5687-BDBC-558FBA5F76ED" "gpn=Büroküche" "gcgl=1" "igl=1" "gid=E6BA6732-F25E-5687-BDBC-558FBA5F76ED" "flags=0x18404" "features=0x4A7FCA00,0xBC356BD0" "fex=AMp/StBrNbw" "deviceid=E0:2B:96:89:74:9C" "btaddr=59:C6:BA:90:C0:D8" "acl=0"]

=  wlan0 IPv4 KRechts                                       _airplay._tcp        local

   hostname = [KRechts.local]

   address = [192.168.178.49]

   port = [7000]

   txt = ["vv=2" "osvers=15.3" "srcvers=605.1" "pk=ec12c623fbcc82ba197fd77714bbfff63045b13482487e8a5ffda60bef6148ef" "psi=A683442A-A5B4-44FB-ADBF-136625DF40AC" "pi=7ee13959-a6df-48e3-a38b-7fff4fdca20c" "protovers=1.1" "model=AudioAccessory5,1" "tsm=1" "tsid=E6BA6732-F25E-5687-BDBC-558FBA5F76ED" "gpn=Büroküche" "gcgl=1" "igl=1" "gid=E6BA6732-F25E-5687-BDBC-558FBA5F76ED" "flags=0x1a404" "features=0x4A7FCA00,0xBC356BD0" "fex=AMp/StBrNbw" "deviceid=E0:2B:96:96:FB:77" "btaddr=6F:1F:F4:F2:C6:98" "acl=0"]



=  wlan0 IPv4 Links                                         _airplay._tcp        local

   hostname = [Links.local]

   address = [192.168.178.46]

   port = [7000]

   txt = ["vv=2" "osvers=15.4" "srcvers=610.14.1" "pk=40e4f71d4e7153f65b5b906e5c2e5a0011b89dd1b5bf598e939fae406e7d34f0" "psi=3CF62C5C-9249-47F0-98A7-6FA451CA53B1" "pi=3af67dea-4913-441e-898f-0ae9e675ab4a" "protovers=1.1" "model=AudioAccessory1,1" "tsm=0" "tsid=EAFA36AA-9785-54B2-A537-D9EE2A55CF1C" "gpn=Büro 2" "gcgl=1" "igl=1" "gid=EAFA36AA-9785-54B2-A537-D9EE2A55CF1C+0+CCDE6117-686A-4C46-8123-432044A6743C" "flags=0x9a404" "features=0x4A7FCA00,0xBC354BD0" "fex=AMp/StBLNbw" "deviceid=D4:A3:3D:7A:28:D8" "btaddr=42:60:B7:8E:D1:7E" "acl=0"]

=  wlan0 IPv4 Rechts                                        _airplay._tcp        local

   hostname = [Rechts.local]

   address = [192.168.178.56]

   port = [7000]

   txt = ["vv=2" "osvers=15.4" "srcvers=610.14.1" "pk=44398512772475964d6156e8a68485325ae773ee23a4698239412b3b407bedef" "psi=85195D3E-AA83-4C5C-A20E-CD309C8C33AD" "pi=0d39b4ce-fd53-4203-b272-efa6fc68d825" "protovers=1.1" "model=AudioAccessory1,1" "tsm=0" "tsid=EAFA36AA-9785-54B2-A537-D9EE2A55CF1C" "gpn=Büro 2" "gcgl=1" "igl=1" "gid=EAFA36AA-9785-54B2-A537-D9EE2A55CF1C+1+ACE6D9D3-CD97-40A9-B3E4-1924E0649F44" "flags=0x98404" "features=0x4A7FCA00,0xBC354BD0" "fex=AMp/StBLNbw" "deviceid=50:BC:96:07:E8:6D" "btaddr=4D:F0:4A:C6:75:F4" "acl=0"]

Your big HomePods are running 15.4. The minis are running 15.3.

I believe you need 15.4 for the fix.

@ma-ku
Copy link

ma-ku commented Jan 31, 2022

Wow, good catch. When HomePod OS 15.3 was released last week, I checked that all speakers are at the same version (15.3) but now I found out that I still have a Beta Profile on the bigger ones. So you might be right. 15.4 seems to be the solution. I will verify with the small ones, too.

@ma-ku
Copy link

ma-ku commented Jan 31, 2022

I have updated the two HomePod Minis to 15.4 and this solved the problem. Playback works nicely without any toggling of the selected speakers. Once 15.4 is out, we will most likely be able to close this issue. Nevertheless, I would like to see groups/stereo pairs supported (mainly in the web ui ) but that's a different subject.

@ChipWolf
Copy link

ChipWolf commented Jan 31, 2022

I have updated the two HomePod Minis to 15.4 and this solved the problem. Playback works nicely without any toggling of the selected speakers. Once 15.4 is out, we will most likely be able to close this issue. Nevertheless, I would like to see groups/stereo pairs supported (mainly in the web ui ) but that's a different subject.

Contributors, worth raising another issue for this?

@ma-ku
Copy link

ma-ku commented Feb 1, 2022

I am willing to devote time to develop the group support. However, I can only talk about HomePods (I have a bunch of these) and two IKEA Symfonisk Speakers that are basically Sonos speakers, that can be grouped into a stereo pair as well. I already looked into this but I would need to get some guidance form @ejurgensen regarding how the data structures should be amended to accomplish this since this could in some way also affect other signal paths that I have no way to test and that I might not even be aware of.

@aleszczynskig
Copy link

@ma-ku - do you have working knowledge of how Apple implement their stereo pairs with HomePods? I appreciate they are advertised differently via mDNS however there must be other changes implemented under the covers swell. Do we know where the L-R processing is done? Does each HomePod just receive the full stream but playback only the specific channel it is assigned? Additionally, since this is an Airplay2 feature, in order to support the grouping would Owntone need to implement ptp in order to support the grouping required?

@aleszczynskig
Copy link

IKEA Symfonisk Speakers that are basically Sonos speakers, that can be grouped into a stereo pair as well.

Do these IKEA speakers support a stereo pair when using Airplay2. To my knowledge no 3rd party speakers support Airplay2 stereo pairs other than the HomePods. I believe Apple ban this. My pair of Denon Home 150s stop advertising Airplay when put into a stereo pair as an example.

@ma-ku
Copy link

ma-ku commented Feb 1, 2022

As I already mentioned; I provided a patched version of airplay2-receiver that allows to run two instances that show up as a stereo pair and can receive audio streams from iOS devices. Technically the grouping is not overly complicated. It's mainly a matter of handling the mDNS metadata correctly. The stereo pair is a grouped set of speakers like other groups (e.g. multiroom groups) but with a few special characteristics that help iOS devices to show them as one group whereas other groupings could be dissolved in the Airplay control panel of your iOS device. The magic of stereo pairs is just that each speaker knows which channel to play but all speakers receive the same stream. From a owntone perspective, it does not matter. Once you are on 15.4 with your speakers, the stereo playback works out of the box, but you have to select both speakers for output. I would still prefer some support in the UI as stereo pairs have their own name that can be different from the names of the individual speakers.
I already implemented the necessary handling of the mDNS metadata but for now it all resides in the additional metadata of an Airplay output device. To make this work properly I would need to map between two Airplay devices in the backend and one Speaker representing the group in the frontend. I could fumble that into the code but I would appreciate some guidance from @ejurgensen.

@ma-ku
Copy link

ma-ku commented Feb 1, 2022

IKEA Symfonisk Speakers that are basically Sonos speakers, that can be grouped into a stereo pair as well.

Do these IKEA speakers support a stereo pair when using Airplay2. To my knowledge no 3rd party speakers support Airplay2 stereo pairs other than the HomePods. I believe Apple ban this. My pair of Denon Home 150s stop advertising Airplay when put into a stereo pair as an example.

Well, the Sonos stereo playback is handled somehow mutually by the Sonos speakers. Once they are grouped, only one device is broadcasted on mDNS and the stream would be sent to that single endpoint. I would assume that Sonos adds some addtl. buffering and handles the simultaneous playback between the peers.

@aleszczynskig
Copy link

As I already mentioned; I provided a patched version of airplay2-receiver that allows to run two instances that show up as a stereo pair and can receive audio streams from iOS devices. Technically the grouping is not overly complicated. It's mainly a matter of handling the mDNS metadata correctly. The stereo pair is a grouped set of speakers like other groups (e.g. multiroom groups) but with a few special characteristics that help iOS devices to show them as one group whereas other groupings could be dissolved in the Airplay control panel of your iOS device. The magic of stereo pairs is just that each speaker knows which channel to play but all speakers receive the same stream. From a owntone perspective, it does not matter. Once you are on 15.4 with your speakers, the stereo playback works out of the box, but you have to select both speakers for output. I would still prefer some support in the UI as stereo pairs have their own name that can be different from the names of the individual speakers.
I already implemented the necessary handling of the mDNS metadata but for now it all resides in the additional metadata of an Airplay output device. To make this work properly I would need to map between two Airplay devices in the backend and one Speaker representing the group in the frontend. I could fumble that into the code but I would appreciate some guidance from @ejurgensen.

Excellent, so this is literally a UI feature really. I hope this can be implemented. I was unaware that the HomePods are playing the left, right channels correctly from OwnTone when in a stereo pair. This is very good news.

@ma-ku
Copy link

ma-ku commented Feb 1, 2022

And ultimately this also means that the same principle could be applied to streams with more than two channels to support spatial playback (e.g. Dolby) since the data is the same for all devices, they just pick the data they are 'responsible' for.

@aleszczynskig
Copy link

IKEA Symfonisk Speakers that are basically Sonos speakers, that can be grouped into a stereo pair as well.

Do these IKEA speakers support a stereo pair when using Airplay2. To my knowledge no 3rd party speakers support Airplay2 stereo pairs other than the HomePods. I believe Apple ban this. My pair of Denon Home 150s stop advertising Airplay when put into a stereo pair as an example.

Well, the Sonos stereo playback is handled somehow mutually by the Sonos speakers. Once they are grouped, only one device is broadcasted on mDNS and the stream would be sent to that single endpoint. I would assume that Sonos adds some addtl. buffering and handles the simultaneous playback between the peers.

Have you been successful in testing this? If the Sonos part is managing the stereo pair I don't see how the timing is maintained with other Airplay2 devices that may be in a group unless Sonos have a special arrangement with Apple, but I thought stereo pair support is one of the HomePod USPs.

@ma-ku
Copy link

ma-ku commented Feb 1, 2022

IKEA Symfonisk Speakers that are basically Sonos speakers, that can be grouped into a stereo pair as well.

Do these IKEA speakers support a stereo pair when using Airplay2. To my knowledge no 3rd party speakers support Airplay2 stereo pairs other than the HomePods. I believe Apple ban this. My pair of Denon Home 150s stop advertising Airplay when put into a stereo pair as an example.

Well, the Sonos stereo playback is handled somehow mutually by the Sonos speakers. Once they are grouped, only one device is broadcasted on mDNS and the stream would be sent to that single endpoint. I would assume that Sonos adds some addtl. buffering and handles the simultaneous playback between the peers.

Have you been successful in testing this? If the Sonos part is managing the stereo pair I don't see how the timing is maintained with other Airplay2 devices that may be in a group unless Sonos have a special arrangement with Apple, but I thought stereo pair support is one of the HomePod USPs.

That's what I meant. Sonos does it their own way. Once speakers are paired, they become one speaker in the Airplay world.

Regarding Airplay2; if we were implementing a playback software, then the timing and synchronization between the peers would be an issue but from a clients perspective it's just streaming to one or more Airplay speakers and they take care of the details.

@aleszczynskig
Copy link

I have updated the two HomePod Minis to 15.4 and this solved the problem. Playback works nicely without any toggling of the selected speakers. Once 15.4 is out, we will most likely be able to close this issue. Nevertheless, I would like to see groups/stereo pairs supported (mainly in the web ui ) but that's a different subject.

Contributors, worth raising another issue for this?

It believe so, as this is more of a new feature and is not related to this issue. There may be more rabbit holes to go down if we get a working POC for the Stereo pair support. As an example, a few observations and questions I have are:

  1. Does the pairing work in the same way when the stereo pair is the default output for an Apple TV. In this situation (and this is my setup), iOS advertises the output device with a different icon. I am not sure if there are further differences; I am led to believe there maybe (look at pyatv for more details).
  2. Is volume control for a stereo pair managed any differently? I have noticed previously though I need to do more testing on 15.4 that the two speakers do not always keep their volume in sync when making changes via the Owntone API and changing the volume using hardware buttons does not always change the volume on both HomePods. I have never looked into detail on this, or raised any tickets but this would need to managed correctly if only a single device is available in the Owntone UI.

@aleszczynskig
Copy link

Right. That's good to know. I don't have any Sonos (or IKEA) speakers. I may have opted for these instead of my Denon's had I known this.

I thought the whole point of Airplay2 was audio synchronisation across multiple speakers. I must admit I am surprised that this works because surely the Sonos pairing needs a buffer to maintain a good sync and this must break the Airplay2 sync. Maybe they factor for this in their Airplay2 implementation. This is not related to this topic though. Thanks for the discussion.

@ejurgensen
Copy link
Member

Very interesting findings, brings hope that grouped/stereo can be supported too. I'm happy to help with guidance on any implementation you want to try, @ma-ku.

Your questions are very relevant @aleszczynskig, and I would add that the role of the group leader is still unclear to me. I initially thought it might be the leaders job to relay the audio stream (or load it from external sources), but I guess that is not the case. But what then? Is it acting as a volume control master, or is it the paring, or maybe related to PTP?

Another question on my mind is why it took Apple so long to develop Airplay 2 if grouping/stereo is mostly presentation. I was under the impression that it was to change architechture to offload the network i/o from the phone to conserve power when there are many speakers - but maybe that wasn't it.

@ma-ku
Copy link

ma-ku commented Feb 1, 2022

The group leader information seems to be related to the ability of the device to act as a group leader. HomePods can play streams to other devices whereas other devices can only act as recipients. In a more complex group of Airplay devices (formed in the Airplay control panel of iOS), the group leaders were set only for HomePod devices even though the iPhone was the streaming source. In the Stereo Pair both HomePods are listed as leaders. For now I would not waste too much though on that. @ejurgensen: Where would we discuss the implementation details?

@aleszczynskig
Copy link

@ma-ku. I tested a stereo file from Owntone on my HomePods which were stereo paired. I had no stereo separation. Both HomePods were playing the left and right channel as though they were grouped. How did you test the left/right separation?

I checked the same stereo file with my AirPods and it worked correctly.

@ma-ku
Copy link

ma-ku commented Feb 2, 2022

Well, I used the following file https://www.kozco.com/tech/LRMonoPhase4.wav to test and there was clear separation on the original HomePods. And I just checked again - still clear separation. Whereas the same test on two HomePod Mini speakers does not provide stereo separation – I can confirm the observation of @aleszczynskig. When I did the test before, I was just looking at the toggling of the selected playback targets in the settings as the computer and the HomePod Minis are in two different rooms (laziness apparently does not always pay off).

@ejurgensen
Copy link
Member

Where would we discuss the implementation details?

I suggest you open a new issue for that purpose. Then we can close this one, since the switching back and forth issue was thankfully solved by Apple. I think it would be good to keep the discussion here on github, that way @aleszczynskig can follow and help, and we might also need @chme's help, since he is the master of the web UI and mpd.

@ma-ku
Copy link

ma-ku commented Feb 2, 2022

Regarding metadata: comparing the mDNS records of the two stereo pairs, the following can be observed:

One of the pair has flags=0x9a404 whereas the other has flags=0x98404. Bit 13 is different and according to https://openairplay.github.io/airplay-spec/status_flags.html this is ** TightSyncIsGroupLeader** apparently indicating the lead role for timing between the two peers.

I collected the mDNS data for the two pairs. Here is the info for the (legacy) HomePods (Group name is "Büro 2" and left speaker is "Links" and right speaker is "Rechts"):

=  wlan0 IPv4 Links                                         _airplay._tcp        local
   hostname = [Links.local]
   address = [192.168.178.46]
   port = [7000]
   txt = [
		"vv=2" 
		"osvers=15.4" 
		"srcvers=610.14.1" 
		"pk=40e4f71d4e7153f65b5b906e5c2e5a0011b89dd1b5bf598e939fae406e7d34f0" 
		"psi=3CF62C5C-9249-47F0-98A7-6FA451CA53B1" 
		"pi=3af67dea-4913-441e-898f-0ae9e675ab4a" 
		"protovers=1.1" 
		"model=AudioAccessory1,1" 
		"tsm=0" 
		"tsid=EAFA36AA-9785-54B2-A537-D9EE2A55CF1C" 
		"gpn=Büro 2" 
		"gcgl=1" 
		"igl=1" 
		"gid=EAFA36AA-9785-54B2-A537-D9EE2A55CF1C+0+6276FFFA-04E1-439E-8139-2C906B34E587" 
		"flags=0x9a404" 
		"features=0x4A7FCA00,0xBC354BD0" 
		"fex=AMp/StBLNbw" 
		"deviceid=D4:A3:3D:7A:28:D8" 
		"btaddr=6C:27:9A:26:46:1A" 
		"acl=0"]

=  wlan0 IPv4 Rechts                                        _airplay._tcp        local
   hostname = [Rechts.local]
   address = [192.168.178.56]
   port = [7000]
   txt = [
		"vv=2" 
		"osvers=15.4" 
		"srcvers=610.14.1" 
		"pk=44398512772475964d6156e8a68485325ae773ee23a4698239412b3b407bedef" 
		"psi=85195D3E-AA83-4C5C-A20E-CD309C8C33AD" 
		"pi=0d39b4ce-fd53-4203-b272-efa6fc68d825" 
		"protovers=1.1" 
		"model=AudioAccessory1,1" 
		"tsm=0" 
		"tsid=EAFA36AA-9785-54B2-A537-D9EE2A55CF1C" 
		"gpn=Büro 2" 
		"gcgl=1" 
		"igl=1" 
		"gid=EAFA36AA-9785-54B2-A537-D9EE2A55CF1C+1+4671EEC3-7E13-4DC7-BEC3-C9805D3AB964" 
		"flags=0x98404" 
		"features=0x4A7FCA00,0xBC354BD0" 
		"fex=AMp/StBLNbw" 
		"deviceid=50:BC:96:07:E8:6D" 
		"btaddr=40:9E:6F:4A:8A:77" 
		"acl=0"]

And here the same information for the two HomePod Minis (Group "Büroküche" with left speaker being "Links (2)" and right speaker "B__rok__che (2)"):


=  wlan0 IPv4 Links (2)                                     _airplay._tcp        local
   hostname = [Links-2.local]
   address = [192.168.178.41]
   port = [7000]
   txt = [
		"vv=2" 
		"osvers=15.4" 
		"srcvers=610.14.1" 
		"pk=5a14d439edf3ad0926f0c96c3059be33861df97c6f72380ab54ea18478e425c0" 
		"psi=7E5AF368-C056-43BF-953B-7C7EA3B9D27F" 
		"pi=01c6816f-3347-4ddd-8cab-e6a735c9b5a9" 
		"protovers=1.1" 
		"model=AudioAccessory5,1" 
		"gpn=Büroküche" 
		"gcgl=1" 
		"igl=1" 
		"gid=A7D5EDDB-26B0-4D2E-A921-06949E8E8675+0+1D921AC6-B591-4141-87E9-D4CF73033038" 
		"flags=0x98404" 
		"features=0x4A7FCA00,0xBC354BD0" 
		"fex=AMp/StBLNbw" 
		"deviceid=E0:2B:96:89:74:9C" 
		"btaddr=54:7C:5E:6E:AD:2F" 
		"acl=0"]
=  wlan0 IPv4 B__rok__che (2)                               _airplay._tcp        local
   hostname = [Keller.local]
   address = [192.168.178.49]
   port = [7000]
   txt = [
		"vv=2" 
		"osvers=15.4" 
		"srcvers=610.14.1" 
		"pk=ec12c623fbcc82ba197fd77714bbfff63045b13482487e8a5ffda60bef6148ef" 
		"psi=A683442A-A5B4-44FB-ADBF-136625DF40AC" 
		"pi=7ee13959-a6df-48e3-a38b-7fff4fdca20c" 
		"protovers=1.1" 
		"model=AudioAccessory5,1" 
		"tsm=1" 
		"tsid=9270BA34-547F-5E97-AB55-B39F6BC9579A" 
		"gpn=Büroküche" 
		"gcgl=1" 
		"igl=1" 
		"gid=9270BA34-547F-5E97-AB55-B39F6BC9579A+0+DB47A04B-0AC2-42A7-8AC7-1A7C3CA85C85" 
		"flags=0x9e404" 
		"features=0x4A7FCA00,0xBC356BD0" 
		"fex=AMp/StBrNbw" 
		"deviceid=E0:2B:96:96:FB:77" 
		"btaddr=56:57:ED:A0:55:B8" 
		"acl=0"]

Another interesting finding is that we have another service involved:

+  wlan0 IPv4 60E57B79-FF1E-494F-AE15-E847621B1D10          _ieee1588._udp       local
=  wlan0 IPv4 60E57B79-FF1E-494F-AE15-E847621B1D10          _ieee1588._udp       local
   hostname = [f2bcd142-9164-4275-947d-07484d823501.local]
   address = [192.168.178.56]
   port = [319]
   txt = [
		"tsid=EAFA36AA-9785-54B2-A537-D9EE2A55CF1C" 
		"did=60E57B79-FF1E-494F-AE15-E847621B1D10"]

This is a PTP server on one of the legacy HomePods and it is referenced through the tsid record of the "Büro 2" group. A similar record exists only for the "B__rok__che (2)" speaker.

@ma-ku
Copy link

ma-ku commented Feb 2, 2022

Well, I used the following file https://www.kozco.com/tech/LRMonoPhase4.wav to test and there was clear separation on the original HomePods. And I just checked again - still clear separation. Whereas the same test on two HomePod Mini speakers does not provide stereo separation – I can confirm the observation of @aleszczynskig. When I did the test before, I was just looking at the toggling of the selected playback targets in the settings as the computer and the HomePod Minis are in two different rooms (laziness apparently does not always pay off).

One update before we close the issue and move forward implementing stereo groups in the UI and the backend; I rebooted the stereo group with the HomePod Minis and gave them plenty of time to come up again before I did the test again and now the stereo feature is working nicely. The initial test was basically executed right after the stereo group was setup and eventually not everything was ready for the show. Maybe that was also the case for @aleszczynskig. Could you please try again.

@ma-ku
Copy link

ma-ku commented Feb 2, 2022

Where would we discuss the implementation details?

I suggest you open a new issue for that purpose. Then we can close this one, since the switching back and forth issue was thankfully solved by Apple. I think it would be good to keep the discussion here on github, that way @aleszczynskig can follow and help, and we might also need @chme's help, since he is the master of the web UI and mpd.

Here it is: #1413

@aleszczynskig
Copy link

Well, I used the following file https://www.kozco.com/tech/LRMonoPhase4.wav to test and there was clear separation on the original HomePods. And I just checked again - still clear separation. Whereas the same test on two HomePod Mini speakers does not provide stereo separation – I can confirm the observation of @aleszczynskig. When I did the test before, I was just looking at the toggling of the selected playback targets in the settings as the computer and the HomePod Minis are in two different rooms (laziness apparently does not always pay off).

One update before we close the issue and move forward implementing stereo groups in the UI and the backend; I rebooted the stereo group with the HomePod Minis and gave them plenty of time to come up again before I did the test again and now the stereo feature is working nicely. The initial test was basically executed right after the stereo group was setup and eventually not everything was ready for the show. Maybe that was also the case for @aleszczynskig. Could you please try again.

I have done some testing on this but it seems I have some problems with my setup because my stereo pair does not work even from my iPhone. I do not believe the stereo pair is forming correctly so it's likely that my setup is broken. I am investigating now and will report back my findings.

@ejurgensen
Copy link
Member

Closing, apparently fixed in Homepod OS 15.4

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants