Missed packets

[RThomasHyde]

First off, I want to tell you that this is an awesome project and I really appreciate the work you've done here!

I'm running my windows guest with virt-manager/QEMU with a bridged network, and the connection between guest and host should theoretically be very fast and stable. However, pwarASIO is giving me some pops and clicks with missed packets and I'm not sure I understand the cause. I'm not incredibly savvy with all of the technologies involved here; could this be caused by a too-small buffer? It seems to be fixed at 128 and I don't see any obvious way to change it.

[ripxorip]

Hi @RThomasHyde ! Thank you very much for the kind works, appreciate it. I actually have a PR: #1 that will introduce segmented packets which will allow for variable buffer sizes. How often do you get the pops? A pop is usually a missed packet due to windows missing a deadline due to a CPU spike etc.

[ripxorip]

@RThomasHyde the PR is now merged and it comes packed with loads of new features, you can now configure the buffer sizes on both ends, the asio driver on the Windows side and 64-128 frame size on the Linux side. Would be super cool if you could run 128 on linux and set the windows one to 512 (ASIO settings in your DAW) designed this feature for you. Cheers

[RThomasHyde]

Sorry for not getting back sooner, I got busy with other things. I'll download the latest and give it a shot, I really appreciate you working on this!

[RThomasHyde]

Ok, these changes are a huge improvement on the user experience, I'm impressed! However, I'm still getting pops in the audio, and I'm starting to question whether it is something wrong with my system. I'm not prepared to assume that PWAR is the problem at this point.

I do not see any CPU spikes on either the host or guest that could explain it, and there are 0 xruns reported in the PWAR gui. The pops are pretty frequent, like anywhere from every couple of seconds to multiple times per second. It also seems like the pops get more frequent the longer I play. I tried setting the windows-side buffer to 512 and 128 on linux, but that just made a terrible noise. I also tried with oneshot mode and it was maybe a little bit better but still getting the pops.

If you want to hear it for yourself, I've recorded a very brief clip that you can find here (but the link expires in a week): https://pub.microbin.eu/upload/mouse-spider-gecko.

[ripxorip]

Thank you very much :) Is the one-shot check box checked? The Windows-side buffer will not work if its checked, so I suppose that's it, also, did you update the ASIO side at the same time?

[RThomasHyde]

I tried with one-shot both checked and unchecked. Here is a rough testing procedure:

On the host side:

1. Install the PWAR .deb package
2. Start the PWAR GUI
3. Pick my input & outputs
4. Make sure the chunk size is set to 128, one-shot unchecked, passthrough test unchecked
5. Set the IP address of the Windows guest
6. Press the Start button

On the Windows guest:

1. Download and register the new PWARASIO DLL
2. Make sure that pwarasio.cfg has the correct IP for the host
3. Start my DAW (Reaper)
4. Choose the PWAR ASIO driver
5. Set the buffer in the DAW to 512 (and check the box to allow Reaper to request a buffer size)

With this procedure, I get horrible noise. even if I stop and restart on the host, same horrible noise. Honestly, though, I also tried many different combinations of startup order, buffer sizes, one-shot state, etc. and I always either got OK sound but with popping, or just noise.

When I'm using only Linux stuff, e.g. the Linux version of Reaper, a Linux-compatible VST like NAM, etc., I can get good sound with pipewire running at a 128 buffer size, so I'm pretty sure the PWAR host buffer size of 128 isn't the reason I'm getting popping sounds, but I'm curious why you don't allow to set a buffer larger than 128 on the host?

[ripxorip]

Hi man! Thanks for getting back to me, I have found an issue with the ASIO drivers sockets and I have a solution. It was only causing issues on lower powered PCs and VMs so I missed it. I have also developed a test suite one can run before actually sending any audio to verify that everything is working and an estimated latency. Will try to wrap that up some evening this or next week before the release. Thanks for your patience, this way you don't need to listen to any noise from my side at least before everything is working :) Appreciate you taking the time to test!

[RThomasHyde]

Any chance of a progress update on this?