Currently groups with AV enabled are decoding the audio in the Tox main thread. This is done here. This also means that the callbacks for groupAV are emitted from the main thread, potentially causing confusion for the client developers.
Ideally we would do the decoding in the dedicated ToxAV thread to keep the protocol and other events running smoothly even under heavy decoding load/many parallel calls. This will also fix the inconsistency of emitting AV callbacks from the main and the ToxAV thread.
Unfortunately this requires an API break since all functions below this line take a Tox struct as parameter and we don't have access to the ToxAV struct. Access to the ToxAV struct is needed, because we need a lock when queuing packets for decoding and a queue which toxav_iterate(...) can access.
Currently groups with AV enabled are decoding the audio in the Tox main thread. This is done here. This also means that the callbacks for groupAV are emitted from the main thread, potentially causing confusion for the client developers.
Ideally we would do the decoding in the dedicated ToxAV thread to keep the protocol and other events running smoothly even under heavy decoding load/many parallel calls. This will also fix the inconsistency of emitting AV callbacks from the main and the ToxAV thread.
Unfortunately this requires an API break since all functions below this line take a
Tox
struct as parameter and we don't have access to theToxAV
struct. Access to theToxAV
struct is needed, because we need a lock when queuing packets for decoding and a queue whichtoxav_iterate(...)
can access.