PulseAudio RTP Multicast - how to play sound on sender too?

Clash Royale CLAN TAG#URR8PPP
up vote
1
down vote
favorite
I am streaming music from a single controlling PC ("sender") to multiple PCs (receivers) on my LAN as described here:
https://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/User/Network/#index2h3
How do I also get the same music to play on the controlling PC (sender)?
My current setup is very simple for testing right now:
sender
pactl load-module module-null-sink sink_name=rtpsink1
pactl load-module module-rtp-send source=rtpsink1.monitor
receivers
pactl load-module module-rtp-recv
audio pulseaudio multicast
 |Â
show 1 more comment
up vote
1
down vote
favorite
I am streaming music from a single controlling PC ("sender") to multiple PCs (receivers) on my LAN as described here:
https://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/User/Network/#index2h3
How do I also get the same music to play on the controlling PC (sender)?
My current setup is very simple for testing right now:
sender
pactl load-module module-null-sink sink_name=rtpsink1
pactl load-module module-rtp-send source=rtpsink1.monitor
receivers
pactl load-module module-rtp-recv
audio pulseaudio multicast
Assuming you stream to a multicast address: Did you try to loadmodule-rtp-recvon the sender, too?
â dirkt
Sep 25 at 6:13
@dirkt - I am streaming to a multicast address (because I just left the default). I did not try to loadmodule-rtp-recvon the sender. I'll try that. Thanks. However, my bigger problem now is that each receiver is out of sync by a full second or more.
â MountainX
Sep 25 at 6:16
Yes, I read and upvoted the other question...
â dirkt
Sep 25 at 6:19
@dirkt - thank you for all your recent help regarding sound!
â MountainX
Sep 25 at 6:22
@dirkt - loadingmodule-rtp-recvon the sender did not solve the issue for me. Is that something that you have used? If you are sure it works, I'll keep trying with that method.
â MountainX
Sep 26 at 5:02
 |Â
show 1 more comment
up vote
1
down vote
favorite
up vote
1
down vote
favorite
I am streaming music from a single controlling PC ("sender") to multiple PCs (receivers) on my LAN as described here:
https://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/User/Network/#index2h3
How do I also get the same music to play on the controlling PC (sender)?
My current setup is very simple for testing right now:
sender
pactl load-module module-null-sink sink_name=rtpsink1
pactl load-module module-rtp-send source=rtpsink1.monitor
receivers
pactl load-module module-rtp-recv
audio pulseaudio multicast
I am streaming music from a single controlling PC ("sender") to multiple PCs (receivers) on my LAN as described here:
https://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/User/Network/#index2h3
How do I also get the same music to play on the controlling PC (sender)?
My current setup is very simple for testing right now:
sender
pactl load-module module-null-sink sink_name=rtpsink1
pactl load-module module-rtp-send source=rtpsink1.monitor
receivers
pactl load-module module-rtp-recv
audio pulseaudio multicast
audio pulseaudio multicast
asked Sep 25 at 3:53
MountainX
4,7412369120
4,7412369120
Assuming you stream to a multicast address: Did you try to loadmodule-rtp-recvon the sender, too?
â dirkt
Sep 25 at 6:13
@dirkt - I am streaming to a multicast address (because I just left the default). I did not try to loadmodule-rtp-recvon the sender. I'll try that. Thanks. However, my bigger problem now is that each receiver is out of sync by a full second or more.
â MountainX
Sep 25 at 6:16
Yes, I read and upvoted the other question...
â dirkt
Sep 25 at 6:19
@dirkt - thank you for all your recent help regarding sound!
â MountainX
Sep 25 at 6:22
@dirkt - loadingmodule-rtp-recvon the sender did not solve the issue for me. Is that something that you have used? If you are sure it works, I'll keep trying with that method.
â MountainX
Sep 26 at 5:02
 |Â
show 1 more comment
Assuming you stream to a multicast address: Did you try to loadmodule-rtp-recvon the sender, too?
â dirkt
Sep 25 at 6:13
@dirkt - I am streaming to a multicast address (because I just left the default). I did not try to loadmodule-rtp-recvon the sender. I'll try that. Thanks. However, my bigger problem now is that each receiver is out of sync by a full second or more.
â MountainX
Sep 25 at 6:16
Yes, I read and upvoted the other question...
â dirkt
Sep 25 at 6:19
@dirkt - thank you for all your recent help regarding sound!
â MountainX
Sep 25 at 6:22
@dirkt - loadingmodule-rtp-recvon the sender did not solve the issue for me. Is that something that you have used? If you are sure it works, I'll keep trying with that method.
â MountainX
Sep 26 at 5:02
Assuming you stream to a multicast address: Did you try to load
module-rtp-recv on the sender, too?â dirkt
Sep 25 at 6:13
Assuming you stream to a multicast address: Did you try to load
module-rtp-recv on the sender, too?â dirkt
Sep 25 at 6:13
@dirkt - I am streaming to a multicast address (because I just left the default). I did not try to load
module-rtp-recv on the sender. I'll try that. Thanks. However, my bigger problem now is that each receiver is out of sync by a full second or more.â MountainX
Sep 25 at 6:16
@dirkt - I am streaming to a multicast address (because I just left the default). I did not try to load
module-rtp-recv on the sender. I'll try that. Thanks. However, my bigger problem now is that each receiver is out of sync by a full second or more.â MountainX
Sep 25 at 6:16
Yes, I read and upvoted the other question...
â dirkt
Sep 25 at 6:19
Yes, I read and upvoted the other question...
â dirkt
Sep 25 at 6:19
@dirkt - thank you for all your recent help regarding sound!
â MountainX
Sep 25 at 6:22
@dirkt - thank you for all your recent help regarding sound!
â MountainX
Sep 25 at 6:22
@dirkt - loading
module-rtp-recv on the sender did not solve the issue for me. Is that something that you have used? If you are sure it works, I'll keep trying with that method.â MountainX
Sep 26 at 5:02
@dirkt - loading
module-rtp-recv on the sender did not solve the issue for me. Is that something that you have used? If you are sure it works, I'll keep trying with that method.â MountainX
Sep 26 at 5:02
 |Â
show 1 more comment
2 Answers
2
active
oldest
votes
up vote
1
down vote
Use module-combine-sink.
On the sender:
pacmd list-sinks
Use the values of the of each sink to be combined in slaves list below:
pactl load-module module-combine-sink sink_name=rtp1combined slaves=abcd,wxyz
where abcd and wxyz would be the names of the two sinks to combine. In my case, that would be slaves=rtpsink1,alsa_output.pci-0000_02_00.1.hdmi-stereo
UPDATE: this method apparently has the disadvantage that the sender is not synchronized with the nodes.
add a comment |Â
up vote
1
down vote
accepted
This is my preferred, working solution. It is based on: pulsertp-multiroom
https://github.com/mada3k/pulsertp-multiroom/blob/master/scripts/pulsertpm-start.sh
I am using this to send audio to multiple receivers (different rooms). There are two lines, noted below, which make the sender a receiver too and solve this question. They are:
- module-rtp-send with the sender's only IP address
- module-rtp-recv with the sender's only IP address
The advantage of this approach is that all receivers (including the one on the sender) stay in sync. That was not the case when combining syncs as in my other answer.
After editing to enter the correct IP addresses, I run this script on the sender when ready to start up RTP unicasting:
#!/bin/bash
#
# PulseRTP-multiroom
# Loads RTP sender modules to setup multiroom audio at request
#
# Notes
# * If you have issues, and have multiple network interfaces, add source_ip= with you prefered local IP
# * mtu=1408 is good initial value. It makes room for 352 PCM frames in 16/44.1k.
#
pa_rtp_mtu=1408
pa_sink="rtpsink1"
echo "timedatectl status:"
timedatectl status --no-pager | grep 'NTP service: active'
if [[ $? -ne 0 ]]; then
timedatectl set-ntp true
sleep 2
timedatectl status --no-pager | grep 'NTP service: active'
if [[ $? -ne 0 ]]; then
echo "WARNING: NTP service not active"
else
echo "timedatectl status OK"
fi
fi
pacmd list-modules | grep module-native-protocol-unix
if [ $? -ne 0 ]; then
pactl load-module module-native-protocol-unix
fi
pacmd list-modules | grep module-default-device-restore
if [ $? -ne 0 ]; then
pactl load-module module-default-device-restore
fi
pacmd list-modules | grep module-rescue-streams
if [ $? -ne 0 ]; then
pactl load-module module-rescue-streams
fi
pacmd list-modules | grep module-always-sink
if [ $? -ne 0 ]; then
pactl load-module module-always-sink
fi
pacmd list-modules | grep module-intended-roles
if [ $? -ne 0 ]; then
pactl load-module module-intended-roles
fi
pacmd list-modules | grep module-suspend-on-idle
if [ $? -ne 0 ]; then
load-module module-suspend-on-idle
fi
#hardcoded addresses of each receiver:
pactl load-module module-rtp-send source=$pa_sink.monitor mtu=$pa_rtp_mtu destination_ip=192.168.0.1 #this is the sender's IP address (see below)
pactl load-module module-rtp-send source=$pa_sink.monitor mtu=$pa_rtp_mtu destination_ip=192.168.0.2
pactl load-module module-rtp-send source=$pa_sink.monitor mtu=$pa_rtp_mtu destination_ip=192.168.0.3
pactl load-module module-rtp-send source=$pa_sink.monitor mtu=$pa_rtp_mtu destination_ip=192.168.0.4
pactl load-module module-rtp-send source=$pa_sink.monitor mtu=$pa_rtp_mtu destination_ip=192.168.0.5
On each receiver:
pactl load-module module-rtp-recv sap_address=192.168.0.X
Use the receiver's actual IP address, e.g., 192.168.0.2
Finally, on the sender, make it a receiver too:
pactl load-module module-rtp-recv sap_address=192.168.0.1
You can make the configuration on the receivers permanent by editing /etc/pulse/default.pa
To stop RTP casting to the receivers, run this script on the sender:
#!/bin/bash
#
# PulseRTP-Multiroom
# Unloads RTP sender modules to avoid unnecessary bandwidth hogging
#
pa_sink="rtpsink1"
IFS=$'n'
for rtpn in `pactl list modules short|grep $pa_sink`; do
PAM_ID=`echo $rtpn|awk 'print $1'`
pactl unload-module $PAM_ID
echo " * unload-module id $PAM_ID done"
done
For starting and stopping music play, no changes are needed on the receivers. Their config can be made permanent. I did not have the need to make any permanent config changes on the sender with my modified version of the start script above.
add a comment |Â
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
1
down vote
Use module-combine-sink.
On the sender:
pacmd list-sinks
Use the values of the of each sink to be combined in slaves list below:
pactl load-module module-combine-sink sink_name=rtp1combined slaves=abcd,wxyz
where abcd and wxyz would be the names of the two sinks to combine. In my case, that would be slaves=rtpsink1,alsa_output.pci-0000_02_00.1.hdmi-stereo
UPDATE: this method apparently has the disadvantage that the sender is not synchronized with the nodes.
add a comment |Â
up vote
1
down vote
Use module-combine-sink.
On the sender:
pacmd list-sinks
Use the values of the of each sink to be combined in slaves list below:
pactl load-module module-combine-sink sink_name=rtp1combined slaves=abcd,wxyz
where abcd and wxyz would be the names of the two sinks to combine. In my case, that would be slaves=rtpsink1,alsa_output.pci-0000_02_00.1.hdmi-stereo
UPDATE: this method apparently has the disadvantage that the sender is not synchronized with the nodes.
add a comment |Â
up vote
1
down vote
up vote
1
down vote
Use module-combine-sink.
On the sender:
pacmd list-sinks
Use the values of the of each sink to be combined in slaves list below:
pactl load-module module-combine-sink sink_name=rtp1combined slaves=abcd,wxyz
where abcd and wxyz would be the names of the two sinks to combine. In my case, that would be slaves=rtpsink1,alsa_output.pci-0000_02_00.1.hdmi-stereo
UPDATE: this method apparently has the disadvantage that the sender is not synchronized with the nodes.
Use module-combine-sink.
On the sender:
pacmd list-sinks
Use the values of the of each sink to be combined in slaves list below:
pactl load-module module-combine-sink sink_name=rtp1combined slaves=abcd,wxyz
where abcd and wxyz would be the names of the two sinks to combine. In my case, that would be slaves=rtpsink1,alsa_output.pci-0000_02_00.1.hdmi-stereo
UPDATE: this method apparently has the disadvantage that the sender is not synchronized with the nodes.
edited Sep 26 at 5:25
answered Sep 25 at 4:08
MountainX
4,7412369120
4,7412369120
add a comment |Â
add a comment |Â
up vote
1
down vote
accepted
This is my preferred, working solution. It is based on: pulsertp-multiroom
https://github.com/mada3k/pulsertp-multiroom/blob/master/scripts/pulsertpm-start.sh
I am using this to send audio to multiple receivers (different rooms). There are two lines, noted below, which make the sender a receiver too and solve this question. They are:
- module-rtp-send with the sender's only IP address
- module-rtp-recv with the sender's only IP address
The advantage of this approach is that all receivers (including the one on the sender) stay in sync. That was not the case when combining syncs as in my other answer.
After editing to enter the correct IP addresses, I run this script on the sender when ready to start up RTP unicasting:
#!/bin/bash
#
# PulseRTP-multiroom
# Loads RTP sender modules to setup multiroom audio at request
#
# Notes
# * If you have issues, and have multiple network interfaces, add source_ip= with you prefered local IP
# * mtu=1408 is good initial value. It makes room for 352 PCM frames in 16/44.1k.
#
pa_rtp_mtu=1408
pa_sink="rtpsink1"
echo "timedatectl status:"
timedatectl status --no-pager | grep 'NTP service: active'
if [[ $? -ne 0 ]]; then
timedatectl set-ntp true
sleep 2
timedatectl status --no-pager | grep 'NTP service: active'
if [[ $? -ne 0 ]]; then
echo "WARNING: NTP service not active"
else
echo "timedatectl status OK"
fi
fi
pacmd list-modules | grep module-native-protocol-unix
if [ $? -ne 0 ]; then
pactl load-module module-native-protocol-unix
fi
pacmd list-modules | grep module-default-device-restore
if [ $? -ne 0 ]; then
pactl load-module module-default-device-restore
fi
pacmd list-modules | grep module-rescue-streams
if [ $? -ne 0 ]; then
pactl load-module module-rescue-streams
fi
pacmd list-modules | grep module-always-sink
if [ $? -ne 0 ]; then
pactl load-module module-always-sink
fi
pacmd list-modules | grep module-intended-roles
if [ $? -ne 0 ]; then
pactl load-module module-intended-roles
fi
pacmd list-modules | grep module-suspend-on-idle
if [ $? -ne 0 ]; then
load-module module-suspend-on-idle
fi
#hardcoded addresses of each receiver:
pactl load-module module-rtp-send source=$pa_sink.monitor mtu=$pa_rtp_mtu destination_ip=192.168.0.1 #this is the sender's IP address (see below)
pactl load-module module-rtp-send source=$pa_sink.monitor mtu=$pa_rtp_mtu destination_ip=192.168.0.2
pactl load-module module-rtp-send source=$pa_sink.monitor mtu=$pa_rtp_mtu destination_ip=192.168.0.3
pactl load-module module-rtp-send source=$pa_sink.monitor mtu=$pa_rtp_mtu destination_ip=192.168.0.4
pactl load-module module-rtp-send source=$pa_sink.monitor mtu=$pa_rtp_mtu destination_ip=192.168.0.5
On each receiver:
pactl load-module module-rtp-recv sap_address=192.168.0.X
Use the receiver's actual IP address, e.g., 192.168.0.2
Finally, on the sender, make it a receiver too:
pactl load-module module-rtp-recv sap_address=192.168.0.1
You can make the configuration on the receivers permanent by editing /etc/pulse/default.pa
To stop RTP casting to the receivers, run this script on the sender:
#!/bin/bash
#
# PulseRTP-Multiroom
# Unloads RTP sender modules to avoid unnecessary bandwidth hogging
#
pa_sink="rtpsink1"
IFS=$'n'
for rtpn in `pactl list modules short|grep $pa_sink`; do
PAM_ID=`echo $rtpn|awk 'print $1'`
pactl unload-module $PAM_ID
echo " * unload-module id $PAM_ID done"
done
For starting and stopping music play, no changes are needed on the receivers. Their config can be made permanent. I did not have the need to make any permanent config changes on the sender with my modified version of the start script above.
add a comment |Â
up vote
1
down vote
accepted
This is my preferred, working solution. It is based on: pulsertp-multiroom
https://github.com/mada3k/pulsertp-multiroom/blob/master/scripts/pulsertpm-start.sh
I am using this to send audio to multiple receivers (different rooms). There are two lines, noted below, which make the sender a receiver too and solve this question. They are:
- module-rtp-send with the sender's only IP address
- module-rtp-recv with the sender's only IP address
The advantage of this approach is that all receivers (including the one on the sender) stay in sync. That was not the case when combining syncs as in my other answer.
After editing to enter the correct IP addresses, I run this script on the sender when ready to start up RTP unicasting:
#!/bin/bash
#
# PulseRTP-multiroom
# Loads RTP sender modules to setup multiroom audio at request
#
# Notes
# * If you have issues, and have multiple network interfaces, add source_ip= with you prefered local IP
# * mtu=1408 is good initial value. It makes room for 352 PCM frames in 16/44.1k.
#
pa_rtp_mtu=1408
pa_sink="rtpsink1"
echo "timedatectl status:"
timedatectl status --no-pager | grep 'NTP service: active'
if [[ $? -ne 0 ]]; then
timedatectl set-ntp true
sleep 2
timedatectl status --no-pager | grep 'NTP service: active'
if [[ $? -ne 0 ]]; then
echo "WARNING: NTP service not active"
else
echo "timedatectl status OK"
fi
fi
pacmd list-modules | grep module-native-protocol-unix
if [ $? -ne 0 ]; then
pactl load-module module-native-protocol-unix
fi
pacmd list-modules | grep module-default-device-restore
if [ $? -ne 0 ]; then
pactl load-module module-default-device-restore
fi
pacmd list-modules | grep module-rescue-streams
if [ $? -ne 0 ]; then
pactl load-module module-rescue-streams
fi
pacmd list-modules | grep module-always-sink
if [ $? -ne 0 ]; then
pactl load-module module-always-sink
fi
pacmd list-modules | grep module-intended-roles
if [ $? -ne 0 ]; then
pactl load-module module-intended-roles
fi
pacmd list-modules | grep module-suspend-on-idle
if [ $? -ne 0 ]; then
load-module module-suspend-on-idle
fi
#hardcoded addresses of each receiver:
pactl load-module module-rtp-send source=$pa_sink.monitor mtu=$pa_rtp_mtu destination_ip=192.168.0.1 #this is the sender's IP address (see below)
pactl load-module module-rtp-send source=$pa_sink.monitor mtu=$pa_rtp_mtu destination_ip=192.168.0.2
pactl load-module module-rtp-send source=$pa_sink.monitor mtu=$pa_rtp_mtu destination_ip=192.168.0.3
pactl load-module module-rtp-send source=$pa_sink.monitor mtu=$pa_rtp_mtu destination_ip=192.168.0.4
pactl load-module module-rtp-send source=$pa_sink.monitor mtu=$pa_rtp_mtu destination_ip=192.168.0.5
On each receiver:
pactl load-module module-rtp-recv sap_address=192.168.0.X
Use the receiver's actual IP address, e.g., 192.168.0.2
Finally, on the sender, make it a receiver too:
pactl load-module module-rtp-recv sap_address=192.168.0.1
You can make the configuration on the receivers permanent by editing /etc/pulse/default.pa
To stop RTP casting to the receivers, run this script on the sender:
#!/bin/bash
#
# PulseRTP-Multiroom
# Unloads RTP sender modules to avoid unnecessary bandwidth hogging
#
pa_sink="rtpsink1"
IFS=$'n'
for rtpn in `pactl list modules short|grep $pa_sink`; do
PAM_ID=`echo $rtpn|awk 'print $1'`
pactl unload-module $PAM_ID
echo " * unload-module id $PAM_ID done"
done
For starting and stopping music play, no changes are needed on the receivers. Their config can be made permanent. I did not have the need to make any permanent config changes on the sender with my modified version of the start script above.
add a comment |Â
up vote
1
down vote
accepted
up vote
1
down vote
accepted
This is my preferred, working solution. It is based on: pulsertp-multiroom
https://github.com/mada3k/pulsertp-multiroom/blob/master/scripts/pulsertpm-start.sh
I am using this to send audio to multiple receivers (different rooms). There are two lines, noted below, which make the sender a receiver too and solve this question. They are:
- module-rtp-send with the sender's only IP address
- module-rtp-recv with the sender's only IP address
The advantage of this approach is that all receivers (including the one on the sender) stay in sync. That was not the case when combining syncs as in my other answer.
After editing to enter the correct IP addresses, I run this script on the sender when ready to start up RTP unicasting:
#!/bin/bash
#
# PulseRTP-multiroom
# Loads RTP sender modules to setup multiroom audio at request
#
# Notes
# * If you have issues, and have multiple network interfaces, add source_ip= with you prefered local IP
# * mtu=1408 is good initial value. It makes room for 352 PCM frames in 16/44.1k.
#
pa_rtp_mtu=1408
pa_sink="rtpsink1"
echo "timedatectl status:"
timedatectl status --no-pager | grep 'NTP service: active'
if [[ $? -ne 0 ]]; then
timedatectl set-ntp true
sleep 2
timedatectl status --no-pager | grep 'NTP service: active'
if [[ $? -ne 0 ]]; then
echo "WARNING: NTP service not active"
else
echo "timedatectl status OK"
fi
fi
pacmd list-modules | grep module-native-protocol-unix
if [ $? -ne 0 ]; then
pactl load-module module-native-protocol-unix
fi
pacmd list-modules | grep module-default-device-restore
if [ $? -ne 0 ]; then
pactl load-module module-default-device-restore
fi
pacmd list-modules | grep module-rescue-streams
if [ $? -ne 0 ]; then
pactl load-module module-rescue-streams
fi
pacmd list-modules | grep module-always-sink
if [ $? -ne 0 ]; then
pactl load-module module-always-sink
fi
pacmd list-modules | grep module-intended-roles
if [ $? -ne 0 ]; then
pactl load-module module-intended-roles
fi
pacmd list-modules | grep module-suspend-on-idle
if [ $? -ne 0 ]; then
load-module module-suspend-on-idle
fi
#hardcoded addresses of each receiver:
pactl load-module module-rtp-send source=$pa_sink.monitor mtu=$pa_rtp_mtu destination_ip=192.168.0.1 #this is the sender's IP address (see below)
pactl load-module module-rtp-send source=$pa_sink.monitor mtu=$pa_rtp_mtu destination_ip=192.168.0.2
pactl load-module module-rtp-send source=$pa_sink.monitor mtu=$pa_rtp_mtu destination_ip=192.168.0.3
pactl load-module module-rtp-send source=$pa_sink.monitor mtu=$pa_rtp_mtu destination_ip=192.168.0.4
pactl load-module module-rtp-send source=$pa_sink.monitor mtu=$pa_rtp_mtu destination_ip=192.168.0.5
On each receiver:
pactl load-module module-rtp-recv sap_address=192.168.0.X
Use the receiver's actual IP address, e.g., 192.168.0.2
Finally, on the sender, make it a receiver too:
pactl load-module module-rtp-recv sap_address=192.168.0.1
You can make the configuration on the receivers permanent by editing /etc/pulse/default.pa
To stop RTP casting to the receivers, run this script on the sender:
#!/bin/bash
#
# PulseRTP-Multiroom
# Unloads RTP sender modules to avoid unnecessary bandwidth hogging
#
pa_sink="rtpsink1"
IFS=$'n'
for rtpn in `pactl list modules short|grep $pa_sink`; do
PAM_ID=`echo $rtpn|awk 'print $1'`
pactl unload-module $PAM_ID
echo " * unload-module id $PAM_ID done"
done
For starting and stopping music play, no changes are needed on the receivers. Their config can be made permanent. I did not have the need to make any permanent config changes on the sender with my modified version of the start script above.
This is my preferred, working solution. It is based on: pulsertp-multiroom
https://github.com/mada3k/pulsertp-multiroom/blob/master/scripts/pulsertpm-start.sh
I am using this to send audio to multiple receivers (different rooms). There are two lines, noted below, which make the sender a receiver too and solve this question. They are:
- module-rtp-send with the sender's only IP address
- module-rtp-recv with the sender's only IP address
The advantage of this approach is that all receivers (including the one on the sender) stay in sync. That was not the case when combining syncs as in my other answer.
After editing to enter the correct IP addresses, I run this script on the sender when ready to start up RTP unicasting:
#!/bin/bash
#
# PulseRTP-multiroom
# Loads RTP sender modules to setup multiroom audio at request
#
# Notes
# * If you have issues, and have multiple network interfaces, add source_ip= with you prefered local IP
# * mtu=1408 is good initial value. It makes room for 352 PCM frames in 16/44.1k.
#
pa_rtp_mtu=1408
pa_sink="rtpsink1"
echo "timedatectl status:"
timedatectl status --no-pager | grep 'NTP service: active'
if [[ $? -ne 0 ]]; then
timedatectl set-ntp true
sleep 2
timedatectl status --no-pager | grep 'NTP service: active'
if [[ $? -ne 0 ]]; then
echo "WARNING: NTP service not active"
else
echo "timedatectl status OK"
fi
fi
pacmd list-modules | grep module-native-protocol-unix
if [ $? -ne 0 ]; then
pactl load-module module-native-protocol-unix
fi
pacmd list-modules | grep module-default-device-restore
if [ $? -ne 0 ]; then
pactl load-module module-default-device-restore
fi
pacmd list-modules | grep module-rescue-streams
if [ $? -ne 0 ]; then
pactl load-module module-rescue-streams
fi
pacmd list-modules | grep module-always-sink
if [ $? -ne 0 ]; then
pactl load-module module-always-sink
fi
pacmd list-modules | grep module-intended-roles
if [ $? -ne 0 ]; then
pactl load-module module-intended-roles
fi
pacmd list-modules | grep module-suspend-on-idle
if [ $? -ne 0 ]; then
load-module module-suspend-on-idle
fi
#hardcoded addresses of each receiver:
pactl load-module module-rtp-send source=$pa_sink.monitor mtu=$pa_rtp_mtu destination_ip=192.168.0.1 #this is the sender's IP address (see below)
pactl load-module module-rtp-send source=$pa_sink.monitor mtu=$pa_rtp_mtu destination_ip=192.168.0.2
pactl load-module module-rtp-send source=$pa_sink.monitor mtu=$pa_rtp_mtu destination_ip=192.168.0.3
pactl load-module module-rtp-send source=$pa_sink.monitor mtu=$pa_rtp_mtu destination_ip=192.168.0.4
pactl load-module module-rtp-send source=$pa_sink.monitor mtu=$pa_rtp_mtu destination_ip=192.168.0.5
On each receiver:
pactl load-module module-rtp-recv sap_address=192.168.0.X
Use the receiver's actual IP address, e.g., 192.168.0.2
Finally, on the sender, make it a receiver too:
pactl load-module module-rtp-recv sap_address=192.168.0.1
You can make the configuration on the receivers permanent by editing /etc/pulse/default.pa
To stop RTP casting to the receivers, run this script on the sender:
#!/bin/bash
#
# PulseRTP-Multiroom
# Unloads RTP sender modules to avoid unnecessary bandwidth hogging
#
pa_sink="rtpsink1"
IFS=$'n'
for rtpn in `pactl list modules short|grep $pa_sink`; do
PAM_ID=`echo $rtpn|awk 'print $1'`
pactl unload-module $PAM_ID
echo " * unload-module id $PAM_ID done"
done
For starting and stopping music play, no changes are needed on the receivers. Their config can be made permanent. I did not have the need to make any permanent config changes on the sender with my modified version of the start script above.
answered Sep 27 at 10:00
MountainX
4,7412369120
4,7412369120
add a comment |Â
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f471222%2fpulseaudio-rtp-multicast-how-to-play-sound-on-sender-too%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Assuming you stream to a multicast address: Did you try to load
module-rtp-recvon the sender, too?â dirkt
Sep 25 at 6:13
@dirkt - I am streaming to a multicast address (because I just left the default). I did not try to load
module-rtp-recvon the sender. I'll try that. Thanks. However, my bigger problem now is that each receiver is out of sync by a full second or more.â MountainX
Sep 25 at 6:16
Yes, I read and upvoted the other question...
â dirkt
Sep 25 at 6:19
@dirkt - thank you for all your recent help regarding sound!
â MountainX
Sep 25 at 6:22
@dirkt - loading
module-rtp-recvon the sender did not solve the issue for me. Is that something that you have used? If you are sure it works, I'll keep trying with that method.â MountainX
Sep 26 at 5:02