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
I've had to change the IP to 10.0.2.2 for my use case (Windows is a guest in a VM, Linux is QEMU host using user networking, guest itself isn't normally reachable.)
Rebuilding just to change these can be tricky and needs all the tooling of course.
The text was updated successfully, but these errors were encountered:
the driver uses a multicast target address, so any host on the same LAN segment should be able to pick up the stream. I don't want to support unicast because of the hassle of having to set up (and keeping track of) IP and Port settings. If multicast didn't work for you, there must a another reason.
I don't want to support unicast because of the hassle of having to set up (and keeping track of) IP and Port settings.
Makes sense, implementing this would also require some sort of config file somewhere or maybe reading windows registry values to know what IP:Port to listen on.
I'll close this then, I don't think handling above is implemented, and that would introduce more complexity indeed.
If multicast didn't work for you, there must a another reason.
Multicast is indeed sufficient for machines connected on the same LAN. It's own my niche use case where scream is running on a NATed Windows virtual machine that makes it more complicated.
Linux receiver has to listen on localhost/127.0.0.1 and scream connects to the the host/gateway. I believe ICMP packets aren't forwarded and multicast doesn't work since the guest is not reachable by the host in this setup.
The proper way to fix this for now is to bridge the VM to the host rather than use the user networking/SLIRP mode, it's either that or hardcoding hosts' IP in scream :)
These two are hardcoded here: https://github.com/duncanthrax/scream/blob/master/Receivers/pulseaudio/scream-pulse.c#L14-L15
I've had to change the IP to
10.0.2.2
for my use case (Windows is a guest in a VM, Linux is QEMU host using user networking, guest itself isn't normally reachable.)Rebuilding just to change these can be tricky and needs all the tooling of course.
The text was updated successfully, but these errors were encountered: