From 302f7ba09f2ee115d0ee4b8f0841f6ffcd50ec57 Mon Sep 17 00:00:00 2001 From: yum Date: Fri, 25 Aug 2023 12:50:59 -0700 Subject: 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. --- Scripts/requirements.txt | 1 - 1 file changed, 1 deletion(-) (limited to 'Scripts/requirements.txt') diff --git a/Scripts/requirements.txt b/Scripts/requirements.txt index bdc93a1..3a2cf42 100644 --- a/Scripts/requirements.txt +++ b/Scripts/requirements.txt @@ -9,7 +9,6 @@ pyopenxr pillow pyaudio python-osc -playsound==1.2.2 pyyaml sentence_splitter transformers>=4.21.0 -- cgit v1.2.3