0
0

Maybe I’m missing this in the docs…

I cannot find the call to set the recording level for microphone input.

Thanks,

Bill

  • You must to post comments
0
0

Well, shoot. There go my ideas of an automatic gain control 😕

Thinking out loud… (perhaps for a future feature and please pardon my obvious lack of knowledge about what I’m about to say)

1) Would it be possible to wrap access to the windows mixing panel so FMOD remains the single access to "all things sound related"?

2) In the end, doesn’t the windows mixing panel punch through to the sound driver to eventually get to hardware attenuation at the mic ADC? Could there be a means to talk directly to the driver from FMOD?

(note: #2 assumes that there is some amount of FMOD access "through" DirectSound to the driver level to do things that DirectSound doesn’t do… perhaps this isn’t the case)

In any case, I do need to figure a way for squelch and AGC; I see how to do squelch fairly easily… maybe I’ll have to do some poking in parallel to FMOD to get at the mic attenuation for AGC.

Thanks,

Bill

  • You must to post comments
0
0

[quote:1pnvd9kf]if you’re capturing microphone input just adjust the sample data you are processing in realtime [/quote:1pnvd9kf]

The only drawback of that is clipping. Some users leave the mic on the desk, others use a headset mic and unless we reduce the gain at the ADC (recording level), the samples max out in amplitude when you’re so close to the mic. So by the time I can extract them from the recording buffer, they’re clipped.

I was just hoping to not have to expose a manual gain setting to the user, but it’s far from a problem.

Just thought of a semi-related question… what happens if the active recording bumps into a locked area of the buffer? In other words, how "locked" is the buffer when you lock() it?

Thanks!

  • You must to post comments
0
0

There are two microsoft APIs that you can hook into to alleviate this, forgive me but i can’t remember the exact names, one relates to (old) netshow which has a little tuning wizard for mic & headphones, i used that quite successfully. The other (newer) api also supports AGC and noise cancellation if the hardware can do it, no idea what it’s called though, never tried it, I think it’s an XP only thing… check MSDN.

Sorry if that’s vague :-)

kimB

  • You must to post comments
0
0

[quote:1b1q0mu3]The other (newer) api also supports AGC and noise cancellation if the hardware can do it, no idea what it’s called though, never tried it, I think it’s an XP only thing… check MSDN[/quote:1b1q0mu3]

Great! Thanks for the info. If they have AGC already, then no reason to re-invent the wheel. I’ll research it.

  • You must to post comments
0
0

i thought more about this….

The main issue with mic recording on a pc is the feedback from the the mic to the speakers… too close usually, that’s why m$ have introduced noise cancellation.

If you have a limiting filter on your input it still will not stop feedback occurring on the output, so agc on the input wouldn’t work, as it’s just poked through to the output and creates feedback in the same way.

You need noise cancellation, not agc. Is that what squelch is? /reminds me of CB radio talk, not that i ever had one.

kimB

  • You must to post comments
0
0

[quote:1wmfiewg]You need noise cancellation, not agc. Is that what squelch is? /reminds me of CB radio talk, not that i ever had one[/quote:1wmfiewg]

Simple squelch is just not sending signal if its amplitude is below a given threshold. For radio, it prevents transmission of a blank carrier when no one is talking (I’ve overly simplified).

Taken to more sophistication, there are ways to use "squelch tones" to send a signal to only certain receivers when all are on the same frequency.

So, yes, squelch is related to radio.

For PC voice comm, squelch can be used to not send voice data packets when no one is talking. One of the things we’re looking to do is press-to-talk comm as well as hands-free and we’d use a squelch so that we stop sending Ethernet voice packets when there’s no sound. Mic gain and a known recording level are important.

You bring up noise (echo) cancellation, which is important as well; However, we will not be playing back the recorded signal locally (we’ll record-and-send), and we envision the primary use to be headsets with the mic in front of the user (hence, taking care not to flood the mic input via AGC).

For mic-on-the-desk applications, an input system with cancellation is important and I’ve started to look into the MSDN reference you mentioned – thanks!

  • You must to post comments
Showing 6 results
Your Answer

Please first to submit.