Thanks, tubaman, some good points.
Yes, it is bizarre that the sound alone goes bad. It is even more bizarre that the problem disappears and reappears - why isn’t it permanent?
The point about the upstream, is a very astute one. yes, could well be indeed, but again why does it later work ok? It must be able to manage some how because it does so at a later time, and people can always hear me, I think.
> Have you tried muting your own mic
That’s a good tip. When the app disconnects and then reconnects, I have noticed that my mic always is initially muted. Perhaps that explains why the app temporarily works for a short while after a reconnection until the audio badness soon starts again. I’ll try that tip if/when it recurs, so thank you.
> perhaps run that on audio only
Ah, excellent tip. I’m not sure how to do that - I think I can work it out, one of the icons on the top line.
The why does it come and go thing remains as a problem that defeats all the worthy candidates for explanation.
Coming back to the maxed out upstream thing. On the AA servers’ traffic pictures, the red line representing upstream is not a straight high horizontal line as it would be when doing a flat out max upload, but even if not maxed out, the upload must be running close to the limits. I can’t buy any more upstream for any money and adding a fourth line didn’t seem to effectively increase measured TCP combined upstream total, at least not at some times. This is seemingly something to do with the behaviour of TCP, and I don’t understand what’s going on. Upstream of line 3 is also really slow, 20% slower than the other lines, so perhaps that has something to do with the TCP thing. I also don’t understand why at times the measured combined upstream total is indeed better than the three line combined total, and sometimes not.
Just to add further confusion, the current measured total TCP upstream reported by speedtest.aa.net.uk is for some reason the highest ever seen, at 1.67 Mbps. Normally it report something like 1.15 to 1.3. Don’t know why it goes up and down - this is with repeated measurements made in the dead if night so no other users generating competing traffic - carefully measured with lower results discarded and only the max taken.
Now since it has been working ok since the start of January why does it fail sometimes now when upstream is the highest ever seen? Seems the least likely time to fail. But then who knows why the speed tester does what it does? We don’t understand what’s going on with TCP and don’t understand why the results vary over a long period and I don’t mean short term statistical noise in a group of repeated back-to-back measurements.
So thank you to Tubaman for a very intelligent and helpful analysis. Still left with overriding questions that seem to have no answers.