09-27-2010 11:04 AM - edited 09-27-2010 11:06 AM
Hi,
I am trying to use a USB-9234 connected to a USB-9162 device to simultaneously acquire 4 microphone's outputs. Because of the nature of the sound I am dealing with, I have to set the sampling frequency to its highest value, ie 51.2kHz. The acquisition must be performed from a laptop, as the microphone array is placed on a mobile robot. This laptop is equipped with OpenSuse 11.2, and DAQmx-Base 3.4.0f2 is also installed (see here for the long story).
We have developed a C library (based on the NI DAQmx-Base C API) which provides some easy-to-use functions for the sound acquisition. But we are not able to simultaneously acquire the 4 channels at 51.2kHz, as we get a "Onboard device memory overflow" error. In order to be sure that the problem was not in our code, I have tested the simple C example contAcquireNChan. The problem is exactly the same, the driver still claimaing that the problem occurs because of "system and/or bud-bandwidth limitations". I have tested the device on 2 differerent laptops (Macbook Pro and Macbook Air), with Mac OS 10.5, 10.6 and linux (OpenSuse 11.2), and the problem is still here ...
But if I try the same contAcquireNChan example on my iMac with Mac OS 10.6, I can acquire 1-min long signals from the 4-microphones array without any problem ! In the same veine, I have no problem with one other computer equipped with Windows XP and Sound&Vibration Assistant. Finally, I have exactly the same problem as mentionned in this topic.
Do you have any idea concerning the way I can solve this problem ? I really have to use a laptop with a UNIX system, as the laptop in a close future will also have to control the mobile robot in relation with the acquired sounds.
Thank you in advance for you help.
09-29-2010 03:30 AM
So, does anyone have an idea ? In you opinion, is it a hardware-related problem ?
10-07-2010 04:14 AM
Hello.
Before taking a look at your application, are you sure to have installed the right drivers to support OpenSuse 11.2 (NI-KAL 2.0 and NI-VISA)?
Best regards
10-07-2010 04:22 AM
Hello.
Thank you for your anwser.
All I have installed is the NIDAQmx Base software (last version). It seems to be the only software I need as the simple NI C examples do work on some computer. But if I try the same C example on a laptop, I get the memory overflow error after a few seconds of acquisition.
Aren't NI-KAL and NI-VISA included in NIDAQmx Base ? If no, why does the NI C-examples work on certain computer, and not on anothers ?
Thank you for your help.
10-07-2010 04:25 AM
Hello.
No, these components are not included in DAQmx Base, and you hava to install them, as you can read here.
Best regards
10-07-2010 04:55 AM
Ok. I will install these two components. I hope this will fix my problem ! Answer in a couple of days 😉
10-07-2010 09:57 AM
NI-DAQmx Base 3.4 includes NI-VISA 5.0 which in turn includes NI-KAL 2.0. Installing DAQmx Base installs of its dependencies 🙂
The behavior you are seeing is not suprising. The USB streaming engine for DAQmx Base is not the same as the one in DAQmx. The DAQmx Base engine runs in user-mode while the DAQmx engine runs in kernel-mode. The reason for this is the Linux USB core: all kernel-mode drivers that use the USB core modules must be GPLv2 or later. NI cannot expose its USB streaming architecture (and thus comply with the GPL requirements) since the effiency of the architecture brings a significant competitive advantage, and so it calls into the USB subsystem by using the public USB API provided by the kernel.
Since the streaming engine is running in user-mode, it is more dependent on the system and computer hardware. Different processors, USB chipsets, and kernel scheduler settings all affect streaming performance. Some computers have a good combination, others do not.
There are a few things you can try, though, to increase your performance:
Joe Friedchicken
NI Configuration Based Software Get with your fellow OS users
[ Linux ] [ macOS ]Principal Software Engineer :: Configuration Based Software
Senior Software Engineer :: Multifunction Instruments Applications Group (until May 2018)
Software Engineer :: Measurements RLP Group (until Mar 2014)
Applications Engineer :: High Speed Product Group (until Sep 2008)
10-07-2010 10:47 AM - edited 10-07-2010 10:49 AM
Thank you JoeFriedchicken for your response.
Unfortunately, I was suspecting all you mentionned as being the cause of my problem. It was indeed the only reason why the same software could work on one computer and couldn't work on another.
There are a few things you can try, though, to increase your performance: 1. Try using `nice` to reprioritize your program. 2. Try changing your read size:
Solution 1 : I have already tried nice, with no success.
Solution 2 : does this read size correspond to the size of the read buffer I have to specify in the C function DAQmxBaseAnalogReadF64 ? I have already try different values, but never these specific sizes. I will try this as soon as possible.
Anyway, as the problem seems deeply related to the association between hardware and software, I have somewhat no hope to make my DAQ system work with the laptop we bought for my application ... quite disappointing ! AIl I want is to read about 4 (channels) *51200 (fs) *24 (bit/sample) =4.5Mbit/s, which is far from what a USB connection can transfer ...
10-07-2010 11:16 AM
The parameter you want to specify is numSampsPerChan, not the arraySizeInSamps [1]. Of course, make sure that the array is large enough to hold numSampsPerChan samples, or DAQmxBaseReadAnalogF64 will fill your readArray and return with fewer samples than you requested (don't worry: the next call to DAQmxBaseReadAnalogF64 will continue where it was when it returned early).
I'm not sure exactly how your unit analysis works out to 4.5 Mbit/sec, but I get:
(4 channels) * (51,200 samples/sec) * (4 bytes/sample) = 819,200 bytes/sec == 800 kiB/sec
Since a 24-bit sample is larger than a word (16-bits), it gets placed in a double word (32-bits) for transfer over the bus. And yes, 800 kiB is well within USB 2.0's maximum speed, but the USB 2.0 marketers are using a small trick: there is a difference between max burst rate and max sustained rate. DAQ applications need good sustained rates, and when they're coupled with user-mode IO, the maximum sustained rate drops and you get the behavior that you're seeing.
[1] DAQmx Base C API Reference
int32 DAQmxBaseReadAnalogF64 (TaskHandle taskHandle, int32 numSampsPerChan, float64 timeout, bool32 fillMode, float64 readArray[ ], uInt32 arraySizeInSamps, int32 *sampsPerChanRead, bool32 *reserved);
Joe Friedchicken
NI Configuration Based Software Get with your fellow OS users
[ Linux ] [ macOS ]Principal Software Engineer :: Configuration Based Software
Senior Software Engineer :: Multifunction Instruments Applications Group (until May 2018)
Software Engineer :: Measurements RLP Group (until Mar 2014)
Applications Engineer :: High Speed Product Group (until Sep 2008)
10-07-2010 02:18 PM
Thanks for your detailed response JoeFriedchicken !
I'm not sure exactly how your unit analysis works out to 4.5 Mbit/sec, but I get: (4 channels) * (51,200 samples/sec) * (4 bytes/sample) = 819,200 bytes/sec == 800 kiB/sec
Exact, I was just not aware of the 24-bit to 32-bit transformation needed by the transfer over the USB bus, so that 4*51200*32 = 6.25Mib/s = 800KiB/s.
I will try to change the numSampsPerChan value and report here if it worked.
Thank you again.