LabVIEW Idea Exchange

cancel
Showing results for 
Search instead for 
Did you mean: 
asbo

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

Status: Declined

Moved to CAR database: CAR 722510

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.

14 Comments
adel.k
Member

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

nestorl
NI Employee (retired)

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

Lindsey Nestor
Program Manager, Hardware Services
National Instruments
wiebe@CARYA
Knight of NI

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...

Darren
Proven Zealot
Status changed to: Declined

Moved to CAR database: CAR 722510

ConnerP
Member

Is there any status update on this issue?

Dataflow_G
Member

I've been working on an open source library called G-Audio which aims to be a replacement for the aging lvsound2 library. Amongst its features is on-the-fly device enumeration, which has been one of many annoyances of mine when dealing with lvsound2.

 

It also supports many more backends (WASAPI / DirectSound / WinMM on Windows, Core Audio on macOS, and PulseAudio / ALSA / OSS on Linux), plus loading MP3 / FLAC / Ogg Vorbis / WAV files.

 

The library is entirely open source, and a VIPM package can be found on GitHub and through VIPM itself.

 

GitHub: https://github.com/dataflowg/g-audio

VIPM: https://www.vipm.io/package/dataflow_g_lib_g_audio/

asbo
Member

@Dataflow_G This is awesome! I appreciate you posting about this, I've also shared it internally for visibility. Hopefully it saves us some heartache on future projects. Thanks for your contribution to the community!

Dataflow_G
Member

Thanks asbo, I hope it helps with your projects. If you or anyone internally run into any issues, or have any feature requests or suggestions, feel free to raise an issue on github. The next release will include Raspberry Pi / LINX support, and adds some advanced device configuration options.

Joe_Guo
Active Participant

G-Audio supports LabVIEW 2020 and above.  Any reason why lower LabVIEW versions not supported?

Dataflow_G
Member

No real technical reason, just that it was developed using LV2020 Community Edition. It does make heavy use of malleable VIs and type specialization structures, so would require at least LV2018.