Audio processing of more than one mic input

What is a typical setup for processing multiple microphone signals?

In the system I'm currently working with, the audio driver calls a callback function which pushes the microphone audio to a queue and it wakes up a task to process the audio in the queue.

However, with several microphone inputs and the current setup, I would have to choose which mic is the master; and the callback for that mic would then drive the processing of all the mic audio signals. This seems like a bad design to me. All the other mics might fall out of sync with the master mic, so I'm wondering what a better design would be? What is a typical approach?

Do you just let all the mics push their data to their respective queues and then have a master thread pull data from each queue and let the master thread wake up the processing of all the pulled mic audio? 

On 09/04/2013 14:47, Mauritz Jameson wrote:
> What is a typical setup for processing multiple microphone signals?
>
> In the system I'm currently working with, the audio driver calls a
> callback function which pushes the microphone audio to a queue and
> it wakes up a task to process the audio in the queue.
>
> However, with several microphone inputs and the current setup, I
> would have to choose which mic is the master; and the callback for
> that mic would then drive the processing of all the mic audio
> signals. This seems like a bad design to me. All the other mics
> might fall out of sync with the master mic, so I'm wondering what a
> better design would be? What is a typical approach?
>
> Do you just let all the mics push their data to their respective
> queues and then have a master thread pull data from each queue and
> let the master thread wake up the processing of all the pulled mic
> audio?
>

Nothing so complex, if the "system" is based on a  standard consumer PC
(or Mac, Linux).

You use a multi-channel sound card (USB, Firewire), which interleaves
the signals from N channels into a single stream (device). At least up
to 8 channels will typically be handled by a single m/c codec (i.e. 
common clock or all channels), and for higher channel counts requiring 
multiple devices, a master sample clock will be used to ensure all 
channels are in sync. This is a pretty mainstream pro audio activity 
these days, and there is plenty of software (ranging from high-end 
commercial to free open-source) out there which will handle it for you. 
With more information from you (e.g. exactly how many channels do you 
need to record together?), more information could be provided back. 
Needless to say, if all you need is stereo recording, even the very 
cheapest soundcards can handle that easily - plug one in and "get on 
with it".

Note that multi-channel cards typically offer a mixture of mic level,
line level and direct digital inputs, and are usually described by
the ~total~ number of ins and outs, e.g. my M-Audio Firewire 410 
supports quad recording and 10ch output, but two of the channels on each 
side are digital (spdif); there are only two balanced mic inputs. Other 
devices offer more inputs and/or outputs, at correspondingly higher 
cost. For "serious" multi-channel recording, most people will use a 
mixer to handle the mic inputs and provide general level and eq 
management (and phantom power for condenser mics), and you route 
line-level outputs from the mixer to the soundcard.

This is only borderline on topic for comp.dsp (as there is not really 
any dsp to speak of in the question). You might consider trying the 
musicdsp list, which is dedicated to all things to do with digital audio.

Richard Dobson

On 4/9/2013 8:47 AM, Mauritz Jameson wrote:

> What is a typical setup for processing multiple microphone signals?

Are all mikes on the same clock or different asynchronous clocks?
What is meant by "processing" ?

> In the system I'm currently working with,

What system?  Win32 ?

> the audio driver calls a
> callback function which pushes the microphone audio to a queue and it
> wakes up a task to process the audio in the queue.
  > However, with several microphone inputs and the current setup, I
> would have to choose which mic is the master; and the callback for
> that mic would then drive the processing of all the mic audio
> signals. This seems like a bad design to me. All the other mics might
> fall out of sync with the master mic, so I'm wondering what a better
> design would be? What is a typical approach?

It depends. What are you really trying to do?


Vladimir Vassilevsky
DSP and Mixed Signal Designs
www.abvolt.com

On Apr 9, 9:47&#4294967295;am, Mauritz Jameson <mjames2...@gmail.com> wrote:
> What is a typical setup for processing multiple microphone signals?
>
> In the system I'm currently working with, the audio driver calls a callback function which pushes the microphone audio to a queue and it wakes up a task to process the audio in the queue.
>
> However, with several microphone inputs and the current setup, I would have to choose which mic is the master; and the callback for that mic would then drive the processing of all the mic audio signals. This seems like a bad design to me. All the other mics might fall out of sync with the master mic, so I'm wondering what a better design would be? What is a typical approach?
>
> Do you just let all the mics push their data to their respective queues and then have a master thread pull data from each queue and let the master thread wake up the processing of all the pulled mic audio?

Why think about such low level details as callbacks, queues etc.
unless it's a final consumer product on the cheapest hardware for the
cheapest price , but then you can usually find lots of other folks who
can do it better and faster on each particular platform and for close
to a minimum wage

For prototyping you can use common pro-audio recording setup: USB
audio interface (e,g. Tascam US-) interfaced to DAW software running
on PC (e.g. Cubase), then implement all of your own dsp processing as
VST plugins

Or use data  acquisition board e.g from Measurement Computing (might
need separate pre-amp circuitry for each mic) interfaced to Matlab or
your custom application in e.g. VC++ (board manufacturers take care of
all low level details for you and provide clean api and sample
projects)

On 4/9/2013 11:48 AM, angrydude wrote:

Hello Dmitry Teres,

> Why think about such low level details as callbacks, queues etc.

Small things is what makes perfection. But perfection is no small thing, 
dear.

> unless it's a final consumer product on the cheapest hardware for
> the cheapest price , but then you can usually find lots of other
> folks who can do it better and faster on each particular platform and
> for close to a minimum wage

You must have a lot of experience releasing new products.
"Tell us about your success" (TM)

> For prototyping you can use common pro-audio recording setup: USB
> audio interface (e,g. Tascam US-) interfaced to DAW software running
> on PC (e.g. Cubase), then implement all of your own dsp processing
> as VST plugins
>
> Or use data  acquisition board e.g from Measurement Computing (might
> need separate pre-amp circuitry for each mic) interfaced to Matlab
> or your custom application in e.g. VC++ (board manufacturers take
> care of all low level details for you and provide clean api and
> sample projects)

Here is your problem, Dmitry: never worked out anything practical.

VLV

On Apr 9, 1:56&#4294967295;pm, Vladimir Vassilevsky <nos...@nowhere.com> wrote:
> On 4/9/2013 11:48 AM, angrydude wrote:
>
> Hello Dmitry Teres,
>
> > Why think about such low level details as callbacks, queues etc.
>
> Small things is what makes perfection. But perfection is no small thing,
> dear.
>
> > unless it's a final consumer product on the cheapest hardware for
> > the cheapest price , but then you can usually find lots of other
> > folks who can do it better and faster on each particular platform and
> > for close to a minimum wage
>
> You must have a lot of experience releasing new products.
> "Tell us about your success" (TM)
>
> > For prototyping you can use common pro-audio recording setup: USB
> > audio interface (e,g. Tascam US-) interfaced to DAW software running
> > on PC (e.g. Cubase), then implement all of your own dsp processing
> > as VST plugins
>
> > Or use data &#4294967295;acquisition board e.g from Measurement Computing (might
> > need separate pre-amp circuitry for each mic) interfaced to Matlab
> > or your custom application in e.g. VC++ (board manufacturers take
> > care of all low level details for you and provide clean api and
> > sample projects)
>
> Here is your problem, Dmitry: never worked out anything practical.
>
> VLV

thanks for trying to help with my problems (I have many) and for not
calling me "stupident matlabi"
But my problem is different from yours as it eventually becomes
someone else's problem, maybe even your problem someday ... heck, who
knows ... (but you would have to work hard to deserve the honours...)

Vlad,

I'm trying to come up with a generic design (if possible) or at least a good design to handle asynchronous mic inputs. The mic inputs are mixed together in a conference bridge. I'm not sure what a good approach would be. My initial thought was that data from a mic is just written to a queue when ever the data is ready (audio driver calls callback); and that the conference bridge would just run every N milliseconds. When the conference bridge runs, it pulls N ms of data from each mic queue. If data is not available, it substitutes the missing data with silence. I'm not sure how well that would work though...so is there a better way of approaching it? Like I said - I'm trying to come up with something that is generic...It should be a design which will work well across different platforms - and only require minor customization efforts (if needed).

On 4/10/2013 8:47 AM, Mauritz Jameson wrote:
> Vlad,
>
> I'm trying to come up with a generic design (if possible) or at least
> a good design to handle asynchronous mic inputs. The mic inputs are
> mixed together in a conference bridge. I'm not sure what a good
> approach would be.

If the sources are asynchronous, then first thing to do would be 
resample each of them to common sample rate. You will need pretty good 
resamplers with timing loops especially if you are intending to do AEC.

> My initial thought was that data from a mic is
> just written to a queue when ever the data is ready (audio driver
> calls callback); and that the conference bridge would just run every
> N milliseconds. When the conference bridge runs, it pulls N ms of
> data from each mic queue. If data is not available, it substitutes
> the missing data with silence.

This is bad in so many ways.

> I'm not sure how well that would work
> though...so is there a better way of approaching it? Like I said -
> I'm trying to come up with something that is generic...It should be a
> design which will work well across different platforms - and only
> require minor customization efforts (if needed).

Unless you have access at low level, there isn't good low latency 
solution for synchronization of audio streams.

Vladimir Vassilevsky
DSP and Mixed Signal Designs
www.abvolt.com

On 4/9/2013 1:32 PM, angrydude wrote:
> On Apr 9, 1:56 pm, Vladimir Vassilevsky <nos...@nowhere.com> wrote:
>> On 4/9/2013 11:48 AM, angrydude wrote:
>>
>> Hello Dmitry Teres,
>>
>>> Why think about such low level details as callbacks, queues etc.
>>
>> Small things is what makes perfection. But perfection is no small thing,
>> dear.
>>
>>> unless it's a final consumer product on the cheapest hardware for
>>> the cheapest price , but then you can usually find lots of other
>>> folks who can do it better and faster on each particular platform and
>>> for close to a minimum wage
>>
>> You must have a lot of experience releasing new products.
>> "Tell us about your success" (TM)
>>
>>> For prototyping you can use common pro-audio recording setup: USB
>>> audio interface (e,g. Tascam US-) interfaced to DAW software running
>>> on PC (e.g. Cubase), then implement all of your own dsp processing
>>> as VST plugins
>>
>>> Or use data  acquisition board e.g from Measurement Computing (might
>>> need separate pre-amp circuitry for each mic) interfaced to Matlab
>>> or your custom application in e.g. VC++ (board manufacturers take
>>> care of all low level details for you and provide clean api and
>>> sample projects)
>>
>> Here is your problem, Dmitry: never worked out anything practical.
>>
>
> thanks for trying to help with my problems (I have many) and for not
> calling me "stupident matlabi"

It is never late.

> But my problem is different from yours as it eventually becomes
> someone else's problem, maybe even your problem someday ... heck, who
> knows ... (but you would have to work hard to deserve the honours...)

You is shit, Dmitry Teres. As your goal is creating problems to other 
people. Fuck you.

On Apr 10, 10:30&#4294967295;am, Vladimir Vassilevsky <nos...@nowhere.com> wrote:
> On 4/9/2013 1:32 PM, angrydude wrote:
>
>
>
>
>
> > On Apr 9, 1:56 pm, Vladimir Vassilevsky <nos...@nowhere.com> wrote:
> >> On 4/9/2013 11:48 AM, angrydude wrote:
>
> >> Hello Dmitry Teres,
>
> >>> Why think about such low level details as callbacks, queues etc.
>
> >> Small things is what makes perfection. But perfection is no small thing,
> >> dear.
>
> >>> unless it's a final consumer product on the cheapest hardware for
> >>> the cheapest price , but then you can usually find lots of other
> >>> folks who can do it better and faster on each particular platform and
> >>> for close to a minimum wage
>
> >> You must have a lot of experience releasing new products.
> >> "Tell us about your success" (TM)
>
> >>> For prototyping you can use common pro-audio recording setup: USB
> >>> audio interface (e,g. Tascam US-) interfaced to DAW software running
> >>> on PC (e.g. Cubase), then implement all of your own dsp processing
> >>> as VST plugins
>
> >>> Or use data &#4294967295;acquisition board e.g from Measurement Computing (might
> >>> need separate pre-amp circuitry for each mic) interfaced to Matlab
> >>> or your custom application in e.g. VC++ (board manufacturers take
> >>> care of all low level details for you and provide clean api and
> >>> sample projects)
>
> >> Here is your problem, Dmitry: never worked out anything practical.
>
> > thanks for trying to help with my problems (I have many) and for not
> > calling me "stupident matlabi"
>
> It is never late.
>
> > But my problem is different from yours as it eventually becomes
> > someone else's problem, maybe even your problem someday ... heck, who
> > knows ... (but you would have to work hard to deserve the honours...)
>
> You is shit, Dmitry Teres. As your goal is creating problems to other
> people. Fuck you.- Hide quoted text -
>
> - Show quoted text -

Thanks for kind words, dude

Always at your service...