simultaneous sound io.vi

[asdfwww]

omg, nevermind, seems its doing real weird stuff now.
Prog runs a lot slower which i dont care about but it seems to miss calculations  now 😞
THe read while loop is probably faster than my code so its lagging behind/ getting wrong values 😞

Gonna try some more then.. lol

[asdfwww]

seems to work afterall, i put read buffer real small to see if it would crash, forgetting i needed more samples for my calculation 😉

Not sure what happens if i scroll now though, if it skips some loops now or whatever, so maybe best u debug that if ur application needs it..


/edit: oh yea the "edit post" timeout is way too short, i couldve just edited /removed previous posts and put the real one if it wouldve let me 😜

Message Edited by asdfwww on 04-20-2007 05:16 AM

[SNN]

Hello. I've been dealing with the same sort of issue with a demonstration program I've been writing. Here are some suggestions that seem to help:

1. If you cannot afford to lose data, use a queue instead of a notifier. Notifiers are lossy.
2. Create a sound read loop that does nothing more than read a buffer and insert the waveform into a queue.
3. For the Sound Input Read VI (LabVIEW 8.2 on Windows XP SP2), go to the Execution options under the VI properties and change the priority to "high priority" and the Preferred Execution System to "data acquisition".
4. Make sure your input buffer, i.e. "number of samples/ch", is relatively large. I'm using 100ms worth of samples for 16kHz, 16-bit, mono input.

[djs2571]

I ran into issues getting the 4823 error when reading from the sound card. Any system delay (or manually entered delay) greater than the sample time used resulted in the error. I manually tested the error by putting a delay after the configuration block to delay the task ID from going to the read block..

I FIXED my issue by putting the configuration mode into "continuous" instead of "finite sample" mode... I'm using LV 2009, not sure when they switched the input wiring for the DLL call.

Hope this helps.