Hi everyone, I'm having a problem where I need to connect two audio-channels which are running with clocks of different rate and which do not run synchronized. So I'm looking for a way in which I can convert sample-rates and do skew-compensation at the same time. One constraint I forgot to mention is the need to do this with the least amount of latency possible as this is a real-time application... Has anyone pointers if such an algorithm already exists? Tobias
8khz / 48khz SRC & clock-skew compensation
Started by ●June 22, 2004
Reply by ●June 22, 20042004-06-22
Tobias Erichsen wrote:> Hi everyone, > > I'm having a problem where I need to connect two audio-channels > which are running with clocks of different rate and which do not > run synchronized. So I'm looking for a way in which I can convert > sample-rates and do skew-compensation at the same time. > > One constraint I forgot to mention is the need to do this with the > least amount of latency possible as this is a real-time application... > > Has anyone pointers if such an algorithm already exists? > > Tobias > >Define "audio" and "least". One obvious way to do this would be to upsample and interpolate with an appropriate low-pass filter, then either pick the closest sample going out or do a simple 2-point interpolation to get the last little bit of synchronization. If you have the processing power and you can stand about 2ms of delay Since you didn't give any details I'd just recommend upsampling to 96kHz and running through a brick-wall sinc filter thats 192 taps long, then taking the closest sample. But you really need to think about what frequencies you need to pass, what latency is acceptable, and how much noise you can add from clock jitter in your sample output. Before you know these you can't make the necessary tradeoffs, after your choices will be obvious. -- Tim Wescott Wescott Design Services http://www.wescottdesign.com
Reply by ●June 22, 20042004-06-22
There are sample rate conversion chips which do exactly that. You didn't say if a hardware solution was acceptable, or if you required a software-only solution. But you might look into the chips, even if you can't use them directly, because the datasheets usually have pretty good descriptions of the algorithms and how they work. I'd recommend starting with Analog Devices. TI, AKM, and Cirrus are other possibilities. "Tobias Erichsen" <t.erichsen@gmx.de> wrote in message news:2jr1iaF14k9piU1@uni-berlin.de...> Hi everyone, > > I'm having a problem where I need to connect two audio-channels > which are running with clocks of different rate and which do not > run synchronized. So I'm looking for a way in which I can convert > sample-rates and do skew-compensation at the same time. > > One constraint I forgot to mention is the need to do this with the > least amount of latency possible as this is a real-time application... > > Has anyone pointers if such an algorithm already exists? > > Tobias > >
Reply by ●June 23, 20042004-06-23
"Tim Wescott" <tim@wescottnospamdesign.com> schrieb im Newsbeitrag news:10dgmk380v4g46c@corp.supernews.com...> Define "audio" and "least". > > One obvious way to do this would be to upsample and interpolate with an > appropriate low-pass filter, then either pick the closest sample going > out or do a simple 2-point interpolation to get the last little bit of > synchronization. > > If you have the processing power and you can stand about 2ms of delay > Since you didn't give any details I'd just recommend upsampling to 96kHz > and running through a brick-wall sinc filter thats 192 taps long, then > taking the closest sample. > > But you really need to think about what frequencies you need to pass, > what latency is acceptable, and how much noise you can add from clock > jitter in your sample output. Before you know these you can't make the > necessary tradeoffs, after your choices will be obvious.The whole solution is Intel-PC-based. The data is coming from the ISDN/ VoIP-network and is therefore limited to about 3.5khz bandwidth. This needs to be fed into a soundcard working with 48khz (possibly 32 or 96khz - thankfully no plans for 44.1khz yet - but one never knows ;-) As I cannot influence the clock of either the phone-network or the clock of the soundcard, I need to compensate myself... The whole thing is not supposed to be introduce more than about 5-10msec latency (on top of what I already got through the ISDN/VoIP and the soundcard-interface). Tobias
Reply by ●June 23, 20042004-06-23
"Tim Wescott" <tim@wescottnospamdesign.com> schrieb im Newsbeitrag news:10dgmk380v4g46c@corp.supernews.com...> If you have the processing power and you can stand about 2ms of delay > Since you didn't give any details I'd just recommend upsampling to 96kHz > and running through a brick-wall sinc filter thats 192 taps long, then > taking the closest sample.Ah - forgot to mention this is a two-way thing - need to do the way 48khz->8khz also... Tobias
Reply by ●June 23, 20042004-06-23
"Jon Harris" <goldentully@hotmail.com> schrieb im Newsbeitrag news:2jr87nF137ncoU1@uni-berlin.de...> There are sample rate conversion chips which do exactly that. You didn'tsay if> a hardware solution was acceptable, or if you required a software-onlysolution.> But you might look into the chips, even if you can't use them directly,because> the datasheets usually have pretty good descriptions of the algorithms andhow> they work. I'd recommend starting with Analog Devices. TI, AKM, andCirrus are> other possibilities.Your are right - I forgot to mention "a few constraints" ;-) Like written above, this is a Intel-PC software-only solution (apart from the isdn & audio-inter- faces of course ;-) Tobias
Reply by ●June 23, 20042004-06-23
Tobias Erichsen wrote:> "Tim Wescott" <tim@wescottnospamdesign.com> schrieb im Newsbeitrag > news:10dgmk380v4g46c@corp.supernews.com... > > >>Define "audio" and "least". >> >>One obvious way to do this would be to upsample and interpolate with an >>appropriate low-pass filter, then either pick the closest sample going >>out or do a simple 2-point interpolation to get the last little bit of >>synchronization. >> >>If you have the processing power and you can stand about 2ms of delay >>Since you didn't give any details I'd just recommend upsampling to 96kHz >>and running through a brick-wall sinc filter thats 192 taps long, then >>taking the closest sample. >> >>But you really need to think about what frequencies you need to pass, >>what latency is acceptable, and how much noise you can add from clock >>jitter in your sample output. Before you know these you can't make the >>necessary tradeoffs, after your choices will be obvious. > > > The whole solution is Intel-PC-based. The data is coming from the ISDN/ > VoIP-network and is therefore limited to about 3.5khz bandwidth. This needs > to be fed into a soundcard working with 48khz (possibly 32 or 96khz - > thankfully no plans for 44.1khz yet - but one never knows ;-) > > As I cannot influence the clock of either the phone-network or the clock > of the soundcard, I need to compensate myself... > > The whole thing is not supposed to be introduce more than about 5-10msec > latency (on top of what I already got through the ISDN/VoIP and the > soundcard-interface). > > Tobias > >A filter with a 5ms delay should give you fairly good frequency resolution -- that's 480 samples at 96kHz, which is a lot more than simple linear interpolation. There's a thread just after yours titled "sampling rate conversion" that gives some specific algorithms. Basically to go from 96 to 8 you low pass down to 3.5 or so, then sample within that. To go from 8 to 96 you make a train that goes (data, 0, 0, ,0 ...), low pass filter down to 3.5, then send every sample out. Your problem will come when you find that your 8kHz isn't _exactly_ equal to your 96kHz / 12. The cheezy quick way to fix this will be to just sample a bit slower or faster (obvious on the 96 -> 8 side, just stuff one more or less 0 on the 8 -> 96 side). I'm sure there are better ways to do this, but I don't know if they're documented. -- Tim Wescott Wescott Design Services http://www.wescottdesign.com
Reply by ●June 23, 20042004-06-23
Did you look into Erik's SRC software: http://www.mega-nerd.com/SRC/ Maybe it helps you out, at least with one part of the problem. --smb
Reply by ●June 24, 20042004-06-24
"Stephan M. Bernsee" <stephan.bernsee@web.de> schrieb im Newsbeitrag news:38ab652c.0406230811.26ede0b0@posting.google.com...> Did you look into Erik's SRC software: http://www.mega-nerd.com/SRC/ > Maybe it helps you out, at least with one part of the problem.The problem I have is not just samplerate-conversion, but adapting between different clocks... the 96khz signal is not locked with the 8khz clock. So it might be 96001hz and 7999hz - so the producer gives slightly more data than the consumer can take... I think this is the biggest problem I need to cope with... (obviously this might just as well be the other way around: 95999hz producer and 8001hz consumer) Tobias
Reply by ●June 24, 20042004-06-24
Tobias Erichsen wrote:> "Stephan M. Bernsee" <stephan.bernsee@web.de> schrieb im Newsbeitrag > news:38ab652c.0406230811.26ede0b0@posting.google.com... > >>Did you look into Erik's SRC software: http://www.mega-nerd.com/SRC/ >>Maybe it helps you out, at least with one part of the problem. > > > The problem I have is not just samplerate-conversion, but adapting between > different clocks... the 96khz signal is not locked with the 8khz clock. > > So it might be 96001hz and 7999hz - so the producer gives slightly > more data than the consumer can take... I think this is the biggest > problem I need to cope with... (obviously this might just as well be > the other way around: 95999hz producer and 8001hz consumer) > > TobiasWhen needed, you delete or double a sample. This is a universal problem when data clocks are not derived from the same source. There are many solutions to fit many circumstances. A search should find them. Jerry -- Engineering is the art of making what you want from things you can get. �����������������������������������������������������������������������
