This issue keeps cropping up. This was my system utilization at the time it occurred on a wired 1gb Ethernet connection.

To what degree and frequency? When (after a sleep for example) would also be helpful information as well as MP version, OS version.

Sean Drohan
Stardock Product Lifecycle Manager

I don't use the secondary for consistent audio output, so I only notice when I go to do something and it doesn't make the correct beeps and boops. I do like me some beeps and boops. Primary is a Windows 10 desktop, secondary is a Windows 10 laptop. Both are on version 22H2. Both are configured to never sleep (when plugged in, as they are when I'm using Multiplicity). Both are using Multiplicity version 3.57.

I ran into a different issue where Multiplicity stopped working entirely, which I resolved by adding the secondary through its IP address instead of just picking from the list. That seems to have helped somewhat with this issue as well- while audio still sometimes stops working, it usually cuts back on a few seconds after I start doing things on the secondary, without needing to actually go through and toggle anything manually. Which to me says something gets turned off due to idleness, but I can't for the life of me figure out what. I turned off every feature I could find that does anything like that, even in the BIOS, to no avail. But maybe I just haven't found the feature doing it.

Anyway, frequency: Hard to say. I can often go 1-3 hours between doing anything with the secondary, but I don't really notice when it works correctly, yknow? Definitely happens multiple times a day, though.

Tuning in to report that I have the same problem. Two devices connected via ethernet (LAN) that can find each other without problem (can ping each other) where audio stops and resumes every minute or so. Tried all the different things, both machines are up to date, the software is up to date.

I tried a suggestion posted by another user, to restart the audio service using "restart-service -Name Audiosrv" in elevated powershell which fixes the issue right away, just like changing certain settings in the multiplicity audio settings does. It's really a bummer that this audio feature isn't working reliably because the entire application is extremely useful and convenient.

I don't know if this was changed in an update in the meantime, but no Multiplicity Audio Device appears in my list of Audio Devices.

I can also report that my secondary PC (the one sending audio) has some built-in audio switcher that changes the output device based on what ports have a device connected. I don't connect or disconnect any devices when the audio is cutting off (or ever, really), but just thought that might be useful to know.

My suspicion is that this is indeed something Windows related. Sometimes it works just fine and goes for hours. It's been working fine for the entire duration that I've been writing this reply. Hoping that a solution can be found

Update:

I can find in the Windows Event Viewer that every time the audio cuts off there is a "Process Termination" event being generated for a process "audiodg.exe", followed some time after with a "Process Creation" event that starts audiodg.exe, which is the same moment when the audio resumes.

A process has exited.

 

Subject:

Security ID:LOCAL SERVICE

Account Name:LOCAL SERVICE

Account Domain:NT AUTHORITY

Logon ID:0x3E5

 

Process Information:

Process ID:0x17a8

Process Name:C:\Windows\System32\audiodg.exe

Exit Status:0x0

Shortly after there is:

A new process has been created.

 

Creator Subject:

Security ID:LOCAL SERVICE

Account Name:LOCAL SERVICE

Account Domain:NT AUTHORITY

Logon ID:0x3E5

 

Target Subject:

Security ID:NULL SID

Account Name:-

Account Domain:-

Logon ID:0x0

 

Process Information:

New Process ID:0x2538

New Process Name:C:\Windows\System32\audiodg.exe

Token Elevation Type:%%1936

Mandatory Label:Mandatory Label\System Mandatory Level

Creator Process ID:0x151c

Creator Process Name:C:\Windows\System32\svchost.exe

Process Command Line:

The creator process name is svchost.exe which on the surface doesn't tell very much. Personally I don't know very much what to do with this,
but I thought it might be useful to you all

Hello,

Sorry to hear you are having trouble.

As a test, use the MP Audio systray app to 'unmute' the sender.  This will indeed have the sender actually play audio. If that is acceptable (meaning, you don't care that it does), keep it that way and see if it ever cuts out. If not, I suspect Windows - not seeing that anything is being played - does that shutdown effort you detailed? That would be even more the case if the sender is any form of laptop and enlist a host of power-saving measures. 

If the sender playing is not acceptable, you might conder plugging in some wired earbuds to it.  Still sending audio but no one can hear it. 

Sean Drohan
Stardock Product Lifecycle Manager

Been experiencing this problem for months, tried all the suggestions everywhere I could find including here, and finally found a fix for mine. 

I somehow found a suggestion to try running LatencyMon for audio related issues and after checking the results with an LLM (actually being useful!), it managed to provide a few possible scenarios. Turns out the problem was actually a failing HDD that seems to be interrupting the CPU and that somehow breaks the audio sharing in Multiplicity. Unplugged that HDD about 10 days ago and have not had any audio issues since.

Bottomline: Try running LatencyMon to see whats potentially causing audio issues. Even if the main cause for your problem is different from mine, it might just help you identify it.

Was that on the sending end or the receive end?

This was on the sending computer.