In reply to a post by jpm:

If just the audio is dropping but the video continues as normal then I doubt this is an internet connection problem.

Do you have a surround receiver connected via ARC to your TV? Has the Hey! ONT been installed near your TV? Is the audio link to your receiver dropping out when these interruptions are occurring?

Interestingly, as I mentioned, it never ever occurs when I switch to my old ISP, hence me thinking it is internet-connection related.

ONT is nowhere near the TV.

I dont have an ARC connection. I use an optical out to a pair of active speakers.

Also, as mentioned, I never have the issue on iPlayer.

It could be down to QoS in the Hey network deprioritising the audio packets compared to other traffic (could be the specific tech that the streaming service is using is not in the QoS table on Hey's config). It would suggest their network is running hot if that is the case.

Agreed, it could be.

But I would assume that if it's not categorised, it likely falls in the same queue as ICMP, or indeed in an 'unknown' queue above ICMP.

If a hot network was then impacting this traffic, we should also see a bad BQM at the same time shouldnt we? (I am assuming they arent giving TBB BQM ICMP traffic a higher priority - that would seem very odd.)

Interesting, the original link is working for me now.

That connection looks pretty flawless. Maybe some issue with buffering somewhere?

Thanks all.

So step 1 is the continuous ping while experiencing the issue, just to check if anything interesting.

I wonder if step 2 is perhaps using a VPN to see whether the issue persists as presumably that takes any HeyB shaping (that may or may not exist) out of the equation, agreed?

Update - audio dropped about 10 times in the last hour (HDR stream on Prime) - very annoying.

Continuous pings look good:

Ping statistics for 9.9.9.9:
Packets: Sent = 3010, Received = 3010, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 4ms, Maximum = 15ms, Average = 5ms

AND

Ping statistics for 8.8.8.8:
Packets: Sent = 3000, Received = 3000, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 3ms, Maximum = 10ms, Average = 4ms

BQM also good....

This is driving me nuts

Edited by Henry8 (Fri 02-Jun-23 21:36:53)

In reply to a post by ian72:

It could be down to QoS in the Hey network deprioritising the audio packets compared to other traffic (could be the specific tech that the streaming service is using is not in the QoS table on Hey's config). It would suggest their network is running hot if that is the case.

Given above, could QoS still be at play, in your opinion?

We had a similar issue at work on a much more complex connection.

I think it was eventually resolved by changing the MTU size so it may be worth spending 5 mins making sure this is setup correctly.

Pretty easy to do e.g. https://www.sonicwall.com/support/knowledge-base/how...

Edited by smouty (Sat 03-Jun-23 09:20:11)

Thanks very much for the suggestion - much appreciated.

I followed the instructions but sadly that just confirmed MTU was already set correctly.

Maybe use ping logger to record the results to a specific host over a period of time e.g teams.microsoft.com