USB Audio Cards via VirtualHere (audible artifacts added)

Yes if you have a fancy audio card you will probably get artifacts due to network latency. Simple audio devices like headsets etc usually work ok on a LAN network and sometimes in a WAN network. It all depends on latency.

But professional audio devices try to sync on audio frames and these do not have regular packet timings in a usb over a networked environment

I have heard that voicemeeter banana greatly helps with this because you can feed one end of the passed through audio device into voicemeeter then change the buffer size and output to a virtual audio device which you make active in windows and most clicks will go.

Yes regarding voicemeeter banana select the passed through usb sound card as the hardware input device and then go to menu->System Settings->Options and set the all the buffers to the maximum e.g 2048 samples. And you can also try setting the synchro delay to 200ms

I'm interested in this subject as well. Similar to the original poster, I've got a Raspberry Pi connected to a USB audio output device, with VirtualHere (Linux) running on the RPi. I've got a Windows machine I'd like to stream audio from to the RPi. In this Audio USB Device -> Linux VirtualHere server --> Windows VirtualHere client scenario, I've got it working, but hear the clicks/pops as well, likely because of network latency as noted.

The recommendation to try VoiceMeeter makes sense, but I wanted to clarify the proposal. Is the idea to run VoiceMeeter on the VirtualHere server, or on the client? That is, do you suspect VoiceMeeter might solve my problem, or would I need to run e.g. Device -> Window VirtualHere Server -> Windows VirtualHere Client?

FWIW, I just investigated using the Linux "Jack" tool to make this work. Jack allows for control of various buffers, so I tried setting that up on Linux. Unfortunately, I hit some snags because once I started VirtualHere on the RPi and shared the audio device, Jack stopped "recognizing" the USB device. I suppose that makes some logical sense, but wanted to mention it. Jack is often cited as the closest Linux equivalent to VoiceMeeter, so I thought I'd try it, but have thus far failed to use it as a solution to the click/pop problem in this scenario.

Thanks for any other tips!

Small typo correction/clarification in my last post:
"That is, do you suspect VoiceMeeter might solve my problem, or would I need to run e.g. Device -> Windows VirtualHere Server -> Windows VirtualHere Client? I mention Windows on the server specifically because VoiceMeeter does not appear to support Linux."

Voicemeeter would run on the client, nothing extra runs on the server.

Essentially with isochronous (sound) data which is transmitted via usb, there is no way for existing devices to understand that there is extra latency in the link (due to streaming over the network) so voicemeeter etc programs sit on top of the usb device stack in the operating system and increase the buffer size to counteract the extra latency. Thats the theory of how it works.

I dont know why Jack would stop recognizing the device if its passed through virtualhere to the pi. I would have throught it should work ok.

In Linux, the virtualhere passed in device would appear attached to the usbip vhci host controller and would just appear as any other usb device would (except not attached to a physical usb host controller would be the only difference)

Thank you very much for your prompt reply! One other quick followup - you mentioned in your prior post to select the passed through USB audio device as the "Hardware input device" in Voicemeeter Banana, which is itself running on the client as you noted. In my case at least, I only see a microphone device and the Voicemeeter outputs listed under each of the "Hardware input 'n'" menus. Example screenshot:
http://www.renzelmann.com/temp/voicemeeter.png

In this screenshot, I've selected the voicemeeter device as "hardware input" and the passed through USB audio device as the hardware output shown as UAE27 PCM_DSD on the right. These selections appear to be at odds with your recommendation, which suggests to me that I'm overlooking something basic. Can you confirm either way? Perhaps my Voicemeeter installation is simply faulty for some reason since it does not list the passed through USB device as expected?

Thanks again!

Also, just to confirm, if the objective is indeed to select the passed through USB audio device as the "hardware input" in Voicemeeter Banana, what device would I select for the "Hardware out", shown on the right in the screenshot above?

Here is an email stream (start reading from the bottom) from back in 2018 from a user I was working with. He had some latency but a fast link 10mbps up/down and was trying to use a local headset with a cloud machine. Im having trouble following the instructions from back then, i sort of forgot my exact setup. But play around with voicemeeter and see if you can get it to improve.

Hey mate. Where the buffer settings are, set the Synchro delay to just above your latency, 
like the nearest 5-10 Ms. Perfect stream!!!! Makes things more stable and gets rid of those little disturbances.

    On Tue, Jun 5, 2018, 2:23 AM VirtualHere  wrote:

        Ok yes 150ms ping to singapore is too big, its not good.

        On Tue, Jun 5, 2018 at 3:47 PM, customer  wrote:

            I wouldn't go too far. I do get some audio disturbances with a 38 millisecond ping to my server. 
            But for the most part it sounds pretty good. Much better than the harsh garbled mess that I got before.

            On Tue, Jun 5, 2018, 1:05 AM VirtualHere  wrote:

                Confirmed! used an EC2 in sydney 20ms and it fixed it greatly.  will try singapore..

                On Tue, Jun 5, 2018 at 10:09 AM, customer  wrote:

                    Oh yes and make sure you set voicemeeter as your default audio device. I forgot to mention that in my excitement.

                    On Mon, Jun 4, 2018, 8:05 PM customer  wrote:

                        Windows 10 eliminated the option in the registry but I absolutely got it working mate!!! I was just 
                        rocking out to some heavy metal through the headset to test it. I get a couple pops and crackles here and there
                         but it's not bad at all. Download VB Voicemeeter or Voicemeeter Banana(both free). Install and reboot. Now 
                        set output A1 as WDM with your main sound device. Set all buffers for A2 to Max(2048 for most of them). 
                        Set your headset as WDM device for A2. Set your headset as WDM input and volume to minimum
                        (Seems you need VM to initialize it but you don't want to duplicate the sound if you are a twitch 
                        broadcaster although other settings are probably fine if you want to hear yourself in other circumstances). 
                       Set up other applications as you normally would and enjoy!

Thanks for the email thread! It sounds like the scenario in the email is slightly different, though one would assume that if it were artifact-free over the internet, it'd be artifact free on my LAN, which at least between the server/client is wired 100mbps with <1ms latency and effectively zero packet loss.

I just tried a bunch of experiments, but sadly, have nevertheless failed to eliminate the artifacts so far, or even reduce them meaningfully. I've got Voicemeeter Banana working on the client machine, which is where I'm hoping to play music "over the network" to the raspberry/USB audio device. I've configured the client with the Voicemeeter Input as the main audio output device in Windows. Then, that virtual audio device ("Voicemeeter Input") is tied to the A1 output in Voicemeeter Banana (by default - I don't have to change anything), which I have set to the passed through USB audio device.

Then, in Voicemeeter Banana, I've tried the following adjustments:
- Modify the settings as noted to increase all the buffers for A1 to the maximum values.
- Modify the same rate options (e.g. 44khz vs 192khz and others), including "Preferred Sample Rate"
- Modify the "monitoring synchro delay" in various ways, e.g. 0ms or 500ms
- Selected several different passed through USB audio output devices; in particular, there's an MME, WDM, and ASIO option, all of which appear to "work," in the sense that audio does get output on the server
- Modified Virtual ASIO Type from Float32LSB to Int32LSB and back

These changes all seem to work, in the sense that I can get audio to play on the server, but all still suffer from similar artifacts. The Monitoring Synchro Delay definitely has an effect - it's clear when e.g. skipping around in a file that the 500ms penalty is incurred. Similarly, Int32LSB sounded dramatically worse than Float32LSB. For these reasons at least, it's clear that the audio playback application is successfully using Voicemeeter Banana -- the changes are resulting in perceivable quality changes.

At this point, I also tried installing the Virtual Audio Cable driver, also from the same company. It has additional latency options, e.g:
http://www.renzelmann.com/temp/voicemeeter2.png

In there, I increased every latency I could find to their respective maximums. I then reconfigured Voicemeeter Banana to use the virtual audio cable output as its main hardware input, and changed Windows to use the cable input as its main audio output. The effect was thus: software player --> Windows default audio output device (cable input) --> Voicemeeter hardware input device 1 (cable output) --> hardware output A1 (passed through USB device) --> ethernet --> raspberry / virtualhere server --> USB audio DAC output to amplifier. Even with the extra latency added virtual Virtual Audio Cable, which in my case was significant because I maxed it all out, the damn thing still had audible clicks/pops/distortion.

FWIW, audio quality overall was probably slightly better when avoiding Voicemeeter Banana entirely, and simply outputing to the passed through device directly. That is, even with all this additional buffering, the overall change was modest at best, unfortunately.

Also, to confirm, if I play the same audio files via DLNA/upnp to the raspberry, playback is fine, so I know the raspberry and the files are otherwise OK. DLNA is how I've been doing this, but the idea of a virtual audio device has a lot of appeal because it opens up the possibility of playing arbitrary audio to the raspberry over the network and would eliminate the need for DLNA-compatible software.

At this point, I'm running low on ideas :p I'm curious to hear if the original poster has any better luck. I'm actually tempted to set the raspberry aside and try this all with a real windows machine (x64 etc) running the server to see if that'd improve it but that'll probably have to wait a while, heh. Let me know if you can think of anything else to try :p

OK thanks for the info. At least this might be helpful for other customers reading this.

I'm trying the same setup and getting poor results. Has anyone gotten this to work?

No its not going to be perfect because of network latency. The USB signal cannot be buffered and network latency is variable. I have done some more experiments over the last few weeks and if i sent the USB data exactly with no drops, the sound will get further and further behind. This is expected behavior as the latency will be cumulative to the signal the longer you stream. So the best way is the way it works currently is that some packets will drop because the network is too slow to carry them.

I would like to link a Behringer X32 Mixer with USB ASIO connectivity to a Windows gaming laptop running OBS.  This should be a very low latency network.  The only thing on it would be a five port switched hub with two existing HD PTZ cameras and the aforementioned laptop.

Has anyone tried that?

If no one has, I am likely to try it in the next few weeks.