Trigger AI to acquire 20s voice for octave analysis.

[Bill Choy]

Hi all,

I'm doing a system response measurement using octave analysis and a 20s broadband wav file. I'm using LabVIEW 7.1, SVT 3.1, PXI 4461 and 8186 controller. Attached is the program for octave analysis. An AO port will be used to drive a speaker to play the wav file. The two AI ports will be used to measure the stimulus and response signal. The major problem is that I'm not sure the AI path is capturing the exact 20s voice. I need to trigger the AI task immediately when AO started to drive speaker. Also the AI task have to capture the whole voice signal for octave analysis. Are there any suggestions for improving my program.

Thanks,
Bill

[SnarrVIEW]

Hi Bill,

There is a LabVIEW shipping example that illustrates how to do analog input and output synchronization. I think if you incorporate this into your program it should work. It can be found by selecting the Help menu in LabVIEW and then choosing Find Examples. This will open up the NI Example Finder. Browse to Hardware Input and Output -> DAQmx -> Synchronization -> Mult-Function -> Multi-Function-Synch AI-AO.vi. Take a look at this and let me know if it helps at all.

Thanks and have a great day!

[Bill Choy]

Hi Bryan,

I tried to incorporate the example into my program before but it didn't work. If you take a look of my program you will find that there are two while loops for AI and AO individually. I can't start the both tasks outside the loops as the exapmle. This is my main problem and I need the other way to trigger the both tasks.

Thanks,
Bill

[SnarrVIEW]

Hi Bill,

After looking at your code I think that you might want to structure it more like the example I recommended. The DAQmx Write.vi does not actually write the waveform to the outputs, it only writes it to the task. The DAQmx Start Task.vi will immediately write the data unless it has to wait for a trigger as in the example program. Once the DAQmx Start Task.vi is called on the AI task then both the AI and AO tasks begin. I would suggest creating your waveform and feeding it into the DAQmx Write.vi outside of a while loop as they do in the example. Then start the AO, which won't actually start until you start the AI if you set up the same triggering as they do in the example. Then I would have your DAQmx Read.vi and DAQmx Is Task Done.vi in the same while loop. After all the acquisition is done I would then do the SVT functions and post process the data instead of processing the data on the fly which can be processor intensive. Let me know if this makes any sense or if you have any more questions please let know.

[Shane E.]

A bit off topic, but...

Is it easy to develop a LabVIEW solution to filter a .wav file (using the S/V toolset IEC1260 filters) and then WRITE the resulting time record (say, 30 seconds of bb noise) to disk AS A .wav FILE ?

One local consultant has his doubts. We're trying to decide whether LabVIEW is the correct technology choice. If not, any suggestions?

We do ASTM E336 and ASTM E1007 work.

Thanks for any help. Happy Holidays,
Shane

[Bill Choy]

Hi Bryan,

Thanks for your suggestion and it works. However, if the wav file size is very large. Do I need to split it into small blocks like my program. Then how can I handle the trigger?

Bill

[Bill Choy]

Hi Shane,

Read a wav file for post processing and save it as a new wav file is not difficult in LabVIEW. I'm also doing similar applications. There are some useful examples of handling wav file read/write are very good for reference. Try and post your problem here. There are many NI support engineers can help.

Bill

[Shane E.]

Thanks Bill,

Meanwhile I found the folks at VI Acoustics. They have some interesting products that relate to our problem and now we're convinced it is possible to use LabVIEW to read a .wav file, process it, then write a new (altered) .wav file.

As to our requirements, basically [& I'm skipping the cal issues since I'm sure we all know how to handle it], we seek a custom solution that:
- operates on a half-dozen 30 s time records (44,1 kSa/s, mono .wav files);
- passes the signal through 18 of the 1/3 octave filters (IEC 1260 compliant, as in the S/V toolset);
- calculates the LEQ(30) (i.e., SPL over 30 s) for each fractional octave filtered time record;
- exports all the LEQ(30) values in a suitable database format, so that our existing database can handle the rest of the mathematics and report generation;

Client FileMaker Database functions include:
- store the 1/3 octave band SPL of each broadband .wav file
- averages the 1/3 octave band SPL across the half-dozen mic positions of the present test case;
- store 1/3 octave band AVG (18 values per test case);
- tracks, tags, supports archiving each .wav file that emerges from field activity;

NOTES:

1) In the field, we do NOT use simultaneous / MULTI-mics. Instead, it is absolutely an "open and shut case" that the optimum process is to move one (1) single mic quickly from spot to spot. While holding the airborne noise at a constant level we position the mic at each spot for 30 s to feed the data recorder, then move on.

2) This explains why we are not interested in the N.I. DAQ h/w. We emerge from the field activity with, say, 60 calibrated .wav files that need post-processing.

3) LabVIEW, it seems, exports best to a spreadsheet, but I may be able to handle the conversion from LV's format to a proper database format that meets "1st Normal Form, 2nd Normal Form, etc.).

4) I hesitate to do more math in LabView than is strictly necessary. i.e., given a choice to calculate the averages in my database, versus in LV (say, to cut down on exported data qty), I'd certainly opt for exporting the octave band SPL's and then relegate the averaging burden to the database.

Thanks for any input at all!

[JedRetherford]

Bill and Shane,

It looks like this post got a bit confusing along the way. It appears that Bryan had been providing some insight on these topics, but he's out of the office right now, so I thought that I would try to jump in and provide some assistance.

First off, Bill, in regard to your most recent question about saving your file:
If you are interested in breaking your file into smaller pieces, I would go about handling it something like this: Under normal circumstances, when acquiring data in a loop you use three steps, 1, Open the file prior to the loop, 2, Write to the file repeatedly in the loop, and 3, Close the file after the loop. I would assume that this is the method you are using to write your very large file. Instead of doing this, I would modify these steps slightly so that you, 1, Open multiple files before the loop, 2, Place a case structure with a file write in each case in the loop, then as the loop iterates, have it change cases (first ten seconds of data gets written to the first file, case structure changes, second ten seconds of data gets written to the second file, etc.), 3, Close out all the files after the loop completes.

Using this method, the data is written into consecutive files and the transition from one file to the next is seamless. This also prevents needing to trigger more than one time, as you only trigger the start of the acquisition.


Shane,
As for your issue, I am not quite sure what you are looking for exaclty. Looking over your posts, I agree with Bill that you should be able to do your .wav to .wav conversion within LabVIEW. As for more specifically what you are trying to accomplish with LabVIEW, as described in your second post, I do not have much experience with the specific application type of application that you are describing. I have also searched through the Example Programs posted on the website, and there aren't a whole lot of programs that look directly related to what you are trying to do. Some of the examples that you might want to review include:

Saving Data to a WAV File

Post-processing of a WAV File

In addition to taking a look at some of those, you may also want to start a new thread that focuses just on your application. This should give it some additional visibility and would make it easier for this forum to find your post and respond to it.


Best of luck to both of you, please post back if you have any questions.

Regards,
Jed R.
Applications Engineer
National Instruments