AirPlay / AirTunes audio stuttering on 0.26

[khanh@…]

I am having a problem with audio stuttering when sending AirTunes? to a frontend. I was using shairport (and still can) without issue. Whenever I send a stream to the frontend, I get what looks like a lot of missed packet errors in the log. I don't have this issue with shairport and just some quick testing of YouTube? videos from an iOS device results in perfect video/audio streaming!

[JYA]

myth is asking for missed audio packets to be resent, but it never gets the requested packets back.

Please provide a fully verbose shairport playback to see if you get missed packets in the same fashion.

Otherwise, surprisingly, your iTunes machine is connecting via IPv4, the default on all iTunes I've seen is to use IPv6 when available, and myth advertise on IPv6 (shairport is IPv4 only).

if the iTunes client isn't properly setup for ipv6 (only need to enable automatic mode if mac in the network preferences) and let it do its thing.

Also, make sure IPv6 on the mythtv-setup is properly configured to listen on the current local-link address.

In all, it sounds like a misconfiguration of the networking on mythtv side

[JYA]

BTW, airplay audio has ZERO to do with AirPlay? video. Different protocol, different networking, different connection.

[wiho@…]

I've been experiencing the same problem since I recently updated my mythtv to the latest 0.26-fixes revision: lots of stuttering when streaming audio from an iOS client (Spotify) to myth over AirPlay? while mythfrontend write the same log messages ("Audio discontinuity seen").

I've also found the change that seems to cause this issue: ​https://github.com/MythTV/mythtv/commit/5f11bda1994c0dad45ff29e3fc8836eb83f98116. When I revert this single line patch in the current 0.26-fixes revision, AirPlay? works just fine again.

I'm not familiar with the myth audio handling code, so I'm not sure if the patch itself is buggy, of if it just exposes a previously undiscovered bug in the AirPlay? handling code.

[khanh@…]

I have a dedicated backend, so I don't know what enabling ipv6 will do, but I enabled it anyway.

The log was from an iPhone 6.1.4 but I've also tried it from a Mac running iTunes 11 with the same results. I've added -v to shairport, but it doesn't log much of anything.

I'll look into the revision at ​https://github.com/MythTV/mythtv/commit/5f11bda1994c0dad45ff29e3fc8836eb83f98116

[khanh@…]

I have a dedicated backend, so I don't know what enabling ipv6 will do, but I enabled it anyway.

The log was from an iPhone 6.1.4 but I've also tried it from a Mac running iTunes 11 with the same results. I've added -v to shairport, but it doesn't log much of anything.

I'll look into the revision at ​https://github.com/MythTV/mythtv/commit/5f11bda1994c0dad45ff29e3fc8836eb83f98116

[JYA]

Can you revert commit: ​https://github.com/MythTV/mythtv/commit/5f11bda1994c0dad45ff29e3fc8836eb83f98116

checkout fixes/0.26 and issue the command: git revert 5f11bda1994c0dad45ff29e3fc8836eb83f98116

and see if that fixes it for you.... thanks

[warpme@…]

@jya, just FYI as another data point: I also have issue with audio stuttering as described in this ticket. I can confirm, reverting 5f11bda1994c0dad45ff29e3fc8836eb83f98116 solves issue. I'm on current 0.26-fixes. Test was with iPhome 4 6.1.2

[JYA]

5f11bda1994c0dad45ff29e3fc8836eb83f98116 fixes a calculation with timestamp. This has a consequence on the RAOP code expiring audio much quicker following the order sync by iTunes/iPhone.

I could easily ease up the test ; but that would cause extra delay in A/V sync. Right now it's pretty spot on...

it's not an easy fix unfortunately :(

[Jean-Yves Avenard <jyavenard@…>]

In 96f58cbf4baa16b2008888f92d4ce2fb7e615aec/mythtv:

Rework RAOP audio sync

commit 9ec7421138adef73ef9cb83b74e046092fecdd6a that fixed audio timestamp calculations revealed an issue in the way RAOP was calculating and setting time syncing.
Rework how things are done: We now calculate the audio card latency and simply drop the initial audio frames amounting for such length of time. From that point on, when we get too far behind we drop all queued audio and restart.

Rather than dropping a whole audio packet at a time (352 frames) we now drop frame by frame, so re-syncs are much smoother.

Surprisingly, this simpler method gives much better results. Synchronisation across multiple airplay device is almost perfect (tested across 2 macs and one linux). Remote audio and video sync are spot on.

Fixes #11530

[JYA]

if you guys could try this commit (it will backport easily on on fixes/0.26) and report... If there's no problem, I'll backport it along all the other AirPlay? fixes...

[khanh@…]

I'm running 0.26-fixes. Can I copy the changes and compile there or do I need to check out the head branch?

[wiho@…]

I've applied patch 96f58cbf4baa16b2008888f92d4ce2fb7e615aec to the 0.26-fixes branch. I can confirm that this fixed the stuttering completely. Nice work!

Thanks for the quick response!

[warpme@…]

Jya, I applied patch to current 0.26-fixes & iPhone4 6.1.3. Songs & Movies playback is flawless. Videos from camera have OK sound - but no video (but video problem for sure isn't related to this ticket). Thx for excellent work!

[Jean-Yves Avenard <jyavenard@…>]

In 27fa52d288ec01f017b43c1f1ec09382c4baaa2f/mythtv:

Rework RAOP audio sync

commit 9ec7421138adef73ef9cb83b74e046092fecdd6a that fixed audio timestamp calculations revealed an issue in the way RAOP was calculating and setting time syncing.
Rework how things are done: We now calculate the audio card latency and simply drop the initial audio frames amounting for such length of time. From that point on, when we get too far behind we drop all queued audio and restart.

Rather than dropping a whole audio packet at a time (352 frames) we now drop frame by frame, so re-syncs are much smoother.

Surprisingly, this simpler method gives much better results. Synchronisation across multiple airplay device is almost perfect (tested across 2 macs and one linux). Remote audio and video sync are spot on.

Fixes #11530
(cherry picked from commit 96f58cbf4baa16b2008888f92d4ce2fb7e615aec)