Continuous Saving from DAQmx to a WAV File

I am trying to save a waveform that was recorded by a DAQmx device into a .wav file. I have found two sample vi's that I used to start with.

Sound Input to File.vi

This vi saves the waveforms from a microphone input to a .wav file. The nice thing about this vi is it has no limit on how long you can record.

SVXMPL_WAV Record (DAQmx).vi

The vi saves the waveforms from the DAQmx input to a .wav file. The nice thing about this vi is it shows how to get the waveform through the DAQmx device, but you can only record for just over 1 minute.

DAQmx Input to File.vi

This was my attempt at combining the best things of the above vi's, but it doesn't work and I don't know why. I'm hoping somebody can tell me where I went wrong and/or how to improve my vi.

Re: Continuous Saving from DAQmx to a WAV File

When you try to acquire more than a few minutes of data are you getting an error message that states the requested memory could not be allocated?

This error appears because the program tries to all acquire data in a single DAQmx read call (1 channel N sample). You will need to instead, modify the program such that you call DAQmx read multiple times so you can use a smaller buffer size. The best way to change this would be to implement a producer/consumer loop where the producer queues all the samples and the consumer dequeues them and feeds them to the Sound Write Waveform VI.

Re: Continuous Saving from DAQmx to a WAV File

From your original post it sounds like creating a producer/consumer loop will help you. What is the acquisition duration you are using? Do you receive this message when using a smaller value like 1 second?

Re: Continuous Saving from DAQmx to a WAV File

If you remove the numeric constant, and adjust your max and min values to +/-1 volts your VI seems to work correctly. The +/-1 volt limitation is defined in the detailed help of the sound file write VI.

Re: Continuous Saving from DAQmx to a WAV File

Yes that works and seems to solve the problem. Thank you. I did have to connect the Number of Samples/ch input to the Sample Clock instead of the numeric constant that I had in order to prevent a different error message.

I can see that the producer/consumer solution would be more elegant than my method, however I have attached my solution in case anyone else ever wants to look at it.