Hi The latest SVN trunk for speex has changed the SpeexPreprocessState to an opaque structure, for jolly good software engineering reasons. However, the Analogue AGC (AAGC) feature of iaxclient (in audio_enode.c) relies on some members of this. It uses speech_prob to detect when there is enough speech to consider AAGC and then loudness2 to decide how to adjust the input mixer. We want to use the latest speex, for echo cancellation and other reasons, so I tried just making SpeexPreprocessState visible again, but it turns out neither of these members are present in the new SpeexPreprocessState_ structure anyway. I was able to re-create the speech_prob member by setting it from Pframe before speex_preprocess_run returns, and I've used agc_gain as the basis for adjusting the mixer (i.e. if agc_gain is high, the input is low, so turn the mixer up and v.v.). This appears to be effective. So is there a way to make these items available to speex clients? The speex_preprocess_ctl interface could be extended, but it's not really what it is intended for, is it? Also, can anyone clarify the new use of speex_preprocess_ctl for SPEEX_PREPROCESS_SET_PROB_START/CONTINUE? It used to have a float parameter, and it now seems to be int, but I couldn't get it to set the value correctly and have had to change speex_preprocess_ctl back to using a float. David
David Brazier wrote:> Hi > > The latest SVN trunk for speex has changed the SpeexPreprocessState to > an opaque structure, for jolly good software engineering reasons. > However, the Analogue AGC (AAGC) feature of iaxclient (in audio_enode.c) > relies on some members of this. It uses speech_prob to detect when > there is enough speech to consider AAGC and then loudness2 to decide how > to adjust the input mixer. We want to use the latest speex, for echo > cancellation and other reasons, so I tried just making > SpeexPreprocessState visible again, but it turns out neither of these > members are present in the new SpeexPreprocessState_ structure anyway. > I was able to re-create the speech_prob member by setting it from Pframe > before speex_preprocess_run returns, and I've used agc_gain as the basis > for adjusting the mixer (i.e. if agc_gain is high, the input is low, so > turn the mixer up and v.v.). This appears to be effective. > > So is there a way to make these items available to speex clients? The > speex_preprocess_ctl interface could be extended, but it's not really > what it is intended for, is it? > > Also, can anyone clarify the new use of speex_preprocess_ctl for > SPEEX_PREPROCESS_SET_PROB_START/CONTINUE? It used to have a float > parameter, and it now seems to be int, but I couldn't get it to set the > value correctly and have had to change speex_preprocess_ctl back to > using a float. >Hi, David, As you can tell, the AAGC integration with speex was really a classic hack. Instead of re-creating the hack, what's probably best here is to integrate AAGC back into speex, and have a proper API. For those of you just tuning in, what I call "AAGC" is an AGC implementation where analog gains are manipulated instead, or in addition to the AGC within speex (where levels are normalized via multiplication). The benefits of AAGC are: (1) (most important), reducing the analog gain can prevent clipping, which can't be done with speex' current AGC, and (2) when raising levels, you get better quality by raising the mixer levels, as opposed to just multiplying. (1) is really the most important reason. Now, the API I'd envision for this would be one where you could tell speex that you would like to use AAGC, and then register some callbacks that speex_preprocess() could call to query or set the input or mixer level. Further, a more intellegent implementation within speex could consider the requested changes in the rest of the preprocessor chain (i.e. it would know that if it asked for a 3dB increase in input gain, to expect that input levels would rise by 3dB within a few frames). The hacky implementation I did inside of iaxclient gave speex no such information. -SteveK
Steve Kann wrote:> ... > Instead of re-creating the hack, what's probably best > here is to integrate AAGC back into speex, and have a proper API. > ...I agree that sounds right. For example, I'm aware that echo cancellation is upset by non-linear effects in the input, and AAGC is certainly non-linear when it changes the mixer level. So the speex pre-processor ought to be aware of changes in the input gain. Jean-Marc, do you think this fits in the speex library? I suppose iaxclient might be the only speex user wanting it. David
> As you can tell, the AAGC integration with speex was really a classic > hack. Instead of re-creating the hack, what's probably best here is to > integrate AAGC back into speex, and have a proper API.Agreed here. If you can come up with a clean patch to add that feature, it's something I'd like to see in Speex.> For those of you just tuning in, what I call "AAGC" is an AGC > implementation where analog gains are manipulated instead, or in > addition to the AGC within speex (where levels are normalized via > multiplication). The benefits of AAGC are: (1) (most important), > reducing the analog gain can prevent clipping, which can't be done with > speex' current AGC, and (2) when raising levels, you get better quality > by raising the mixer levels, as opposed to just multiplying.It's a good thing to do, but you need to be really careful when doing that because: 1) Any change in the analogue gain automatically de-adapts the echo canceller so you only want to do that when really necessary (e.g. clipping screws up the EC anyway) 2) The processing chain goes "AEC -> noise suppressor -> AGC", but for the analog gain, you really want to measure the signal that goes into the echo cancellation, not at the AGC. Otherwise, you risk increasing the analog gain to a level that creates clipping before the AEC (even if the signal at the AGC is lower. Hmm, or does that mean the analogue AGC is actually completely independent from the "real" AGC. Any thoughts?> (1) is really the most important reason. > > Now, the API I'd envision for this would be one where you could tell > speex that you would like to use AAGC, and then register some callbacks > that speex_preprocess() could call to query or set the input or mixer > level. Further, a more intellegent implementation within speex could > consider the requested changes in the rest of the preprocessor chain > (i.e. it would know that if it asked for a 3dB increase in input gain, > to expect that input levels would rise by 3dB within a few frames). The > hacky implementation I did inside of iaxclient gave speex no such > information.This is probably things we'll want to consider one we decide on where to put the AAGC in the first place. Jean-Marc> -SteveK > > > > _______________________________________________ > Speex-dev mailing list > Speex-dev@xiph.org > http://lists.xiph.org/mailman/listinfo/speex-dev > >