Recording long sound files to disk

[gobeirne]

Hello all,

Here's a pretty clumsy VI with an incredibly messy block diagram that I've cobbled together to record wave files to disk and automatically increment the file names after each recording. It does what I want for short duration recordings, but I was wondering if there was a way of streaming the recorded sound data direct to wave file on the HDD so that we don't run out of memory for long recordings (e.g. 1 hour? 2 hours?). Oh, and there's also a little clipping-detection section in there that I had to install for external microphones that clip below the dynamic range of the sound-card input.

I'd be keen to hear the solutions people use for this sort of streaming - I'm sure there's a much better way out there! If you make any changes to the attached VI, please post them here for others to see (and in a format that can be opened by LabVIEW 8.20!)

Cheers,

Greg.

Recorder19.vi

[Chris O]

Hello all,

Here's a pretty clumsy VI with an incredibly messy block diagram that I've cobbled together to record wave files to disk and automatically increment the file names after each recording. It does what I want for short duration recordings, but I was wondering if there was a way of streaming the recorded sound data direct to wave file on the HDD so that we don't run out of memory for long recordings (e.g. 1 hour? 2 hours?). Oh, and there's also a little clipping-detection section in there that I had to install for external microphones that clip below the dynamic range of the sound-card input.

I'd be keen to hear the solutions people use for this sort of streaming - I'm sure there's a much better way out there! If you make any changes to the attached VI, please post them here for others to see (and in a format that can be opened by LabVIEW 8.20!)

Cheers,

Greg.

The easiest way to record for long periods of time is write to your file periodically. There are different ways to go about this. If you want to write less often, you can build a buffer and then open/write/close your file every few minutes. Or, if you want to keep memory usage as low as possible, open the file and leave it open. Then write to it after shorter periods of time (every second or so). Once you are done recording, close the file. Be careful not to write to the file too often (10's of times a second or more) because you will lose hard drive performance and incur high CPU usage.

One other thing to note: LabVIEW uses 64bit values for file position in binary files, but a 32bit integer for the length value in a wave file. This will cause a problem if your wave file gets above 2GB. We had to use a hex editor to fix the length value in a wave file that was too long. For normal audio recoding rates though, that's a pretty long time. (3-6 hours or more depending on the number of channels.)

[PaulG.]

Ahhhhhh!!! MY EYES!!!

[Phillip Brooks]

Ahhhhhh!!! MY EYES!!!

That's one BIG block diagram!

[Daklu]

Here's a pretty clumsy VI with an incredibly messy block diagram

After Paul's comment I just had to take a look, and... I guess you did warn us.

If you're planning on doing any more Labview development I recommend learning the state machine design pattern. It's a fairly simple pattern that will go a long ways towards making your code more readable and maintainable.

If you make any changes to the attached VI...

Not a chance. Before I made any changes I'd have to understand it, and to be blunt, your code is far too messy to comprehend in a reasonable amount of time. I had to delete your vi from my computer--I was worried it would be a bad influence on my vis.

If it were me, I'd probably implement a buffer and write to disk every couple minutes. If you keep the file open continuously then if LV crashes or your app gets into an undefined state you run the risk of losing all your data by not closing the file. You might need to implement a front buffer and a back buffer so you don't lose any data during the disk write operation.

[gobeirne]

Thanks for the tips guys. I'll get to work on the state machine architecture - definitely preferable to the Big Ball of Mud

If you're planning on doing any more Labview development I recommend learning the state machine design pattern. It's a fairly simple pattern that will go a long ways towards making your code more readable and maintainable.

[Stagg54]

That's one BIG block diagram!

If you think that is bad, you should see what I have to put up with on a daily basis!

Making huge messy diagrams is a great method of job security (because no one else can understand it), but it sure sucks for the guy who replaces you when you retire.

[jgcode]

I had to delete your vi from my computer--I was worried it would be a bad influence on my vis.

I'll take one for the team - here is the image in case anyone else is too scared to download it

PS - On the upside the Icon looks really nice!

[asbo]

BD Cleanup gave it its best shot ... (the raw bitmap was 28.8MB and this PNG is 1.1MB)

[jgcode]

BD Cleanup gave it its best shot ...

Wow! That actually looks half decent!