…oh, and obviously you’re compiling it in release mode, right? I wouldn’t expect a debug build to run audio smoothly.
Sorry for spelling Tracktion wrong, I guess it is because of NI Traktor that I spelled it wrong 
Ofcourse I am compiling everything in release mode.
Setting the latency to 512 does not change things much. But I can use other apps with 128 samples latency without a problem, even with 64 samples latency I have no trouble.
I will try to download a Tracktion demo.
perhaps it’d help to know more about your system other than the audio interface; what processor do you have?
I have:
AMD Sempron 3100+
GeForce2 MX
M-Audio Delta 1010LT
But, as said, i never ever have any audio drops or crackles with other apps. My system is rock stable. I am downloading Tracktion and will try that one.
Actually, I vaguely remember that in tracktion I might have lowered the UI thread’s priority… Or I might just be imagining that…
I just tried now with Tracktion 2 Demo, no problem. I can move the window around as much as I want, in High priority (checked that in the Task Manager) and ASIO Direct Mode (on or off, doesn’t matter) at 256 samples latency…
Where is the difference between the Juce Demo and Tracktion, audio-wise?
There are no differences below the level of the callback from the AudioIODevice.
Ok, then it really must have something to do with the GUI Thread? Or not?
I wouldn’t assume that it’s because that thread is drawing the GUI - probably just any other thread using up CPU would have the same effect. Try reducing the priority of the GUI thread and see if that helps…?
Ah yes, just checked, and tracktion does drop the main event thread to priority 3, while running the process as high- (or realtime) priority.
That sounds promising 
Where do I have to change these 2 priorities? Can you point out which files and where I have to change it?
Just call Thread::setCurrentThreadPriority somewhere on the UI thread.
Yes it worked!
Inserting these 2 lines in the Juce Demo’s initialise() was the cure:
Process::setPriority(Process::HighPriority);
Thread::setCurrentThreadPriority (3);
Could you please give me an explanation why it helped? What is exactly going on there?
Can’t give you any proof, but I guess that the m-audio driver doesn’t set the audio thread’s priority high enough to beat the UI thread when it gets busy.
Zamrate: thanks for the latency discussion and suggestion to set a separate thread for read (as I’m doing for write). I also fixed my cpu usage problem on record (write). It was a zero ms wait if the writer thread has nothing to do. Putting in a wait equal to my latency buffer size/sample rate dropped the cpu usage to the same as play. And I just discovered Juce’s performance counter/logger! I’ve got more performance questions/issues, but I’ll put them in a separate post so you and Jules can continue your discussion. I’ll be following though as I’m learning alot from this thread…
Still got problems with crackles :x
Altough I used the trick with the process and UI thread priorities, the scanning still does some crackles (when only playing a sine wave in the Audio IO Callback) and the scanning Thread is running at lowest possible priority.
I have no clue why, it cannot be the file access itself because in other apps this does not influence the ASIO output.
There are also crackles at the start of the application: The sine is already playing and then the application window shows up, and during this showup the sound output crackles.
What I noticed, is that also in the Juce Audio Demo there are crackles when I hold a note on the MIDI Keyboard and then press “Browse” to open the File Browser.
In other apps, calling a File Browser also doesn’t produce any ASIO crackles.
So what could possibly happen when the File Browser gets called that produces crackles?
In Tracktion, opening a file/dir browser during play does NOT influence the sound (perhaps that helps).
No idea. I don’t get any such problems with any of my other soundcards, even crappy built-in ones playing at low latencies through asio. I’ve been pretty vocal in the past about how appalling m-audio drivers used to be, especially old ones like the 1010 (hopefully they’ve improved things since their takeover, I don’t know…). If it works in tracktion then at least you know it’s not the audio driver code, so all I can suggest is juggling priorities.
What I found out, is that when I switch on “Animated Menus”, the menu animation will cause crackles in Ableton when opening the menu. I guess this is somehow related. I changing my graphic card Accelerations settings and disable “write combining”, but no difference.
I will just try everything on another system with another soundcard. The whole thing just drives me nuts.
On my laptop (with a crappy U46DJ soundcard) I got no crackles whatsoever even with 64 latency (over USB!). I would love to know what’s the problem and what’s the cure on the other system.
Is it possible that other apps like NI Traktor check the System Load and put in Sleeps() in their Threads so the computer doesn’t get too much load? (In fact, even while scanning NI Traktor never goes above a certain CPU load). How would one realize such a check in JUCE?
I doubt if any hosts would bother doing anything as far-fetched as that, but they might use lower priority threads. I think you’ll eventually come to the same conclusion as me - that m-audio’s drivers suck, and that you’ve wasted too much time trying to work around their idiotic bugs.