Audio pops

Although I consider myself an expert about computers and Hauptwerk, I am reaching out to others to see if your experiences can guide me in the correct direction.

I am experiencing loud audio pops while playing Hauptwerk - but not at first. I can load an organ and it will play completely correctly for as much as a few days before these pops stat occurring. The pops are associated with specific pipes in specific ranks - and these always appear to be the same for a given loaded organ. If they happened from the start after loading, I would assume they were caused by discontinuities in the audio samples. Indeed, when they do occur, they appear in only one of the release samples if multiple ones are present.

If I reload the organ, the pops go away - for a day or so... The pops then come back after a time - in the same pipes as before.

I am running HW on a Mac mini 8, with 6 cores and 64 MB of RAM. I am running OSX 12.6 and HW 8.

I run no other applications on this machine - though it still has all the normal Apple operating system apps and is running mail. The machine is connected to the Internet.

I tend to play large sample sets because I have a huge organ console - however, I experience this problem even when there is more than 32 GB RAM still free - according to Hauptwerk.

I suspected a bad RAM chip, so I ran Apple's diagnostics ("D" mode") but everything passed the tests.

The problem has nothing to do with MIDI as I can trigger the problems on the screen using a mouse.

I just loaded the St. Anne organ to see if it exhibits the same behavior. I will have to wait a day or so to see if any pipes begin "popping." My theory is that this has nothing to do with the sample set and is, instead, a problem in RAM in some way.

Let me know if you have either experienced a similar problem or have any ideas I haven't yet tried.

Thanks in advance.

Les

[mdyde]

Hello Les,

I've never heard of anyone having exactly that problem before. I too would guess that RAM is getting corrupted somehow.

I would:

- See whether you can reproduce it with St. Anne's (as you're doing currently).

- If so, with St. Anne's, see whether Hauptwerk's built-in audio recorder records it. (Exit Hauptwerk before playing the resulting file.)

- With St. Anne's, see whether any of the meters on the "Audio, MIDI and Performance" large control panel show any spikes when the pops occur.

- Likewise, if your audio interface's driver software/hardware has meters, see whether they show spikes.

It could be swapping. Perhaps the page fault counter of the Activity monitor can tell.

First, thank you both for your quick replies.

Tgv, I hadn't considered swapping as a cause - but it is a reasonable theory. I am running Mac Activity Monitor and, even when I am playing a lot of notes, I cannot see any swapping happening - and the "pressure graph" is always in the green zone. However, I am currently running this with St. Anne's and this is a very small organ.

I will continue in this mode for a couple more days to see if St. Anne will start having pops. If not, I will load one of my larger sample sets and see how it behaves with swapping in Activity Monitor.

Martin, I will be VERY surprised if the HW audio recorder cannot capture the pops - but I will definitely try this experiment.

I can also investigate if HW's reverb has any effect. I typically use dryer sample sets and att HW revere - because this allows me to have more ranks and polyphony when using very large sample sets. Of course, the reverb intensifies the pop! This is probably a good thing at the moment while I am trying to identify pops...

If swapping ends up being an issue, I will likely upgrade to OSX 14 to see if some of the bug fixes apply to this.

Les

[mdyde]

Thanks, Les.

In theory, macOS shouldn't page out any of Hauptwerk's sample data, since Hauptwerk asks macOS to lock its data into physical RAM (a.k.a 'wired' memory), provided that the RAM isn't already nearly full.

Martin,

As mentioned above, my RAM seems to always have a lot of extra space. However, my hard disk space is rather limited because of all the organs I have cached and all the samples in my library. I typically have about 80 BG of disk space free. This is often small enough that HW gives me a warning message when I load a new organ - which I often override because I know I have sufficient space. Could this be another clue to my problem?

If needed, I could clear out some of the organ caches and free up another 100 GB or so. The only down side to this is the increase time needed to reload these organs next time.

Les

[mdyde]

Hello Les,

I wouldn't expect having only 80 GB free to cause audio glitches or affect paging, but I suppose it's conceivable that macOS might do something different if it thinks it's running low on space. I'd try the other test first.

Hi Les

Three ideas…

Have you tried running without the machine connected to the network? Some of the Apple OS apps synchronise data with iCloud periodically, if the popping continues when not connected to the network, then it probably rules out this activity as the cause of the problem.

As the problem seems to be very similar each time you load the system, have you tried running another large application, then letting it remain idle, then loading HW, This may use different parts of the physical memory for HW and it’s samples. If the problem changes it could point to memory being used by HW.

Did the pops record in the HW recorder? I assume if they didn’t then this points to the audio driver. Does the problem go away if you restart the audio driver from within HW?

Good luck.

Iain

[mdyde]

To add to Iain's reply, to restart the audio driver (without reloading the sample data) you would use "Engine | Restart audio/MIDI ..." in Hauptwerk.

Iain,

Thanks for the additional ideas!

I expect iCloud activity will not be the cause. I see no reason that this would always affect the same few pipes in a sample set. Rather, I would expect such effects to appear random. I need to keep connected in general because I use iLok's Internet-enabled licensing with HW - though I would gladly spend a small amount of money if I knew this would solve the problem...

I have not tried running another large program - though I agree with you that this would likely change the spot in RAM that gets corrupted. I might try this.

And, as for your idea about restarting HW's audio driver, I did not realize that it was possible to do this without restarting HW as a whole! I guess I can still learn things every day. I will definitely try this if I can get HW to pop again.

I will give up own St/ Anne after today. Either it will also pop or I will go back to sample sets that will.

Les

That it's always the same pipes does not make me think of faulty RAM. Memory under a modern OS isn't laid out linearly. Especially as time progresses, there's no reason to expect the same relation between logical address (i.e. which sample) and physical address. It also doesn't point at swapping, since there's almost no reason to expect the OS to consistently swap out the same samples.

Does it happen to the same notes or a random pipe in the rank? And is the pop always at the same point in the sample (e.g. always at 1.5s)? And does the pop stay when you've played the same sample multiple times?

[mdyde]

Also make sure that all macOS power-saving features are disabled, such as 'App Nap' (a.k.a. 'Power Nap'): https://www.lifewire.com/control-how-ma ... ap-2260788

It might also be worth looking at the figures for 'wired' memory in Activity Monitor once the organ has been loaded, and then seeing whether they've decreased once the problem occurs, just in case macOS is deciding to 'un-wire' any of the sample RAM after a period of time.

When memory pages are "wired" in MAC OS they are locked in memory and are not to be paged out by the OS. They are to remain in memory until being "unwired" or freed when HW frees up memory (as it exits).

With Les' problem, when the sample set is loaded into memory it is "wired" (by HW making appropriate system calls). It is possible that on each boot the sample set is loaded into the same part of physical memory. Hence loading something large before running HW might cause another part of memory to be used and possibly either change the falling samples or remove the problem,

Using the system monitor to check on the "wired" memory is a good idea.

Iain

Update - problem still there:

After running St. Anne for a few days I did not get any pops. I decided to load one of my large regular sample sets again - in this case a customized version of the PCC organ. It uses about half of the available 64 GB of RAM.

After about 12 hours, I began to get pops again. Interestingly, they were not on the same pipes as I had last week. Evidently, loading St Annes in between moved the problem to different pipes.

(I will reload the organ (to cancel the pops) and run it for another day or so to verify that the same pipes pop as this morning.)

Once I had a pipe that popped, I tried some experiments:

1) I verified that I could trigger the pop using a mouse on the HW organ keyboard screen (no surprise).

2) I verified that the pop is indeed captured by HW's audio recorder..

3) I reset HW's MIDI/Audio driver and verified that the pop remained after this.

4) I was running Activity Monitor during all of this and I could not see any swapping activity - and the RAM pressure remained green the entire time.

I still need to check if wired memory is decreased when the pops start - unfortunately I could not do this today because the pops were present when I woke up!

Les

[mdyde]

Hello Les,

"Engine | Restart audio/MIDI ..." also resets all of Hauptwerk's real-time models (audio engine, background models, organ 'relay', etc.) so, given that the problem persists after using it, I think almost certainly the sample RAM is indeed getting corrupted somehow (or paged out, but if that were the case the sample should get paged back in again after playing it again).

I'd suggest:

- Take a screenshot of Activity Monitor's memory/wired information after loading the organ (when it's working fully), so that you can compare it to Activity Monitor when the problem later occurs.

- For good measure, try loading your ODF once with "Design tools | Load organ (with design options)" with the "Skip all organ definition validation ..." option *not* ticked, just to verify that no errors in the ODF are reported. (When loading an organ normally Hauptwerk intentionally doesn't validate the ODF, so as to allow it to load rapidly. An error in an ODF could potentially cause a crash or memory corruption.)

- Test whether the problem still occurs if using an unmodified sample set from a different producer.

- Verify that reloading the organ, without exiting Hauptwerk first, eliminates the problem for a while. (I would expect so, since that would reload the sample data).

- Try re-downloading and reinstalling the organ, first verifying the MD5 checksums of the downloaded files.

- If you haven't tried it already, try disabling all macOS power-saving functions.

- As a test, try keeping the computer disconnected from the Internet (disconnect any Ethernet cables, disable WiFi and BlueTooth, etc.), and completely disable any virus scanner or similar software that you might have, then load Hauptwerk and the organ and see whether the problem then occurs again (after a period of time).