Thank you all for the insightful conversation, learned a lot here.. The
SOC I'm using has fractional clocks that can be adjusted by 0.02%. I
implemented ISO sync as that was outlined by our customer in their
spec.. From all I read before, everyone seemed to be in consensus that
ISO Async is the way to go.. As for now I've heard no pops/clicks ever
since I implemented the clock matching..
From reading this thread, fractional clocks on SOC may just be "good
enough" as long as the clock matching is done in hardware. I hope I get
to implement the Async method sometime so I can try to differentiate
between them.. I will definitely mention to our test engineer to not use
1Khz. I agree with you that it is not a good rate to use.
Thanks,
Ak
On 10/18/2017 10:13 PM, Troy Gentry (Redacted sender tge96 for DMARC) wrote:
in there lies the truth, the opertative phrase here is "If you have the proper hardware"... the previous poster is attempting to solve this age old problem mostly in software... also, a SOC that natively has an Integer PLL (along with a few other goodies) can actually (has actually) solve this problem, and for both clock trees, and from a single external crystal... so one really can pull a rabbit out of a hat ;)
I haven't ran into "many" ears that can do the Pepsi challenge with ASYNC vs SYNC (properly done in hardware, as Geert lays out below) and actually tell the difference, but I have had the privilege of meeting one such sole (at a world renowned music studio) that could hear the difference, it was truly an amazing encounter... so, have been fortunate enough to have had the chance to implement ISO SYNC synchronization method "properly" in hardware.
...that said, proper test equipment and measurement methods can easily "see" the difference...
if you ever get to that level of measurement, I'll leave you with this one tip... do not make all of your audio test files with 1k-Hz sampling (yes someone did actually do this), as you will simply mask the traditional 1k-Hz noise generated by the digital processing "current pumping" inherent in USB audio systems. tip :: change all of these test files to 1.4k-Hz to validate that your hardware is not excessively impacting the audio quality.
yes, ASYNC shifts the problem to the USB Host, no doubt about it, luckily I haven't had to struggle with USB audio on the host side of system... not so surprising, I guess, is that historically USB Hosts have struggled to properly implement ASYNC synchronization... fun fun
....nobody was assuming that we live in a perfect world, but rather we're all just simply following the spirit of the USB spec <grin, as I type this message to the UAC spec author>.... welcome to the world of extremely low jitter bit perfect prosumer audio that those customers demand ;)
Oh yeah, Hi Geert and thank you very much for all that you do for us ;)
really Kindest Regards (don't shoot the messenger),
-t
------------------------------------------------------------------------
*From:* "geert@xxxxxxxxxxxxxxxxxxx" <geert@xxxxxxxxxxxxxxxxxxx>
*To:* wdmaudiodev@xxxxxxxxxxxxx
*Sent:* Wednesday, October 18, 2017 6:44 PM
*Subject:* [wdmaudiodev] Re: Windows Clock Compensation
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,
D&A <http://www.designandadvice.com/> JW House <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 <mailto: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 <mailto:asharma@xxxxxxxxxxxxxxxxxxxxx>>
*To:* wdmaudiodev@xxxxxxxxxxxxx <mailto: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/
>
>
******************
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/
