Measuring audio parameters on data streamed via UDP

[mikejm467]

Hello,

I have the task of trying to measure some audio parameters from multiple wave files that has been streamed over a network using UDP.

I can capture the individual streams at the UDP ports, but when I try to make a measurement on the data the frequency not correct and I am having trouble scaling the data vertically.

The data streams are different sampling rates and depths, 8Ks/S@16bit, 16Ks/S@16bit, 44.1Ks/S@24bit.

The data stream at the higher rate (44.1K) is closer to the expected value but still not correct.

I beleive I need to scale the data but cannot figure out how to parse it after I do a UDP read.

Any help is appreciated.

Michael

[George_P_Burdell]

Michael-

Are you using the Sound and Vibration Toolkit or Sound and Vibration Measurement Suite?  I believe this software may help you. 

As for the UDP protocol, UDP does not ensure reliable data transfer.  Therefore it may not be the best protocol for you to use.  I would suggest you look at the differences between TCP/IP and UDP and possibly use TCP instead (linked below).

LabVIEW Help: Using LabVIEW with TCP/IP and UDP
https://www.ni.com/docs/en-US/bundle/labview/page/using-labview-with-tcpip-and-udp.html

[Coq_Rouge]

Can you post your code and tell us more about what you are doing. Like how many samples do you process each time. And then you say "is closer to the expected value but still not correct" what are you referring to. The Sound and Vibration Toolkit or Sound and Vibration Measurement Suite. Is somewhat pricey and works best with expensive NI hardware. I have hunch that your problem may be solved with standard Labview analysis functions

[Coq_Rouge]

---

George P Burdell wrote:

Michael-

Are you using the Sound and Vibration Toolkit or Sound and Vibration Measurement Suite?  I believe this software may help you. 

---

How can you recommend a quite expensive toolkit without knowing anything about the original poster problem. I know all AE are drilled in the importance of selling as part in the NI training. But this seams somewhat unserious behavior to me. As it looks like you are more concerned about selling a toolkit. And do not care if the costumer need this toolkit or not. If you were some dubious used car salesman. I could have understood it. But not now. As NI represent people trust you and that the advices you give are correct. And you have a strong influence on what the costumer choose to do.

By the way  both the Sound and Vibration Toolkit or Sound and Vibration Measurement Suite. Are some quite interesting toolkit with many useful functions in the sound and vibration special field. So if needed I do have not any questions then it comes to recommend it.  

[mikejm467]

Hello All,

Thanks for the responce(s).

Unfortunatley I am stuck with the UDP format. Our product will not be connected to the"Net" so we are not very concerned with loosning any information. We just need to get it out of the box and to our test equipment.

I have reviewed all of my code and stimulas. Seems that the audio streaming utility I have been using (VLC) would automatically generate streams at 44.1Ks/S. There is a small, criptic setting that by default is turned off to be able to keep the original sample rate of the audio stream. By enabling this setting I am able to make some accurate SINAD, Freq, and THD+N measurements without the Sound and Vibration toolkit. I am now working on getting the vertical scaling correct so I can make a valid amplitude measurement.

The only thing I can see that the S&V toolkit would gives is some tailored graph and charting frequently used in the S&V business. It does nothing for capturing streams of audio and being able to easily decode the header information that is in a .wav file. This for me is pretty important.

Here is sample of my code. It is very crude and I am very new to LV. I have been a VB guy for the last 10 years. Istruggle alot with these icons and wires. It is very hard to follow the logic behind the samples when there are no comments to guide you.

Regards,

Michael Mayers

Test Engineering