Need Help Getting Sound From QEMU

And also thank you everyone who has given me help and suggestions on what I can do to fix the issue, I really appreciate it. :smiley:

What a typical “Linux” user response, don’t use an easy workaround for now, go learn C and dig through source code! Appreciate the response but suggesting to an end-user that they should go poking around in the source code instead of simply using another solution is not a good recommendation when trying to invite users to Linux. You already intimidated the OP by your statement, as shown in his response:

QEMU audio has always been broken and buggy, this is a quick alternative that yields instant perfect results, and latency is absolutely a non-issue if you use a local network bridge (which I recommend anyway if you are also sharing files or using Synergy).

In my subjective testing Scream has far less latency from VM to host via PulseAudio than the ICH6 audio device, my BF also backs this up as an avid OSU! player.

In the meantime I highly recommend Scream while we await the audio fixes to be merged upstream.

That’s not a typical “Linux user” response. It’s a respectable “Developer” response. Don’t hack around the problem when you could fix it the right way.

I don’t think this was your intent, but that statement came off a bit rude and dismissive.

I get that OP may not have the requisite skills, but gnif was simply pointing out that your “solution” is not a solution, but a hack.

Don’t get me wrong, I tried it and it’s a pretty neat tool, and it might be the best we have at the moment, but I think gnif was trying to point out that we have a problem that needs solving and if someone has the skills to fix it or if anyone wants to take a crack at it, they’re more than welcome to.

1 Like

By all means, anyone with the skills should take a look. But in the meantime it is quite rude to shoot down a good alternative and assert that the user should dig through source code.

I stand by my statement, I don’t feel that gnif’s response (as you say, “developer”) was appropriate in this thread which was pretty clear by this:

I never stated Scream was a replacement for native support, but rather a good alternative to the previous posts which were changing all sorts of random settings to get audio working.

Now rather than appreciating the hard work of duncanthrax, we’ve discouraged a user from a quick solution to their issue.

And really the issue here isn’t even at the point of QEMU handling audio, it’s not able to connect to pulse because pulse doesn’t seem to be configured quite right to accept outside connections, so I’m agreement that it’s pretty cool, and will probably work to get around this, but it’s not a true solution to what is trying to be achieved.

1 Like

Understood. @Cookie I would check to make sure you have these settings confirmed:

It seems like we’re all in agreement and are simply arguing over politeness?

1 Like

Sounds good to me.

PulseAudio has some strange quirks, I’m interested to see if OP has the edits from my original guide, they yield great results for me and those I’ve helped in person.

If we can get audio at all that’s a major step, avoiding stuttering is a whole new discussion. :wink:

1 Like

They got me closer to having it flawless, that’s for sure.

Hello all, thanks for all the suggestions and help that you guys have given me. I managed to get it to work, it was a permission error all along. Now the only issue that I have is that there is a bit of lag and the occasional popping/crackling. Like when you’re watching a video the lip syncing is off, anyone have a reconmendation on how to fix that? Also I wasn’t really intimidated, it was more of a “I’m gonna need a lot of help to do this” XD. I mean I’ve made it this far, not going to waste all that work for nothing.

Actually this was not what I stated, please go back and read things more carefully. I said to YOU, that YOU should do this since you made a “Shameless plug”, which implies that YOU are the author of Scream and as such a developer yourself.

I challenge this statement, it is not a better solution, it’s a hack. I am by no means discouraging the workaround until it’s fixed, I am simply disagreeing with your bold statement.

But in real world actual latency testing which is not hard, it adds substantial latency, I know, I have tested this. I am extremely familiar with the Windows and Linux audio subsystems as I am the author and inventor of Kodi’s platform agnostic audio subsystem. I have a pretty good understanding of how the physical audio hardware operates also. The bad cook in the kitchen here is Pulse Audio, which TBH I could go further into, but that’s a discussion for another thread.

Indeed it did.

I also agree, it’s actually something I have wanted in the past for other projects and I do intend to play more with it.

Not really, we were trying to narrow down the fault so that it doesn’t just help @Cookie but everyone that uses Qemu.

Also please note that @Cookie and I have been in communication outside of this forum and I have spent quite considerable time helping him to get his KVM setup working correctly. I am by no means dismissive of his needs nor do I suggest that he start pouring through the source code.

:orange_heart::yellow_heart::green_heart::blue_heart::gift_heart::blue_heart::green_heart::yellow_heart::orange_heart:

2 Likes

Also is the audio latency normal, is there anything that I can do to reduce it? Should I not use pulse audio then and should I make a new thread asking about it? Oh and got any plans to stream this week?

First let’s address the crackling, etc… The technical term for this is a “buffer underrun” btw. I have found that the PA code in Qemu is whats lacking a this time and in my personal opinion a better workaround is to tell Qemu to use ALSA instead. It will still be using PA as there is a ALSA to PA shim, but using this method in my experience it completely resolves all guest audio issues without any custom software on the guest.

See if you can get aplay working as the user you’re running Qemu as.

aplay -L should list all the devices, one of which should be pulse.

If you can get this working you should be able to do what I suggested earlier and tell Qemu to use ALSA by setting the QEMU_AUDIO_DRV environment variable to alsa.

Here are the exact environment variables I am using with great success:

# tell qemu to use ALSA
QEMU_AUDIO_DRV=alsa

# tell ALSA to use the output device called "pulse" 
QEMU_ALSA_DAC_DEV=pulse           

# tell ALSA to use the input device called "pulse"
QEMU_ALSA_ADC_DEV=pulse           

# total size of the audio buffer to setup for DMA to the hardware
# this varies depending on your hardware, some can handle low values which = lower latency
QEMU_ALSA_DAC_BUFFER_SIZE=512

# how big each period inside the buffer is (512 / 128 = 4 periods)
# this affects how often the kernel will wake up your application for more data.
QEMU_ALSA_DAC_PERIOD_SIZE=128

Note though that the buffer and period sizes will likely need to be tweaked as these values are specific to your hardware. In simple terms these dictate how much audio data is to be buffered between each audio thread wake up. I have a professional audio card which can handle extremely low values so what you see here may already be too low (although they are conservative as I don’t need extremely low latency for my guest VM). Note that these values must be powers of 2.

For completeness the total latency is calculated using the following formula

latency = sample rate / buffer size

For example, at 48000Hz (48KHz), the latency would be 48000 / 512 = 93ms

For more detail on this specific subject see: https://www.alsa-project.org/main/index.php/FramesPeriods

Removing PA will break tons of stuff, most packages that have any kind of audio support now depend on PA and removing it will break audio for other applications. It also does increase latency and reduces quality (forced 48KHz re-sample by default) but not enough that you would care unless you were dealing with studio quality audio, and if you were you would already be using “JackAudio” instead.

Yeah, tonight actually I plan to have a go at the Division 2 now it’s out. I have been away on a camping trip and only just got back.

Welp, I get

alsa: Could not initialize ADC
alsa: Failed to open `pulse':
alsa: Reason: Connection refused
Failed to create secure directory (/home/cookie/.config/pulse): Permission denied

Like I said, start with aplay. What does it give you?
Btw, aplay is a wav file player, if you don’t care for the noise you can use random noise as it’s input… ie

cat /dev/urandom | aplay

This must work before qemu will

It shows the help menu.

Ohh, yeah it works, I can hear the static.

Excellent, so what user is Qemu running as? and I can’t remember, are you using libvirt?

QEMU is running as my user and I think so. Libvirt is the one that uses <> and not - in the XML file right?