"Sound Output Write (I16)" problem

[AQ1]

Using LabVIEW 2014 (v14.0f1 (32-bit). Windows 7 (64-bit) with inbuilt HD audio and std Microsoft audio drivers.

My program plays continuous stereo audio out the HD Audio device via repeated calls to "Sound Output Write (I16).vi" (which calls lvsound2.DLL: SOWrite function).

My program works great for a few days, then no audio.

My program continues to run, I can see the data being submitted to the "Sound Output Write (I16).vi" function using graphs (data is all OK), the DLL function keeps getting called with the same 'task ID' and returns error code 0 (no error).

Without stopping my program, if I insert a breakpoint just ahead of the call to "Sound Output Write (I16).vi", allow the program to break, then single-step into the "Sound Output Write (I16).vi" function, allow it to execute in debug mode, then drop back to the main program, the audio is restored.

I have been very careful not to insert or remove any other audio devices during the period of testing.

I wonder if anyone else has experienced similar behaviour or has some ideas I could try to improve reliability?

[mikeporter]

First off let me say that this is strange behavior that I am clueless about too. But, some things to try.

If instead of single stepping through the subVI, how about execution highlighting, does that make the audio to return?

Can you run this code on another computer?

Does it still do it if you build an executable?

Does it always fail after the same amount of time?

Mike...

[rolfk]

I don;t really know either as I never used that function for days without interruption but I'm pretty sure it is not the execution highlighting itself but rather the fact that when you start execution highlighting you probably slow the code down enough that the internal buffers get (almost) depleted. Does the sound get interrupted when you do that?

Do you pace your waveform generation with the speed of sound generation or are you simply continously throwing data at the SO Write VI which might somehow, somewhere overflow an internal buffer limit, causing the API function to block because it is waiting for more buffer space while the sound output is also somehow blocked?

[mikeporter]

Execution highlighting, like single stepping, effects timing but it also effects the optimizations that the compiler can apply to the code.

Mike...

[rolfk]

---

@mikeporter wrote:
Execution highlighting, like single stepping, effects timing but it also effects the optimizations that the compiler can apply to the code.

Mike...

---

Only on the diagram level and only very limited. This is most likely an issue in the lvsound2.dll as the LabVIEW VIs are only a very thin wrapper around that. The LabVIEW execution settings can't really change how the DLL itelf is optimized. That's a function of the compiler settings when the DLL was created.