MIDI latency increasing! (FL Studio)

[ggoyal2]

hallo mr. tipaach..

please read my post on kvr:
www.kvraudio.com/forum/viewtopic.php?t=135411

See screenshot below:



It shows 2 output devices. Whenever I disable second output and close and reopen offline settings, second output does not stay disabled.

Why is it there anyway? Can it be causing my MIDI latency? When I disable it in my host (FL Sfudio) the sound comes instantle when I press keys on my MIDI keybord. However after some time the midi latency again comes. POsters of kvr are saying it is problem with asio drivers. can you help?

sorry for bad english.

fl stidio 6.08
asio4all 2.7
O2 usb midi controler with latest drivars
p4 2.6 ghz, 256mb ram, xp pro sp2 with all updats.

[Michael Tippach]

_Any_ change in the device configuration will force a driver reset, in turn re-starting the FLS audio engine afresh.

If you have the impression that the lag is getting bigger steadily over time, you may suffer from an issue that is described here:

www.jay.fm/blog/pc-midi-timing-and-nuendo.html

...a bit Cubase/Nuendo specific, but you should at least read the section about MIDI timestamping, which applies to _all_ Windows MIDI, irrespective of the particular host application!

How you would achieve the equivalent to Cubase "Use system timestamp" in FLS is a question to ask someone more skilled in the art of mastering FLS. It might be as easy as selecting a different MIDI device, should your MIDI input device show up in multiple incarnations.

Another - albeit very remote - possibility is that there may be a certain clock drift between the input and the output of your audio device, which _might_ be caused by the fact that the Realtek most likely resamples the output to 48kHz internally anyway.

Again, this possibility is very remote, but things to try would be to either check the "Always resample..." option or set the FLS project sample rate to 48kHz and see if this changes anyhing. Worth a try, at least...

[Bram Bos]

I recognise the problem, and I'm witnessing the same thing in my own host (Tunafish, which I'm the developer of). It's a strange problem and I can't tell if it's related to version 2.7 of ASIO4ALL.

I don't think it has to do with timestamping, because it also happens when no midi or audio-input is happening. It seems as if bufferswitches are requested too soon and slowly a queue of audio is building up which is waiting to be played back. The time between sending audio to the ASIO driver and the moment it is played back is increasing even while it should be constant.. very weird.. any input would be greatly appreciated.. (because I'd like to know if it's a bug in my own code, or if it's something with ASIO4ALL).

Either way, thanks for the good work. Without ASIO4ALL I wouldn't have ASIO on my laptop at all..

Cheers!

Bram Bos
--
Tunafish VST Sequencer
www.brambos.com

[Michael Tippach]

I had a deeper look into this. If you see a burst of buffer switches "early", they are, in fact, _late_. This means that something (not necessarily your BufferSwitch() handler) has been stalling the audio thread for too long before - in which case ASIO4ALL would send pending BufferSwitches in a burst style fashion.

Having said that, normally the overload detection in ASIO4ALL is supposed to detect this kind of condition and restart audio internally (without letting the host know) if the condition cannot possibly be healed by this kind of "burst".

In practice, it is a bit difficult to decide if a situation can be "healed" i.e. operation continued with no interruption to the audio stream - or not.

I have identified a condition in which such an incurable situation would not be detected (and "Overload" signaled). This mostly will happen if the ASIO buffer size is set too low. It can, however also kick in if the host has a habit of stalling the audio thread for a long time - and FLS is known to do exactly that.

I'll see if I can improve upon the overload (stall) detection. I'll keep you posted.

[Bram Bos]

admin said:

I had a deeper look into this. If you see a burst of buffer switches "early", they are, in fact, _late_. This means that something (not necessarily your BufferSwitch() handler) has been stalling the audio thread for too long before - in which case ASIO4ALL would send pending BufferSwitches in a burst style fashion.

Hi Michael,

thanks so much for looking into this. It sounds like a plausible cause for the problem I'm seeing. I have made a workaround to the problem by stopping and then restarting the ASIO process at the moment the user hits the play-button. In a host this happens quite often so in practice the problem - if it occurs - is solved by a simple stop-play action.

Thanks!

Bram
--
Tunafish VST Sequencer
www.brambos.com

[Michael Tippach]

Hello Bram,

Thanks for your willingness to work around this on your end! Alas, I don't think this is the right approach.

Eventually , you will want to have the user play their software synths without the transport actually running, i.e. not direct monitoring but monitoring through effects and so on...

Further, the time e.g. ASIOinit(), ASIOstart()... may take to execute is unspecified. This would mean that - depending on the driver - the users would not get an instantanious response whenever they press "Play". This has been an issue with e.g. Cakewalk for centuries =:/

Therefore, this needs to be fixed at the driver level. I'm working on that.

[ggoyal2]

Hallo mr. tippach. Are u still woking on it? How far away is sokution?

[Michael Tippach]

You may want to try this:

www.asio4all.com/271test.zip

But I must warn you that this one is about as stringent towards possible underruns as the British are about their Monachy!

[ggoyal2]

sorry for responding late mr. Tippach, the problem seems to be a bit more under control. However, you were right about underruns, they have increase by a lot. i have to increase buffer latency to 1024 for it to become like before.

I am also getting bluescreen sometimes (when FL stop responding and i have to close it thru task Manager). the details are follow:

DRIVER_IRQL_NOT_LESS_OR_EQUAL

...
...
...

***STOP: 0x000000D1 (0x00000000, 0x00000002, 0x00000000, 0xAAD5E42D)
***RtkHDAud.sys - Address AAD5E42D base at AAB8A000, Datestamp 44435258

I am running all latest drivers for all my hardware and my OS is fully up to dates.

[ggoyal2]

Hello Mr. Tippach, I've discovered that I get this BSOD ***everytime*** I change the buffer settings with ***every*** audio application (like FM7 v1.1.3.4, Battery v2.1.5, etc.). After I click "exit" in ASIO4ALL settings window, the audio application crashes with the standard windows cresh message (the program need to close...). Then as soon as I click on "close", I **unvariably** get the BSOD. The details of BSOD are explained in the above post.

I decided to go with ASIO4ALL v1.8 for now, and haven't found BSOD (so far). Best of all, the MIDI latency seems to have gone away!!! But I miss the per-application settings and Einstein/Bush photos! ;D There is one more important problem: it gives a LOT more crackles at buffer latency of 11ms than ASIO4ALL v2.x (and the test vertsion). Please help!

[ggoyal2]

Please help Mr. Tipach!

[Keldon]

Which version of FL studio are you using? 6.04 has problems with asio4all which are fixed in 6.08.

[ggoyal2]

6.08 man! pleas read first post!

[ggoyal3]

help Mr. Tipach where are you???

[Laptopeer]

Hi Mate,

I see ya!!

I have almost identical (possably identical) BSOD

I am getting MT to look at it by posting my bug report. Please check around this for more info.

Thanks,

LPTPR