Sound is laggy/stuttering

[MagicManICT]

If I understand the question correctly, there is no programming involved. This is a console command, similar to cheat codes and console commands in other games. When you press the colon key ':', it opens the command console. Type the rest of the command and push enter. Make sure you don't type it into chat or you just send what you're trying to do through chat. You can change the number and make it larger if your sound is stuttering.

[SiO2]

When you press the colon key ':', it opens the command console.

Thanks.
For my Core i5 2450M + 4 Gb RAM (notebook) + W7 x64 + Java 8 x64 (update 71)
:audiobuf 2048 makes that terrible noises just a slightly laggy. Raising audiobuf any further seems to be useless, so this is a performance issue, probably.

[linkfanpc]

Oh yeah, and can confirm. 8192 fixes laggy sound.

Woot-woot! Beautiful work on the music Seatribe! Love you guys!

[Ragnar214]

Do I have to input the script code every time I start up the game and log in?

WOW.

So this fix makes the whole game work better.

My fan is no longer screaming (And I have a pretty high end PC) It used to scream playing this. I thought it was the graphics.

It's the Audio.

Changed it to 8192 like you guys said. Game works basically flawlessly now.

[loftar]

My fan is no longer screaming (And I have a pretty high end PC) It used to scream playing this. I thought it was the graphics.

I find it extremely hard to imagine that the audiobuf command would change that, though. It doesn't change the total CPU usage of the audio thread, only how much audio it buffers at a time. Then again, of course, I can't really imagine why any value above 1024 should be necessary to begin with, since that's already more than 20 ms of latency sensitivity.

Thinking about it, could it potentially be that some audio drivers have some extreme overhead in submitting an audio buffer? Do you guys who have audio troubles have some particular sound card in common?

[strpk0]

My fan is no longer screaming (And I have a pretty high end PC) It used to scream playing this. I thought it was the graphics.

I find it extremely hard to imagine that the audiobuf command would change that, though. It doesn't change the total CPU usage of the audio thread, only how much audio it buffers at a time. Then again, of course, I can't really imagine why any value above 1024 should be necessary to begin with, since that's already more than 20 ms of latency sensitivity.

Thinking about it, could it potentially be that some audio drivers have some extreme overhead in submitting an audio buffer? Do you guys who have audio troubles have some particular sound card in common?

Could using integrated audio chips be the problem here? I'd imagine most if not all people nowadays don't bother purchasing fancy dedicated audio cards, and instead just settle for the motherboard solution.
Do you use a fancy audio card? Could be why the sound is fine for you, if so. I'm using a Realtek ALC662 and do have pretty bad audio stutter issues, for the record.

[MagicManICT]

Could using integrated audio chips be the problem here? I'd imagine most if not all people nowadays don't bother purchasing fancy dedicated audio cards, and instead just settle for the motherboard solution.
Do you use a fancy audio card? Could be why the sound is fine for you, if so. I'm using a Realtek ALC662 and do have pretty bad audio stutter issues, for the record.

Interesting question, but it really depends on motherboard manufacturer and model. Some of the integrated audio processors are discrete hardware processing types, others are software processors, ie rely on the CPU to handle all of the processing. For software processing, any latency in CPU processing (low frame rates, etc) are going to seriously hinder audio performance, too.

[Granger]

I noticed sound always being fine with one client open, having multiple of them the stuttering happens.
This is on a machine where I can playback a dozend videos in parallel without any problems with the mixing of the sound of them, so my guess is that something about the way the clients drops frames when not the active window also fucks up the sound.

[loftar]

Could using integrated audio chips be the problem here?

While I do indeed use a dedicated sound card on my desktop machine (a SoundBlaster Live that is like 20 years old), audio also works fine on my laptop, which uses some bog-standard Intel HD Audio codec. Jorb also uses his motherboard audio, and has no audio problems (though I don't know what kind of audio solution his motherboard has). So I doubt that is a problem in and of itself; I also generally think it sounds like a stretch to blame the hardware; after all, all it does is use DMA to feed a DAC, pretty much. I'd be more inclined, again, to blame drivers or something like that. I mean, if there is a fairly large amount of overhead in submitting an audio buffer to the hardware, that would certainly explain why larger audio buffer sizes help. (The problem is that the overhead would have to be pretty enormous even at :audiobuf 1024, though, but perhaps the driver might have issues with particular buffer sizes or something weird like that.)

For software processing, any latency in CPU processing (low frame rates, etc) are going to seriously hinder audio performance, too.

The audio processing runs entirely parallel in its own thread, though, so FPS issues shouldn't be a problem for it.

I noticed sound always being fine with one client open, having multiple of them the stuttering happens.

Perhaps this could be an issue that only happens when software mixing kicks in, though? Does the audio stutter in both of those clients, or only in the one running in the background, or something like that? Also, does setting audiobuf help?

[Ragnar214]

My fan is no longer screaming (And I have a pretty high end PC) It used to scream playing this. I thought it was the graphics.

I find it extremely hard to imagine that the audiobuf command would change that, though. It doesn't change the total CPU usage of the audio thread, only how much audio it buffers at a time. Then again, of course, I can't really imagine why any value above 1024 should be necessary to begin with, since that's already more than 20 ms of latency sensitivity.

Thinking about it, could it potentially be that some audio drivers have some extreme overhead in submitting an audio buffer? Do you guys who have audio troubles have some particular sound card in common?

I'm not sure why but it does. Physical(Graphical) lag goes away on my client mostly once I use that command. The sound cleans up really nice too.

I'm thinking that maybe the Audio Files themselves may be to blame? You say "It doesn't change the total CPU usage of the audio thread, only how much audio it buffers at a time" Perhaps the way the audio files are saved or the format they are in have something to do with it? Like data is getting jammed up like an upside down beer bottle being pourn out? I don't really know. Audio isn't my speciality and I am leaving audio stuff til last with my programming

I'm guessing the :audiobuf 1024 (1024 is the MB in memory set aside to buffer audio correct)?

Drivers may be to blame my PC uses Realtek Audio and I believe it is integrated into the motherboard. I also don't see how an audio thread can affect the visuals and graphics.

This is my motherboard: https://www.asus.com/Motherboards/Z87EXPERT/ I also have an EVGA Geforce 770 Classified 4GB for my GPU. CPU is an Intel i7 4770k 3.5 ghz quad core hyperthreaded. Not sure if that helps you find the problem. But I wouldn't lie... the :audiobuf command certainly improves overall performance.