Audio file reading produces drop-outs

[chaos318]

I have Tracktion 5 but also testing latest Tracktion 6 and have problems with audio drop-outs.
When the drop-outs occure the CPU-Usage shows a peak at "Audio File Reading".

It looks like the parameter "Audio cache size" does influence the problem. Higher value means less drop-outs.
But why is it limited to 60 secs? Why could Tracktion not just load all files into cache as long as it fits?
My currenty project has 500MB source files, easy to load in the RAM, isn't it?

System:
Intel Core i5 2430m
Windows 7 64bit
RME Babyface

[chaos318]

Anybody else who has this problems and found a reason?
Or maybe someone has a fix for this?

[PierreG]

I have Tracktion 5 but also testing latest Tracktion 6 and have problems with audio drop-outs.
When the drop-outs occure the CPU-Usage shows a peak at "Audio File Reading".

It looks like the parameter "Audio cache size" does influence the problem. Higher value means less drop-outs.
But why is it limited to 60 secs? Why could Tracktion not just load all files into cache as long as it fits?
My currenty project has 500MB source files, easy to load in the RAM, isn't it?

System:
Intel Core i5 2430m
Windows 7 64bit
RME Babyface

This setting has been an issue since T2, when it was configured for MBs as opposed to seconds to buffer. I remember needing to crank it to the max 150mb in T2, which helped there as well, yet it seemed the max should have been higher. I think part of the issue is how Windows now handles hard drive I/O, which may be harder to control from the DAW.

I use the RME FireFace 800, which in T4 through 6 exhibits a lot more audio glitching than it did in T2 and 3. I've heard others complain about how the new versions of T have the issue of glitching until the edit has been played through once. This happens for me, and it's very annoying. Workable, yet not optimal. Jules and the dev team have suggested that it's an RME driver issue, which I've pushed back on, in that they're still updating the drivers for these old workhorses!

Not sure how to sort this out...

Anybody?

[chico.co.uk]

Do you have any apps that scan files when they're loaded into memory running?

Eg, antivirus (including windows defender, installed by default on newer o/s), are the files in dropbox or similar syncing locations, any kind of firewall or similar inspection type software running in the system tray, indexing services, etc? Try disabling those, see if it makes any difference.

[PierreG]

Do you have any apps that scan files when they're loaded into memory running?

Eg, antivirus (including windows defender, installed by default on newer o/s), are the files in dropbox or similar syncing locations, any kind of firewall or similar inspection type software running in the system tray, indexing services, etc? Try disabling those, see if it makes any difference.

Thanks for the suggestions Chico.

I've extensively pursued the course you recommend, yet it has not resolved the issue. I use the W7 Resource Monitor to examine disk I/O, which reveals that the issue can present itself with T audio buffering happening, or not.

Again, this behavior of audio dropouts when first running through the edit, seems like T needs to load the cache buffers, which takes a while, thus the dropouts happen until the buffers are loaded. Yet I also will get the dropouts after mixing for a while, which suggests that there's more cache management happening and causing the dropouts again. Then once cache is reloaded, all is good again. As Chaos points out, why is the cache buffer limit so small? Perhaps going larger actually causes other issues. Maybe my hard drive is too slow for 88.2 audio...

[klangbastler]

there are definitely things in the tracktion audioengine that need to be improved.
i have these glitches from t4 - t6 (behaviour as described by PierreG). it's annoying, but i just got used to it.
devs seemed not to be interested to take a deeper look, so well ... that's where it stands.

blaming it on the drivers, especially rme drivers, which run rocksolid on most daws is pretty lame in my opinion.
i experience these glitches with all drivers i use here (rme fireface uc, motu 112D (via usb), macbook internal soundchip with macosx and bootcamp windows). sometimes more, sometimes less, but never completely gone.

i would suggest to tracktion devs to maybe improve their audioengine (if they don't already have for t7)?
there are also other things related to the audioengine regarding looprecording, that were announced to be taken care of with an updated engine, which never came about.

let's see what t7 brings ...

[PierreG]

there are definitely things in the tracktion audioengine that need to be improved...

What klangbastler said!

Seriously, it's deeply frustrating to be told by T devs that your computer and or audio interface is not cutting it. DAWs are a complicated beast, with many variables to sort out, yet as many have pointed out, our gear works well with other apps, so why should T get a pass on taking care of these basic core issues. I'm getting very tired of getting sucked into the groovy new features, resulting in continuing to Beta test T as I install the many updates, still not finding basic audio engine stability. These audio dropouts are only one of many T fails. Lately with 6.3.0, I've been having edits completely loose their folder track assignments and poof crash on a regular basis.

If T7 is the resolution, I'll gladly upgrade, yet my trust is low for this to be the case. Thing is, once 7 is released, so much for expecting 6 audio engine issues to be resolved. My opinion is that there's too much dev work being done on the new features, and not nearly enough on stability. Feeling like I'm stuck in bad dream, spending WAY more time and energy dealing with T issues than I am producing music.

End of rant.

[Gymnopedies]

there are definitely things in the tracktion audioengine that need to be improved...

What klangbastler said!

Seriously, it's deeply frustrating to be told by T devs that your computer and or audio interface is not cutting it. DAWs are a complicated beast, with many variables to sort out, yet as many have pointed out, our gear works well with other apps, so why should T get a pass on taking care of these basic core issues. I'm getting very tired of getting sucked into the groovy new features, resulting in continuing to Beta test T as I install the many updates, still not finding basic audio engine stability. These audio dropouts are only one of many T fails. Lately with 6.3.0, I've been having edits completely loose their folder track assignments and poof crash on a regular basis.

If T7 is the resolution, I'll gladly upgrade, yet my trust is low for this to be the case. Thing is, once 7 is released, so much for expecting 6 audio engine issues to be resolved. My opinion is that there's too much dev work being done on the new features, and not nearly enough on stability. Feeling like I'm stuck in bad dream, spending WAY more time and energy dealing with T issues than I am producing music.

End of rant.

You'll need to buy Tracktion COPPER interface for it to work, sorry....

[chico.co.uk]

"I use the W7 Resource Monitor to examine disk I/O, which reveals that the issue can present itself with T audio buffering happening, or not."

I don't think I understand what you mean by this. How can you tell whether T audio buffering is happening from Resource Monitor?

The old T4 manual used to say this:

"Cache size: You can adjust how much of your computer’s main memory (RAM) is used to cache audio files. Caching helps audio tracks play back without glitches or drop-outs, but reduces the amount of memory available to other applications and plug-ins. Making this value too large will also be counter-productive because computers become greatly less efficient once main memory is depleted. The default setting of 64MB is usually fine, but you may want to increase it if you have lots of RAM installed on your computer."

Your laptop will try to page memory to disk, if you've got a page file configured, even if you're not using all the available physical ram (I think, for reasons I can't remember, at the moment) so you might end up reading an audio file off disk to memory, then writing it to pagefile on the same disk, if you had a large audio cache in the app. Which wouldnt be great...

I don't have any answers to this really, but I'd probably get some disk utility and run it to check the read and write and random access speeds for the disks you use, and check you can actually read and write the kind of iops you're trying to achieve at the samplerate you're using

I'd also maybe check whether all the audio (recorded tracks and any samples, or audio sounds used in plugins) are at the same samplerate and bit depth you're using in your soundcard. Just because I'd want to rule out some kind of resampling taking place in either the app or by the audio driver, to play back everything in the edit. As in, if you're using 16bit 44khz samples on one track, but recording audio at 88khz, and the card is running at 88khz, does the sample get converted on the fly, when the audio first gets played? I dunno, but if you're looking for things to rule out, maybe that's an idea...

Did you look for DPC issues yet? I spent ages chasing them on an old laptop that finally died a death, but they seemed to be causing me grief, at one point...

Sorry if this is all old news, just thinking aloud

[valley]

The old T4 manual used to say this:

"Cache size: You can adjust how much of your computer’s main memory (RAM) is used to cache audio files. Caching helps audio tracks play back without glitches or drop-outs, but reduces the amount of memory available to other applications and plug-ins. Making this value too large will also be counter-productive because computers become greatly less efficient once main memory is depleted. The default setting of 64MB is usually fine, but you may want to increase it if you have lots of RAM installed on your computer."

That sounds like my writing from the T2 / T3 manuals. Things are a bit more complicated these days.

Even in the XP era, Windows would go off and make itself a swap file regardless of how much system space was free. I'm simplifying greatly here, but the old theory on swap files was early and often. The idea being that running out of RAM is messy, so an OS would strive to commit as little RAM as actually possible at any given time. I know some people liked to run Windows with the swap file disabled on their DAW if they had two or more gigs of RAM installed.

Modern OSes now tend to work in the opposite direction. Unused RAM is wasted RAM. A lot of this is being driven by the move to mobile, where disk accesses are expensive in watts. However some of it is performance too. Personally, today I'd probably bump the buffer size as a matter of course. RAM is cheap and drives are fast. That said, the hard drive probably already has a buffer equal to this size, and at a certain point, buffers only delay the inevitable. If a system is emptying the buffer faster than it can be filled, no amount of buffer is going to completely solve the problem.

In this case though instinct tells me the buffers are a red herring.

Again, this behavior of audio dropouts when first running through the edit, seems like T needs to load the cache buffers, which takes a while, thus the dropouts happen until the buffers are loaded. Yet I also will get the dropouts after mixing for a while, which suggests that there's more cache management happening and causing the dropouts again. Then once cache is reloaded, all is good again. As Chaos points out, why is the cache buffer limit so small? Perhaps going larger actually causes other issues. Maybe my hard drive is too slow for 88.2 audio...

I'm assuming 24bit stereo? Two tracks is only about a megabyte a second. A typical desktop hard drive should handle sustained throughput of around 100MB. (Note though that 'typical' here is a *wide* net. If yours is an energy efficient drive, such as the WD green series, you might see much lower numbers). Also note, we're talking sustained throughput here; multiple tracks playing at the same time will obviously perform significantly less well, as more time is spent seeking data, rather than reading it.

If you haven't already, I'd run a performance test over the drive but look for signs of uneven throughput. 100MBs per second isn't quite so great if the drive likes to deliver that data in bursts.

[PierreG]

You'll need to buy Tracktion COPPER interface for it to work, sorry....

[chico.co.uk]

Just remembered something about DPC. Turning wifi off (disabling the wireless interface in control panel, and using any available hardware button to disable wifi) really helped.

Can't remember if disabling Bluetooth too made a difference or not. Suspect it would. Might mean plugging a USB wired mouse in, instead of using a Bluetooth or wifi one, but it's an easy enough thing to try

[chico.co.uk]

'king hell, valley' s back...

Hope you're well sir

[jabe]

Sysinternals have some handy utilities that might help to pinpoint what is happening behind Windows and Tracktion. I'd start ProcExp (Process Explorer), make something happen with Tracktion, and then look at spikes in the graphs in ProcExp. You can put the mouse pointer over the graph for clues to what was running when your problems happened.

[valley]

Totally stupid question here, but are you using a laptop? If so, do you have *all* hard-drive idling disabled[1]? I only ask, because it occurred to me I might be thinking about this problem back to front. The drive may not be delivering data because it is *too* busy, rather it might not be busy *enough*. With a decent cache on the drive, and in Tracktion, it's possible that practically all activity is being performed via cache, so short of much to occupy itself, the drive spins down. The next time data is needed the drive will spin up, but might not do so fast enough. This would certainly look like insufficient throughput.

If any of this seems like it might be applicable, one easy test would simply be to stress the drive *more*. Try playing an large and long audio file (perhaps a mix-down of another song) on a muted track so the drive has no choice but to keep streaming data.

Just a thought.

[1] Note, WD Green Series drives will sleep regardless, so all bets are off here.