Hi, Im developing a LabVIEW built test application that involves usb sound cards. Breifly the application consists of a GUI VI based on a state machine with an event structure. Each test object (sound card) has its own I/O loop VIs, one for recording and one for playback. These VIs are dynamically started and shared clone reantrents. My tests are critical in terms of latency and I'm therefore forced to use small I/O buffers ( 2x50ms for the playback). The thing is that everything is working well as long as I don't move the mouse cursor rapidly over the application GUI. If I do so it triggers buffer underrun on the playback and the sound output glitches. This behavior makes me suspect that there is a unwanted UI thread dependency in the I/O loops. I have set the execution properties of the VIs that encapsulates the I/O loops (and their sub VIs) to time critical priority and data acquisition as their prefered execution system. Unfortunately this does not solve the problem. Does anyone know what could be the reason why fast mouse movements over the GUI affecting the I/O loop VIs and how to solve the problem? Best regards Jon

LabVIEW

Unwanted UI thread dependency in data acquisition VIs

Author

The interface to the sound cards that I'm using is a library called WaveIO (http://www.zeitnitz.eu/waveio). Writing and reading buffers are done via Call dynamic linked library nodes i.e a C DLL and these function calls uses multi-threading, not the UI thread.

The calls to the WaveIO isn't done from within the GUI. Breifly the application consists of a GUI VI based on a state machine with an event structure. Each time I start a playback / recording session I dynamically start a daemon process (VI) dedicated for that specific soundcard. This VI contains a two sub VIs, one for recording (loop) and one for playback (loop), and these are running in parallel. I have set the execution properties of all these I/O VIs to time critical priority and data acquisition as their preferred execution system. These VIs are also set to shared clone reentrants because they are shared between multiple sessions (sound card) that run in parallel. The data from these loops are continuously enqueued to queues and dequeued in a lower pace in the GUI for analysis. The I/O VIs are clean from local variables, property nodes and other stuff that for what I know uses the UI thread. The CPU for the application while running is fairly low (about 1-4 % cpu) according to the windows task manager.

JonS