Sound Input Read VI hangs

[bentnail]

I'm using the SI Read VI to sample from the Soundblaster card in my Dell PC. I've configured the device for 16-bit mono input, sample rate 44.1 kHz, and the buffer size is 1024 samples. The SI Read VI is in a Timed Loop whose period I've set to 23 ms (1024 / 44.1kHz). Following each acquisition, I do some filtering, frequency analysis, and plotting inside the loop.

The acquisition works well for the first 10 minutes or so that it is running. But sometime after about 10 or 15 minutes, the VI hangs. I've traced the hang back to the SI Read VI, but have not yet figured out how to avoid the hang or recover from it (I have to abort and restart the program).

Has anyone had similar problems with the SI Read VI? Could there be a problem with the DLL that the SI Read VI calls? Are there any upgrades or fixes for this? Can someone suggest a way to recover from the hang?

Thanks for any help,

Mark

[Philip_Courtois]

Hi Mark,

A similar behaviour to the one you are describing has been reported to us previously, and the LabVIEW developers are currently looking into the cause of this issue. Here are a few things to try that might fix your VI from hanging:

• Increase the buffer size on "SI Config.vi"
  
• Disable hyperthreading

Please let me know if any of the above fixes your VI, thanks.

[Sheldon_Stokes]

I have a similar sort of problem, although it's not a bug.  I wrote a belt tension program to test the drive belt tension on my supercharger.  It's based on the geometry of the belt (pulley span, and belt physical parameters), and the resonant frequency to calculate the belt tension much like a guitar tuner.  The belt should be as tight as possible within the design limits of the accessory bearings. 

My program is an infinite loop where the sound input is sampled 4 times a second, and if the value is over a threshold, a longer period of data is collected and added to the original signal that exceeded the threshold.  The data is plotted, tension is calculated, and execution falls back into the threshold listening loop.  This allows the program to be running in the background waiting to "Hear" the belt being plucked. 

I have an issue with the sound read buffer overflowing, and SI_read sending zero length arrays out.  I've played with buffer length, and can stop the problem at the expense of slower "listen for threshold" loop rates.  The buffer only overflows if the computer is busy doing something else (typically me messing with another program or something). 

The point is that if you can reduce the background tasks on your test computer (screen saver, disk defrag, etc) you may eliminate your problem.  It's been about 10 minutes as I write this, and my idle laptop disk drive just went nuts with XP doing some sort of housecleaning. 

Sheldon

[bentnail]

Phillip,

I have disabled hyperthreading, but that did not seem to fix the issue. I can increase the size of the input buffer, however that effectively decreases my loop rate since the SI Read vi waits to sample the whole buffer before returning the data, and I am performing operations on the data and displaying the results as quickly as it comes in (i.e. if I increase the buffer size to 2048 from 1024, my loop rate increases from 23 ms to 46 ms, and I would prefer to stay at the 23 ms rate). Please let me know when your engineers come up with some suggested solutions. I've tried running the application on several different PCs now, and this problem is worse (occurs more frequently) on some computers than on others.

Sheldon,

Thanks for the suggestions. I, too, have experienced the "buffer overflow error" and the zero-length data arrays, and this problem is also alleviated by longer buffer sizes (although as I mentioned before, I really would like to keep my 23 ms loop rate). When this happens, I have to re-configure the task using the SI Config, and I just use the previous iteration's data (from a shift register) to avoid confusing the rest of my code doing operations on the input data. I've also noticed this error is more common when I am doing other things on the PC, such as dragging windows around or even scrolling through the front panel of my LabVIEW application.

I've also seen occasionally that the SI Read vi returns two buffers worth of data (i.e. 2048 samples). Since my program expects arrays with length 1024, I just take the last 1024 samples and discard the first 1024 when this happens.

This may be related to the SI Read.vi "hang" that was in my original post.  However, I can recover from the "overflow error" by checking the error output from the SI Read and re-configuring the SI task if this occurs; but when the SI Read vi hangs inside the VI, I cannot catch it and my program freezes, so this is the bigger issue for me right now.

[Philip_Courtois]

Hi Mark,

One other thing that I noticed when reading your initial post again, is that you are performing "...some filtering, frequency analysis, and plotting inside the loop..." after the acquisition of the data. I will strongly recommend that you separate the acquisition and analysis/presentation to run in two parallel loops instead. Please refer to e.g. the Producer/Consumer design pattern for a very suitable structure for your application:

Application Design Patterns: Producer/Consumer

Let me know if that gets rid of your issue, thanks.

[bentnail]

Philip,

Good suggestion. The produce/consumer design pattern is definitely a better way to write this application. I have now implemented this, as well as added a 100 ms time out for the "Wait for Occurrence" that is in the SI Read.vi. This seems to solve the problem on my machine, as well as one other Dell PC I've tried it on. Unfortunately, on the target PC for this application, the software still hangs after its been running for about 5-7 minutes. I don't have LabVIEW on this machine, so I'm just running the exe I make with Application Builder, and can't debug while it's running!

My PC is a Dell Optiplex GX 260, with Pentium 4, 2.4 GHz cpu, 2.0 GB ram, running Windows XP Pro, with SoundMax Integrated Digital Audio soundcard.

The other PC on which it works is a Dell Optiplex GX 260, with Pentium 4 2.5 GHz, 360 MB ram, Windows XP Pro, and SoundMax Integrated Digital Audio soundcard.

The target PC that is still crashing is a custom-built PC with ASUS P5GD1 motherboard, Pentium 4, 3.20 GHz, 1.0 GB ram, Windows XP Pro, and Realtek High Definition Audio integrated soundcard.

The biggest difference I can see is the audio card. Could this be related to the problem? Guess my next step is to try a new soundcard in that PC and hope it solves it...

Or, could it be that, because I do not have LabVIEW installed on this target PC, that the DLL is not transferred correctly as part of the exe I build?

-mark

[Philip_Courtois]

Hi Mark,

I doubt that the "lvsound.dll" gets corrupted when distributed to the other machine. However, even though the "lvsound.dll" is the DLL that is directly called from the Sound VIs, it's doesn't call the sound card directly. The "lvsound.dll" calls the operating system's sound input DLL that then calls the driver DLL for the actual sound card. Since the sound card is different on the distribution machine, the issue might be caused by the sound card driver. Please make sure to update the driver for the sound card to the newest version from here.

By changing the sound card, you will probably also fix the issue, but the solution might be as easy as upgrading the driver for the existing sound card. Please let me know if it works, thanks.

[Sheldon_Stokes]

I've done a LOT of sound IO in labview on windows platforms from 98 up to XP and I haven't had any hangs using a Creative Soundblaster Live.  It's a cheap card that actually has quite good analog specs (very strange form creative). 

I've also got an M-audio card that was a lot more expensive and has given me fits in labview. 

Speaking of sound IO, I would LOVE to have Labview support higher than 44100 KHz sample rate. 

Also I messed with Labview 7.1 on a friends OS X machine and anytime I tried to read the input buffer, Labview would crash.  I could start and stop sound input just fine, but couldn't read it. 

Sheldon

[Sambo]

This message is a reply to "Sound Input Read VI hangs" (National Instrument) NI Discussion Forums posting found at: http://forums.ni.com/ni/board/message?board.id=170&message.id=137258 and http://forums.ni.com/ni/board/message?board.id=170&message.id=110656&requireLogin=False

Hi everybody,

From the large count of how many of you guys read the above thread of messages, including myself, and who are dealing with the same problem of SI Read VI hanging found National Instrument (NI) LabVIEW (LV), I decided to share my (not so perfect) solution with you guys to save you time and frustration. Here is the story of 3 days (18 hrs/day) of my life, fighting a bug in SI Read VI (SI: Sound Input) (I am currently using LabVIEW Pro v 7.1.1):

For the reason that "A Message cannot exceed 10,000 characters" on this Forum I included my message in the attached Word doc. Hopefully, there is no such limitation on uploaded files!

Samir Berjawi

Research Assistant and Lab Instructor

American University of Beirut

sb@envirosir.com

sb38@aub.edu.lb

[Sheldon_Stokes]

I was able to work around my sound input issues described earlier. And I've made great progress on my speaker measurement and design VI's (MLS impulse response and swept sine waves) for speaker measurement, passive measurement, and Theil Small parameter calculation.

I think LabView 8 has new sound routines which aren't limited to 44.1K; I haven't done much with Labview 8 yet with sound. I've got it at work and I hate the new pallets. Would NI please stop rearranging the pallets. Trig functions go in numeric, etc. As someone who has them burned into his brain from prior to LabView 4, I find it very upsetting to be coerced into relearning them.

On to your problem. I strongly suspect that what you and I experienced is not NI's fault. I am 99.9% sure that the dll that we see as the problem is really just a pass-through to the soundcard driver. There's a nasty nasty chain of command here:

Sound in VI -> NI dll -> Windows Sound Subsystem -> soundcard driver -> soundcard hardware

There could be a problem in any one of those handoffs. The fact that I had problems with it when XP was busy, and restarting Labview didn't fix the problem (I needed a reboot) indicates to me that the actual clog in the pipe is actually at the system or even the driver/hardware level.

I've been doing a bit of Mac OSX programming and their core audio framework is really really impressive.

Sheldon