I was able to load Montucky Blues in Cantabile (couldn’t fully load Blue, since your Zip archive only contains a link to the MIDI file, not the real MIDI file). Not able to fully reproduce it, since I don’t own Helix Native, but the audio and MIDI files played back without dropouts even on my office machine with WASAPI drivers. Can you try if playback works without issues when you turn off (or even remove) Helix Native? Just to check for any funny side-effects on that front that I can’t reproduce…
But there’s something funky going on in the .wav file of Montucky Blues on the left audio channel - some glitchy sounds like a shaker going off at erratic times, e.g. around 01:00 or around 01:49; also at 02:00. I checked with an audio player - this has nothing to do with Cantabile, but is part of the original audio file. Not something I’d call a “dropout” but definitely a glitch; and these sounds are definitely at times that make no musical sense, so I don’t think they were intended…
Could you check the Wave file at these points and tell me if this is the kind of sound you mean with “dropouts”?
That’s weird, I just downloaded the zip file from Dropbox and extracted the files and both songs play fine with no glitches at all. Keep in mind that the glitches will happen randomly and sometimes not at all but then just when you think its gone it drops out and I mean no sound at all but the timeline is not effected. The midi files got copied wrong try these. Midi files.zip (488 Bytes)
OMG!!! I added a new song and copied one of my existing songs into it and saved it as a new file with a different name. Next I deleted the VST (Helix Native) in the new song to test if it would drop out and now all my songs (all 37) have no Helix VST in the racks! Please tell me there’s a way to get my show back…
When I load my original Cantabile show file with all my songs and there’s no Helix VST in the rack on all the songs. Are all the different saved versions of Cantabile connected?
when you delete the plugin inside a linked rack it will be apllied to all the songs the rack is loaded in. Try shutting down C♪3 then downloading the helix rack you uploaded here earlier and replacing the one you altered in your rack folder, then restart C♪3 or just add the helix native plugin back to the rack where you deleted it and check all the routes and bindings. You only have to fix the rack once.
Thank you @dave_dore that restored everything back! Now back to where I was… After deleting the Helix rack I played it back a few time and there was no audio drop outs. Now I can’t say that means anything because it drops out when you least expect it. I’m not sure what else I can do to narrow this issue down.
Great news Leroy, I was looking at all the material you uploaded and it led to a few more questions. I see where you are using a separate drive for the audio and MIDI tracks. Is it an internal or external SSD? Also, do you use the same separate audio drive and buffer settings when using Studio One?
I have 3 drives in my laptop C: drive (local disk) is a 250Gb SSD, D: drive (content libraries) is a 1T 7200rpm and E: drive (storage space) is a 1T 7200rpm. I use the same settings when I’m using Studio One but sometimes I switch up the block size to deal with high track/vst count. I usually run it at 64 when tracking guitars for the low latency. My Quantum 2626 has really low latency at 64.
Well, maybe you could try coping a few audio and MIDI tracks to the SSD and put them in the media file folder under the C♪3 folder in my documents. Then run those songs in Cantabile. This way we can see if it has drop outs that way as well. It’s sounding like a disk media retrieval issue caused by I know not what. Another thought is to check the defrag on the media disk.
Hi @dave_dore, I put all my audio and midi files in the “recordings” folder in the Cantabile folder on my C: drive and I’m happy to report that I played through many songs with out any audio drop outs!!! I did notice in the “profiler” that I was getting more page faults that previously. Is that a issue and is there a normal average number of page faults that’s acceptable? Great catch by the way you’ve been very helpful and I appreciate you!
Hi Leroy TBH I am not so clear on this question so I think it is a question @Torsten can better answer better than me because of his experience in the field. I too could learn from a good explanation of their affect on the performance of a system. FWIW I get them regularly but experience no ill affect to my music laptop performance.
Thanks in advance Torsten if you have something to offer
Sure - here’s my understanding: sloppily said, page faults occur everytime a Windows program wants to access part of a file that is opened but not completely loaded in RAM (see full explanation here). So, if you have a song loaded in Cantabile, and all plugins and all their data are loaded into RAM and everything’s chugging along nicely, there shouldn’t be any page faults.
Things change significantly with sample-based instruments and with media files: since Cantabile will regularly need to read part of a file from disk, there will always be page faults (whenever a file is open and being read from disk to RAM) in such a case. As such, nothing to worry about fundamentally - the more sample-based plugins and media files you use, the higher your page fault count will be. Especially with sample players that cache the first part of a sample in RAM and stream the rest from disk, the number of page faults can actually be pretty high.
Also, you’ll see page faults when you have a plugin GUI open, since the GUI doesn’t always seem to be fully loaded into RAM, so when the display changes, you’ll see page faults because of graphics being updated.
So, PFs are not an issue in themselves, but of course the speed in which your hard disk / SSD can supply these memory blocks does affect the performance; if the overall data supplied can’t keep up with demand, glitches / drop-outs will occur.
Therefore there is no “safe” or “unsafe” number of page faults - you’ll expect more PFs with media playback and sample-based instruments (sometimes around 6000 PFs or more with Kontakt or Spectrasonics instruments, since these always have a large number of files open for all the samples they are streaming) - it’s just a question of your drive being able to provide the data in time. An SSD certainly helps speed up things…
I was just asking if too many page faults were a bad thing and what would be the number of faults that would be considered a problem. I don’t think I have a problem now. Also if I were to put A SSD drive in my E: drive (storage) would it be as fast as my C: drive? I like to keep my C: available for programs.
if it’s an internal disk interface it would be, if it’s an external usb not as fast. I use all SSD in my 2 laptops for media and system drives, it gives consistent high speed and reliability to the rig but not as much storage space for the $$.
I’ve just read this entire thread and firstly thanks everyone for helping @Leroy with this issue.
My gut reaction to this is it’s processor related more than disk related. The CPU load jumping from 6% to 60-80% is big red flag. First suggestion would be to check for CPU parking (see here) when in the high CPU load state.
Just a couple of notes regarding page faults:
Page faults and Windows memory management are phenomenally complicated topics.
Page fault numbers should only be used as a hint that there may be a problem. They’re a normal operation.
Page faults on the audio thread are bad, page faults on other threads are fine. Unfortunately the Windows API doesn’t provide an easy way to get per-thread page fault counts so Cantabile can’t easily separate good vs bad page faults.
It’s complicated even further by the fact there are hard and soft page faults which have different impacts but none of that really helps with diagnosing these kinds of issues.
Cantabile’s audio player shouldn’t affect page faults since it’s not using memory mapped files - it directly reads the file into a set of re-used buffers. Also the file reads are don’t on a background non-real-time thread.
Cantabile’s MIDI player shouldn’t affect page faults because it loads the whole MIDI file into memory and there’s not disk activity involved.
What you want to watch for is high page faults that correlate with the how busy the synths you’re using are. If you get high page fault count on hitting a large lush chord, that might be something to worry about. If you see page faults when going File Open - that’s perfectly fine. Page faults on switching songs or presets is to be expected.
Hi @brad that’s for the info and the link. I went through the video that I posted a link to above and and my 8 cores ow are not parked. I just checked with the Resource Monitor app and all 8 cores are indeed being used. At this point it appears that having all my media (audio & midi) in the “Recordings” folder on my SSD C: drive made a difference. I haven’t had a drop out in the audio since making the change. Hopefully it’s all good now!
Stop Press: so I was just reviewing a crash report and noticed some debug code in the audio player that may be having a small impact here. I’ve removed the code and will have a new build up asap.
Interested to hear if things are better in build 3660.
Now back to where I was… After deleting the Helix rack I played it back a few time and there was no audio drop outs. Now I can’t say that means anything because it drops out when you least expect it. I’m not sure what else I can do to narrow this issue down.
