rtuite

Join Date 02/2017

Multiplicity Audio Sharing can't find other PC

I have 2 PCs on my desk with 3 monitors each. I have been using Barrier to use them all with one keyboard and mouse, but it has been buggy and crashes in a way that forces me to reboot losing everything I was working on. I am on a trial of Multiplicity now and would like to get the audio working as my current solution relies on a physical connection which is very poor quality. If I can get this working, I'm definitely buying Multiplicity.

However, when I try to set up the Audio Sharing from the secondary machine, I get an error "Unable to find a computer with the name provided on your network." However, the Control function is working perfectly. I'm using it right now to post this from my secondary computer using the HID devices on my primary computer. There is zero perceptible delay, so I know the networking is good.

I manually added inbound and outbound rules for TCP and UDP for port 30567 on both machines, still no dice.

Edit: I completely disabled Windows firewall on both devices and still can't connect. I can ping both directions and, like I said, the remote connection between the two systems works fine.

stardock software multiplicity

Advanced Search

Watch this post

Do not email me updates for this post Email me updates for this post

Successfully updated karma reason!

Hello,
Sorry to hear you are having issues. Please review this guide: https://forums.stardock.com/486104/multiplicity-support-faq#audio. Do report back if you still have issue.

Thanks
Basj,
Stardock Community Assistant.

Successfully updated karma reason!

I know I rebooted both machines after installing, but rebooting both again worked.

I do have a connection, and I can get audio across. But after 30 -60 seconds it gets EXTREMELY choppy. I set the buffering control to maximum, and it does not help. Even though videos are almost unwatchable because of the audio delay, LOL.

I'm on a gigabit connection and tested my connection between the 2 PCs using CommTest and I'm getting around 120 Mbps in and 50 Mbps out with zero latency on the sending PC. Assuming audio is in the Kbps range as it normally is, bandwidth should not be an issue.

Successfully updated karma reason!

Hello,
I have forwarded your problem/question to Stardock Support Team for their assistance. Please keep an eye on this thread for any updates. We appreciate your feedback and patience.

Basj,
Stardock Community Assistant

Successfully updated karma reason!

sdrohan

Join Date 10/2012

+674

Hello,

Sorry to hear you are having trouble.

and would like to get the audio working as my current solution relies on a physical connection which is very poor quality.

Why is the physical connection 'poor quality'?

If you unmute the sender, is its sound 'choppy' from it as well?

The reason for asking is MP sends what it 'hears'.

Are both PCs on the same connection medium (Ethernet, wireless, for example). If at all possible, test with them both connected via Ethernet.

Sean Drohan
Stardock Product Lifecycle Manager

Successfully updated karma reason!

After doing some more testing and rebooting both machines again, I have a little more info. When I log in to the machines and start audio on the secondary, the audio will play normally for a 5 to 10 minutes then start stuttering. If i stop audio for a few seconds then start it again, it will play normally again for a minute or 2 but start stuttering again. It seems to play longer without stuttering the longer I let it sit without playing audio. I've monitored system performance on both systems and it's normal.

I also performed a recording on both systems showing the issue, here is a hastily edited video showing the issue.
https://youtu.be/2HcvBTCOxWo

1) Physical audio connection is poor quality because it's an analog connection from my laptop docking station (secondary PC is a laptop).

2) I've enabled that and the issue persists as described above.

3) Both PCs are on wired gigabit connections to the same gigabit switch.

Edit, System spec detail: The primary PC is a desktop, the secondary PC is a laptop.

Desktop is a Ryzen 3700x with 64 GB RAM running Windows 10 Pro
Laptop is a Dell Latitude 5521 with an Intel i7-11850H and 32 GB RAM running Windows 11 Pro
Both systems have NVMe SSDs.

Successfully updated karma reason!

sdrohan

Join Date 10/2012

+674

Quoting rtuite,

reply 5

2) I've enabled that and the issue persists as described above.

But did the sender still have something plugged into it to render sound (<--this is important). There are two results that would be telling:

1. Is the sender choking and sending garbage. You would be able to hear this with speakers \ headset \ earbuds plugged into the sender.

2. Is Windows tapping out if it does not see that it's actually rendering sound (nothing plugged in). If there is no issue when there is a device to render sound plugged into the sender, that would be the cause.

Also, as a test, if you switch what is the sender and receiver, can you reproduce the issue?

Sean Drohan
Stardock Product Lifecycle Manager

Successfully updated karma reason!

I can say for sure that local audio is muted when this feature is enabled. The "muted" icon appears in the task bar.

I swapped the sending/receiving machine and it does seem to be working for ~30 min or so.

I don't understand what you mean by "it does not see that it's actually rendering sound (nothing plugged in)". There is a device plugged in and available to Windows, and the sound icon in the task bar goes to a "muted" icon (speaker with an X next to it) when audio sending is active. This behavior is consistent between both systems on the sending system. On the laptop, it's the USB docking station. On the desktop it is my wireless USB headset.

I wouldn't be able to hear anything because Multiplicity mutes the local audio output. Windows still renders it though, which is why I was able to pick it up with OBS and create the recording I sent. In the recording you can hear that the sending system is not stuttering at all when the stuttering is happening on the receiving PC. I can tell you didn't look at the video (there are no views, LOL), it's probably worth the 3 and a half minutes it will take you to look at that. (https://youtu.be/2HcvBTCOxWo)

Successfully updated karma reason!

Correction... I was just playing a game on the primary PC with the audio still being routed through the secondary and my audio died entirely. I had to disable the feature to get the audio back.

Successfully updated karma reason!

sdrohan

Join Date 10/2012

+674

Quoting rtuite,

reply 7

When the sender is set to be unmuted:

You can then adjust the sound on said sender:

When this is the case, you would hear sound coming out of the sender via its speakers as well as the receiver. With this method, we will know if the sender stop sending or if the receiver stop receiving....

Quoting rtuite,

reply 7

On the laptop, it's the USB docking station.

For these tests, please eliminate that from the equation...

After reviewing your recording, if I had to guess, its one of two things.

The receiving PC is getting crushed. Does Task Manager show something crushing the PC? Are you sending a monster amount of network traffic between the PCs?
Something is communication on the Port MP uses for audio: 30567.

You can try changing it to something not in use (on both PCs) but that will not guarantee something might not still broadcast on it.

Sean Drohan
Stardock Product Lifecycle Manager

Successfully updated karma reason!

OK, sorry I haven't reported back. I've been insanely busy.

After your last suggestion about the docking station I changed my output device in Windows 11 to the internal speakers as opposed to the USB output (which is how Windows sees the thunderbolt docking station). This seems to be working. I haven't had any issues with intermittent use over the past few days.

Previously it would work fine for upwards of 20 or 30 minutes without an issue, but would then start stuttering. I've been able to have music playing for at least an hour with no issues. I'll report back if the issue returns.

Thank you for your help!

Successfully updated karma reason!