LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

lvsound2.dll continuous sound input read vi hanging issue

I am new to labview and am not an experienced programmer.  I have had an issue with the sound input read vi hanging while doing a continuous read.  It has taken me about a week of trying different things and looking into similar issues before I found a fix for my paticular problem.  Even though I am not sure why this fixes the issue I want to share in case it saves some pain for other users.  Any experienced users that want to comment to clarify or correct me please do!!

 

Basically my labview would crash after a certain amount of time doing a continuous sound input read using the example provided with labview.  Sometimes it would take  10 minutes and sometimes less than 1 minute.  After a lot of researching and tinkering I set up the following conditions and have not got it to crash since (over 4 hours of testing so far).  Most of what I read said the lvsound2.dll has some buffering issues which seemed to be the problem for me as well. Here are the steps I took to overcome this:

 

First I took my sound card setting on my pc to 44100 samples/sec 16 bit 2 channel.  I did this in case it was an issue between the sound card and sound input read.

 

Next using the example vi for continuous sound input (example found in sound_input_read.vi). I saw that first the sound configure happens then the sound input read does the rest.  When reading the sound input configure help menu I saw that the samples/channel actually determines the size of the buffer.  In the example it uses the same samples/channel for both the read and configure vi's.  I then changed the samples/channel for the sound input read vi to 25% of what I enter for the sound input configure.  In my case 15000 samples/ channel for the configure then divided by 4 and input into the samples per channel on the sound input read vi.

 

I then set my sampling rate to 48,000 samples per second in case it was a buffer overflow with the sound card (my thinking is I am reading faster than the card is putting out data so if there is a delay in my program I should be able to catch up)

 

I also changed my vi properties in the execution tab to "time critical".  I did this so the operating system will give the vi as much resources as possible because I did notice doing other things on the same pc would cause the crash (probably overflow issue) very quickly.

 

I want to thank Chris at NI tech support as he stayed with me on this issue for over 3 days straight trying to help me fiind a fix and was key in getting this resolved for me.

 

Again I want to re-itterate I am not very experienced and am self taught so my reasoning and explanation may be way off (and hopefully to be corrected by more experienced programmers) but this solution did work for me reguardless.

 

0 Kudos
Message 1 of 3
(3,641 Views)

The sound card interface in Labview far from the best Ni have done. I have been complaining about it for years. Errors reported take sevral versions to fix, and new ones are often introduced. I dropped it and started to use this http://www.zeitnitz.de/Christian/waveio 



Besides which, my opinion is that Express VIs Carthage must be destroyed deleted
(Sorry no Labview "brag list" so far)
0 Kudos
Message 2 of 3
(3,638 Views)

It's hard to say exactly what was going on without any error codes.  But you are correct in thinking of a buffer overflow if your sampling rate is too high.

 

 

If you want, you can try to recreate the error and share the code so we may be able to narrow down exactly what was going on.

Peter C.
Applications Engineer
National Instruments
0 Kudos
Message 3 of 3
(3,623 Views)