LabVIEW Idea Exchange

About LabVIEW Idea Exchange

Have a LabVIEW Idea?

  1. Browse by label or search in the LabVIEW Idea Exchange to see if your idea has previously been submitted. If your idea exists be sure to vote for the idea by giving it kudos to indicate your approval!
  2. If your idea has not been submitted click Post New Idea to submit a product idea to the LabVIEW Idea Exchange. Be sure to submit a separate post for each idea.
  3. Watch as the community gives your idea kudos and adds their input.
  4. As NI R&D considers the idea, they will change the idea status.
  5. Give kudos to other ideas that you would like to see in a future version of LabVIEW!
Showing results for 
Search instead for 
Did you mean: 

Update the lvsound2 library (Sound Input/Sound Output VIs) to support changing audio devices on-the-fly

Currently the lvsound2 library -- the Sound Input and Sound Output VIs supported by lvsound2.llb and lvsound2.dll -- updates the audio device list from the operating system only when first being loaded into memory. If you change the device list (e.g.., pair/unpair a Bluetooth headset) the device IDs will not reflect the new configuration until all the lvsound2-dependent VIs have been unloaded from memory. After adding or removing a device, the VIs will generate error 4803 ("The sound driver or card does not support the desired operation.") for device IDs related to the new/removed device,  even if the ID is still actually valid and points to something else. This is extraordinarily inconvenient for test systems focused on audio device testing, but understandably a niche issue, which may be why it hasn't been caught before now.


In the interim, the workaround is to dynamically call any of the VIs you're interested in to force them to load/unload as necessary. There are two appropriate solutions I can think of:


1) Update the Sound X VIs to implement the dynamic call workaround (preferably directly around lvsound2.dll calls so we can still borrow other VIs in the LLB).

2) Update the DLL to support on-the-fly changes.


The latter solution is ideal, particularly for performance. This reads both as a suggestion and a bug report so that anyone else who has this problem can find a public forum documenting the issue.


Do you have an updated lvsound2.dll that we could apply? Thanks!


I've had another customer request this feature or a workaround. Any update?

Lindsey Nestor
Technical Support Engineer
National Instruments
Trusted Enthusiast

This is sad. The lvsound.llb does in fact seem to somewhat allow this. You can add a device, and that device will become a valid device, dynamically. But the lvsound.llb doesn't provide VIs for getting the number of devices or device info, and most VIs assume device 0 as a statically hard coded device...


Seems to me lvsound2.dll has an internal state that buffers device info. Useful for performance. But not resettable. This function is not called during loading (the dll doesn't have a dllmain), but when first run. With the source code of the dll, probably not that difficult to fix... Without the source code, a nasty hack at best, impossible at worse...

Example Gatekeeper
Status changed to: Declined

Moved to CAR database: CAR 722510

DNatt, LV R&D