Multiplicity 4 cannot send Audio

two laptops can receive but not send audio. third laptop sends to either of the other two just fine.

from Stardock Forums

 

Windows 10 22H2 with all current updates on all laptops involved.

I have three laptops setup with multiplicity 4.07.  Mouse and Keyboard work fine between all three.  I've never used the Audio redirect before.  Two of the laptops cannot send audio, but can receive it.  The third can send.  Cannot test receive on the third since neither of the other two can send.

Difference between the laptops.

The one that can send is an HP Envy circa 2016.  Never had multiplicity on it.  4.07 was the first installed

The two that cannot send, Lenovo W520 circa 2011, so even older.  However, both also previously had Multiplicity 3 installed via Steam.  On the main one I foolishly installed v4 (downloaded directly from Stardock, not Steam) and installed it.  When I tried to uninstall v3 via add/remove programs it seems like it uninstalled v4.  I tried to cleanup best I could and uninstall from Steam, etc. and install v4 "clean."  On the second w520 I uninstalled v3 first then installed v4.  The primary w520 still left a bunch of cruft in places like firewall rules, etc. that I tried to cleanup by looking at the HP that had the single, clean install of v4.  The other w520 have not checked but assume it has the same cruft.  Since my attempt to clean up the primary yielded no obvious value, I did not spend the time cleaning up the other w520 yet.  I feel like the two w520s still have v3 cruft but did not capture what I saw that made me think that.  I think one of them popped up with old settings after a supposedly clean install.

My target setup has a w520 setup to receive with speakers plugged into the USB port.  My primary laptop I wish to setup to send, has a speaker plugged into the audio jack on the laptop.  The HP Envy that is setup to send has no external speakers setup, just the built-in one.

What I found experimenting between them.  I can setup [either] one of the w520s to receive and can setup the HP Envy to send.  This works.  If I temporarily disable the receiving w520 (uncheck the box) and try to send from the other w520 I get a delay and then an error message that says the targeted laptop is not setup to receive which is expected.  If I, then enable the receiving laptop again and try to enable sending from the other w520 it makes no complaints but never sends the audio. Audio continue to play on the local speaker.  HP sends fine.

So, my question is four-fold.  First, should I even expect this to work on hardware this old?  Two, how can I completely, cleanly uninstall Multiplicity and make sure there is no cruft from either the current v4 install and the previous v3 install either on the file system, in firewall rules, registry and any other place that Windows squirrels away settings and configuration data?  Three, where can I look for some sort of message/indicators this is working or doing something other than just poke-n-hope?  Four, is there a way to test using telnet or some other CLI method that will not hide error messages behind a GUI?

 

Stardock Software Multiplicity Type: Bug Report
81 views 1 replies
Reply #1 from Stardock Forums Top

The split you are describing lines up with the install history more than the hardware. The laptop that sends is the one that only ever had a clean 4.07 on it. The two that will not send are the two that had Multiplicity 3 from Steam taken off by hand.

For a genuinely clean removal, use the purge file rather than Add/Remove Programs: https://cdn.stardock.us/support/uploads/Purge_MP-New.zip Right-click it and choose Run as Administrator, and on Windows 11 you have to pick "Show more options" first to see that entry. Save your work before running it, as the PC may restart.

Two parts of that matter for your situation specifically. The purge does not touch Steam, so on any machine that ever had the Steam build you also need to use the uninstall option in the Steam client itself. And rather than repairing the leftover firewall entries, remove all the Multiplicity Windows firewall rules and let the reinstall recreate them.

Run it on all three PCs rather than just the two that are misbehaving, then reboot and reinstall everywhere. A version mismatch between machines causes its own problems, so you want them all on the same build afterwards.

Once they are clean, the audio-specific setting worth knowing about is under Enable audio sharing, Advanced settings: "Disable Windows 7/8 jack detection". Windows will sometimes decline to send audio when it decides no output device is attached, and that option bypasses the check. It is one of the documented causes of a sender that reports no error and sends nothing.

Your own test is informative here. When you disabled the receiver and the sender came back saying the target was not set up to receive, that tells you those two machines were reaching each other. That points at the sending side rather than the network path between them.

On your third question, the receiver is the better place to watch. All shared audio arrives as the Multiplicity process, so anything getting through shows up as Multiplicity in the Windows volume mixer on the receiving PC. There is also a Multiplicity Audio system tray icon with a Configure Multiplicity Audio entry, and a secondary option to show that icon whenever a machine is sending.

For your fourth, audio runs on TCP 30567, separate from the main service on 30564. That is the port to test reachability against from the sending W520. Two related things to confirm while you are there: that the Multiplicity Inbound rule is enabled in the firewall on each PC, and that you have tried the receiver's IP address rather than its hostname in the "Send audio to" field. The audio passcode is also separate from your connection passcode and needs at least six characters.

On the age question, nothing in the audio requirements rules out a W520. The only hardware-class exclusion documented for audio sharing is Windows XP. Multiplicity 4 did move to a newer CPU instruction set than 3 required, with a 32-bit fallback for older processors, but that governs whether the product runs at all, and yours plainly runs.