Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

What amazes me on conference calls is how no one can explain audio issues. Really, really smart people on a call that can explain registers, cryptography, kernel tuning.

Sounds like you are having network issues/bit errors? You are breaking up.

Sounds like your bluetooth is having issues? You are breaking up.

Sounds like they are mobile, and in a weak service area? You are breaking up.



As a person who is an audio engineer, dsp programmer and supporting such systems professionally: That is because the breaking up for the most part sounds very much the same. It is a CODEC specialized for low bitrate transmission going into low bitrate compressions, packets being dropped entirely or arriving with a delay etc.

Who knows where such a thing comes from? It could be any number of things on a huge technological stack distributed over a large geographical area.

A domain expert should of course be able to distinguish various bad conditions by ear, e.g. clipping, saturation, wromg microphone distances/orientation, signal interferences, hum, bad grounding etc.

But not all people are good at analytical hearing regardless of them being engineers or not. That is why people pay the likes of me.


To say the network guru should automatically know the cause of a packet drop is like to say the postal worker automatically knows why the letter never arrived, or a doctor automatically knows the cause of that cough.


This is mostly a consequence of the complexity of all the abstraction layers between "conference call" and "physical routed and switched connection". At best you might be able to identify that the visible/audible symptom is due to packet loss, but proving a root cause of the packet loss is extremely difficult. Through some tooling, like ThousandEyes (which I work on), you might be able to identify the hop in the path that's causing that forwarding loss, but unless you have access to that device it'd be impossible to prove exactly /why/ it has forwarding loss.

Any type of problem like that ultimately becomes a "5 Whys?" kind of troubleshooting to get to a real root cause, and from a end-user device you generally don't have the necessary access or data to answer more than 2-3 layers of abstraction.


I try to be more specific, but there's just so much going into modern sound processing. Told a guy once his bluetooth connection was failing, but the real issue was that he had a plane taking off overhead and the VC software was noise-cancelling everything.


Are those things distinguishable? I thought people say you're breaking up because they only see the symptom of audio cutting out and have no way to distinguish what the cause is.


Mediatec professional here: hard/impossible to distinguish especially, because knowing precisely which signal processing your video-conferencing solution might be doing under which conditions and in which version is even hard to know for people who analyze one version of software in a lab environment.

That is like a relative saying you are not an IT expert because you don't know immidiately what the distinct root cause of "the screen being black" is.




Consider applying for YC's Winter 2026 batch! Applications are open till Nov 10

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: