The Case of the Extra 40ms

Re:The Case of the Extra 40ms by golergka on Tuesday December 15, 2020 @01:13AM (#25427527)

> And if you're not, you need to be capable of buffer filling way more than one frame's worth of audio - at least 100ms, preferably much more.

Author addressed this point and agrees with it:

> Why don’t you just copy more data each time the handler is called? This was a fair criticism, but changing this behavior involved deeper changes than I was prepared to make

In general, "real time audio" usually refers to low-latency audio, which uninteractive video playback is not.

[ Parent | on HN ]

Re:The Case of the Extra 40ms by pierrefermat1 on Tuesday December 15, 2020 @01:36AM (#25427644)

Yes he addressed it but just said he was unwilling to do anything about it as it resulted in too much change/work

That does answer the issue of why it was implemented like that in the first place

[ Parent | on HN ]

Re:The Case of the Extra 40ms by golergka on Tuesday December 15, 2020 @02:29PM (#25433998)

Well, it's been my experience that you only find out the proper way to implement something after you do it one or a couple of times.

[ Parent | on HN ]