I realize that the preprocessor echo suppression is not designed specifically to counter the effects of data loss. On the other hand, as much as I might like to, I do not have the option to "fix that problem for real." The sad truth is that some end users have systems that may drop samples, or do other unfathomable things, no matter what I do. I can not rewrite their drivers, firmware, or operating system. My job is to do the best I can in a difficult situation. At this point, the echo canceller seems to work well on literally 90% of the machines I have tested. I am trying to put together a "backup" strategy to cover the cases where it does not work. I might eventually settle for detecting non-convergence and enforcing half-duplex in that case, but I'd like to better than that if I can. I initially assumed that the echo suppressor is similar to other echo suppressors (also called "nonlinear processors" or "loss controls"). Those suppressors use cruder algorithms that exhibit artifacts but that may not depend on the fine time structure of the audio signals. Is this not true of the preprocessor echo suppressor? -mjc -----Original Message----- From: Jean-Marc Valin [mailto:jean-marc.valin@usherbrooke.ca] Sent: Tuesday, June 26, 2007 8:49 PM To: Coffey, Michael Cc: speex-dev@xiph.org Subject: Re: [Speex-dev] Residual Echo Suppression by the Preprocessor The residual echo suppression is supposed to be working decently well now. However, it's not designed to counter the effects of samples being dropped off the soundcard. You'll just need to fix that problem for real. Jean-Marc
Coffey, Michael a ?crit :> I realize that the preprocessor echo suppression is not designed > specifically to counter the effects of data loss. On the other hand, as > much as I might like to, I do not have the option to "fix that problem > for real." The sad truth is that some end users have systems that may > drop samples, or do other unfathomable things, no matter what I do. I > can not rewrite their drivers, firmware, or operating system. My job is > to do the best I can in a difficult situation.Actually, there's still a lot you can do. You can reduce the amount of sample drops by playing with the priority and the amount of buffering you do. Also, there are sometimes ways to make sure that the drops don't change rec/play synchronisation (the key is the sync, not the lost samples). As for how the residual echo suppression works, I've no idea, you need to try.> I initially assumed that the echo suppressor is similar to other echo > suppressors (also called "nonlinear processors" or "loss controls"). > Those suppressors use cruder algorithms that exhibit artifacts but that > may not depend on the fine time structure of the audio signals. Is this > not true of the preprocessor echo suppressor?Not sure what other echo suppressors do. Some are actually designed to act alone while others (like the Speex one) are designed only to suppress the echo that was left by a first echo canceller. Jean-Marc> -mjc > > -----Original Message----- > From: Jean-Marc Valin [mailto:jean-marc.valin@usherbrooke.ca] > Sent: Tuesday, June 26, 2007 8:49 PM > To: Coffey, Michael > Cc: speex-dev@xiph.org > Subject: Re: [Speex-dev] Residual Echo Suppression by the Preprocessor > > The residual echo suppression is supposed to be working decently well > now. However, it's not designed to counter the effects of samples being > dropped off the soundcard. You'll just need to fix that problem for > real. > > Jean-Marc > > >
Believe me; I've "played with" priorities and buffering. Did you just say you have no idea how the Speex residual echo suppressor works? If that is the case, can you tell me where I could get some information about it? -----Original Message----- From: Jean-Marc Valin [mailto:jean-marc.valin@usherbrooke.ca] Sent: Friday, June 29, 2007 7:38 PM To: Coffey, Michael Cc: speex-dev@xiph.org Subject: Re: [Speex-dev] Backup Echo Suppression Coffey, Michael a ?crit :> I realize that the preprocessor echo suppression is not designed > specifically to counter the effects of data loss. On the other hand, as > much as I might like to, I do not have the option to "fix that problem > for real." The sad truth is that some end users have systems that may > drop samples, or do other unfathomable things, no matter what I do. I > can not rewrite their drivers, firmware, or operating system. My job is > to do the best I can in a difficult situation.Actually, there's still a lot you can do. You can reduce the amount of sample drops by playing with the priority and the amount of buffering you do. Also, there are sometimes ways to make sure that the drops don't change rec/play synchronisation (the key is the sync, not the lost samples). As for how the residual echo suppression works, I've no idea, you need to try.> I initially assumed that the echo suppressor is similar to other echo > suppressors (also called "nonlinear processors" or "loss controls"). > Those suppressors use cruder algorithms that exhibit artifacts but that > may not depend on the fine time structure of the audio signals. Is this > not true of the preprocessor echo suppressor?Not sure what other echo suppressors do. Some are actually designed to act alone while others (like the Speex one) are designed only to suppress the echo that was left by a first echo canceller. Jean-Marc> -mjc > > -----Original Message----- > From: Jean-Marc Valin [mailto:jean-marc.valin@usherbrooke.ca] > Sent: Tuesday, June 26, 2007 8:49 PM > To: Coffey, Michael > Cc: speex-dev@xiph.org > Subject: Re: [Speex-dev] Residual Echo Suppression by the Preprocessor > > The residual echo suppression is supposed to be working decently well > now. However, it's not designed to counter the effects of samples being > dropped off the soundcard. You'll just need to fix that problem for > real. > > Jean-Marc > > >