[wdmaudiodev] Re: Windows Clock Compensation

  • From: "geert@xxxxxxxxxxxxxxxxxxx" <geert@xxxxxxxxxxxxxxxxxxx>
  • To: wdmaudiodev@xxxxxxxxxxxxx
  • Date: Wed, 18 Oct 2017 18:43:58 -0700

If you have the proper hardware (i.e. a fractional PLL) the adjustments you can 
make to the local clock are extremely precise (typically 0.01 ppm) If you then 
also implement a low-pass filter behavior on the clock adjustment algorithm and 
deploy very extensive averaging, you can achieve audio clock quality levels 
that are beyond what current ADCs and DACs require.

Going with the asynchronous mode actually shifts (not solves) the problem to 
the Host. If the Host has sufficiently sophisticated asynchronous sampling rate 
algorithms available, then that may be a good solution. But do not assume that 
all quality concerns evaporate when you switch to async mode.

Kindest Regards,

  <http://www.designandadvice.com/>  <http://www.jwhouse.org/>Geert Knapen 
President/Owner

Design & Advice, L.L.C. <http://www.designandadvice.com/>
1725 Martin Avenue, San Jose CA 95128
e-mail: geert@xxxxxxxxxxxxxxxxxxx <mailto:geert@xxxxxxxxxxxxxxxxxxx> | Tel: 
+1-408-297-3731 | Cell: +1-408-507-7852 | Google Voice: +1-408-805-4320

On Oct 18, 2017, at 5:05 PM, Troy Gentry (Redacted sender "tge96" for DMARC) 
<dmarc-noreply@xxxxxxxxxxxxx> wrote:

doing it this way, is as Tim says an "extremely tricky problem" - agreed
doing it this way, will likely produce noticeable audible synchronization 
clocking artifacts in the actual audio stream itself (depending on the actual 
clock mismatch between the USB Host and the USB device)

if this is all one has for their audio buffer management mechanism, then 
switching to ASYNC synchronization method would be highly recommended.


From: Akshaykeerti Sharma <asharma@xxxxxxxxxxxxxxxxxxxxx>
To: wdmaudiodev@xxxxxxxxxxxxx 
Sent: Wednesday, October 18, 2017 4:51 PM
Subject: [wdmaudiodev] Re: Windows Clock Compensation

Yes, we are monitoring the micro controller queues live to ensure that there 
is no problem. If I remember correctly the usb audio 1.0 spec we are using 
transmits 48samples/ms(48khz) in our implementation. Making a very small 
change to our I2S reference clock(this is what drives the audio out to a 
speaker essentially) controls the FIFO queue. The trim setting on the micro 
is accurate enough to ensure precise enough changes to the clock to sometimes 
even match the input data stream. 

Another way is to sync to the usb frame start of frame which results in 
getting the same information. You would sync to the start frame and up/down 
the clock appropriately. 

The disadvantage is that we are introducing harmonic distortion in the 
signal. Albeit it is small enough to have no noticeable difference on the 
not-so-great speaker. 

Again, this is using the USB synchronous mode. 

Since the digital stream on the microconroller side is continuous if you 
start over/underflowing data it really messes up the sound. Currently our 
implementation works without any discontinuity. We still have some 
qualitative tests to do to ensure that the reproduction is top notch. 

For a high quality audio application I would recommend ASYNC mode to control 
the data stream in software. 

Sent from my iPhone

On Oct 18, 2017, at 4:40 PM, Tim Roberts <timr@xxxxxxxxx 
<mailto:timr@xxxxxxxxx>> wrote:

Akshaykeerti Sharma wrote:

One possible solution we implemented for usb-audio using synchronous
mode was to adjust the reference clocks on the micro-controller in
realtime by a very small amount to ensure that there are no
underflow/overflow conditions that manifest themselves as
pops/clicks(we did have pops and clicks otherwise)

How would you know?  By monitoring the levels in your onboard FIFOs? 
This is an extremely tricky problem, because even though audio seems to
be smoothly continuous, at the microscopic level it is rather chunky. 
Audio Engine tries to transfer 10ms at a time, and applications commonly
work in buffers even larger than that.

-- 
Tim Roberts, timr@xxxxxxxxx <mailto:timr@xxxxxxxxx>
Providenza & Boekelheide, Inc.

******************

WDMAUDIODEV addresses:
Post message: mailto:wdmaudiodev@xxxxxxxxxxxxx ;
<mailto:wdmaudiodev@xxxxxxxxxxxxx>
Subscribe:    mailto:wdmaudiodev-request@xxxxxxxxxxxxx ;
<mailto:wdmaudiodev-request@xxxxxxxxxxxxx>?subject=subscribe
Unsubscribe:  mailto:wdmaudiodev-request@xxxxxxxxxxxxx ;
<mailto:wdmaudiodev-request@xxxxxxxxxxxxx>?subject=unsubscribe
Moderator:    mailto:wdmaudiodev-moderators@xxxxxxxxxxxxx ;
<mailto:wdmaudiodev-moderators@xxxxxxxxxxxxx>

URL to WDMAUDIODEV page:
http://www.wdmaudiodev.com/ ;<http://www.wdmaudiodev.com/>





******************

WDMAUDIODEV addresses:
Post message: mailto:wdmaudiodev@xxxxxxxxxxxxx ;
<mailto:wdmaudiodev@xxxxxxxxxxxxx>
Subscribe:    mailto:wdmaudiodev-request@xxxxxxxxxxxxx ;
<mailto:wdmaudiodev-request@xxxxxxxxxxxxx>?subject=subscribe
Unsubscribe:  mailto:wdmaudiodev-request@xxxxxxxxxxxxx ;
<mailto:wdmaudiodev-request@xxxxxxxxxxxxx>?subject=unsubscribe
Moderator:    mailto:wdmaudiodev-moderators@xxxxxxxxxxxxx ;
<mailto:wdmaudiodev-moderators@xxxxxxxxxxxxx>

URL to WDMAUDIODEV page:
http://www.wdmaudiodev.com/ ;<http://www.wdmaudiodev.com/>




Other related posts: