PLEASE can a AE from NI take a look at my problem. Sound input read behave in strange manner then the buffer size is larger than 2X number of samples to read.

[Coq_Rouge]

On my computer I have discovered some strange behavior then reading data from the sound card. Then the buffer size is 2x samples to read everything is as expected. But since I read the sound card 10 times pr second I feel a .2 second buffer is to small. I am using XP, and XP is not a RTOS so with a buffer set to 0.2 seconds I may lose data. Therefore I set the buffer size (number samples/ch on Sound Input Configure.vi) to be in range of 2 seconds. The result then is that then reading from Sound input.vi, a reading often take more than 0.1 second. On my computer it is often 500mSec. Then the next 5 read follows with almost zero interval. I do not loose data. But on my front panel the graphs looks like an very early silent movie. This error was introduced in Labview 8.x. To be honest I think the labview 7.x sound system was much better in many ways.

But before I point any finger NI. Other people has to verify the behavior I experience. I have made an example showing this error. It is a modified version  of the "Continuous Sound Input.vi" example. Then the "buffer in seconds" control is set to 0.2 every thing works OK. Changer this to a larger number will produce the mentioned above hiccup. The larger number in this control the larger hiccup. Is it any way to fix this? My solution up to now has to use a free 3. part software(http://www.zeitnitz.de/Christian/index.php?sel=waveio) But I guess it soon will be outdated. It may not work with newer windows versions.

Any help at all will be appreciated 

And yes I have the most updated version fo DirectX. Also I se this in Labview 2009 which I have trail version of. The VI I have made is in 8.6

Message Edited by Coq Rouge on 09-07-2009 10:54 AM

[johnsold]

I know this does not address your issue, but for the sake of comparison, your VI runs fine on my Mac.  Any value I set in the buffer is the value which appears on the time between sound readings chart, or an occasional reading slightly smaller.  I tried multiples of the 0.2 value and irregular values like pi.

Lynn 

[Coq_Rouge]

Thank you for having a look. Perhaps the Mac version of the Labview sound system is better.

[Coq_Rouge]

Here is a picture showing my problem. Then the update rate is 10 and the buffer is 0.2 seconds it works as expected. But as the buffer size increase, the actual refresh rate is reduced. Using a 3 seconds buffer the refresh rate is about one second. I know I can not demand anything in this forum. But it is somewhat disappointing that no one from NI has a comment regarding this problem. I do not expect a immediate fix. But it would be nice with a explanation why I see this behavior.

[Mark_SAI]

Hello,

If you take a moving average of the 0.2s buffer vs. 3s buffer at an update rate of 10, then they are the same (just under 100ms), so the average refresh rate is the same. I agree that is odd behaviour that the time between sound reads go to zero quite a lot then take a long time once in a while (presumably to fill the buffer?), I would have to let someone who knows the internals of the sound VI's comment further on this.

I'm going to play more with this! I'll let you know if I make any breakthroughs.

Thanks,

[Coq_Rouge]

---

macaba wrote:

If you take a moving average of the 0.2s buffer vs. 3s buffer at an update rate of 10, then they are the same (just under 100ms), so the average refresh rate is the same. I agree that is odd behaviour that the time between sound reads go to zero quite a lot then take a long time once in a while (presumably to fill the buffer

---

I guess it goes to zero because it is reading data from the buffer it do not has to wait for data from the sound card. The mysterious thing is the periodic delay. You are also correct then saying that average timing is correct. And in my application I have no data loss.

If you search for sound in this forum you will find out that many people has reported trouble with the sound system.

[Mark_SAI]

Hello,

I have come up with a rule of thumb:

If you use sound input read with a number of samples/ch that is less than 1/5 of the configured number of samples/ch, you will occasionally get zero read times; the probability of these occurring is:

1 - 4 / [(number of samples/ch configured) / (number of samples/ch read)]

Example:

4 second buffer = 80000 configured

10 updates = 2000 samples per read

1 - 4/[80000/2000] = 0.9.

(The output looks like 1000,0,0,0,0,0,0,0,0,0 which means 90% of the samples are zero time reads)

This isn't a fix, just analysis.

[Mark_SAI]

Hello,

I have a solution/workaround:

The trouble is the Sound Read VI doesn't have any built in timing so it reads from the buffer as fast as possible until the buffer realises it needs to fill up again. So putting this delay in solves the issue (just makes it more deterministic really). I still don't have any low-level explanations and I probably never will! 

[DFGray]

If you use macaba's delay and change the output type from DBL to I32, the problem virtually disappears (Vista64, LabVIEW 2009 32-bit).  I don't know why.  I would suspect a memory allocation issue, but really do not know.

The Windows sound API was changed to use ActiveX around the LabVIEW 8.0 timeframe.  Linux followed suit with a change to OSS about LabVIEW 8.2.  I don't think the Mac system has been changed yet, but I could be wrong.  This could explain why it works on Macs but not on Windows.  Has anyone tried on Linux?

[Coq_Rouge]

---

DFGray wrote:

If you use macaba's delay and change the output type from DBL to I32, the problem virtually disappears (

---

But with this method will we not risk a growing scan backlog? It may grow to the buffer runs full, and the system stops. Or am I wrong?

Also the Labview sound system (windows) was changed from 7.1 to 8.0. I have Labview 8.0  and the this also happens in 8.0

The old system is still installed and can be find in \vi.lib\sound\sound.llb. But is not put on the palette