Hey Hammertimer,
Sorry for a slightly delayed reply, this possibly isn't an issue for you anymore.
I think you are seeing the problem mainly from the FIFO behaviour of queues. The enqueue function will only dequeue in one of the dequeue functions rather than both of them and won't be particularly explicit as to which of the dequeue function it dequeues the element at (almost random chance of dequeueing into microphone loop or DAQ loop), leading to some undesired effects I imagine.
(1) You could modify just one acquisition loop, so that when you pressed start, the start case contained both the information to start the microphone recording and the DAQ acquisition in one acquisition loop, rather than having one loop for each.
(2) If you want to control either individually, you could edit the "create all message queues.vi" to add additional queues (other than acquisition, logging and UI) for example, "microphone acquisition" queue, and then in your microphone acquisition loop, unbundle this queue instance instead of the standard acquisition queue instance to give you a seperate control over microphone acquisition.
Option (1) is more suitable if you want to trigger everything off one button
Option (2) is more suitable if you want different buttons to trigger either microphone recording or DAQ acquisition.
Hopefully I've explained that clearly and satisfied your query about scaling up your Queued message handler!
Thanks,
Justin, Applications Engineer
