WIP. Will update this as I go. If you read this before I update here are some quick thoughts:
the calls into the FFI native code were not async so our async methods and refactor that trickled down from that was unnecessary. I know there is a task to make the API async but if the methods are sync it doesn't make sense to force it at least for now. Once we get this working and testing and see performance issues then we could circle back there and split methods up with delays/etc.
threading. I removed many of them as we were creating threads from threads. If the assumption is that everything can be called from a background thread as the notion dock states then it seems threading should be started outside of the api and we should just support it. I'll share access to our LiveKitTester class which spins up threads for publishing data, mic, and video. That said! We definitely want threads in the high performance areas of audio and video. Areas that previously were coroutines. So I overhauled AudioStream, AudioSource, VideoStream, and VideoSource.
Some thoughts moving forward:
Test. We have an audio issue elsewhere which Cristian is working on so I can't fully test this yet.
For threading in audio/video I am mostly using the last object. Will need to see if we need a queue instead.
For threading again... make sure everything is working on a background thread. I believe the client should handle ensuring texture updates/etc should be done on the main thread.
WIP. Will update this as I go. If you read this before I update here are some quick thoughts:
the calls into the FFI native code were not async so our async methods and refactor that trickled down from that was unnecessary. I know there is a task to make the API async but if the methods are sync it doesn't make sense to force it at least for now. Once we get this working and testing and see performance issues then we could circle back there and split methods up with delays/etc.
threading. I removed many of them as we were creating threads from threads. If the assumption is that everything can be called from a background thread as the notion dock states then it seems threading should be started outside of the api and we should just support it. I'll share access to our LiveKitTester class which spins up threads for publishing data, mic, and video. That said! We definitely want threads in the high performance areas of audio and video. Areas that previously were coroutines. So I overhauled AudioStream, AudioSource, VideoStream, and VideoSource.
Some thoughts moving forward: