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
Currently, the roc_sender module is sending heavy UDP traffic whether the client is playing audio or not. It can impact the performance of the network when not playing anything and/or lead to unnecessary charges. That traffic is seen as redundant in the network, seeing as it does not lead to anything being played. Unless the sender module is unloaded manually, there is no way to stop the traffic. The redundant traffic precludes the use of roc over metered connections without prior access to the Pulseaudio load-module/unload-module commands, which is greatly impractical.
Ideally, the sender should stop sending any data to the client as soon as playback is stopped.
The text was updated successfully, but these errors were encountered:
gavv
changed the title
Pulseaudio roc_sender quiesce UDP traffic when not playing audio
Pulseaudio roc_sender should quiesce UDP traffic when not playing audio
Nov 29, 2022
To achieve this, roc_sender sink should handle suspend request from PulseAudio and stop sender. Accordingly, it should handle resume request from PulseAudio and restart sender.
gavv
changed the title
Pulseaudio roc_sender should quiesce UDP traffic when not playing audio
roc_sender should quiesce UDP traffic when not playing audio
Nov 29, 2022
Currently, the roc_sender module is sending heavy UDP traffic whether the client is playing audio or not. It can impact the performance of the network when not playing anything and/or lead to unnecessary charges. That traffic is seen as redundant in the network, seeing as it does not lead to anything being played. Unless the sender module is unloaded manually, there is no way to stop the traffic. The redundant traffic precludes the use of roc over metered connections without prior access to the Pulseaudio load-module/unload-module commands, which is greatly impractical.
Ideally, the sender should stop sending any data to the client as soon as playback is stopped.
The text was updated successfully, but these errors were encountered: