Repeated running record and play from WaveIO gives error -5

[Spejz]

Hello,

we have a problem in LabVIEW. We use the library called WaveIO. The purpose of this part of the program is simultaneous generating and recording signal using a sound card. (We have tryed both ASIO and standard drivers allowed by this library). We need to play and record the signal. After that increase the generated signal level and play and record again.
We have modified the example vi from waveIO library but the original untouched VI gives the same error. We control the subvis (stop them) using a global variable "StopGlobal.vi". First step executes correctly but repeated execution of these subvi generates unspecified error -5.
We included simplified part of our code.

Thank you for your help. This is our first project in LabView so we appreciate any advice.

[Bob_Schor]

I suspect the -5 error was generated by the Third-Party Software that actually "does the work" for you.  Do your manuals list error codes that the software packages can produce?  Often times errors arise because of "bad timing" or not doing things in the right sequence.  I would examine the Third-Party hardware and its accompanying drivers and utilities.

Bob Schor

[Rajesh_Nair]

Hello,

I am also facing the same problem. Did you got a solution?

Thanks,

Rajesh

[Dataflow_G]

The -5 error is from WaveIO, and is a timeout in calling the underlying WaveIO DLL. The WaveIO manual describes the timeout configuration:

"A watchdog thread is started, if the specified timeout is greater than zero. The watchdog will close the device, if no call to the DLL is detected within the given time window. For each device (and I/O mode) a separate watchdog thread is started."

You might try setting the timeout to 0 to disable the watchdog timer.

I have run into unexpected timeouts even though the WaveIO DLL is called tens of times per second. In these cases closing and reopening the device is normally enough. If you get error -3, that requires a restart of LabVIEW to fully unload and load the WaveIO DLL again.

If you're still running into error -5, could you provide a code example?

[Rajesh_Nair]

Thanks for the reply. The tone generation VI for ASIO is called dynamically and I bench marked the tone generation. Its around 5ms and still am getting timeout error. And I am seeing glitches in the tone (when CPU is getting loaded, CPU usage more than 80%) and its a big issue for my application which is Audio. Am attaching the code, please open the vi named Gen.vi PFA.

FYI, and this code is the part of Veristand custom device which we are developing.

[Dataflow_G]

Hi Rajesh,

Thanks for posting the code. I don't have access to VeriStand (and I think there are a few missing VIs too), but can see how it should all work.

For glitch-free, continuous audio output you'll probably need to separate the WaveIO code into a subVI running in parallel, and have it run using a higher thread priority and a different execution system. Apart from a larger audio buffer, these execution settings seem to make the biggest difference in maintaining glitch-free audio output. When running within the User Interface thread (the default), it's competing with other tasks also running in the UI thread (VI Server, the "root loop") plus actual UI events (window drawing, user inputs, etc) which are all potential sources of glitch causing jitter.

Other things to help reduce glitches include disabling debugging in VIs, and ensuring no calls to VI Server occur within non-UI execution thread VIs.

As an example of all of the above, I recently wrote an open source DJing application in LabVIEW which achieves glitch-free, low-latency, continuous audio output using LabVIEW's sound API or the WaveIO API. Here's a short example video of it in action, showing simultaneous playback, file loading, and interactive audio processing, while maintaining glitch-free output.

Spoiler

Some questions and things to try:

• Is ASIO output a requirement, or can the application handle slightly higher audio latency?
• Are you using ASIO4ALL as the driver, or a soundcard with a dedicated ASIO driver? ASIO4ALL is generally good, but can have problems.
• Consider moving the WaveIO code and waveform generation into a separate subVI and set it to a different execution system + thread priority
• Extending the previous point, one subVI dedicated to audio production and manipulation (generating the audio data), and a second subVI dedicated to audio output. These would both run at different priorities and execution systems to each other and the main VI.
• Is the DVR being accessed elsewhere while this code is running (potentially causing it to block)?
• IPEs do have some overhead, so unless they're absolutely necessary I'd probably remove them. The LabVIEW compiler is pretty good at avoiding memory copies.
• Does a simplified example work without glitches?
• I couldn't see it in the code, but what buffer settings are used when initializing WaveIO? I've used 3 buffers, 1024 samples/buffer, and Samples as the unit successfully.

[Rajesh_Nair]

Thanks for the reply and sorry for the delayed response.

Your application is superb, well done man.

Actually I am talking with the person who developed WaveIO, he found some issues with thread priority. I am working with him. I will keep you posted.

Again appreciate your support.