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 > > >
Selon "Coffey, Michael" <mcoffey@avistar.com>:> Believe me; I've "played with" priorities and buffering.Then either you haven't played well enough or you're using a braindead OS.> 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?What I'm saying is that I've no idea how the residual echo suppressor reacts when it's used in a way it wasn't designed for (i.e. working around broken audio capture/playback). Jean-Marc> -----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 > > > > > > > >
Millions of ordinary people have systems that do not meet your stringent specifications. It does not matter what OS you or I use. It's the customers for whom this work is done. -----Original Message----- From: Jean-Marc Valin [mailto:Jean-Marc.Valin@USherbrooke.ca] Sent: Monday, July 02, 2007 6:35 PM To: Coffey, Michael Cc: speex-dev@xiph.org Subject: RE: [Speex-dev] Backup Echo Suppression Selon "Coffey, Michael" <mcoffey@avistar.com>:> Believe me; I've "played with" priorities and buffering.Then either you haven't played well enough or you're using a braindead OS.> 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?What I'm saying is that I've no idea how the residual echo suppressor reacts when it's used in a way it wasn't designed for (i.e. working around broken audio capture/playback). Jean-Marc> -----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 > > > > > > > >
On Jul 2, 2007, at 7:34 PM, Jean-Marc Valin wrote:> Selon "Coffey, Michael" <mcoffey@avistar.com>: >> Believe me; I've "played with" priorities and buffering. > > Then either you haven't played well enough or you're using a > braindead OS.This is sort of what I was talking about with nibbling. Imagine you have a microphone sampling at 128 samples at a time, filling a 256 byte buffer, and you have a player that writes 256 samples at a time, or 512 bytes. You have to nibble a frame every 160 samples, so you get this, where each digit represents 32 samples, so 00000 is 160 samples: 0 1 2 3 4 5 6 7 <- timestamp when each speex frame is read 0000111122223333444455556666777788889999 <- input frame 0000011111222223333344444555556666677777 <- speex frame 00000 11111 22222 33333 44444 55555 66666 77777 0000011111222223333344444555556666677777 <- speex frame 0000000011111111222222223333333344444444 <- output frame 0 2 4 5 7 <- timestamp when each speex frame is written 1 3 6 00000 11111 22222 33333 44444 55555 66666 77777 I've shown the points in time when an input buffer can be passed into a speex frame, or a speex frame can be passed into an output buffer. The echo canceler can't assume that each input/output pair are going to arrive perfectly synced and at the same time. Due to threading delays and other issues, it could easily get 2 inputs and 1 output briefly, or vice versa. I THINK that looking at this from a high level, the echo canceler IS guaranteed to get an input frame for every output frame, as long as it doesn't look at the frame's timestamp. Perhaps internally it has a queue that can save up frames until it has both an input and an output frame. In that case, it needs to stop writing warnings about extra or missing frames to the console, which seems to happen every time I run. But if the echo canceler IS using each frame's timestamp when it's trying to converge, it's almost guaranteed to fail on most operating systems, because the timestamp has such a high variability between frames, and can even sometimes be 0 for the output buffer in this example. Also, I think that many machines have separate input/output hardware that can suffer from clock drift. I'd really like to see an echo canceler that can work even when input/output frames are fed in with a large random time delta. I should be able to skip the first few input or output frames, and the echo canceller should be able to find out what the time delta is, and know from that point on, it will be relatively constant between any given pair of input/output frames. The easiest way to do this might be to look at the maximum of the covariance of the input/output, or find the phase offset of the input and output FFTs. Maybe it already does this, and someone can say if so? P.S. The above situation is almost exactly what happens on my Mac, and would be exacerbated by people with third party sound cards. ------------------------------------------------------------------------ Zack Morris Z Sculpt Entertainment This Space zmorris@zsculpt.com http://www.zsculpt.com For Rent ------------------------------------------------------------------------ If the doors of perception were cleansed, everything would appear to man as it is, infinite. -William Blake, The Marriage of Heaven and Hell