undefined | Better HN

0 pointsanyfoo1y ago0 comments

Even if the buffer is large enough, at some point (i.e. a long enough meeting in this case), it will fill up.

> (Now, why does it produce a pop as opposed to silence/hiccup/stretched sound? probably because it was easiest to code)

Sudden "silence" pretty much is a pop, and so is the silence suddenly ending. The sharp transition at least theoretically contains energy in all frequencies (or rather the full bandwidth of this bandwidth-limited signal), which we perceive as a pop.

Bang a steel bar against a hard table, and you get a whole range of frequencies as well, also very pop-like. Do the same with a tuning fork, and after the initial bang you get a nice, clean, single tone, because the tuning fork effectively filters out all the other frequencies through its impulse response.

0 comments

rcxdude1y ago

It's possible to handle buffer underruns more elegantly than that, but it does require more processing power on the receive side of the buffer (basically by using some strategy to extrapolate the audio forward and decay, as opposed to just dropping the signal to zero when there's no data coming from the other side). It's a common thing to do in streaming audio contexts, especially voice, but generally at the end of the user's network connection which is presumed to be unreliable, not in the middle of a processing pipeline which is presumed to be able to hit its latency targets.

anyfooOP1y ago

Oh yeah, I didn’t mean to imply that the pops are a necessary consequence of buffer overruns. But as you say, gracefully mitigating the symptom requires non-negligible engineering effort (and potentially resources), when the actual problem, namely buffer overruns occurring because the consumer is too slow, shouldn’t exist in this particular system in the first place.

theamk1y ago

The delays was on their servers, not on endpoints. So from the consumers' view, this was a buffer underrun due bad communication link.

(In reality, the communication link was fine and it was packet-forwarding server that was slow; but I bet the consumers just saw the packet delays)

j / k navigate · click thread line to collapse