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]

Hi DFGray or Macaba

Is it any development in this case? Have one of you reported this as bug. I think it is a bug. But if it is already reported I do not need to do it

[Mark_SAI]

Hello,

You said yourself that there isn't any data loss, so how do we know that this is not intended behaviour? I shall push further to find out more and report back when I know more.

Thanks!

[DFGray]

I tend to think this is a bug.  I have reported it as such (CAR 186741).  I have run into some similar issues on a different project causing timeout errors.

[Coq_Rouge]

DFGray and Macaba

Thank you again for the answers I really appreciate it.  To be honest the Labview sound system introduced in 8.x has never preformed in a reliable manner. I think it is time to take the whole system in for a total refurbishment. As it is now the old 7.x sound system outperforming the 8.x system

A sound card may not be very useful for a commercial measurement application. But they are very useful in academic settings and school projects that is on a budget. Since every computer nowadays has a sound card. And also for the hobbyist of course. I do not expect the Labview sound system to be as advance as the NIdaq system. But it should perform better that it do today.   

Since the 8.x sound system is due for refurbishment I have a list of some more bugs

• Then using the "sound output write.vi" the sound gets chopped then trying to update more than 5 times pr second. I Guess this is related to the same error as in the sound input case. The old 7.x system could handle this update rate without any problem
• The "Sound Device Info.vi" does not report report correct depths in bit. 24 bit depth is not reported for 24 bits sound cards. This VI also report wrong maximum samplerate for input. It does not report higher sample rate than 44100 even if the card can handle 48 KHz and 96 KHz as input rate. This is important since the "Sound Device Info.vi" is used in config for the sound input and output EXpress VIs

---

Macaba wrote:
You said yourself that there isn't any data loss, so how do we know that this is not intended behavior?

---

I think certainly think it is a bug. Would you like that your Daq card was behaving like this? I do not think so.;) 

[Mark_SAI]

R&D is aware of the issues, for example there is another CAR (121626) that contains some of the issues you've mentioned so expect improvements on the horizon! 🙂

[Coq_Rouge]

---

macaba wrote: 
So expect improvements on the horizon! 🙂

---

Well let us hope, that is the case 🙂 If you or DFGray has any (public) information on this topic please post it. And thank you both for looking into my problem. 

Ps If my latest findings(bugs) were not already reported, can one of you please report them. You can not fix a problem if you are not aware of it;) 

[DFGray]

I was not satisfied with the current CARs, so reported your two issues as CAR 187316.  Thanks!

[AdamKemp]

If there is no loss of data and you are reading on average the same rate as you configured then it's not a bug. This is inevitable behavior in a buffered system.What you're seeing is that you are reading data faster than it can be read from the sound card. You told LabVIEW to use a buffer of .2 seconds, but then you read .1 seconds of data as fast as you can. There are two threads here competing for the same shared buffer: the background thread reading from the sound cardand filling the internal buffer, and the LabVIEW execution thread reading from the internal buffer and copying into your array. Some of the time there's no contention because the two threads use different parts of the buffer (that's when you see the fast read times), but sometimes both threads want the same part of the buffer at the same time (this is inevitable since you are reading faster than it can possibly fill the buffer). Since you're doing a read the background thread has to win, and the other has to wait for it to finish with that part of the buffer.

The tricky part is that the two threads don't use the same size chunk. The background thread uses a chunk size of 1/4 the buffer, so it locks a quarter of the buffer at a time, fills it, and then unlocks it. That chunk will be locked however long it takes to get 1/4 of the buffer filled (in this case .2/4=.05 seconds). Your read loop's thread wants .1 seconds of data, so it may have to wait for the other thread twice. If you include the overhead of thread synchronization and copying the data you end up with slightly more than .1 seconds. Meanwhile, during that thread synchronization and copying overhead time, the background thread keeps working filling other parts of the buffer, and it takes a few iterations to catch up again. That's why you see some go fast and some go slower.

There are some improvements we can make to how we do buffering, but I don't think this particular behavior is a bug. As long as you can actually process the data faster than the sound card can produce it then you're not going to have a problem, and as long as the occasional hiccup due to the OS doesn't last longer than your buffer then you should not overflow.

[Coq_Rouge]

Thank you for taking time to answer my question. I must say I do not agree we with your argumentation and you have turned approach to the problem upside down. The main problem is that Windows is not a real time OS. So it is impossible to time operations like reading a from a sound card memory to exact the moment then x bytes is read. Therefore we must implement a buffer in order to not loose data. We can pull data from the buffer at irregular timing intervals. And as long as the average reading rate is larger than the buffer input rate everything will work fine. Then reading the buffer two situations may occur. The requested number of data is available in the buffer, and can be delivered at once. Or we must wait to the buffer is filled up and the requested amount of data is ready to be delivered. This is how buffers like those used in NI DAQ, and the serial port IO works.  

The problem with the buffer in the Labview sound input system is that something is wrong so data is piled up until a certain level. Then data is delivered. I can tell you that this behavior would not have been accepted in any DAQ or serial application. And it cause big problems in my applications. And you will also find that many other in this forum struggle with the sound system. The fact is as I have mentioned before the sound system in Labview 7.x worked much better. Instead of doing a upgrade in Labview 8.x The sound system was reduced to some buggy flimflams in Labview 8.x. Totally useless in many situations, and nothing at all to be proud of. I have given it up and use a 3. party system called WaveIO found here. http://www.zeitnitz.de/Christian/

I do not know if your answer is the official Labview policy. Yes we know about it, but we do not really care about the problems. As we in NI think that the sound system is good enough as its current state. I do not know the reason for this. Perhaps NI fear that a sound card IO could move into NI DAQ territory as many sound card offer excellent high speed performance with high resolution for very little money compared to NI DAQ cards. The latter is wrong as a sound card is useless in many DAQ applications. As for one thing the total absence of absolute accuracy. Also the fact that every sound card is AC coupled is important. But it can be very useful for applications in the audio range (20-20KHz). The application are not limited to sound. I have found using a sound card in other applications like physical experiments in a educational setting. Or as DFGRAY has done by making a xylophone. A cool way to learn Labview

[AdamKemp]

I understand what you're saying. Let me be more clear: I do think this is a deficiency in the way we do buffering on Windows (we do it differently on Linux and Mac, and it seems from comments that the API works better on those platforms). It's a deficiency in that it doesn't work as well as it should for common use cases which it was meant to solve. All I was saying is that technically it's not a bug because it isn't losing data. I'm just trying to distinguish between a bug (wrong behavior) and performance issues.

We already have a CAR for addressing this issue. We just have to weigh it against a lot of other CARs.

Thank you for your detailed feedback and patience.