Strange M-Audio ASIO behaviour with 0.2a

[kruntz]

I just quit a two-hours session with 0.2a.
(BTW the new Monitor mixer source assignment is great, thanks!)

Gears:
Old Sony Vaio NB with Intel Pentium M 1.70 GHz (Texas PCI7x20 1394a)
M-Audio Profire Lightbridge
Settings:
2x64

I used a template (32 channels + 4 monitors) that used to produce a steady 50% load with release 0.1d

When I start the live engine with 0.2a, the load is at 30-32%. Then, it slowly increase 'til 62-64%, and it stay there.

Left-clicking on the load display, I always see 3 (three) slipped output buffers right after engine startup. Then, slipped output buffers increase slowly by ~100 every 10 minutes.
Slipped input buffers is *always* zero.

[Bob L]

Sounds like the system is not capable of holding the 2x64 without buffer loss... even though they should be corrected and stop latency drift... this is not the way I would run the system.

Not sure what is building up in your system that increases the load over time... other than, it is running right on the edge and eventually runs out of play room and the load stays constantly behind and builds and builds trying to catch up.

Try the realtime priority option... something may be running in the background that is stepping on the threads.

Also... try 1 or 2 x 128 and see if that stabilizes it...

Bob L

[kruntz]

Not sure what is building up in your system that increases the load over time...

Me too.. With 0.1d and the same HW, the load meter is steady at 50-51%

Try the realtime priority option...

No effect. :-(
With or without realtime priority, DPC Latency Checker gives Absolute Maximum Latency at 375uS on a 10 minutes stint.

Also... try 1 or 2 x 128 and see if that stabilizes it...

At 1x128 it's rock solid. Zero slippage and 50% load.

BTW: even with ~800 slipped buffers in one our, I didn't notice any click or out-of-sync in the audio output.
Bob, is there any chance you'll support multiple different ASIOs at the same time?
Thanks in advance.

[Bob L]

Well... it seems clear to me that the 64 sample size is not capable of maintaining itself... there appears to not be enough time to complete the buffer processing in time for the next output on a steady basis... the old engine is not complaining becuse there was no measuring and checking and correcting going on... it stayed rock solid... but my guess is it drifted latency badly over time.

I would say 1 or 2x128 would be your ticket on that rig.
Bob L

[kruntz]

I would say 1 or 2x128 would be your ticket on that rig.

I'll do. Thanks.
Any thoughts on the multiple ASIOs devices?

[Mountain Media]

Sounds like the system is not capable of holding the 2x64 without buffer loss...

Also... try 1 or 2 x 128 and see if that stabilizes it...

Bob L

Bob, this goes back to SAW apps, too - but, is there a rationale or recommentation as to whether the 'number' of buffers or the 'size' of buffers should be changed first, to improve stability and hold latency to the lowest value, or is it just play with both parameters?

[Bob L]

Here's how things work...

The entire processing loop must be done within the time it takes for one buffer to be sent out the soundcard based on the buffer size setting... so if the size is set to 64 samples, there is aprox 1.45 ms between buffers in order to keep smooth streaming audio... at 128 samples there is almost 3 ms... twice as much time...etc.

Now... when the soundcard notifies the program that new data has been collected, SAC starts the processing loop... it must do all the data processing and routing and buffer transfers within that allotted time and then wait for the next signal to start again.

In reality... Windows may interrupt the process at any time to handle something else going on in the background... if your session load is very low... even if the processing loop is interrupted a few times within that allotted time... it can still finish in time and all is well....

But... if your load is high... then any interruption may cause the loop to be late... and when the soundcrad driver comes around for the buffers... there is none ready to go... and therefore you miss a buffer... and the card glitches... therefore... if this is happening a lot... you may find improvement by giving more processing time between buffers... therefore increasing the size.

But... in reality... this may only happen once in a while if the machine is not generally being overloaded... so... the number of extra buffers comes into play... with more than 1 buffer preloaded... you now have a cushion... if one particular loop does not make it in time... the driver still has an extra buffer or two to keep the data stream glitch-free... and if the delay was caused by some random hit by Windows in the background, then the loop that finishes late, will finish on time the next time around... and the extra buffer kept things running smoothly.

So there can be an advantage to using extra buffers rather than only 1 at a larger size... but... if the load is too high and most of the loops are late... then the larger size is the solution...

1 buffer at any size leaves no room for error... if anything blocks the procesing threads... you will glitch.

Bob L

[DominicPerry]

John,

Just as an example - 2x32 drops buffers for me, one every couple of minutes, 1x64 was stable for 10 hours.
I think you just have to try the options and see what works.

Dominic

[Mountain Media]

Thanks Bob and Dominic -- that gives technical and real-world. The better understanding of how it works for comfort and just trying the options is real-world!