Sound Output Timing Issues

[FranklinLab]

Hello,

I am having issues producing consistently timed sound loops using the attached VI. Can anyone point towards my error or provide any suggestions? The .Wav file was built in audacity at 44100kHz, but ultimately will be played mono.

Currently the first loop is ~3 seconds, while subsequent loops are ~5 seconds. I need the file to run exactly 5 seconds each time.

I have tried the following:

• Setting timeouts within subVIs to 0
• Lowering the samples/Ch on SoundOutputConfig.VI  to ~1000.

Thank you,

Frank

[BertMcMahan]

I don't have time to fully run this and try things, but a couple thoughts:

-From the help on Sound Output Configure.vi:

number of samples/ch specifies the number of samples per channel in the buffer. Use a large number of samples for continuous operations. Use a smaller number of samples if you want to use less memory.

You need a larger buffer, not a smaller one. I'd set it to something like 2x the number of samples you want per loop, as Sound Output Write should block until it writes the data to the buffer.

From Sound Output Write.vi's help:

timeout (sec) specifies the time, in seconds, that the function waits for the sound operation to complete. This VI returns an error if the time elapses. The default is 10. If you set timeout (sec) to -1, the VI waits indefinitely. If you set timeout (sec) to 0, the VI returns immediately while the sound continues to play. You can use the Sound Output Wait VI to wait for playback to complete.

This means you don't need the Wait function (why's it there if the timeout is 0 anyway?) as your Write function is waiting until it's finished playing anyway.

I would set the buffer to 1.5x your sample size and set the Write timeout to 0. This means your first loop will finish extremely quickly, as the Write doesn't wait, like it's doing right now. It will then start writing to the buffer, but stop (since it can't get the whole file in there) until half the file is written. Once half the file has been played, there's enough space in the buffer to write more file, then it writes it and the loop happens again.

Either way this is likely an issue with your buffer size- you only gave the buffer 1/2 second of space, and your file is 5 seconds long, so you're fighting the buffer constantly. The buffer is what makes it continuous, so give the buffer more room.

This will probably also work OK at a 1:1 buffer:file size application, but I've never used these sound functions so I don't know exactly.

[Bob_Schor]

I've not done much with LabVIEW's sound VIs, but I have used them, so I thought I'd give your Wave form a try.  Here are some findings (I'll try to describe what I did so that you can try to reproduce it -- you'll learn much better if you "do it yourself"):

• I wrote one line of VIs connected by a straight Error Line consisting of the following functions:
  • Sound File Info (I looked at both of its numeric outputs, which confirmed that it had a single sample of 5 seconds of sound).
  • Sound File Read Open, with no particular Polymorphic Version selected (defaulting to Automatic).
  • Sound File Read (with Data output examined, described below).
  • Sound File Close.
• I wrote a second line of VIs connected by a straight Error Line below the "Read line" described above, with the following functions:
  • Sound Output Configure, with the Sound Format input wired from the Read line's Sound File Info output, and all other inputs unwired, taking the default values of Continuous Samples, 22050 samples/ch, and Device ID 0.
  • Sound Output Write, with no particular Polymorphic Version selected, defaulting to Automatic, and having the Data Output from the above Sound File Read wired to its input.
  • Sound File Wait.
  • Sound File Write.
• The Error lines of these two routines, the Sound Reader and Sound Writer, were combined with a Merge Errors and then wired to the Simple Error Handler.
• I also timed the Write + Wait functions in the Write line.  I should note that the sound appeared very shortly after I pressed the Run button, meaning that the reading took almost no time (I'd guess less than a tenth of a second).

Better practice, of course, would have been to not try to "gulp" the entire file down all at once, but to read, say, a second at a time and play back the same way -- you'd certainly want to do this for recordings that last minutes.  I'll leave this as a further Exercise for the Reader.

Bob Schor

When I ran this code, I heard what sounded like white noise that lasted for 5.03 seconds.  I should note that