opus - Sep 2014 - Opus and sender and receiver sample rate drift.

Hi All.

I have an application where the sample rate of the sender and receiver can vary
by a small margin and the latency needs to be maintained within bounds and
can't drift significantly and the system has to be able to cope with clock
mismatches up to 0.5%.  For example, the sender may have a clock rate of 48.1kHz
and the receiver may have a clock rate of 47.9kHz.
Unfortunately the clock rate of the receiver cannot be adjusted as this is a
multichannel device with a common clock and potentially senders from different
geographic locations can be sending to different channel on this device at the
same time.

I am using the OPUS codec in mono celt mode with a data rate of 32,000 bits per
second.

What is the best practice for dropping a frame?  Will there be significant audio
artefacts if a frame is just dropped,  that is opus_decode (n-1) and then
opus_decode (n+1)?

What is the best practice for adding a frame to the jitter buffer?  Will there
be significant audio artefacts if a packet is added by calling opus_decode with
a null input playload, that is opus_decode(n), opus_decode(null) and followed by
opus_decode(n+1)?

Thanks.

George de Vries
Senior Software Engineer

Open Access
Ph:  +61(0)2 9978 7105

For every complex problem, there is a solution that is simple, neat, and wrong
H.L Mencken.

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.xiph.org/pipermail/opus/attachments/20140922/b711a5e4/attachment.htm

Hi George,

Clock skew is a common problem and I can think of at least three
reasonable ways to deal with it. From highest to lowest quality:

1) The best (and often hardest) approach is to estimate the clock skew
in real-time and do resampling on the decoder's output. In your example
where the sender's operating at 48.1 kHz and the receiver's operating at
47.9, you'd simply be resampling from 48.1 to 47.9 so that the skew is
perfectly compensated. Assuming you have a good estimate of the skew
(which is the hard part), you get perfect quality.

2) Another approach is to track the buildup/emptying of the buffer and
try to insert or delete audio in the silence periods. When there's no
silence, you try to insert or delete an integer number of pitch periods
to minimize the effect.

3) Still acceptable, but lower quality is what you're describing. You
can just discard packets (without telling the decoder) when there's a
buildup in the buffer. When there's not enough in the buffer, you
pretend there's a packet loss and call the PLC. Ideally, you would still
attempt to do the adjustments during periods of silence.

Hope this helps.

	Jean-Marc

On 21/09/14 10:29 PM, George de Vries wrote:
> Hi All.
> 
>  
> 
> I have an application where the sample rate of the sender and receiver
> can vary by a small margin and the latency needs to be maintained within
> bounds and can?t drift significantly and the system has to be able to
> cope with clock mismatches up to 0.5%.  For example, the sender may have
> a clock rate of 48.1kHz and the receiver may have a clock rate of 47.9kHz.
> 
> Unfortunately the clock rate of the receiver cannot be adjusted as this
> is a multichannel device with a common clock and potentially senders
> from different geographic locations can be sending to different channel
> on this device at the same time.
> 
>  
> 
> I am using the OPUS codec in mono celt mode with a data rate of 32,000
> bits per second.
> 
>  
> 
> What is the best practice for dropping a frame?  Will there be
> significant audio artefacts if a frame is just dropped,  that is
> opus_decode (n-1) and then opus_decode (n+1)?
> 
>  
> 
> What is the best practice for adding a frame to the jitter buffer?  Will
> there be significant audio artefacts if a packet is added by calling
> opus_decode with a null input playload, that is opus_decode(n),
> opus_decode(null) and followed by opus_decode(n+1)?
> 
>  
> 
> Thanks.
> 
>  
> 
> George de Vries
> 
> Senior Software Engineer
> 
>  
> 
> Open Access
> 
> Ph:  +61(0)2 9978 7105
> 
>  
> 
> For every complex problem, there is a solution that is simple, neat, and
> wrong
> 
> H.L Mencken.
> 
>  
> 
> 
> 
> _______________________________________________
> opus mailing list
> opus at xiph.org
> http://lists.xiph.org/mailman/listinfo/opus
>