LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Unwanted UI thread dependency in data acquisition VIs

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

JonS
0 Kudos
Message 1 of 11
(3,122 Views)

I suppose that you use Labview on a PC OS? I think that if you are concerned by latency in the ms order of magnitude, your only solution is to switch to Labview Real-Time.

Marc Dubois
0 Kudos
Message 2 of 11
(3,113 Views)

The thing is that the buffer underrun only occurs when the mouse is moved rapidly over the application GUI or other running VI front panels, not if it is moved outside. This suggests that it is rather the LabVIEW UI thread that somehow is used in the I / O loop which is causing the problem rather than Windows.

JonS
0 Kudos
Message 3 of 11
(3,092 Views)

Jon,

 

Please post your VIs. Without seeing exactly how everything is set up it is difficult to determine where the problem may be.  

 

Do the sound VIs run in the UI thread?

 

Lynn

0 Kudos
Message 4 of 11
(3,086 Views)

Lynn

 

Unfortunately I can not post the project.

 

A correction to my previous post about the fast mouse movements. It has an impact even if its outside the application GUI (or other active VI front panels).

 

As I mentioned earlier the VIs containing the I/O loops are set to data acquisition as the prefered execution system. Is there anything else I can do?

JonS
0 Kudos
Message 5 of 11
(3,071 Views)

Don't use the same USB bus for your sound card and your mouse.

They might influence each other!

Best regards,
GerdW


using LV2016/2019/2021 on Win10/11+cRIO, TestStand2016/2019
0 Kudos
Message 6 of 11
(3,062 Views)

GerdW,

 

I have already thought about this and tested to use the computer's the touchpad instead of the usb mouse but the problem persists. Even if I use the computer's integrated sound card.

 

Thanks anyway for the tip 🙂

JonS
0 Kudos
Message 7 of 11
(3,055 Views)

So in your "time critical" vi, do you use Property nodes, local variables?

Anything that can force your vi to run in the UI thread?

0 Kudos
Message 8 of 11
(3,036 Views)

What's the interface to the sound cards? If it's a non-reentrant DLL, it will run in the user interface thread regardless of how the VI is set.

0 Kudos
Message 9 of 11
(3,026 Views)

What does your CPU usage look like?  Maybe you have a few loops that are spinning out of control ad even a mouse movement gives your PC fits?

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 10 of 11
(3,022 Views)