wenxin-wang / PulseDroidRtp

Receive and play PulseAudio RTP stream on Android
48 stars 2 forks source link

Destination IP confusion #13

Open adastx opened 1 year ago

adastx commented 1 year ago

I wasn't able to get any sound until I used the phones IP as RTP module destination, and 0.0.0.0 as the IP in the app.

I also tried the reverse case with destination=localhost, and IP set to my PC's address, but no sound.

So I got the app to work but I'm not sure this is the intended way? The readme and the app's default values make it look like I should be able to use RTP's 224.0.0.56 IP?

allan-null commented 1 year ago

Looks like the "IP" field on the Android app is the IP the app will be listening for incoming connections, so if you set it to 0.0.0.0 it will listen to all IPs of your Android device (even mobile data, I suppose, which is not secure). And the "destination" argument on the RTP module setup is your Android device IP which the module should connect to. I also found the instructions confusing, and made it work only thanks to this issue.

adastx commented 1 year ago

Your comment inspired me to give this issue another round of troubleshooting.

It seems that whether or not the multicast IP (224.0.0.56) works, or works well, depends on your internet.

I tried using the default target and listen IPs again and it actually worked this time but the audio was super choppy. So it seems like UDP multicast doesn't work well on my router.

I also tried the same thing when using my phone's hotspot / USB tethering, and it actually worked perfectly there. Note: I had to set the destination IP to a different multicast address, found with the command ip maddress

So I guess it can vary a lot between networks, whether or not it works with the default IPs. I don't think it is anything that can be fixed in PulseDroid, but it's probably worth mentioning the alternative setup that worked for us somewhere in the README.

ghistes commented 1 year ago

Same for me. Multicast addresses do not work, probably due to a router not forwarding multicast packets or something like that. I found the workaround to use the ip of the device by experimentation, but it would have saved me some time if it was mentioned somewhere in the docs.