Mac drops airplay connection after inactivity

[fruitofgeorge]

I've got a couple of little annoying things that I don't think are necessarily related to bugs in shairport-sync but you know airplay better than most so I'm looking for ideas. Shairport-sync running on a CHIP (currently a recent development build. The always on DAC works a treat. No more pops!) Streaming from my Mac running 10.11.6, everything was just fine. Then I updated to 10.13.6 (the latest my Mac can run) and two things started happening. First, I put my computer to sleep every night and after waking, the first time I try to connect to the CHIP it acts as if it doesn't know the password. I cancel the dialog box and select CHIP as the output device again and it connects fine. Not a huge problem but kind of strange. Second, after about 10 or 15 minutes of not playing audio, my computer reverts the output device back to the internal speakers rather than staying connected to airplay. On macOS 10.11.6 it would stay connected to airplay indefinitely, whether streaming audio or not. Again, the only thing that changed was updating the OS so not really a shairport-sync problem but wondering if you have any ideas of how to remedy these minor issues? Ultimately what I would prefer is to have the CHIP as the default audio output device and auto-connect whenever it's available but in my searching that doesn't seem to be possible.

[mikebrady]

Thanks for the post. There are two things here, it seems:

1. Not reconnecting to a password-protected service after reawakening. This is something I haven't experienced, but haven't tried either -- must have a look.
2. Dropping the connection after an idle period. This is a behaviour that has changed over recent version of macOS and iOS, and I'm pretty certain it's an Apple thing. The timeout occurs on macOS and iOS, though not on iTunes itself. TBH, I'm not sure if there is a non-hacky way to get around this.

[messismore]

The timeout also occurs when playing podcasts in iTunes. It will drop the connection after every episode.

[fruitofgeorge]

Thanks Mike. I figured it was a result of Apple mucking around with things. Just spitballing but what if the shairport-sync service somehow pinged the source at intervals to keep the connection alive?

[mikebrady]

Regarding item 1 above, there is something there -- it'll take some investigation.

The scope for pinging back is somewhat limited, I'm afraid, but worth thinking about.

[mikebrady]

Trying to investigate item 1 above, I think it's an iTunes / Keychain issue. At one stage, I deleted the AirPlay password for the Shairport Sync device I was experimenting with from the Keychain. Later on, I reentered the password, and allowed it to be stored by the Keychain, but it was stored as an Airtunes remote speaker password and not as an AirPlay password. Everything seems to work properly now. Weird. Does this happen to you?

[fruitofgeorge]

Keychain Access is definitely the culprit for that issue. Upon looking, I actually had both an Airplay password and Airtunes remote speaker password in the keychain, with differing dates and access control. I played around with a lot of variables but nothing conclusive. After deleting both of them, any new passwords saved through the system pop-up dialog would get stored as a "local item" rather than in the login keychain which caused all sorts of havoc. Eventually I had to manually create a new password in the keychain and grant access to "AirplayUIAgent.app" and it seems to be working as it should now. I've always found Keychain Access to be unreliable and this is just further proof of its unpredictable behavior so thank you for pointing me in the right direction.

[mikebrady]

Good stuff. TBH, this kind of shuffling of responsibilities in an application makes me think Apple are preparing for some changes in the medium term, getting [almost!] everything lined up gradually and then making a public move later on.

[fruitofgeorge]

Just thinking a bit more about item 2 from above. In the same way of having the option to keep the DAC always on, what if you could keep the RTSP thread open until a request for a new thread came? Would that theoretically maintain the connection to the airplay source? Or another idea would be to utilize the stuffing capability and when audio stops, just continue inserting silent frames until a new audio stream comes. Just making assumptions because I really have no idea how it works so may not be possible.

[anttiautio]

Thanks for the post. There are two things here, it seems:

1. Not reconnecting to a password-protected service after reawakening. This is something I haven't experienced, but haven't tried either -- must have a look.
2. Dropping the connection after an idle period. This is a behaviour that has changed over recent version of macOS and iOS, and I'm pretty certain it's an Apple thing. The timeout occurs on macOS and iOS, though not on iTunes itself. TBH, I'm not sure if there is a non-hacky way to get around this.

Hi, is there a hacky way (or indeed any way) of getting around the disconnection on inactivity thing? I have the same problem in my setup (Raspberry PI 3B, Hifiberry DAC+, new iMac). Sound output reverts to internal speakers when the iMac wakes from sleep or is otherwise inactive/not playing anything for a while.

[fleetingfanatic]

I have this problem from an iPhone also. I am connecting to a Raspberry Pi 3B with Allo Boss running the latest version of RopieeeXL.

I am connecting via Airplay using the system settings to stream music from Tidal. If the music is paused for more than 10 seconds the connection is lost, but the iPhone or Mac thinks they are still connected. When I hit play the music starts playing but no sound comes out of the Pi. After playing for a couple seconds, then the iPhone pauses the music and shows that it is no longer connected via AirPlay. I do not remember experiencing the same behavior when streaming to an Airport Express, or at least not as quickly. I am running the latest version of iOS.

It gets tedious having to go into control center, tap the airplay button, select the internal speaker, then select the shairport device again every time music is paused.

The problem seems to be with connecting to Shairport using the system options, which is necessary for apps like Tidal that do not directly support AirPlay.

[mikebrady]

Thanks for the post. An AirPlay connection should persist for numbers of minutes of inactivity. Actually, if the connection was really dropped, then the iPhone / iTunes / Mac OS Music app would stop. Given that the iPhone / Mac "thinks" it's still connected, it's likely that the connection is still there and that Shairport Sync is still working. I wonder if the RopieeeXL system is causing some kind of problem. For example, is it possible that it is grabbing the output device when Shairport Sync goes to the "inactive" state, which can happen for a brief pause? Have you raised an issue with the RopieeeXL guys?

[fleetingfanatic]

Based on your comment it seemed likely that shairport was not to blame, and I decided I needed to do a bit of work to figure out where the problem was. It seems you were right, the problem I experienced does appear to be with RoPieeeXL.

I tried connecting to shairport running on RoPieeeXL from iTunes running on a Mac, and I was able to pause and continue playing without errors, but anytime I paused for more than ten seconds iTunes would say it was connecting to the device again when I continued playback and would take a few extra seconds to start. So whatever was happening Is not specific to iOS, but the problem was not as disruptive in iTunes.

I spent a couple of hours tonight setting up an install of dietpi with shairport and Roon bridge installed to test it. After getting it up and running I tried it out and I have a stable connection using airplay. It works even better than I expected. I can connect my phone through airplay, start a song in Tidal, pause the song, play a song to the Pi using Roon, and then go back to my phone and continue the first song over airplay, and my phone is still connected and able to play to shairport.

Now that I have narrowed down the source of the problem I will try to report it to the RopieeeXL team when I have time. Thank you for the help, and sorry for cluttering up this issue with something that has turned out to be unrelated.

[mikebrady]

Thanks for the update. Please keep up apprised of any developments.

[sdedalus1]

Hi all, I'm having trouble reconnecting to Airplay after the both the receiving machine and the sending machine sleep and rewake. Receiving: 2008 Macbook (aluminum unibody), running patched 10.12.6 (Sierra), shairport-sync installed via Homebrew (had to compile since no package available for Sierra) Sending: 2020 MBP, 10.15.7 (Catalina)

Here's what I see upon waking both machines, running verbose mode:

18.171240558 "rtsp.c:1062" Connection 1: SETUP DACP-ID "5823C4971F555ABA" from fe80::14c2:3e9a:1612:2984 to fe80::187f:e8af:bb18:7a5b with UDP ports Control: 6001, Timing: 6002 and Audio: 6003.
       667.441333109 "rtp.c:821" Time ping turnaround time: 13221581593 ns -- it looks like a timing ping was lost.
         0.000141893 "rtp.c:506" Error 50 using send-to to the timing socket: "Network is down".
         3.010049723 "rtp.c:506" Error 65 using send-to to the timing socket: "No route to host".
        51.266085144 "rtp.c:821" Time ping turnaround time: 207972822 ns -- it looks like a timing ping was lost.
        46.504717816 "rtsp.c:2236" Connection 2: ANNOUNCE failed because another connection is already playing.
        35.408422050 "rtsp.c:338" Connection 1: As Yeats almost said, "Too long a silence / can make a stone of the heart".
         4.005975911 "rtsp.c:347" *warning: an unrecoverable error, "unable_to_cancel_play_session", has been detected.

It appears that on wake, although the sending machine shows the receiving machine as the selected audio device in the menubar, it tries to open a second connection, which fails?

If one machine sleeps and wakes while the other is still running, they reconnect successfully. I have searched for "air" in the Keychain of both machines and can't find an Airplay or Airtunes password on either of them. Any guidance appreciated.

[github-actions[bot]]

This issue has been inactive for 60 days so will be closed 7 days from now. To prevent this, please remove the "stale" label or post a comment.