audio data to be acquired at 192khz

[VivekM]

hi ...

well i  have made a VI to acquire  audio data  and then write it to a file to furthur process it. the problem is that  when i send  stram of audio data upto 48 khz the data is captured continuously, but if i try to  send a stream of 64khz or 192 khz the data is acquired but for a little time. i want to acquire data of 192khz stream continuously.  i m using labview 6.2 and dio32hs card.

i want to acquire data at 192khz for atleast 6 min continuously.

is it possible???

please help..

thanx and regards

vivek modgil

[falkpl]

You will have to balance the daq load.  Is your application multithreaded?  Do you pre allocate the memory to store the results of the DAQ reads? Are you processing the in real time?  I have done apps like this many times and balancing the read times with a processing loop and fole io is very important.  The easiest code a loop which reads as fast as possible and appends the results or writes to file will cause the read buffer to fall behind and overrun, is this the error you have?  Best is to have a read loop run as fast as possible and queue the results to a slower loop which handles the array and file writes as well as the processing.  GUI should be in a thirs loop.

Paul

[VivekM]

hi Paul

 sorry for late reply. well i m not able to understand  what  u mean by multithreaded.  my vi only acquires data and then writes it to the file.

the memory for the buffer is allocated  with the help of =number of scans terminal of the dio config vi. the vi acquires the data and writes it to the file in real time. other proceesing is done offline. the error i get is error no.10845(.ie.Because of system and/or bus-bandwidth limitations, the driver could not read data from the device fast enough to keep up with the devicethroughput; the onboard device memory reported an overflow error).

how can i  change the acquisition rate of the read loop and make the buffer memory to not to overflow.

please help...

thanx and regards

vivek modgil

[falkpl]

Look at the producer consumer template for multithreading.

Essentially what happens if you use a simple model like

Initialize()

DaqLoop

   Read()

   Process()

   Display()

   Save()

LOOP

is that if the saving and/or sace takes too long the next itteration of read will have caused a buffer over run in the daq task.  This is more evident in the faster Acquisition rates.  Making the buffer larger only delays the onset of this event.

A better model is (Threads are just parallel loops)

Thread 1 (Producer):{

Initialize DAQ()

DaqLoop

{

   Read DAQ data()  //all data avaliable.

   send data to a Queue

}Loop(until done)

Kill queue();

}

Thread 2 (Consumer):

{

DataLoop

{

  Wait for data at queue; // put in some timeout  ie 100ms 

  If new data-> Process() Display(); Save();

}Loop(While queue is valid)

}

This is just a starting point.  Look at the producer/consumer model.

This ensures that the DAQ loop will (should) never overrun and the consumer loop will attempt to keep up with the data.  Saving data to file is slow so do this post acquisition if possible (IE build array in memory).

Paul 

[VivekM]

Hi Paul

Queued data is allocated  to the RAM of the PC(I have a PC with 1 GB RAM , P4 ,3GHz,SATA HDD) , but the OS (XP)does not allow more than 300 MB of the RAM to allocate to the labview program.

 The system acquires data upto this and then the system halts and gives an ERROR "  Because of system and/or bus-bandwidth limitations, the driver could not read data from the device fast enough to keep up with the device throughput; the onboard device memory reported an overflow error".

It looks that  the thread 1 Producer (DIO 32 HS) to Consumer (Queue) is  working fast and the  another thread 2 Producer (queue) to consumer (HDD file) is slow.

The data injection rate  which it copes with without failing is 2.92 MBytes/sec( Audio sampling rate at 48 KHz ,2channel audio data,each sample of 4 bytes and Each bit of thisi s captured in One Byte, Port A of DIO). But if we increase the sampling frequency above 48KHz, the system halts generating above mention error.

Looking to this scenario it looks like the max  data transfer rate between Cosnumer cope is 3 MBytes/sec.

the max data rate  to be acquired is coming at rate of 12.288  MBytes/sec(sampling at 192 KHz)

Please suggest is this the case or i got struck in some other issue. any suggestion/brain storming will be a great help.

thanx and regards

vivek modgil

[falkpl]

This should be doable.  I just completed a project where I acquired 8 DI lines at 10 MHz continiously, processed the data in realtime and streamed to disk.  If the producer is the look which contains the DAQ error (buffer overrun) then your producre is not keeping up.  This loop should be as fast as possible Only reads data and queues it up.  This is hardware limited so if your hardware can keep up then you should beable to run for unlimited amounts of time.  Try this, 2 simple loops loop 1 is configure DIO, then inside loop read all buffered values (-1) and feed this to queue (of same data type)  place a small delay 10-50ms. after 6 minutes end wile loop and terminate queue.

In loop 2 wait for data at queue and loop while loop is valid.  Dont put any data saving or processing yet.  Your hardware should keepup with this scenerio.  

Next add a graph in the consumer loop.

Next add a save in the loop, it is best to open the file reference outside of the loop and close the reference after the loop.  You can add explicit waits in the second loop to balance the load.

[VivekM]

Hi Paul

 have u used DIO 32 HS card for ur project  to acquire  8 DI lines at 10 MHz continiously.

and other thing is  according to u  "first loop read all buffered values (-1) and feed this to queue (of same data type) place a small delay 10-50ms". well  where to buffer all the values before queue??

 i mean  i straight away queue all the values coming from the DIO Read  to the queue..

and  where to place a delay i mean between which two operations  i place a delay???

[falkpl]

I did the 10Mhz acquisition with a PCI-6534 not the dioHS 32.  I have not used the HS 32.  I know from a software standpoint that I was able to balance the data dransfer from a card and process and save the data on the fly with no buffer overrun.  Essentially you have to get the data (8Bits of data? at 192kHZ) off the cards buffer and into the systems RAM fast enough that you dont run out of onboard memory.  So lets say you are acquiring 192KB of data each Second and there is 256kB (This is all theoretical numbers) you have to read all the data in the card faster than 256/192 seconds.  If you put too much processing inside of the DAQ thread, such as data saving) then you can overrun your buffers and data is lost.  Systems have lots of RAM so dump it there and in a second loop process the data as fast ad the primary loop will allow.  The processing /save loop is a slave loop and will have to allow the DAQ loop to keep the buffer clean.  What version of LV are you using?

Paul

[falkpl]

Sorry I havent had my caffeine yet.  The 32HS is the same as the card I used I think, there are 2 names I usually use the product number.  Attached is a simple example of a multiloop daq at 192K, should work.  It only took me 3 minutes so it might not work though.  Good luck, got to get back to coding.

Paul

[VivekM]

Hi Paul

well i m using LV 6.1. and 6533 card.

 the main difference between 6533 and 6534(that u used ) is the onboard memory. the 6533 card has 16 samples of FIFO whereas 6534 has 64 MB of onboard memory.