John, Thanks for the reply! You mentioned output sample rates should be 44100 or 48000, should I worry about input (Mic) Sample rates as well? (Currently I was requesting the sample rate on both ends to be 16000 samplesPerSecond, for ease of passing into the codec) Also, do you recommend any particular resampler that I should use, or are any of the ones out there probably okay, or should I just write my own? Thanks again for your help! Jamie John Miles wrote:>>-----Original Message----- >>From: speex-dev-bounces@xiph.org [mailto:speex-dev-bounces@xiph.org]On >>Behalf Of James Stanton >>Sent: Thursday, October 04, 2007 12:53 PM >>To: speex-dev@xiph.org >>Subject: [Speex-dev] Audio Speed Variability >> >> >>I have a video conference like application that I've been working on for >>a while now, and a recent change is causing some odd problems, and I was >>wondering if anyone else had seen problems like this.... >> >> > > >Short answer: don't use output sample rates other than 44100 or 48000. > >Longer answer: Sound chips usually run at one of those rates, often either. >Those rates are more or less guaranteed to work properly. Most chips don't >support other rates directly; a software resampler in the driver is used >instead. Unfortunately, Microsoft released a horribly-broken reference >resampler implementation to sound hardware OEMs a few years ago, and many of >them still use it. On their sound cards, if you ask for 11025 Hz, for >example you're likely to get 11100 Hz or something similarly-imprecise. >That obviously causes cumulative latency/slippage problems. > >Bottom line: voice codec applications that need to work at lower rates >really need to resample to 44.1K or 48K themselves in order to work robustly >across all hardware platforms. Neither MS nor sound-hardware OEMs have >shown the slightest interest in fixing this bug, so that's just the way it >goes. > >-- john > >_______________________________________________ >Speex-dev mailing list >Speex-dev@xiph.org >http://lists.xiph.org/mailman/listinfo/speex-dev > >
I don't know about the input side; I have personally only experienced being bitten by the output resampler. But it seems like a safe assumption that yes, the input side is equally broken. Any resampling code found on the 'net should be suitable as long as it sounds good, doesn't take too much CPU, and is compatible with your product's licensing/distribution terms. There are quite a few options out there, but I haven't investigated any of them. It's probably reasonable to replicate the sample points yourself and run the result through an FIR or IIR low-pass filter kernel that's hardwired to bandlimit the resulting data for the rate your codec uses. E.g., 16000 Hz to 44100 Hz would involve making two or three copies of each sample point as necessary, then running an FIR or IIR filter calculated for 0.36 Nyquist. If you have only one input and one output stream to deal with, both with fixed rates, it's hard to find a resampler that *won't* work. -- john> -----Original Message----- > From: speex-dev-bounces@xiph.org [mailto:speex-dev-bounces@xiph.org]On > Behalf Of James Stanton > Sent: Thursday, October 04, 2007 3:14 PM > To: speex-dev@xiph.org > Subject: Re: [Speex-dev] Audio Speed Variability > > > John, > > Thanks for the reply! You mentioned output sample rates should be 44100 > or 48000, should I worry about input (Mic) Sample rates as well? > (Currently I was requesting the sample rate on both ends to be 16000 > samplesPerSecond, for ease of passing into the codec) Also, do you > recommend any particular resampler that I should use, or are any of the > ones out there probably okay, or should I just write my own? Thanks > again for your help! > > Jamie > > John Miles wrote: > > >>-----Original Message----- > >>From: speex-dev-bounces@xiph.org [mailto:speex-dev-bounces@xiph.org]On > >>Behalf Of James Stanton > >>Sent: Thursday, October 04, 2007 12:53 PM > >>To: speex-dev@xiph.org > >>Subject: [Speex-dev] Audio Speed Variability > >> > >> > >>I have a video conference like application that I've been working on for > >>a while now, and a recent change is causing some odd problems, and I was > >>wondering if anyone else had seen problems like this.... > >> > >> > > > > > >Short answer: don't use output sample rates other than 44100 or 48000. > > > >Longer answer: Sound chips usually run at one of those rates, > often either. > >Those rates are more or less guaranteed to work properly. Most > chips don't > >support other rates directly; a software resampler in the driver is used > >instead. Unfortunately, Microsoft released a horribly-broken reference > >resampler implementation to sound hardware OEMs a few years ago, > and many of > >them still use it. On their sound cards, if you ask for 11025 Hz, for > >example you're likely to get 11100 Hz or something similarly-imprecise. > >That obviously causes cumulative latency/slippage problems. > > > >Bottom line: voice codec applications that need to work at lower rates > >really need to resample to 44.1K or 48K themselves in order to > work robustly > >across all hardware platforms. Neither MS nor sound-hardware OEMs have > >shown the slightest interest in fixing this bug, so that's just > the way it > >goes. > > > >-- john > > > >_______________________________________________ > >Speex-dev mailing list > >Speex-dev@xiph.org > >http://lists.xiph.org/mailman/listinfo/speex-dev > > > > > > > _______________________________________________ > Speex-dev mailing list > Speex-dev@xiph.org > http://lists.xiph.org/mailman/listinfo/speex-dev >
Actually, Speex now includes a resampler. I suggest you use that. There's even a parameter that allows to control the CPU/quality tradeoff. Jean-Marc John Miles wrote:> I don't know about the input side; I have personally only experienced being > bitten by the output resampler. But it seems like a safe assumption that > yes, the input side is equally broken. > > Any resampling code found on the 'net should be suitable as long as it > sounds good, doesn't take too much CPU, and is compatible with your > product's licensing/distribution terms. There are quite a few options out > there, but I haven't investigated any of them. It's probably reasonable to > replicate the sample points yourself and run the result through an FIR or > IIR low-pass filter kernel that's hardwired to bandlimit the resulting data > for the rate your codec uses. E.g., 16000 Hz to 44100 Hz would involve > making two or three copies of each sample point as necessary, then running > an FIR or IIR filter calculated for 0.36 Nyquist. > > If you have only one input and one output stream to deal with, both with > fixed rates, it's hard to find a resampler that *won't* work. > > -- john > >> -----Original Message----- >> From: speex-dev-bounces@xiph.org [mailto:speex-dev-bounces@xiph.org]On >> Behalf Of James Stanton >> Sent: Thursday, October 04, 2007 3:14 PM >> To: speex-dev@xiph.org >> Subject: Re: [Speex-dev] Audio Speed Variability >> >> >> John, >> >> Thanks for the reply! You mentioned output sample rates should be 44100 >> or 48000, should I worry about input (Mic) Sample rates as well? >> (Currently I was requesting the sample rate on both ends to be 16000 >> samplesPerSecond, for ease of passing into the codec) Also, do you >> recommend any particular resampler that I should use, or are any of the >> ones out there probably okay, or should I just write my own? Thanks >> again for your help! >> >> Jamie >> >> John Miles wrote: >> >>>> -----Original Message----- >>>> From: speex-dev-bounces@xiph.org [mailto:speex-dev-bounces@xiph.org]On >>>> Behalf Of James Stanton >>>> Sent: Thursday, October 04, 2007 12:53 PM >>>> To: speex-dev@xiph.org >>>> Subject: [Speex-dev] Audio Speed Variability >>>> >>>> >>>> I have a video conference like application that I've been working on for >>>> a while now, and a recent change is causing some odd problems, and I was >>>> wondering if anyone else had seen problems like this.... >>>> >>>> >>> >>> Short answer: don't use output sample rates other than 44100 or 48000. >>> >>> Longer answer: Sound chips usually run at one of those rates, >> often either. >>> Those rates are more or less guaranteed to work properly. Most >> chips don't >>> support other rates directly; a software resampler in the driver is used >>> instead. Unfortunately, Microsoft released a horribly-broken reference >>> resampler implementation to sound hardware OEMs a few years ago, >> and many of >>> them still use it. On their sound cards, if you ask for 11025 Hz, for >>> example you're likely to get 11100 Hz or something similarly-imprecise. >>> That obviously causes cumulative latency/slippage problems. >>> >>> Bottom line: voice codec applications that need to work at lower rates >>> really need to resample to 44.1K or 48K themselves in order to >> work robustly >>> across all hardware platforms. Neither MS nor sound-hardware OEMs have >>> shown the slightest interest in fixing this bug, so that's just >> the way it >>> goes. >>> >>> -- john >>> >>> _______________________________________________ >>> Speex-dev mailing list >>> Speex-dev@xiph.org >>> http://lists.xiph.org/mailman/listinfo/speex-dev >>> >>> >> >> _______________________________________________ >> Speex-dev mailing list >> Speex-dev@xiph.org >> http://lists.xiph.org/mailman/listinfo/speex-dev >> > > _______________________________________________ > Speex-dev mailing list > Speex-dev@xiph.org > http://lists.xiph.org/mailman/listinfo/speex-dev > >