Audio Microstutter During SL Scene-Init

[libertyordeath]

This is what i would classify as "first world problems" when it comes to Skyrim troubleshooting: it's not really an "issue", but i'm running out of real issues to fix with my modsetup, so now i'm going after trivial annoyances.

 

When a sexlab scene starts - the part where the grass disappears and reappears,  actors teleport around - i'm getting audio microstutter for about half a second. It's not actually "choppy audio" - instead the interruptions are so short, they sound like a brief burst of noise. If i were to record it, the waveform almost certainly would look something like "100,0,100,100,100,0,100,0,0,100" - basically "micro-dropouts" that are only one or a few samples long.

 

It's been like this forever. It's not a CPU issue: I can reproduce this with the maincore at 70%. It's not Papyrus running out of juice - scene setup only takes 2-3 seconds. Normally the first thing i would look for is the audiobuffer running running low on stress, but that usually sounds like choppy audio, not microstutter, and again it happens even with the maincore at 70%.

 

So with all the above in mind, three theories i can come up with are:

 

1. Skyrim itself has a timebudget for everything, and for some reason the timebudget for audio output - not the audiobuffer - is running out of juice. Not because there's no core-time left, but simply because skyrim decides to not allocate enough time during SL scene setup.

 

2. SL Tools at fault again. Somehow. Someway. I don't know why, but this POS always finds a way to mess with SL anim setup and switching. It's built a reputation for this on my setup, so now whenever something goes wrong with SL scene management, i automatically treat it like a "usual suspect".

 

3. It is actually the audiobuffer running out, but an edge case where it only happens for microseconds. How that could happen reproducably, i don't know. I couldn't find any pointers online to changing audiobuffer length, so i have no way to test it.

 

EDIT: I should mention that i run at 80 FPS capped. So the time per frame is lower than 16ms, which might fuck with Skyrim's internal timebudget allocations.

 

 

Edited September 12, 2024 by libertyordeath

[traison]

I would say most likely audio driver or audio device issue:

1. Make sure you're actually running the vendor provided driver, i.e. Realtek, and not some generic thing from Microsoft.
2. Update or otherwise change it.
3. If you have multiple devices, make sure its actually using the correct one.
4. If you're using USB headphones (or similar) that install their own sound device (or similar), unplug it and test with the actual audio output jack from your motherboard and/or expansion card.
5. Get Process Explorer and keep an eye on your interrupts while playing audio in a media player or web browser, also test in-game if you have multiple monitors or can replicate the issue with Skyrim in windowed mode. If interrupts get even close to 1% (should be more like 0.01%) of CPU utilization while playing audio or other media, you have a driver issue.

2 hours ago, libertyordeath said:

the maincore at 70%

 

What's the "maincore"? If that's the overall CPU utilitization then that's awfully high for Skyrim on a modern system.

 

Edit: Also there's apparently a fix for the grass disappearing. Might be a good idea to test that.

Edited September 12, 2024 by traison

[libertyordeath]

1 hour ago, traison said:

I would say most likely audio driver or audio device issue:

1. Make sure you're actually running the vendor provided driver, i.e. Realtek, and not some generic thing from Microsoft.
2. Update or otherwise change it.

It's the OEM driver.

 

1 hour ago, traison said:

1. If you have multiple devices, make sure its actually using the correct one.
2. If you're using USB headphones (or similar) that install their own sound device (or similar), unplug it and test with the actual audio output jack from your motherboard and/or expansion card.

My setup is: Mobo -> USB-Audiocard -> Analog Headphones

Testing by plugging straight into the mobo would be... annoying given the cable lengths and placement of the rig - but let's be honest: It's the obvious and prudent thing to do, because: 2 audiochips = Easy to exclude hardware/drivers, by just trying the other one.

 

 

1 hour ago, traison said:

1. Get Process Explorer and keep an eye on your interrupts while playing audio in a media player or web browser, also test in-game if you have multiple monitors or can replicate the issue with Skyrim in windowed mode. If interrupts get even close to 1% (should be more like 0.01%) of CPU utilization while playing audio or other media, you have a driver issue.

I didn't even know IRQ stuff is still an issue nowadays, but with USB i can imagine there to be potential timing issues. Thanks for pointing this out. Number two on the list of things to test.

 

1 hour ago, traison said:

 

What's the "maincore"? If that's the overall CPU utilitization then that's awfully high for Skyrim on a modern system.

Umm, you don't know this? Normal Skyrim multithreading behavior. Here, spot the "maincore":

 

 

 

1 hour ago, traison said:

Edit: Also there's apparently a fix for the grass disappearing. Might be a good idea to test that.

Grasspatch invasively modifies Sexlab scripts. For some people it works, for others it completely breaks sexlab. In my case i tried it twice, and it broke everything. No thanks.

[traison]

4 minutes ago, libertyordeath said:

Grasspatch invasively modifies Sexlab scripts.

 

Nah, just generates about 10GiB of grass filled files:

https://www.nexusmods.com/skyrimspecialedition/mods/42161

 

4 minutes ago, libertyordeath said:

Normal Skyrim multithreading behavior. Here, spot the "maincore":

 

This is not a concept in the Windows scheduler however. Whichever core happens to be the "main" (in this case the one which gets the highest load) is going to depend on the scheduler and it can move around at any moment. Only with CPU thread affinity can you simulate some kind of "main" core, but then that's an entirely different thing.

 

Would be interesting to now which thread (if it can be pinpointed to a single one) is causing that one core to nearly hit the roof there. Have a look in Process Explorer. Properties of SkyrimSE.exe, Threads -tab. While not guaranteed to be the case, I would at this point assume threads with a start address in XAudio2*.dll to be audio related. Got any suspiciously performance hungry ones in there in general? Where are they coming from?

 

For reference, my Skyrim hovers around 6-30% CPU utilization (total, of 12 logical), from which the Xaudio one is 0.13%.

[libertyordeath]

1 hour ago, traison said:

 

Nah, just generates about 10GiB of grass filled files:

https://www.nexusmods.com/skyrimspecialedition/mods/42161

Oh! That one. Yeah, i know about this. And well, back when i first heard about it, my interest plummeted when i red the 10 GB part. I mean sure, people with grass pop-in issues might pay that price. But my landscape and grass mods allow me to render grass to the maximum loaded cell with minimal performance impact, and at that distance it blends into the landscape. And well, temporarily disappearing grass in SL scenes isn't worth 10 GB to me.

 

1 hour ago, traison said:

Would be interesting to now which thread (if it can be pinpointed to a single one) is causing that one core to nearly hit the roof there. Have a look in Process Explorer. Properties of SkyrimSE.exe, Threads -tab. While not guaranteed to be the case, I would at this point assume threads with a start address in XAudio2*.dll to be audio related. Got any suspiciously performance hungry ones in there in general? Where are they coming from?

I benchmarked by loading the worst possible area for demonstration. Normally the mainthread averages around 80%. As for what thread that is: I can lower it by about 20% by halving my framerate with a limiter. So i'm pretty sure it's the same thread that sends render-calls to the GPU-driver. XAudio thread has minimal utilization by the way. Less than 1%., 

 

And no, there's no other performance hungry threads, or once taking unusual time for their task. It's only that one single skyrim thread eating up all the CPU-time.

 

Also, i just noticed i can't test the "plug it into the mobo and try again"-part today. Logistics. Embarassing logistics. But i should be able to do that tomorrow.

Edited September 12, 2024 by libertyordeath

[traison]

32 minutes ago, libertyordeath said:

same thread that sends render-calls to the GPU-driver

 

I would also assume it handles game logic and feeds the audio thread with data, among other things. Did you test the audio issue @ 40 fps?

[libertyordeath]

1 hour ago, traison said:

 

I would also assume it handles game logic and feeds the audio thread with data, among other things. Did you test the audio issue @ 40 fps?

Great idea. Just tested 40 FPS with the mainthread at 55%: No difference. 0.5secs of audio "micro-pops". So it's not CPU-bottlenecks.

 

Oh, i just remembered: This only happens for player scenes, not NPC.

[libertyordeath]

...

 

Silly idea! I do have a handful of soundmods that modify reverb and so on. Could the pops be a result of audio-processing running out of allocated time? But then again: Those mods are all plugins, not DLLs, and you don't do DSP stuff in papyrus scripts. So they way i understand it, those mods should simply be reusing DSP functions in the skyrim engine. 

 

Nevermind, that's indeed a silly idea. Just brainstorming.

[traison]

13 minutes ago, libertyordeath said:

I do have a handful of soundmods that modify reverb and so on.

 

This seems like someone having graphics issues while still continuing to run ENB/ReShade/CS. There's no point having these enabled when debugging graphics issues: they're too simple to disable to not do it - reduce variables, don't make it difficult for yourself.

 

So, why have these enabled when the issue is audio?

[libertyordeath]

1 hour ago, traison said:

 

This seems like someone having graphics issues while still continuing to run ENB/ReShade/CS. There's no point having these enabled when debugging graphics issues: they're too simple to disable to not do it - reduce variables, don't make it difficult for yourself.

 

So, why have these enabled when the issue is audio?

Interesting results!

 

The pops are gone! BUT, now at the time where the pops would be, there's brief moments of silence (audio muted).

 

Here's what i think is going on: When a sexlab scene initializes, the audiobuffer DOES run out for brief moments. Always been that way. BUT one of those audiomods i have uses a DSP that turns those buffer-drops into pops. And the pops psychoacoustically (yes, that's a real word) mask the dropouts, so i only heard the pops, not realizing this was a bogstandard buffer underrun, and making things more complicated than they actually are.

 

TLDR: SL scene setup just bogs down skyrim to a halt for a brief moment, which makes the audiobuffer run out. That is all that's really going on. All the alien popping stuff were just illusions created by some audiomod DSP.

[traison]

18 minutes ago, libertyordeath said:

his was a bogstandard buffer underrun

 

Makes sense, but I feel like there should still be an explanation for why the buffer is running out. I haven't seen this on my own system in Skyrim SE. I know you said you have a USB audio device and headphones, but are those perhaps set to something silly like 5.1 or 7.1 speakers? More channels = more data. If the buffer is a static size that doesn't consider channels then that could explain why you're running out so quick.

[libertyordeath]

1 hour ago, traison said:

 

I know you said you have a USB audio device and headphones, but are those perhaps set to something silly like 5.1 or 7.1 speakers? More channels = more data. If the buffer is a static size that doesn't consider channels then that could explain why you're running out so quick.

USB Audiocard -> Analog HEadphones

 

Just checked: Not only is it set to stereo, it only supports stereo. Which makes sense, given that the device has no ports for a 5.1 setup - just plain old headphone jack and microphone.

[libertyordeath]

Finally tried plugging into the mobo: No difference, so it's the game itself, not the hardware.

 

At this point i think we spent an unreasonable amount of time on a small nuisance. After all this only happens during player SL scene setup, and only for half a second.