dataflowg/g-audio

Different device and audio channel count causes gaps in audio playback

Closed this issue ยท 7 comments

Is looping playback supported yet?

If I do something like this there is a noticeable (several hundred ms dead period before my tone starts again).

image

Hi Neil, thanks for raising this issue.

Looping / continuous output is definitely supported. I tried the example code and can reproduce the issue you're seeing. The problem is the audio device is configured for 2 channels, but only a single channel is being written to the device. Internally the single channel signal is being interpreted as a stereo channel, resulting in gaps and a higher pitched tone (882 Hz).

Upmixing / downmixing of channels to handle this exact scenario is on my todo list for the next release. In the mean time you can either configure the audio device for 1 channel, or build a 2D array to create a 2 channel signal (watch out for funky vim broken wire behavior if you insert a build array, you may need to recompile the BD by holding ctrl and clicking the run arrow).

image

This should be addressed with commit 23b8757 on the dev branch. The commit contains an updated VIPM package too.

Thanks, I will check it out. Yeah I did originally have a 2D array, but the VIM kept on breaking and I could not figure out how to get it runnable again.

Can confirm the issue goes away if I make the device configuration mono, or use a 2D array.
23b875 also fixes the issue (device can be configured for stereo and a mono signal plays with no audible gaps).

Thanks for confirming the fix ๐Ÿ‘

Yeah I did originally have a 2D array, but the VIM kept on breaking and I could not figure out how to get it runnable again.

Looks like #4 isn't fixed after all. There seems to be some LabVIEW bug with VIMs and changing array dimensions, and the BD not being recompiled. I'll reopen it and look for other workarounds.

The VIM did break again for me yesterday when I changed the 1D to a 2D array, but force-compiling like you suggested fixed it straight away.

I think I've tracked down the cause of the broken VIMs, which appear to be caused by nested type specialization structures and the order in which LabVIEW evaluates the cases. Workaround is to not use the assert vims inside the type spec struct. I'll raise it as a bug on the NI forums.

I'll close this issue now, as it looks to be working. Thanks again for the report, and trying out the library. If you have any feature suggestions please let me know.