Playback reliably stops after 10-20 minutes with iTunes/Mac/Sonos PLAY:1

[tedd4u]

First - thanks for this project, really appreciate it.

Problem: Playback from iTunes on iMac to Sonos PLAY:1 reliably stops after 10-20 minutes.

macOS: 10.11.6 (El Capitan)
iTunes: 12.7.3.46
Sonos: up-to-date firmware as of 2/15/2018
AirConnect: 5faf953 0.2.0.3
Command: bin/airupnp-osx-multi -l 1500:3000

Basically I start airupnp, it loads up and runs fine. I hit play in iTunes and everything goes fine for 15-20 minutes. Then it just stops.

Here are the logs -- Audio stops at just about 8:06:06 - there's lots of log spew just after that
https://gist.github.com/anonymous/0f81501c1b976b2b50c0ca8f1ad4de8b

Happy to do any diagnostics or try anything to help solve this. The PLAY:1 was a gift but is pretty useless to us without AirPlay 😄

[philippe44]

I've seen this on a few systems and unfortunately I have no idea what's happening. In some cases, TCP packets sent to the UPnP device (Sonos or other) takes forever to reach it, it happens in bursts and buffering is not enough to deal with that. I assume it's network configuration/prioritization related, but I really don't understand. There is nothing special in the code at that place, just a send() of bytes that sometimes return after more than a couple of sec, even if the other party is supposed to be ready. It's a blocking send, but I've tried using a non-blocking socket and verify it's ready for writing with no better result. The thread which is sending packets over HTTP has nothing else to do, so even if it's suspended in the send, it does not prevent anything else to run. And there is no reason why the send would block for long because the data are sent from a UDP source, so they arrive in real time, it's not like TCP should suspend the connection because the player is full ... basically, no idea again except look at your router for some traffic prioritisation maybe.

[realLaotse]

I used to have a similar problem which solved itself magically if replacing the flac codec with pcm wav.

[tedd4u]

Hmmmm, I ran airupnp-osx-multi under dtruss and it's been running fine for a couple hours ... ? Strange. @realLaotse, thanks for the suggestion, I'll try that too -- appreciated.

…

On Sun, Feb 18, 2018 at 12:21 AM realLaotse ***@***.***> wrote: I used to have a similar problem which solved itself magically if replacing the flac codec with pcm. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#54 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAlWp4eST_6HaUVE_v3Y6JERKta5p-9jks5tV919gaJpZM4SIkTh> .

[philippe44]

Any help on finding this issue would be really appreciated. I've seen it on Windows, Linux and MacOS .... The difference with pcm vs flac is that each send() in PCM is 1408 bytes, so closer to MTU where in flac, each call is less as data are compressed. I'm wondering if there is not something funny with Nagle/MSS and all that. I tried that route a while ago but could find anything

[philippe44]

I've added TCP_NODELAY in 0.2.0.4 - I can't remember if I tried that in the past. Let me know how it works

[tedd4u]

Tried 0.2.0.4. Seems to help - much longer uptime now. Thank you. By the way, FLAC and WAV work for me but PCM doesn't work at all. Wonder why that would be? Maybe Sonos can't accept PCM? Tim

…

On Sun, Feb 18, 2018 at 9:00 PM philippe44 ***@***.***> wrote: I've added TCP_NODELAY in 0.2.0.4 - I can't remember if I tried that in the past. Let me know how it works — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#54 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAlWp7HyKCJuI2H_nrP8yTyRtH6re8rKks5tWP_cgaJpZM4SIkTh> .

[philippe44]

That's correct, Sonos does not accept PCM raw format, it must be encapsulated into WAV or AIFF (which is really horrible ...)

[philippe44]

closed for inactivity