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
Other Information - Fedora Linux 39, using pipewire audio stack
What did you do?
We've a server (Pion) which now always acts as a audio receiver and is the one which makes the offer.
We've two types of clients: browser (which uses the native WebRTC client) and a CLI (which uses Pion)
The server (always Receiver) adds an audio transceiver:
After connection is established the Sender adds a track to Transceiver on its side.
RTPPackets are flowing normally
On Client/Sender we have a "mute" implementation which calls RTPSender.ReplaceTrack(nil) when we want to "mute" the audio and then it calls RTPSender.ReplaceTrack(track) to establish the audio again.
What did you expect?
When RTPSender.ReplaceTrack(nil) is called: the Receiver should stop receiving RTP packets.
When RTPSender.ReplaceTrack(track) is called: the Receiver should start receiving RTP packets again.
What happened?
From Browser Client -> Receiver (Pion): it is working flawless, every time that we replace the track with null, the TrackRemote of the RTPReceiver is not receiving the RTPPackets and when we replace the track with the local track (the same track or a new one get using getUserMedia), the RTPPackets start to flow again through the TrackRemote of the RTPReceiver.
From Pion Client -> Receiver (Pion): when we replace the track with nil, it looks okay and the TrackRemote stops on receiving the RTPPackets, but very frequently after we call ReplaceTrack with the local track (the same track or a new one using pion/mediadevices/getUserMedia) the RTPPackets do not start to flow again through the TrackRemote of the RTPReceiver.
And after that we call ReplaceTrack(nil) and ReplaceTrack(localTrack) again, sometimes we still don't have the RTPPackets, sometimes we do start receiving RTPPackets, we couldn't find a pattern
The same Receiver is being used for both clients.
I've tried to debug the Pion Client RTPSender.ReplaceTrack, we don't get any error when calling the method with nil or with the local track and the track looks like is being set by the RTPSender.ReplaceTrack in either case.
We now solved our problem by not calling ReplaceTrack with Pion Sender and using other channel like the signaling to communicate the state change, but we keep the RTPSender flowing the RTPPackets to the Receiver and is working correctly, which means that is not a problem with the Pion mediadevices or the audio driver.
The text was updated successfully, but these errors were encountered:
kenzoi
changed the title
RTPSender stops sending audio packets when alternating between track and nil with ReplaceTrack method
RTPSender stops sending audio packets when alternating between nil and track with ReplaceTrack method
Nov 24, 2023
Your environment.
What did you do?
We've a server (Pion) which now always acts as a audio receiver and is the one which makes the offer.
We've two types of clients: browser (which uses the native WebRTC client) and a CLI (which uses Pion)
The server (always Receiver) adds an audio transceiver:
After connection is established the Sender adds a track to Transceiver on its side.
RTPPackets are flowing normally
On Client/Sender we have a "mute" implementation which calls
RTPSender.ReplaceTrack(nil)
when we want to "mute" the audio and then it callsRTPSender.ReplaceTrack(track)
to establish the audio again.What did you expect?
RTPSender.ReplaceTrack(nil)
is called: the Receiver should stop receiving RTP packets.RTPSender.ReplaceTrack(track)
is called: the Receiver should start receiving RTP packets again.What happened?
From Browser Client -> Receiver (Pion): it is working flawless, every time that we replace the track with null, the TrackRemote of the RTPReceiver is not receiving the RTPPackets and when we replace the track with the local track (the same track or a new one get using getUserMedia), the RTPPackets start to flow again through the TrackRemote of the RTPReceiver.
From Pion Client -> Receiver (Pion): when we replace the track with nil, it looks okay and the TrackRemote stops on receiving the RTPPackets, but very frequently after we call ReplaceTrack with the local track (the same track or a new one using pion/mediadevices/getUserMedia) the RTPPackets do not start to flow again through the TrackRemote of the RTPReceiver.
And after that we call ReplaceTrack(nil) and ReplaceTrack(localTrack) again, sometimes we still don't have the RTPPackets, sometimes we do start receiving RTPPackets, we couldn't find a pattern
The same Receiver is being used for both clients.
I've tried to debug the Pion Client RTPSender.ReplaceTrack, we don't get any error when calling the method with nil or with the local track and the track looks like is being set by the RTPSender.ReplaceTrack in either case.
We now solved our problem by not calling ReplaceTrack with Pion Sender and using other channel like the signaling to communicate the state change, but we keep the RTPSender flowing the RTPPackets to the Receiver and is working correctly, which means that is not a problem with the Pion mediadevices or the audio driver.
The text was updated successfully, but these errors were encountered: