Search the Community

We are searching for a smart, enthusiastic and innovative software engineer with a passion for LabVIEW who is highly proficient with complex LabVIEW application architectures such as Actor Framework. You will be a key technical leader within the development team, creating new features and solutions while maintaining a large code base for SoundCheck, Listen’s flagship electroacoustic test software. This position requires commitments to following-through, testing, and implementation in order for the team to deliver critical software releases. You will be enthusiastic to learn from and share knowledge with other team members and be willing to find solutions to programming challenges that are new to the team. A perfectionist streak, pride in your work and attention to detail are key characteristics that are required for this role. If you are looking for an opportunity to take your passion for LabVIEW and apply it to a leading commercial test and measurement system, please review the detailed job descriptions at our website.

I'm working on a project that requires sound output via the Windows audio subsystem, and so I've recently found myself using the LabVIEW "Sound" pallet vi's for the first time in.....well...ever! The sound output ("Play") vi's allow you to setup and configure an output "task". As part of that configuration, you define a buffer size. Once that sound output task is configured, you effectively write your sound samples into this buffer over time, periodically refreshing this buffer with new audio sample data. That's all fine and good, but unfortunately it seems like there is no mechanism to query the buffer status and find out if the buffer is about to overflow or underflow. While this might not seem to matter if you're playing a sound file for a few minutes on a machine with lots of RAM, it definitely does matter if you're streaming live audio continuously through the system for several days or weeks. If you refresh the buffer with new audio sample data at rate that is just slightly faster than the audio card's configured sample rate, then it seems like the buffer will eventually use up all available PC RAM. if you are refreshing that buffer just slightly slower than the audio card's configured sample rate, then it seems like the buffer will eventually underflow and create a glitch in the audio output. And since there is no way to monitor whether the buffer is trending toward overflow or underflow, there is no way to figure out how to adjust the rate at which you feed new audio sample data into the buffers. Am I missing something here? Is the audio subsystem doing some sample rate conversion that I don't know about? What is the proper way to ensure that the sound playback buffers do not overflow or underflow over an extended period of time?

Hey everyone, I'm very excited to let all NIWeek attendees know about a new podcast series I started in collaboration with NI. Aptly named the NIWeek Conference Podcast, you can listen to the first episode here. We'll be releasing one episode per week, to the run-up to August.