Open Martmists-GH opened 2 years ago
Even after just 3 underflows, the delay is starting to get very noticeable to the point where it's pretty much unusable. Other times it underflows a couple dozen times per second and is delayed 3 seconds after 10 seconds have passed.
I've never really used "blocking mode" and I honestly don't really understand how to use it except in the most trivial situations.
Regarding your problem, I guess it all boils down to how the process()
method is called.
As far as I understand (and I don't really understand it), the blocking functions are supposed to be called back-to-back, without an artificial break between them.
They are "blocking" after all, so you don't need to wait between calls, they are waiting on their own!
I normally prefer using "callback mode", where the callback function is automatically called at the proper times.
Sadly callback mode is not possible here due to the GIL and having to sync up threads as a result. Even so, that's not the problem, as it's a portaudio bug with opening the same device twice.
I encountered output underflow
once. By adjusting latency
to a higher value (>0.1), the output underflow
was gone.
I'm trying to use sounddevice in a graphical application, so I run it in a background thread in blocking mode. However, it often gives an underflow and I'm not sure what to do about this. I tried passing extra np.zeros arrays, but those don't seem to solve it. After about 5 minutes, the audio is ~5 seconds behind real-time.
In the code below, process() gets called once every ~21ms
where sounddevice_handler.py contains the following: