[pulseaudio-tickets] [Bug 105231] New: module-rtp-recv's unicast does not parse

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=105231

            Bug ID: 105231
           Summary: module-rtp-recv's unicast does not parse
           Product: PulseAudio
           Version: unspecified
          Hardware: Other
                OS: All
            Status: NEW
          Severity: normal
          Priority: medium
         Component: modules
          Assignee: pulseaudio-bugs at lists.freedesktop.org
          Reporter: westlake2012 at videotron.ca
        QA Contact: pulseaudio-bugs at lists.freedesktop.org
                CC: lennart at poettering.net

according to documentation (bug occurs with pa10 and pa11)
https://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/User/Modules/#index39h3
"sap_address
The address used to listen for SAP announcements, defaults to 224.0.0.56. It
can be either a multicast group or a unicast address."

when sap_address=<unicast> is specified such as 192.168.2.101, pulseaudio fails
with a message that this address is not acceptable.

The sender can still be set to a unicast address
(load-module module-rtp-send source=<source> source_ip=192.168.2.101
destination_ip=192.168.2.105)

load-module module-rtp-recv sink=<sink> sap_address=192.168.2.101
latency_msec=50
is not acceptable, 

however "load-module module-rtp-recv
sink=alsa_output.pci-0000_00_1b.0.analog-stereo sap_address=0.0.0.0
latency_msec=50" works.

if sap_adresss is not set to 0.0.0.0 then the only way for it to work would be
to allow the default to be the destination(the multicast address).

If the multicast address is specified on the receiver side with sap_address, it
works. The multicast address of course also works when not specified.

just to make clear,
tcpdump demonstrates the unicast address 192.168.2.101 is being sent to but is
only playable on the receiver side if sap_address is set to 0.0.0.0

The documentation can also be slightly improved to mention that the rtp sender
be set to an rtp sink.monitor.

"It reads audio data from an existing source and forwards it to the network
encapsulated in RTP. " should mention that the "source" not be a final sink
device otherwise it wouldn't work.


thanks

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/pulseaudio-bugs/attachments/20180224/114dfd18/attachment.html>