You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug
I've had my experimental project working for a while now: https://github.com/Charles92011/webrtc-java-experimental-server
It was working great, but I put it away for a couple of months until we're ready to transition to it.
When I started it up today, it gets this error upon connecting two connections together:
#
# Fatal error in: ../../audio/audio_send_stream.cc, line 387
# last system error: 0
# Check failed: !race_checker.RaceDetected()
#
I updated my pom file to get the latest version of the library and it still fails.
This error is untrappable, so I can't recover from it
@Charles92011 hey i saw your project and that is really amazing most of the things i learn from there and about this error i need to resolve this because i am trying to make sfu server in webrtc and now i have been stuck at this point if you want we can figure out on this
@naveenSaini1 I'm in the same situation. My goal was to build a server with this library, but I had to abandon it because of this error.
You could always download the library source, and see if you can trap the error.
From my research, the error is actually occurring in the WebRTC code itself, not the java RTC library. So you could try to modify JavaRTC to trap the exception or try to debug Google's WebRTC code to fix it. I don't have the resources available to do either one.
WebRTC has detected that multiple threads are accessing the same audio send stream object concurrently without proper synchronization. Or it is improper stream lifecycle management when the stream is closed but still accessed. Try to wrap your peer-connection control flow into one managing thread.
The cause of this is now understood and fixed on fix/adm-capture-gate. Full write-up in #217.
Short version: this was never a threading mistake in your code. The factory's AudioDeviceModule feeds captured audio into every audio sender of that factory, so a sender whose track is backed by a CustomAudioSource, or by a track forwarded from another peer, is fed twice from two different threads. The RTC_CHECK_RUNS_SERIALIZED in audio_send_stream.cc then aborts the process.
@naveenSaini1 your SFU case is exactly that shape. Re-adding a received track creates a sender that WebRTC feeds from the thread that decodes the remote audio, while the microphone feeds the same stream from the capture thread. On the branch, the recording device is only opened once you ask for device-captured audio with createAudioSource, so forwarding received tracks works without any change on your side. If you do both on one factory you now get an IllegalStateException naming the conflict, rather than a crash minutes later.
@Charles92011 this is also why it only appeared with an audio track and never with video alone.
My earlier answer here, to wrap the peer connection control flow into one thread, was wrong: the second thread belongs to WebRTC. Sorry that it stood for so long.
Following up with the actual cause, since this is the same abort as #217.
AudioSendStream::SendAudioData is fed twice. A forwarded remote track feeds it on the decoding thread through the track's sinks. At the same time, WebRTC's AudioState starts the factory's AudioDeviceModule recording as soon as any send stream starts, and the capture thread fans every captured frame out to every send stream of that factory. The two overlap intermittently, and the function's RTC_CHECK_RUNS_SERIALIZED aborts the process.
#289 closes the capture path for factories that only forward or push audio, so the device is never opened and the send stream has a single feeder. No application change is needed for the forwarding case.
Activity
Charles92011 commentedon Mar 31, 2023
This error only appears when transmitting an audio track.
Video tracks alone do not throw this error.
naveenSaini1 commentedon Apr 10, 2024
hey i am also getting this same error wheni am trying to add mediastreamtrack of another party
so help
Charles92011 commentedon Apr 10, 2024
@naveenSaini1 I was never able to get past this error, and in a year there's been no update that mentions it.
I had to abandon it.
naveenSaini1 commentedon Apr 11, 2024
@Charles92011 hey i saw your project and that is really amazing most of the things i learn from there and about this error i need to resolve this because i am trying to make sfu server in webrtc and now i have been stuck at this point if you want we can figure out on this
Charles92011 commentedon Apr 11, 2024
@naveenSaini1 I'm in the same situation. My goal was to build a server with this library, but I had to abandon it because of this error.
You could always download the library source, and see if you can trap the error.
From my research, the error is actually occurring in the WebRTC code itself, not the java RTC library. So you could try to modify JavaRTC to trap the exception or try to debug Google's WebRTC code to fix it. I don't have the resources available to do either one.
naveenSaini1 commentedon Apr 12, 2024
@Charles92011
hi i noticed something in this , like whenever we send the audioTrack like this
we will not get the error so i change this way to puting the track in diffrent way
but guess what same thing that same issue
@devopvoid can you please look into this , i really don't know like how to resolve this or can you gave little hint
devopvoid commentedon Aug 28, 2025
WebRTC has detected that multiple threads are accessing the same audio send stream object concurrently without proper synchronization. Or it is improper stream lifecycle management when the stream is closed but still accessed. Try to wrap your peer-connection control flow into one managing thread.
turbo-hammer commentedon Aug 28, 2025
I managed to resolve the issue using static mutex:
sc-sityad commentedon Oct 19, 2025
I have done that still that error persist @turbo-hammer can u give the full exxample of connection + signaling + customAudioSource usage, if possible?
turbo-hammer commentedon Oct 22, 2025
This is not working for me. Some times passed but then happened again.
sc-sityad commentedon Oct 22, 2025
Then , how u resolved it or u haven't?
devopvoid commentedon Sep 16, 2026
The cause of this is now understood and fixed on
fix/adm-capture-gate. Full write-up in #217.Short version: this was never a threading mistake in your code. The factory's
AudioDeviceModulefeeds captured audio into every audio sender of that factory, so a sender whose track is backed by aCustomAudioSource, or by a track forwarded from another peer, is fed twice from two different threads. TheRTC_CHECK_RUNS_SERIALIZEDinaudio_send_stream.ccthen aborts the process.@naveenSaini1 your SFU case is exactly that shape. Re-adding a received track creates a sender that WebRTC feeds from the thread that decodes the remote audio, while the microphone feeds the same stream from the capture thread. On the branch, the recording device is only opened once you ask for device-captured audio with
createAudioSource, so forwarding received tracks works without any change on your side. If you do both on one factory you now get anIllegalStateExceptionnaming the conflict, rather than a crash minutes later.@Charles92011 this is also why it only appeared with an audio track and never with video alone.
My earlier answer here, to wrap the peer connection control flow into one thread, was wrong: the second thread belongs to WebRTC. Sorry that it stood for so long.
devopvoid commentedon Sep 19, 2026
Following up with the actual cause, since this is the same abort as #217.
AudioSendStream::SendAudioDatais fed twice. A forwarded remote track feeds it on the decoding thread through the track's sinks. At the same time, WebRTC'sAudioStatestarts the factory'sAudioDeviceModulerecording as soon as any send stream starts, and the capture thread fans every captured frame out to every send stream of that factory. The two overlap intermittently, and the function'sRTC_CHECK_RUNS_SERIALIZEDaborts the process.#289 closes the capture path for factories that only forward or push audio, so the device is never opened and the send stream has a single feeder. No application change is needed for the forwarding case.
fix: keep device-captured audio out of sink-fed audio senders (#289)