Forums

Audio processing of more than one mic input

Started by Mauritz Jameson April 9, 2013
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&#2013266080;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&#2013266080;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 &#2013266080;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&#2013266080;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 &#2013266080;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...