Stuttering sound in HW7

Dear all,

I am currently noticing some "stuttering".
Happens in HW 7, playing on the High Quality setting (Higher Bitrate, Audio Engine Processing at max, the tremulant model quality set on medium).
My cpu (AMD Ryzen 5950x) can handle these settings as even when playing on tutti in a very large set, like Nancy, doesn't push the cpu into red.
I also never experienced this problem before in HW 6 (where I played at the 48 instead of the 96 bitrate).

So what happens is, if I'm playing a simple thing, with only a few stops (I tested several organs) all of a sudden the CPU goes into red and I hear a stuttering sound, like the effect of a "tremolo" on a Vox AC30 guitar amp. so, the sound repeats itself like a stutter. It happens at random, so sometimes I can play 30 minutes without having it, sometimes it happens after a few minutes. Also considering the horsepower of my pc, and only the few stops I have selected I cannot think it is a question of lack of processing power or Windows settings. And I never had the problems in HW 6

Anyone noticing the same?

My system specs:

MSI MPG X570 GAMING PRO CARBON WIFI motherboard
128 GB Ram 3600 Mhz
AMD Ryzen 5950x CPU
Win 10, build 211H 64bit
RME Babyface Pro FS audiocard.

I suggest checking that the Windows system service Sysmain is disabled. It can make sudden and high demands on you cpu which may contribute to problems with the audio stream.

Iain

Hey Ian,

Yes, all of that is disabled.
Like I said, my system functioned fine in HW 6.
Nothing has changed on the Windows side of things.
I did all the optimisations, in windows, like disabling not needed services, apps, antivirus/firewall etc
Incl the sysmain.

Thanks anyway

[mdyde]

Hello Laurens,

It won't be due to the fact that you're using v7 above v6 per-se, except conceivably to the extent that the new 'higher' option for the "Audio engine processing quality" organ preference is a little more CPU-intensive than the 'medium' option (which was equivalent to v6's highest quality option).

If it's related to anything in Hauptwerk it will almost certainly be due to the fact that you're now using 96 kHz instead of 48 kHz. For a given amount of buffer size in milliseconds, 96 kHz is about twice as CPU-intensive as 48 kHz. However, it's very important to bear in mind that at 96 kHz a given buffer size in sample frames (e.g. 1024) represents half as much buffering in milliseconds as it would at 48 kHz. Hence if, for example, you were using a buffer size of 512 reliably at 48 KHz then if using 96 Khz you should set the buffer size to 1024, since smaller amounts of buffering in milliseconds make the computer much less resilient to audio glitches (from background computer activity, etc.).

N.B. then also check that your audio interface's driver is actually using the desired buffer size, since some audio drivers ignore the value that the application (Hauptwerk) requests, and instead use the buffer size setting in their own control panel.

Hence please first make sure that at 96 kHz your audio interface is indeed using twice the buffer size (in sample frames) that you were previously using successfully at 48 kHz.

Some other things to check:

- Make sure you aren't overfilling the PC's memory. E.g. try testing using a small sample set such as St. Anne's.

- Make sure Windows' page file is disabled for all drives.

- Make sure that Windows disk indexing is disabled for all drives.

- As a test, try disconnecting the PC from the Internet, in case some background process is trying to install/update something periodically.

- If you have a virus scanner installed then try temporarily disabling it (whilst disconnected from the Internet), in case it's trying to do a background scan of the drives periodically.

Hi Martin,

As always thanks for answering.
I was also thinking about the increased quality, however, when I play tutti in the nancy sampleset, the cpu can handle it.
So hence I'm so puzzled that even in a "small" set like Freiberg or Bergen op Zoom with only a few stops this happens from time to time. No continuously.

I already disable the page file.
The pc is not connected to the internet.
No antivirus is running in the background
Disk indexing is disabled
I had the buffersize in HW set previously to 256 and in the RME console it was 1024. I have no idea which one of the two the computer uses... is tthere a way to check this?
Maybe I could try setting both of them to 512 (doubled in hauptwerk) and lowered to 512 in the RME console.
If that doesn't work, maybe I'll set the RME to 2048, but I guess that's kind of high?
Also, there is normally only 1 bar of the cpu lit, so that's that's the crazy part of everything.
If the buffer would be too small, one would expect the cpu bars to be continuously almost in the red or am I mistaken?

Cheers, I'll let you know if I have further news.

Ps: Any release date planned on the 7.1 release? [for my Launchpad ]

Laurens

At this moment there are problems with the fTPM in AMD processors: "Intermittent System Stutter Experienced with fTPM Enabled on Windows 10 and 11".
See https://www.amd.com/en/support/kb/faq/pa-410 and the Reddit forum (https://linustechtips.com/topic/1353904 ... t=15267661 and following comments)

Disabled fTPM in the BIOS; you are on Windows 10 and fTPM or TPM is not needed.
Give it a try and test again.

Reason that this is an issue at this moment is that fTPM is standard enabled on new motherboards because to be ready for Windows 11. In the past fTPM was disabled by default.

The only thing I don't know is why HW7 has stuttering problems and HW6 on the same system with same BIOS and Windows settings haven't. In my country a person has the same problem. New PC, AMD x5900, optimized Windows and with HW6 no problems. He updates to HW 7 and there is a "CPU in red" problem, also with minimal audio engine settings and low polyphony.

Hi Evertjan,

I disabled this setting in the bios also long ago.
Thanks for your reply anyway.
Cheers,
Laurens

[mdyde]

As always thanks for answering.
I was also thinking about the increased quality, however, when I play tutti in the nancy sampleset, the cpu can handle it.
So hence I'm so puzzled that even in a "small" set like Freiberg or Bergen op Zoom with only a few stops this happens from time to time. No continuously.

I already disable the page file.
The pc is not connected to the internet.
No antivirus is running in the background
Disk indexing is disabled
I had the buffersize in HW set previously to 256 and in the RME console it was 1024. I have no idea which one of the two the computer uses... is tthere a way to check this?
Maybe I could try setting both of them to 512 (doubled in hauptwerk) and lowered to 512 in the RME console.
If that doesn't work, maybe I'll set the RME to 2048, but I guess that's kind of high?

Thanks, Laurens.

After loading an organ, use "Help | View activity log", scroll to the end, and have a look at the INF:5152 message, which will be something like this:

"2022-03-09-13-02-12: INF:5152 ASIO audio device 'ASIO: M-Audio FireWire ASIO' started at 48000 Hz with default stream resolution 32 bits (stream format ID: 18), 6 channels, driver buffer size 1024 sample frames, driver latency 93 frames (1.9 ms), application buffer size 0 frames, buffer latency 1024 frames, overall total latency 1117 frames (23.3 ms), audio engine buffer chunk size 1024 frames, num buffers 1. Buffer sizes supported by driver: min: 64, max: 4096, preferred: 1024, granularity: -1."

That "driver buffer size NNNN sample frames" excerpt will show the buffer size that the driver (and thus also Hauptwerk) is actually using.

If the log goes back far enough, you could search it from the top for the first line containing "Hauptwerk version: 7", then scroll up a bit to see (via the last INF:5152 line above that point in time) what buffer size the driver was previously using when you were using Hauptwerk v6 at 48 kHz.

At 96 kHz on a powerful modern PC I would expect that a buffer size of 1024 should be safe, and 512 probably would be fairly safe too.

Also, there is normally only 1 bar of the cpu lit, so that's that's the crazy part of everything.
If the buffer would be too small, one would expect the cpu bars to be continuously almost in the red or am I mistaken?

Probably, but not necessarily. With a small amount of buffering the audio performance will be more susceptible to anything else that might occur on the PC, including background tasks that might run periodically.

If you still have the periodic glitches with St. Anne's and with a buffer size of 1024 being used (as reported in the log), please:

- Try checking for, and applying, all available Windows updates. (Check, apply, reboot, and repeat until there are no more.)

- Also make sure that the latest version of iLok License Manager is installed ( https://ilok.com/ ). (It doesn't hurt to reinstall it if in doubt.)

- If that doesn't solve it, try temporarily setting Hauptwerk to use 48 kHz again, to see whether the problem persists.

(The only platform difference between v6 and v7 is that v7 is linked to the latest version of the iLok libraries, which might in turn be linked to later versions of the Windows libraries than the v6 iLok libraries were. Hence it might possibly be necessary or beneficial to have recent Windows updates installed.)

Ps: Any release date planned on the 7.1 release? [for my Launchpad :-) ]

I can't promise it, but I would expect fairly soon (within the next small number of weeks). We were waiting for a while to see whether any other new bugs were found in v7.0.0, but that's still the only one.

Hi Martin,

Will do. I'll keep you informed!

Cheers,

Laurens

Possibly related, possibly not: I had a much more frequent -- every few seconds -- stuttering problem on my AMD 5700U Windows 11 laptop (for my travel keyboard), with the CPU meter jumping into red and back rapidly with only one stop drawn on a small organ like St. Mary Downe and noise from the headphones.

I had done all of the Windows tuning checklist in Performance Tuning in the Hauptwerk Installation and User Guide *except* running Hauptwerk as Admin and setting the real-time priority preference. In my case, changing to real-time solved it.

However, several people have reported the same symptoms as mine, in the Hauptwerk Virtual Organ facebook group, on Windows 10 or 11, where switching to real-time priority wasn't enough.

They were only able to fix it by resetting Hauptwerk's processor affinity to all cores in Task Manager, and they have to do that after each organ load or audio engine restart. Task Manager shows all cores selected, but setting affinity to the same value (all boxes checked) fixes the jumping CPU meter until the next restart, when I think HW sets core affinities again.

The fb posters said this is a known bug in Windows (NOT a bug in HW 7), though I haven't found a good explanation searching for the Windows issue. Unfortunately, going into Task Manager and setting processor affinity each time you restart an organ isn't a very nice solution. Setting it in a script when you start HW isn't enough because HW changes affinity later.

(I asked the fb folks to post about it here, too, but nobody has that I can find.)

Here's a link to the latest fb post on the topic:
https://www.facebook.com/groups/4237813 ... 921594860/

Sorry, that's probably not going to address the problem above with a lot more time between spikes.

See viewtopic.php?f=16&t=20318
about the more rapid noise issue. Not likely the same problem as the original post here, because the timing of glitches was slow.

[mdyde]

Thanks, Mark for the information.

I've moved that topic to the 'computer hardware' section, made it 'sticky' and edited the link in your reply to point to the topic's new location.