Hey everyone! Today was a pretty nice working day.
Acted on all the comments in the code review I got on the real-time transcription I'm working on, made the codebase cleaner and refactored a lot of componenents within it.
However, I had some problems with the socket timing out. Which makes sense, because when I loaded a large transcription model, it took some time and the server was unresponsive during that time. It's not a good practice to have your server be unresponsive at all, so I got to threading. I absolutely love the threading library in Python and I honestly don't know if I've started to abuse it!
I created a separate thread for the initialization to solve it.
However, during this initialization, the client can disconnect from the socket. So I also considered this situation and didn't proceed to creating the stream if it'd been done.
Since the application provides graceful shutdown of the stream, which means that the client will receive the transcriptions of the remaining audio data when they request to stop the stream, it needs to wait for the stream to finish transcribing. However, this blocks the server. So offloaded that to a different thread as well.
However, during that time, the client may disconnect as well. Which will lead to clashing operations. So I had to keep track of two things:
- Is the client disconnecting?
- Is the client ending the stream?
If the client is doing both, the first one they requested is the leader and the operations won't clash.
It was pretty amazing to see how all this played out to keep a clean and responsive server (main thread). I believe that this directly paves the way to multi-client support, which is what I'll be exploring tomorrow with this application!
Happy coding everyone!
Top comments (0)