Showing results for 
Search instead for 
Did you mean: 

Programmatically unload lvsound2.dll

Go to solution

I have a LV program to test USB headset audio. It works fine for one model.

Each time I want to test another headset model (another device USB PID), error 4800 (selected device is invalid) is found.

Take a look at Labview sample code named Generate . Connect a USB headset and run VI. Then change usb headset to another model and run again. You will have error 4800.

If I close and open Labview,it works fine but I do not want to do it because it is complicated flow of test process.

To generate audio in speaker USB headset or read signal in Microphone USB headset, I use sound VIs from labview and they use lvsound2 library.

This library also uses lvsound2.dll

In order to avoid closing and opening Labview, I want to programmatically unload lvsound2.dll

Is there any way to do it?

Any sample code?



0 Kudos
Message 1 of 10

You should be able to detect the error when you remove the USB headset. When this happens make the program reset until the error goes away. This means you need to close the coms, initialize the coms until there is no error when you initialize the coms.


I would make a timeout so it retried to ini the coms every 2 or three seconds. This give you time to plug int he new USB headset before it tries again.

0 Kudos
Message 2 of 10



The only open port is USB audio session. It is closed intermediately before finish program.

Then after 10 seconds, I unplug and plug new headset, then wait about 5 seconds for windows to detect it. Enough timeout.

Then I run program again, and error appears when open new usb audio session.

I made a research in internet and Labview forums and it seems it is an issue with lvsound2 library.

So, my last option is unload lvsound2.dll

Is there any way how I can do it ?




0 Kudos
Message 3 of 10
Accepted by topic author EDGAR_PLATRONICS
05-16-2018 12:44 PM

Only way I can think off...


Copy the entire sound library. Modify all VI's to use a path specified on the diagram. To unload, call the all the VI's\dll's once with a different path. Just hope no VI's are protected.


See How to Load and Unload a DLL When Wanted in LabVIEW and LabView doesn't unload dll when called in development environment.

0 Kudos
Message 4 of 10

Another way to do what you want to do instead of modifying the Sound VIs would be to write a single top level VI that handles all the sound related hardware control so that you do not have any Sound VIs outside of the hierarchy of this top level hierarchy. Then you can load and unload this top level VI at runtime at will. If you use some named queue based producer consumer scheme to communicate between your subsystems, it would be very easy to adapt to this scheme, otherwise it will require some serious rearchitecture. 


Using VI Server you can open de reference to the top level sound controller VI and start it, then send it commands through named queues and receive answers through responses to those commands and once you are finished you send your "sound processor" the terminate signal and then close the VI refnum, which will also unload the DLL as long as it is not referenced anywhere else in your application.

Rolf Kalbermatter
Averna BV
LabVIEW ArchitectLabVIEW ChampionLabVIEW Instructor
0 Kudos
Message 5 of 10

@rolfk wrote:

which will also unload the DLL as long as it is not referenced anywhere else in your application.

Just to be clear, this is also true for my method. LV will only unload a dll if it's not used anywhere. Both our methods are just a way to make that happen.

0 Kudos
Message 6 of 10

Thank you for your comments.

My code to do this test has some complexity level and USB audio VI's are used several times.

So, it will take me some time to modify an test if it works.

But maybe I can isolate just one case and test it.

I will post results,



0 Kudos
Message 7 of 10

If there are multiple parallel processes, let's say 4, you might succeed by simply making 4 copies of the dll, and let each process use it's own dll.


I have no idea how this turns out, but as each process can now load and unload it's dll (using previous tricks) it might be easier. It's a huge hack, but so bold it might just work. If you decide to use the path from diagram trick, this would not be too hard to implement either. (I'd convert the library to a class, and put the used path in the private data. The init can then decide on the path to use.)


However, there is a change that the error is a result of allocated resources in the dll, so copying the dll might not do anything.


It might cause more problems then it solves (if any)... Just thinking out loud.

0 Kudos
Message 8 of 10

Than you very much.

Since I do not use the whole lvsound2 library, I just focus on VIs that I use and modify "path specified on the diagram" for each VI.

I isolate one of my USB audio test VI and applied those changes.

So, each time I test one unit I run local path first, then I run NI path. It works if I change USB device without closing Labview.

It seems that I need to run local path for all VIs needed in audio session. I mean, "Sound input configuration VI, Sound Input read VI, Sound input clear and so on. But If I run only one time all of them prior testing one unit, it is not a problem.



0 Kudos
Message 9 of 10

Yes, each loaded VI will keep a reference to the loaded memory. Only running each one of them once with another path will clear this reference. Those CLFN don't share their information in any way. That is by design, and for the best, although not convenient in your situation.

0 Kudos
Message 10 of 10