Ah, I’ve tried a lot of different things that people suggested, just searching. But none of them work and I really can’t figure out why. Guess I’ll just have to find some other way unless someone manages to figure out what’s wrong. 
I recently switched to using JACK + PulseAudio which is working well for me, for some reason on kernel 5.0 when I would resume from suspend PA wasn’t seeing my built-in audio anymore but it was there in alsamixer and I could run speaker-test on it without issue so it was still working but PA didn’t want to pick it up. However one more thing I would say to check before you try to switch to JACK, and again because I did this so long ago I probably forgot about it, is by using the “paprefs” utility to ensure that remote connections are allowed. That is what was adding the preferences more specific to my user which showed up in the XML I mentioned and also in dconf. I’m still using the QEMU PA arguments with the VM as well, also seems to have fixed my audio crackle on VM start as well.
Shameless plug, but I found a better solution for VM audio:
And a video if you prefer:
2 Likes
I am sorry but I simply do not agree, not only does this add overhead due to the IP stack being involved in both the host and the guest, it increases latency. The emulated sound device literally writes to block of memory that is shoved directly into your hosts sound device, there is almost zero overhead. At best this is a workaround.
If you really want to put some time into this issue it would be better spent looking into the QEMU sources and figuring out what’s wrong there.
Yeah, but the thing is that I don’t even know where to start to attempt to try to fix it. Would you happen to know of a guide that you know works? I could try redoing it and hope that fixes it.
I am not suggesting that you @Cookie should fix it, the workaround may suit you. I am responding to @GrayBoltWolf as he suggests that this is a better solution which I challenge. At best this is a workaround.
I see, still if possible I really want to get pulse audio to work. So I’ll keep trying and hopefully I or someone helps me figure out how to fix it. Thanks, I really appreciate all the help that you’ve given me, fixing the various issues that I’ve had trying to get passthrough and everything to work.
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. 
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
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. 
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.
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?