diff options
| author | yum <yum.food.vr@gmail.com> | 2023-08-25 12:50:59 -0700 |
|---|---|---|
| committer | yum <yum.food.vr@gmail.com> | 2023-08-25 12:50:59 -0700 |
| commit | 302f7ba09f2ee115d0ee4b8f0841f6ffcd50ec57 (patch) | |
| tree | 5c07175619a1e9d5e56a30f8d2fdd4e6bbde1623 /Scripts/generate_params.py | |
| parent | 9e43487c1bf62402e96cb6139b24cd8446515673 (diff) | |
Put audio feedback into its own thread
I this improves the code structure of the controller input thread and
leads to some deduplication, so I'm going to keep it. However, the
intended purpose was to decrease lag when pressing buttons, and in that
regard it failed.
The lag goes all the way down to the input layer, implying that the
input thread is not able to consistently run at its intended 100 Hz
sample rate. I suspect that the Python global interpreter lock (GIL) is
at fault.
Since we can't realistically move all our functionality into one thread
in a non-blocking model, I think multiprocessing is the logical choice
going forward. Each thread in transcribe.py would become its own
process, and pub/sub through some intermediary process sitting in the
middle.
Diffstat (limited to 'Scripts/generate_params.py')
0 files changed, 0 insertions, 0 deletions
