Is Pulseaudio able to receive RTP Multicast from any source?












2















Been attempting to get Pulseaudio to receive an RTP stream from VLC. I can get it to receive a TCP audio stream no problem - the pi running Pulse is receiving the multicast data as expected, but when running --verbose I just see it sitting suspended. sap_address is configured to the correct network and rcv is uncommented, is it listening on all ports since there is not one defined? Does it need to have CIDR after the address?










share|improve this question



























    2















    Been attempting to get Pulseaudio to receive an RTP stream from VLC. I can get it to receive a TCP audio stream no problem - the pi running Pulse is receiving the multicast data as expected, but when running --verbose I just see it sitting suspended. sap_address is configured to the correct network and rcv is uncommented, is it listening on all ports since there is not one defined? Does it need to have CIDR after the address?










    share|improve this question

























      2












      2








      2








      Been attempting to get Pulseaudio to receive an RTP stream from VLC. I can get it to receive a TCP audio stream no problem - the pi running Pulse is receiving the multicast data as expected, but when running --verbose I just see it sitting suspended. sap_address is configured to the correct network and rcv is uncommented, is it listening on all ports since there is not one defined? Does it need to have CIDR after the address?










      share|improve this question














      Been attempting to get Pulseaudio to receive an RTP stream from VLC. I can get it to receive a TCP audio stream no problem - the pi running Pulse is receiving the multicast data as expected, but when running --verbose I just see it sitting suspended. sap_address is configured to the correct network and rcv is uncommented, is it listening on all ports since there is not one defined? Does it need to have CIDR after the address?







      audio pulseaudio multicast






      share|improve this question













      share|improve this question











      share|improve this question




      share|improve this question










      asked Sep 17 '17 at 8:12









      InfieldFlyInfieldFly

      112




      112






















          1 Answer
          1






          active

          oldest

          votes


















          0














          I am not sure what exactly you tried (you didn't specify), but I can get two pulseaudio servers to communicate via multicast RTP in the following way.



          On the sender,



          pacmd load-module module-rtp-send source=name_of_mic_source destination_ip=232.43.211.230 inhibit_auto_suspend=always


          where name_of_mic_source is a source connected to a microphone for testing (use pamcd list-sources | grep name: to see names, ignore the angular brackets).



          On the receiver,



          pacmd load-module module-null-sink sink_name=rtpsink
          pacmd load-module module-rtp-recv sink=rtpsink sap_address=232.43.211.230


          This creates a "null" sink I can monitor with pavucontrol to verify the noises I making in front of the mic get through. Wireshark verifies the packets are really multicast.



          It also works without destination_ip resp. sap_address, in which case the default 224.0.0.56 multicast group will be used. However this group is link-local, so it won't be routed, and both computers must be on the same segment for it to work.



          This was a test setup. To forward sound from vlc etc., I'd create the null sink on the sender, let vlc play into this sink, use the associated rtpsink.monitor source for module-rtp-send, and connect module-rtp-recv directly to an audible sink on the receiver.



          I haven't tried this with an RTP-stream directly produced by vlc, but if you describe your setup, I can test this, too. If something goes wrong, it should be east to compare the SDP/SAP announcements with Wireshark to see if the problem is there.






          share|improve this answer
























          • Well forgetting VLC for a moment as I was just using that to create a multicast stream, I am attempting to take a USB Audio device's line in on one Pi, RTP the signal out multicast, and receive on multiple units in a house. I'm new to Pulse but it appears there is a loop through feature I can utilize - I am just trying to figure out what my default.pa should look like on both sides, as I am obviously missing something. At the moment I'm not having luck getting the server to actually send out Multicast data - my default.pa file contains a line similar to your pacmd example.

            – InfieldFly
            Sep 21 '17 at 21:18











          • To clarify, I see RTP uncompressed audio traffic in Wireshark but receive nothing when connecting to the stream using VLC or Pulseaudio on the other end.

            – InfieldFly
            Sep 22 '17 at 4:21











          • Hit enter too soon, full comment was To clarify, I see RTP uncompressed audio traffic in Wireshark but receive nothing when connecting to the stream using VLC or Pulseaudio on the other end using the following command on the "server" (apologies for formatting here) pacmd load-module module-rtp-send source=alsa_output.usb-Burr-Brown_from_TI_USB_Audio_CODEC-00.analog-stereo.monitor destination_ip=224.0.0.57 port=5001 inhibit_auto_suspend=always

            – InfieldFly
            Sep 22 '17 at 4:27











          • It's difficult for me to debug this without everything in front of me. You did create the null sink on the receiver, you monitor it with pavucontrol, you start module-rtp-recv with the correct IP, and you see the SDP/SAP announcement + the RTP traffic on the receiving machine in Wireshark? If yes, I don't know where the problem is, it "should" work.

            – dirkt
            Sep 22 '17 at 5:26











          • I've actually gotten things working, realized I was off in a couple places. Now if I can get the multicast flood to stop when I'm not playing audio, it would be perfect....with inhibit_auto_suspend=never it just suspends my input and two sources after a second - "always", and it constantly fires off multicast traffic.

            – InfieldFly
            Sep 22 '17 at 10:55











          Your Answer








          StackExchange.ready(function() {
          var channelOptions = {
          tags: "".split(" "),
          id: "106"
          };
          initTagRenderer("".split(" "), "".split(" "), channelOptions);

          StackExchange.using("externalEditor", function() {
          // Have to fire editor after snippets, if snippets enabled
          if (StackExchange.settings.snippets.snippetsEnabled) {
          StackExchange.using("snippets", function() {
          createEditor();
          });
          }
          else {
          createEditor();
          }
          });

          function createEditor() {
          StackExchange.prepareEditor({
          heartbeatType: 'answer',
          autoActivateHeartbeat: false,
          convertImagesToLinks: false,
          noModals: true,
          showLowRepImageUploadWarning: true,
          reputationToPostImages: null,
          bindNavPrevention: true,
          postfix: "",
          imageUploader: {
          brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
          contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
          allowUrls: true
          },
          onDemand: true,
          discardSelector: ".discard-answer"
          ,immediatelyShowMarkdownHelp:true
          });


          }
          });














          draft saved

          draft discarded


















          StackExchange.ready(
          function () {
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f392728%2fis-pulseaudio-able-to-receive-rtp-multicast-from-any-source%23new-answer', 'question_page');
          }
          );

          Post as a guest















          Required, but never shown

























          1 Answer
          1






          active

          oldest

          votes








          1 Answer
          1






          active

          oldest

          votes









          active

          oldest

          votes






          active

          oldest

          votes









          0














          I am not sure what exactly you tried (you didn't specify), but I can get two pulseaudio servers to communicate via multicast RTP in the following way.



          On the sender,



          pacmd load-module module-rtp-send source=name_of_mic_source destination_ip=232.43.211.230 inhibit_auto_suspend=always


          where name_of_mic_source is a source connected to a microphone for testing (use pamcd list-sources | grep name: to see names, ignore the angular brackets).



          On the receiver,



          pacmd load-module module-null-sink sink_name=rtpsink
          pacmd load-module module-rtp-recv sink=rtpsink sap_address=232.43.211.230


          This creates a "null" sink I can monitor with pavucontrol to verify the noises I making in front of the mic get through. Wireshark verifies the packets are really multicast.



          It also works without destination_ip resp. sap_address, in which case the default 224.0.0.56 multicast group will be used. However this group is link-local, so it won't be routed, and both computers must be on the same segment for it to work.



          This was a test setup. To forward sound from vlc etc., I'd create the null sink on the sender, let vlc play into this sink, use the associated rtpsink.monitor source for module-rtp-send, and connect module-rtp-recv directly to an audible sink on the receiver.



          I haven't tried this with an RTP-stream directly produced by vlc, but if you describe your setup, I can test this, too. If something goes wrong, it should be east to compare the SDP/SAP announcements with Wireshark to see if the problem is there.






          share|improve this answer
























          • Well forgetting VLC for a moment as I was just using that to create a multicast stream, I am attempting to take a USB Audio device's line in on one Pi, RTP the signal out multicast, and receive on multiple units in a house. I'm new to Pulse but it appears there is a loop through feature I can utilize - I am just trying to figure out what my default.pa should look like on both sides, as I am obviously missing something. At the moment I'm not having luck getting the server to actually send out Multicast data - my default.pa file contains a line similar to your pacmd example.

            – InfieldFly
            Sep 21 '17 at 21:18











          • To clarify, I see RTP uncompressed audio traffic in Wireshark but receive nothing when connecting to the stream using VLC or Pulseaudio on the other end.

            – InfieldFly
            Sep 22 '17 at 4:21











          • Hit enter too soon, full comment was To clarify, I see RTP uncompressed audio traffic in Wireshark but receive nothing when connecting to the stream using VLC or Pulseaudio on the other end using the following command on the "server" (apologies for formatting here) pacmd load-module module-rtp-send source=alsa_output.usb-Burr-Brown_from_TI_USB_Audio_CODEC-00.analog-stereo.monitor destination_ip=224.0.0.57 port=5001 inhibit_auto_suspend=always

            – InfieldFly
            Sep 22 '17 at 4:27











          • It's difficult for me to debug this without everything in front of me. You did create the null sink on the receiver, you monitor it with pavucontrol, you start module-rtp-recv with the correct IP, and you see the SDP/SAP announcement + the RTP traffic on the receiving machine in Wireshark? If yes, I don't know where the problem is, it "should" work.

            – dirkt
            Sep 22 '17 at 5:26











          • I've actually gotten things working, realized I was off in a couple places. Now if I can get the multicast flood to stop when I'm not playing audio, it would be perfect....with inhibit_auto_suspend=never it just suspends my input and two sources after a second - "always", and it constantly fires off multicast traffic.

            – InfieldFly
            Sep 22 '17 at 10:55
















          0














          I am not sure what exactly you tried (you didn't specify), but I can get two pulseaudio servers to communicate via multicast RTP in the following way.



          On the sender,



          pacmd load-module module-rtp-send source=name_of_mic_source destination_ip=232.43.211.230 inhibit_auto_suspend=always


          where name_of_mic_source is a source connected to a microphone for testing (use pamcd list-sources | grep name: to see names, ignore the angular brackets).



          On the receiver,



          pacmd load-module module-null-sink sink_name=rtpsink
          pacmd load-module module-rtp-recv sink=rtpsink sap_address=232.43.211.230


          This creates a "null" sink I can monitor with pavucontrol to verify the noises I making in front of the mic get through. Wireshark verifies the packets are really multicast.



          It also works without destination_ip resp. sap_address, in which case the default 224.0.0.56 multicast group will be used. However this group is link-local, so it won't be routed, and both computers must be on the same segment for it to work.



          This was a test setup. To forward sound from vlc etc., I'd create the null sink on the sender, let vlc play into this sink, use the associated rtpsink.monitor source for module-rtp-send, and connect module-rtp-recv directly to an audible sink on the receiver.



          I haven't tried this with an RTP-stream directly produced by vlc, but if you describe your setup, I can test this, too. If something goes wrong, it should be east to compare the SDP/SAP announcements with Wireshark to see if the problem is there.






          share|improve this answer
























          • Well forgetting VLC for a moment as I was just using that to create a multicast stream, I am attempting to take a USB Audio device's line in on one Pi, RTP the signal out multicast, and receive on multiple units in a house. I'm new to Pulse but it appears there is a loop through feature I can utilize - I am just trying to figure out what my default.pa should look like on both sides, as I am obviously missing something. At the moment I'm not having luck getting the server to actually send out Multicast data - my default.pa file contains a line similar to your pacmd example.

            – InfieldFly
            Sep 21 '17 at 21:18











          • To clarify, I see RTP uncompressed audio traffic in Wireshark but receive nothing when connecting to the stream using VLC or Pulseaudio on the other end.

            – InfieldFly
            Sep 22 '17 at 4:21











          • Hit enter too soon, full comment was To clarify, I see RTP uncompressed audio traffic in Wireshark but receive nothing when connecting to the stream using VLC or Pulseaudio on the other end using the following command on the "server" (apologies for formatting here) pacmd load-module module-rtp-send source=alsa_output.usb-Burr-Brown_from_TI_USB_Audio_CODEC-00.analog-stereo.monitor destination_ip=224.0.0.57 port=5001 inhibit_auto_suspend=always

            – InfieldFly
            Sep 22 '17 at 4:27











          • It's difficult for me to debug this without everything in front of me. You did create the null sink on the receiver, you monitor it with pavucontrol, you start module-rtp-recv with the correct IP, and you see the SDP/SAP announcement + the RTP traffic on the receiving machine in Wireshark? If yes, I don't know where the problem is, it "should" work.

            – dirkt
            Sep 22 '17 at 5:26











          • I've actually gotten things working, realized I was off in a couple places. Now if I can get the multicast flood to stop when I'm not playing audio, it would be perfect....with inhibit_auto_suspend=never it just suspends my input and two sources after a second - "always", and it constantly fires off multicast traffic.

            – InfieldFly
            Sep 22 '17 at 10:55














          0












          0








          0







          I am not sure what exactly you tried (you didn't specify), but I can get two pulseaudio servers to communicate via multicast RTP in the following way.



          On the sender,



          pacmd load-module module-rtp-send source=name_of_mic_source destination_ip=232.43.211.230 inhibit_auto_suspend=always


          where name_of_mic_source is a source connected to a microphone for testing (use pamcd list-sources | grep name: to see names, ignore the angular brackets).



          On the receiver,



          pacmd load-module module-null-sink sink_name=rtpsink
          pacmd load-module module-rtp-recv sink=rtpsink sap_address=232.43.211.230


          This creates a "null" sink I can monitor with pavucontrol to verify the noises I making in front of the mic get through. Wireshark verifies the packets are really multicast.



          It also works without destination_ip resp. sap_address, in which case the default 224.0.0.56 multicast group will be used. However this group is link-local, so it won't be routed, and both computers must be on the same segment for it to work.



          This was a test setup. To forward sound from vlc etc., I'd create the null sink on the sender, let vlc play into this sink, use the associated rtpsink.monitor source for module-rtp-send, and connect module-rtp-recv directly to an audible sink on the receiver.



          I haven't tried this with an RTP-stream directly produced by vlc, but if you describe your setup, I can test this, too. If something goes wrong, it should be east to compare the SDP/SAP announcements with Wireshark to see if the problem is there.






          share|improve this answer













          I am not sure what exactly you tried (you didn't specify), but I can get two pulseaudio servers to communicate via multicast RTP in the following way.



          On the sender,



          pacmd load-module module-rtp-send source=name_of_mic_source destination_ip=232.43.211.230 inhibit_auto_suspend=always


          where name_of_mic_source is a source connected to a microphone for testing (use pamcd list-sources | grep name: to see names, ignore the angular brackets).



          On the receiver,



          pacmd load-module module-null-sink sink_name=rtpsink
          pacmd load-module module-rtp-recv sink=rtpsink sap_address=232.43.211.230


          This creates a "null" sink I can monitor with pavucontrol to verify the noises I making in front of the mic get through. Wireshark verifies the packets are really multicast.



          It also works without destination_ip resp. sap_address, in which case the default 224.0.0.56 multicast group will be used. However this group is link-local, so it won't be routed, and both computers must be on the same segment for it to work.



          This was a test setup. To forward sound from vlc etc., I'd create the null sink on the sender, let vlc play into this sink, use the associated rtpsink.monitor source for module-rtp-send, and connect module-rtp-recv directly to an audible sink on the receiver.



          I haven't tried this with an RTP-stream directly produced by vlc, but if you describe your setup, I can test this, too. If something goes wrong, it should be east to compare the SDP/SAP announcements with Wireshark to see if the problem is there.







          share|improve this answer












          share|improve this answer



          share|improve this answer










          answered Sep 18 '17 at 16:23









          dirktdirkt

          16.9k21336




          16.9k21336













          • Well forgetting VLC for a moment as I was just using that to create a multicast stream, I am attempting to take a USB Audio device's line in on one Pi, RTP the signal out multicast, and receive on multiple units in a house. I'm new to Pulse but it appears there is a loop through feature I can utilize - I am just trying to figure out what my default.pa should look like on both sides, as I am obviously missing something. At the moment I'm not having luck getting the server to actually send out Multicast data - my default.pa file contains a line similar to your pacmd example.

            – InfieldFly
            Sep 21 '17 at 21:18











          • To clarify, I see RTP uncompressed audio traffic in Wireshark but receive nothing when connecting to the stream using VLC or Pulseaudio on the other end.

            – InfieldFly
            Sep 22 '17 at 4:21











          • Hit enter too soon, full comment was To clarify, I see RTP uncompressed audio traffic in Wireshark but receive nothing when connecting to the stream using VLC or Pulseaudio on the other end using the following command on the "server" (apologies for formatting here) pacmd load-module module-rtp-send source=alsa_output.usb-Burr-Brown_from_TI_USB_Audio_CODEC-00.analog-stereo.monitor destination_ip=224.0.0.57 port=5001 inhibit_auto_suspend=always

            – InfieldFly
            Sep 22 '17 at 4:27











          • It's difficult for me to debug this without everything in front of me. You did create the null sink on the receiver, you monitor it with pavucontrol, you start module-rtp-recv with the correct IP, and you see the SDP/SAP announcement + the RTP traffic on the receiving machine in Wireshark? If yes, I don't know where the problem is, it "should" work.

            – dirkt
            Sep 22 '17 at 5:26











          • I've actually gotten things working, realized I was off in a couple places. Now if I can get the multicast flood to stop when I'm not playing audio, it would be perfect....with inhibit_auto_suspend=never it just suspends my input and two sources after a second - "always", and it constantly fires off multicast traffic.

            – InfieldFly
            Sep 22 '17 at 10:55



















          • Well forgetting VLC for a moment as I was just using that to create a multicast stream, I am attempting to take a USB Audio device's line in on one Pi, RTP the signal out multicast, and receive on multiple units in a house. I'm new to Pulse but it appears there is a loop through feature I can utilize - I am just trying to figure out what my default.pa should look like on both sides, as I am obviously missing something. At the moment I'm not having luck getting the server to actually send out Multicast data - my default.pa file contains a line similar to your pacmd example.

            – InfieldFly
            Sep 21 '17 at 21:18











          • To clarify, I see RTP uncompressed audio traffic in Wireshark but receive nothing when connecting to the stream using VLC or Pulseaudio on the other end.

            – InfieldFly
            Sep 22 '17 at 4:21











          • Hit enter too soon, full comment was To clarify, I see RTP uncompressed audio traffic in Wireshark but receive nothing when connecting to the stream using VLC or Pulseaudio on the other end using the following command on the "server" (apologies for formatting here) pacmd load-module module-rtp-send source=alsa_output.usb-Burr-Brown_from_TI_USB_Audio_CODEC-00.analog-stereo.monitor destination_ip=224.0.0.57 port=5001 inhibit_auto_suspend=always

            – InfieldFly
            Sep 22 '17 at 4:27











          • It's difficult for me to debug this without everything in front of me. You did create the null sink on the receiver, you monitor it with pavucontrol, you start module-rtp-recv with the correct IP, and you see the SDP/SAP announcement + the RTP traffic on the receiving machine in Wireshark? If yes, I don't know where the problem is, it "should" work.

            – dirkt
            Sep 22 '17 at 5:26











          • I've actually gotten things working, realized I was off in a couple places. Now if I can get the multicast flood to stop when I'm not playing audio, it would be perfect....with inhibit_auto_suspend=never it just suspends my input and two sources after a second - "always", and it constantly fires off multicast traffic.

            – InfieldFly
            Sep 22 '17 at 10:55

















          Well forgetting VLC for a moment as I was just using that to create a multicast stream, I am attempting to take a USB Audio device's line in on one Pi, RTP the signal out multicast, and receive on multiple units in a house. I'm new to Pulse but it appears there is a loop through feature I can utilize - I am just trying to figure out what my default.pa should look like on both sides, as I am obviously missing something. At the moment I'm not having luck getting the server to actually send out Multicast data - my default.pa file contains a line similar to your pacmd example.

          – InfieldFly
          Sep 21 '17 at 21:18





          Well forgetting VLC for a moment as I was just using that to create a multicast stream, I am attempting to take a USB Audio device's line in on one Pi, RTP the signal out multicast, and receive on multiple units in a house. I'm new to Pulse but it appears there is a loop through feature I can utilize - I am just trying to figure out what my default.pa should look like on both sides, as I am obviously missing something. At the moment I'm not having luck getting the server to actually send out Multicast data - my default.pa file contains a line similar to your pacmd example.

          – InfieldFly
          Sep 21 '17 at 21:18













          To clarify, I see RTP uncompressed audio traffic in Wireshark but receive nothing when connecting to the stream using VLC or Pulseaudio on the other end.

          – InfieldFly
          Sep 22 '17 at 4:21





          To clarify, I see RTP uncompressed audio traffic in Wireshark but receive nothing when connecting to the stream using VLC or Pulseaudio on the other end.

          – InfieldFly
          Sep 22 '17 at 4:21













          Hit enter too soon, full comment was To clarify, I see RTP uncompressed audio traffic in Wireshark but receive nothing when connecting to the stream using VLC or Pulseaudio on the other end using the following command on the "server" (apologies for formatting here) pacmd load-module module-rtp-send source=alsa_output.usb-Burr-Brown_from_TI_USB_Audio_CODEC-00.analog-stereo.monitor destination_ip=224.0.0.57 port=5001 inhibit_auto_suspend=always

          – InfieldFly
          Sep 22 '17 at 4:27





          Hit enter too soon, full comment was To clarify, I see RTP uncompressed audio traffic in Wireshark but receive nothing when connecting to the stream using VLC or Pulseaudio on the other end using the following command on the "server" (apologies for formatting here) pacmd load-module module-rtp-send source=alsa_output.usb-Burr-Brown_from_TI_USB_Audio_CODEC-00.analog-stereo.monitor destination_ip=224.0.0.57 port=5001 inhibit_auto_suspend=always

          – InfieldFly
          Sep 22 '17 at 4:27













          It's difficult for me to debug this without everything in front of me. You did create the null sink on the receiver, you monitor it with pavucontrol, you start module-rtp-recv with the correct IP, and you see the SDP/SAP announcement + the RTP traffic on the receiving machine in Wireshark? If yes, I don't know where the problem is, it "should" work.

          – dirkt
          Sep 22 '17 at 5:26





          It's difficult for me to debug this without everything in front of me. You did create the null sink on the receiver, you monitor it with pavucontrol, you start module-rtp-recv with the correct IP, and you see the SDP/SAP announcement + the RTP traffic on the receiving machine in Wireshark? If yes, I don't know where the problem is, it "should" work.

          – dirkt
          Sep 22 '17 at 5:26













          I've actually gotten things working, realized I was off in a couple places. Now if I can get the multicast flood to stop when I'm not playing audio, it would be perfect....with inhibit_auto_suspend=never it just suspends my input and two sources after a second - "always", and it constantly fires off multicast traffic.

          – InfieldFly
          Sep 22 '17 at 10:55





          I've actually gotten things working, realized I was off in a couple places. Now if I can get the multicast flood to stop when I'm not playing audio, it would be perfect....with inhibit_auto_suspend=never it just suspends my input and two sources after a second - "always", and it constantly fires off multicast traffic.

          – InfieldFly
          Sep 22 '17 at 10:55


















          draft saved

          draft discarded




















































          Thanks for contributing an answer to Unix & Linux Stack Exchange!


          • Please be sure to answer the question. Provide details and share your research!

          But avoid



          • Asking for help, clarification, or responding to other answers.

          • Making statements based on opinion; back them up with references or personal experience.


          To learn more, see our tips on writing great answers.




          draft saved


          draft discarded














          StackExchange.ready(
          function () {
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f392728%2fis-pulseaudio-able-to-receive-rtp-multicast-from-any-source%23new-answer', 'question_page');
          }
          );

          Post as a guest















          Required, but never shown





















































          Required, but never shown














          Required, but never shown












          Required, but never shown







          Required, but never shown

































          Required, but never shown














          Required, but never shown












          Required, but never shown







          Required, but never shown







          Popular posts from this blog

          How to make a Squid Proxy server?

          Is this a new Fibonacci Identity?

          19世紀