02-20-2024 04:25 PM - edited 02-20-2024 04:27 PM
Hello! I need to acquire a 1-hour long analog signal and save it as a WAV file, but I'm running out of memory around 15 minutes. I learned through researching online that this may require a producer/consumer architecture, and I have read through the description and example codes. While I understand it conceptually, I cannot figure out how to implement it for my case (after trying and failing for many days). I've attached my original code and would really appreciate any help, since I am completely new to LabVIEW. Thank you so much in advance!
02-20-2024 07:09 PM
You can refer to Producer/Consumer Read Waveform Data and Write to TDMS at Two Different Rates and replace the TDMS API with Sound Files VI. Use the low-level Open, Write, and Close instead of the Sound File Write Simple VI.
02-22-2024 05:42 PM - edited 02-22-2024 05:43 PM
Thank you so much! I was able to use your suggestion to make my code run successfully. I have a quick follow-up question-- how do you determine the optimal consumer loop speed? The given example (writing 3 times slower than reading) works for my current case, but I'm hoping to learn how that value is decided in general. Thanks : )
02-22-2024 07:30 PM
The Producer/Consumer example you were studying talks about the Consumer running "three times slower than the Producer" because it is counting "loop speeds". The Producer sends 1 Buffer-full each loop. The Consumer acquires three of these Buffers before it writes all three, so (technically speaking) the Consumer runs one loop for every 3 that the Producer runs. So if you count "loops per second", the Consumer is 3 times "slower", but if you count "Buffers" or "Bytes", both loops run at exactly the same time.
One consideration is what "extra" work does the Consumer have to do to handle whatever it does (such as "write to a file"). Sometimes it is "more efficient" to bundle several buffers-worth of data in a single "File I/O" command. There's nothing to stop you from collecting 10 buffers before writing, but that would require more memory to hold the buffers, plus other considerations you might encounter.
Bob Schor
02-26-2024 07:44 PM - edited 02-26-2024 07:46 PM
02-26-2024 07:59 PM - edited 02-26-2024 08:02 PM
Hello! I was able to rewrite my code using @ZYOng's helpful suggestion, and it successfully records the long audio now, but I just realized the saved file is completely jumbled (samples are out of order). I've tried changing several different components but cannot seem to figure out the issue unfortunately. Would you mind helping me take a look at the attached VI? Thanks so much again!
02-26-2024 08:43 PM
@p0rg wrote:
Would you mind helping me take a look at the attached VI? Thanks so much again!
Unfortunately, I don't have LabVIEW 2022 installed. Can you "Save for Previous Value" and specify LabVIEW 2021 and re-attach it? [I'm also sure @ZYOng will also be able to respond with the clarity I've come to expect ...]. If you are using a Queue or Stream Channel correctly, and are building the WAV file correctly, it should be "automatic", but I haven't examined it carefully yet ...].
I remember about a decade ago, looking into reading and writing "sound" data into a .WAV file by using third-party tools to allow me to stream 2-channel analog data into a "as long as it needs to be" .wav file. The need for this effort disappeared (my colleague dropped the research project), so I don't remember what/how I was trying to accomplish this. I certainly didn't think of doing this directly in LabVIEW, but the Example file seems to suggest that this might work. I might try it out tomorrow ...
Bob Schor
Bob Schor
02-26-2024 09:00 PM
Well, I was so curious that I opened the example, started it running, and then sang the Alphabet Song ("A, B, C, D, E, F, G .... H, I, J, K, ..." etc). When I finished, I had a .wav file that was 15 seconds in length and took 1.3 MB of disk space. Unfortunately, when I played it, I heard myself singing the Alphabet Song -- it wasn't pretty! [My wife asked me why I was singing ...].
And this didn't even use the Producer/Consumer Design Pattern. Of course, its sample rate wasn't that high (nor was the fidelity), so putting in a nice two-loop Producer/Consumer Stream Channel certainly wouldn't hurt. I may play with this a bit more tomorrow, but I'm encouraged that this seems to work! Bravo, NI (if I'm correct).
BS (stands for Bashful Singer, of course)
02-27-2024 02:32 PM - edited 02-27-2024 02:40 PM
Hahaha your post just made my day! Inspired by your method, I recorded myself counting out loud and discovered the issue-- when the consumer loop dequeues a packet of 3, the samples are appended to the waveform in reverse order. So for example, when I counted to 10, the recording saved "3,2,1, 6,5,4, 9,8,7, 10." I'm having trouble fixing this issue in my code though-- would you be able to provide some help (LV2021 VI attached)? Thanks!