Windows VM Audio Crackling

Okay. Thanks. I am not an expert on this, but you may be having a resampling issue or a buffer size issue with Pulse. This all comes down to the host hardware and what it is capable of. I would say, see if you can force the pulse device that you created to output something like 41Kz sample rate and play with the buffer size (try a little larger) to see if you can get the crackles and pops to go away.

There was also mention in another thread that you can actually use Pipewire to help with this. Pipewire is a PulseAudio and Video infrastructure replacement that gives a little more control about howto route video and audio and sync it together. Basically it is a mix of Jack and PulseAudio.

Could you send these threads? And do you have any other sources for me in relation to these options?

I don’t know what your distro is, but the ArchWiki can help you get through it, if you want to go the PipeWire way.
https://wiki.archlinux.org/title/PipeWire#Audio_is_distorted

Not really. You can search the forvm for a solution, It has been covered many of times but the use cases are all different. If you are trying to use Looking Glass, then search for that here on the forvm. There is an updated guide that was created.

These troubleshooting tips might prove useful.

For what it’s worth, my audio config is more barebones than yours and works fine, but not all hardware behaves the same.

    <sound model='ich9'>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x1b' function='0x0'/>
    </sound>

edit
I checked my passthrough config on another machine, and on that one, I’m defining things in the <qemu:commandline> section as described in the link above.

I attempted the method provided in the article you linked, and it appeared that the audio is just as bad if not a little worse? added a distortion to it almost? I’m not sure.

Thank you for the help.

I am using Manjaro, and I would like to try something with Pipewire but there appears to be a lock on it. Shown here:

ls /run/user/1000/                                                                       
pipewire-0 pipewire-0.lock

If there is a way to remove the lock I could try it, but I’m not really sure what the best method for that would be.
I found this thread about audio integration with looking glass as you mentioned, I’m going to try this.

I’m looking through the comments of the thread provided and it seems there are a ton of issues with this method? Am I interpreting this correctly?

There should be a newer guide than that.
Here is a more recent one using the network sound driver from MS Windows.

This one is along the lines of the thread that you linked.

In regards to the lock, you may have to stop the pipewire service first.

I am sorry for the late reply, I now work another shift at work and it has been keeping me hella busy.

1 Like

Have you looked into using Scream over the bridged network?

ArchWiki - Scream VFIO

GitHub - Scream

I got scream setup in April and haven’t had any audio issues since.

2 Likes

I used the Arch Wiki setup along with Looking Glass. And now Looking Glass will no longer display. Is there any way to remedy for this?
Update: I tried the solution that @Mastic_Warrior posted within one of the threads he mentioned but it did not work. I also followed the guide from looking glass and that did not work either. The Scream device is listed within the virtual machine and also in my host but is not producing any sound, am I doing something wrong?

Thank you for your help.

Unfortunately I don’t run Looking Glass so I cannot really assist there.
@gnif is the Developer of Looking glass. Let’s see if he can assist with getting your display back.

Just attach a monitor to see what is going on. Looking Glass can only take over from the moment Windows had successfully booted and started the Looking Glass Server. If your Windows is not booting successfully you will see not output in Looking Glass. Sometimes it won’t even start during the login screen, this is why automatic login is recommended.

I can confirm that Windows is running when Looking Glass is not responding, and I do not usually have an issue with the login screen, Looking Glass usually works and I am able to login.
By looking at a lot of the threads around Scream and Looking Glass I think it is a case where Scream is stealing the memory set aside for Looking Glass? When I remove the memory that is used for Scream from the xml the issue is gone. But I can’t explain the lack of functionality for Scream over network. I’m not really sure what the solution could be.

Thank you for your help.

This would be nice.

https://github.com/duncanthrax/scream#using-ivshmem-between-windows-guest-and-linux-host

I suggest you ditch SCREAM completely and use QEMU’s inbuilt audio layer with the Jack audodev (also works with pipewire).

1 Like

Do you have a guide I can refer to? There is a lock on pipewire and don’t know how to get rid of it.

Thank you for the help.

Not sure, but there seems to be some good information here:

https://www.reddit.com/r/VFIO/comments/kcl2pl/best_solution_for_pipewire_with_vfio/

I know it works well as several in the LG discord have discussed their success in making it work.

2 Likes

dunno if you have the option but try reducing the bitrate to 44000 or 48000 and the bit depth the 16 or 24 … (16 =cd/dvd quality 24 for high quality zero compression audio)
if set to high you will get random electrical noise from your system especially when over 48khz.

1 Like

QEMU only supports 48KHz or it has to resample, and a maximum of 65535Hz (or, 65.5KHz) due to it’s design, so you’re best to just go with 48KHz

If you are getting “random noise” at > 48KHz you have a broken sound card or bad drivers. Coming from an electronics engineering background, increasing the sample rate can not induce “random nose”, all increasing the sample rate does is allow you to sample higher frequency audio that is outside of the human hearing range and only makes sense if you’re doing professional audio work (aka, mastering).

Humans average range is 20 Hz to 20 kHz, in order to faithfully reproduce 20kHz we need to sample at a minimum 2x that, at 40kHz (see: Nyquist frequency - Wikipedia). Some people can hear slightly higher frequencies so we sample at 44.1kHz to give some headroom and a few other technical reasons (see: 44,100 Hz - Wikipedia).

In short, if you can hear “random noise” when you sample at higher rates, then you have faulty hardware as any additional noise being captured should be outside of the range of human hearing.

An extra tidbit of information, 48kHz is the industry professional audio standard, not 192kHz as people would have you believe.

2021-10-01-230051_610x89_scrot
https://www.aes.org/publications/standards/search.cfm?docID=14

Yeah, I am unfortunately one of those people. Sometimes this becomes highly annoying because people’s homes and the offices are hella noisy to me. At other times it is funny since my reaction to those noises is the same as a dog to a dog whistle; flip a switch or plug in a power brick and my head tilts to the side.

By slightly higher I mean 21-22Khz, it’s literally only a tiny amount, not enough to warrant > 48KHz sample rates.