KoljaB
commented
2 months ago First I have to say, I developed this for single user only, since I don't have the resources to test multiuser scenarios.
I do not know if this next scenario makes sense but is it good practice to use one instance of this class that can handle multiple clients internally. I have only skimmed through the realtime worker method in audio_recorder.py, but it seems like it persists the text buffers until the instance is destroyed. This returns the transcription of the first client to the second client if we use the same instance.
I don't think this is good practice. I'd have to redesign RealtimeSTT from scratch to support this. Problem isn't only the text buffers, it's also the realtime processing of incoming audio signals. We'd need seperate audio buffers for every client. This is a massive redesign.
If I'd need to support this with the current code I'd create a pool of RealtimeSTT instances which would server 1 instance 1 user until the pool is exhausted, then I'd queue the requests.
bilalshafim
Reset the state of the class instead of destroying it and instantiating again for next?
I am currently working on creating a recorder pool that socket connections can borrow from to speed up the initial setup. The idea is that we can return the instance to a pool at the end of a client session.
I do not know if this next scenario makes sense but is it good practice to use one instance of this class that can handle multiple clients internally. I have only skimmed through the realtime worker method in audio_recorder.py, but it seems like it persists the text buffers until the instance is destroyed. This returns the transcription of the first client to the second client if we use the same instance.