Revisiting ASRC (sample rate conversion) and up-sampling

Jump to Latest
#41
philipsmarantz said:
Not to be "mean" (= facetious), but I don't know what I mean 😉
That is, I don't know why the ASRC improves sonics? I definitely heard improvement when I added the AD1896 into the 1305 setup -- compared to no SRC.
Yes, as can be noted in the photos, the AD1896 will 2x "oversample". But it might be interesting to use the ASRC with, say, a TDA1543 or 1545 or 1541.
I suppose I should do some objective tests. But one can only go so far w/o, say, this: https://www.ap.com/analyzers-accessories/apx555/
Click to expand...
If I recall correctly, the ratio-estimator block of the AD1896 co-incidentally enables it to very effectively suppress incoming data stream clock jitter. Much more so than is typically provided by a Digital Input Receiver chip's analog PLL. Perhaps, that is the reason you hear an improvement?
 
#45
bohrok2610 said:
And when comparing Amanero+AD1896+TDA1305 to synchronous USB CM108+TDA1305 I would not expect possible jitter suppression of AD1896 to be the key for any audible differences.
Click to expand...
In the Chinese 1305 kit (see the Naim thread), there is the another device between the CM108 and TDA1305: CS8412. The CM108 has a 12Mhz osc. feeding it its XO. Also, the CM108 block diag. has something called a Clock Gen. What is this?
I don't recall exactly how I probed the kit dac, or mod it, but I couldn't get the 1305s to work w/o the CS8412. The CS8412 spits out MCK (256fz) at pin 19 -- in sync with its I2S lines - - and that feeds the 1305 MCK.
So is the Chinese kit using "synchronous" USB?
 
Last edited:
#47
In the Chinese 1305 kit, I went back and traced the I2S lines between the 1305 and CM108.
When a USB cable is plugged in, the CS8412 seems to be bypassed (via the Omron relays???) -- and the CS8412 (with no SPDIF but just USB plugged into Chinese kit) outputs "nonsense" at MCK and I2S outputs.
As far as CM108 and USB mode. The datasheet notes: "Isochronous Transfer uses Adaptive Mode with Internal PLL for Synchronization"
So neither async or sycn according to [1].
But Audiophilesytle seems to have varied opinion [4].
===============
(1)
http://bucarotechelp.com/networking/basics/88092302.asp
(2)
https://pdf1.alldatasheet.com/datasheet-pdf/view/87252/CIRRUS/CS8412.html
(3)
https://www.digchip.com/datasheets/parts/datasheet/574/CM108-pdf.php
(4)
https://audiophilestyle.com/forums/...s uses isochronous,from the USB packet timing.
 
Last edited:
#51
philipsmarantz said:
As far as CM108 and USB mode. The datasheet notes: "Isochronous Transfer uses Adaptive Mode with Internal PLL for Synchronization"
So neither async or sycn according to [1].

===============
(1)
http://bucarotechelp.com/networking/basics/88092302.asp
Click to expand...
CM108 uses adaptive USB isochronous mode for output, e.g. in https://forum.ubuntu-it.org/viewtopic.php?p=5206523&sid=70bda68fd75263daa3feb9208ea28e90#p5206523 :

Code: 
idVendor           0x0d8c C-Media Electronics, Inc.
idProduct          0x013c CM108 Audio Controller
bcdDevice            1.00
iManufacturer           1 C-Media Electronics Inc.     
iProduct                2 USB PnP Sound Device
...
Endpoint Descriptor:
       bLength                 9
       bDescriptorType         5
       bEndpointAddress     0x01  EP 1 OUT
       bmAttributes            9
         Transfer Type            Isochronous
         Synch Type               Adaptive
         Usage Type               Data
       wMaxPacketSize     0x00c8  1x 200 bytes
       bInterval               1
       bRefresh                0
       bSynchAddress           0

I am afraid that link [1] does not relate to USB isochronous transfers where synchronous, adaptive, and asynchronous have very precise meanings.

BTW does anyone know how synchronous OUT is supposed to work? Without PLL (which would mean adaptive) it would have to output bits in 12MHz chunks as USB frames arrive to the device. IMO audio devices reporting synchronous OUT mode (I have seen those) are actually adaptive. No difference for the USB host anyway.
 
#52
The difference between synchronous and adaptive UAC is rather vague as in both cases the endpoint needs to match its natural data rate to host's data rate. Jitter-wise both are inferior to asynchronous UAC.

According to UAC specification synchronous endpoint can be controlled externally through SOF synchronization. I would assume PLL is the easiest solution for this but that would make it actually adaptive.
 
Last edited:
#53
Maybe the sync mode was not aimed at audio, but e.g. at video - showing a frame requires receiving all pixels and their jitter does not matter, no pixel clock needs to be recovered. The frame is displayed once all pixels for the frame are delivered. Maybe something like that. But for audio I do not see any usage of the sync mode (not adaptive).
 
#54
I don't even know what those modes are, but this is what Wikipedia says about it ( https://en.wikipedia.org/wiki/USB ):

"USB provides three isochronous (fixed-bandwidth) synchronization types,[68] all of which are used by audio devices:[69]


  • Asynchronous – The ADC or DAC are not synced to the host computer's clock at all, operating off a free-running clock local to the device.
  • Synchronous – The device's clock is synced to the USB start-of-frame (SOF) or Bus Interval signals. For instance, this can require syncing an 11.2896 MHz clock to a 1 kHz SOF signal, a large frequency multiplication.[70][71]
  • Adaptive – The device's clock is synced to the amount of data sent per frame by the host[72]

While the USB spec originally described asynchronous mode being used in "low cost speakers" and adaptive mode in "high-end digital speakers",[73] the opposite perception exists in the hi-fi world, where asynchronous mode is advertised as a feature, and adaptive/synchronous modes have a bad reputation.[74][75][67] In reality, all types can be high-quality or low-quality, depending on the quality of their engineering and the application.[71][59][76] Asynchronous has the benefit of being untied from the computer's clock, but the disadvantage of requiring sample rate conversion when combining multiple sources."
 
#56
MarcelvdG said:
  • Synchronous – The device's clock is synced to the USB start-of-frame (SOF) or Bus Interval signals. For instance, this can require syncing an 11.2896 MHz clock to a 1 kHz SOF signal, a large frequency multiplication.[70][71]
Click to expand...
If packets contain varying number of samples (e.g. 44.1kHz rate), it is very hard to sync the sample clock to SOF/bInterval without PLL (which would make it adaptive).

But this is just a theoretical discussion anyway, IMO no use for audio.
 
#57
All else held equal, the USB sync vs async is pretty confusing -- not the technolgy, per se, but the benefits of one over the other. And even after Gordon Rankin claims to have solved some problems with his Streamlength patent, see https://www.usbdacs.com/Concept/Concept.html , the sync/async issue was challenged by other major players, like Benchmark:
The USB input is taken to a Texas Instruments TAS1020B chip, which extracts the audio data using a phase-locked loop and converts it to i2S. According to Benchmark's Elias Gwinn (footnote 1), the DAC1 USB runs in the USB protocol's "synchronous" mode, to allow the host PC to, at all times, send audio data at the original sample rate of the audio being played. If the PC (or, more specifically, Windows XP's kmixer DLL) is not forced to do sample-rate conversion, it can maintain bit-transparent operation. "There is a tradeoff, of course," said Gwinn: "significant amounts of jitter arrive at the DAC1. This is not a problem for the DAC1, however, because Benchmark's UltraLock clocking system makes it immune to jitter."
Click to expand...
See:
https://www.stereophile.com/headphones/108bench/index.html

It might be down to how much computation a USB receiver can do cleanly. Supposedly, the latest XMOS can do async fairly quietly. But even older devices, like CM108, might be just fine given they only do the work of 16/44.1 and are supplied with clean power on Vcc pins with plenty of decoupling.
Like the long-used Buick’s 3800 engine. Overbuilt for the job. Might take a bit more fuel, but burns cleanly and runs smoothly.
 
#58
The claims of Benchmark are overstated. They use an SRC4392 ASRC to convert all incoming PCM digital audio to 24/211 (a submultiple of around 27Mhz, IIRC). That being the case there is no point to asynchronous USB. Does SRC4392 'eliminate' jitter? No, it attenuates jitter. Does ASRC sound as good as Asynchronous USB in an exceptionally well designed dac? No, at least not IME. And I used to own an Benchmark DAC-1, then a Benchmark DAC-3.

Some explanation at: https://benchmarkmedia.com/blogs/application_notes/dac3-introducing-the-new-es9028pro-converter (maybe search for: 211)
 
Last edited:
#59
I thought they used a 211 kHz sample rate, but apparently that's for the DAC2:

https://benchmarkmedia.com/blogs/application_notes/inside-the-dac2-part-2-digital-processing

Having funny master clocks and output sample rates helps to avoid low-frequency beat notes that could end up in the passband of the sample rate ratio estimator (among other advantages). Systematic jitter in the passband would not be suppressed.

Edit: also DAC3, https://benchmarkmedia.com/blogs/ap...9028pro-converter?_pos=3&_sid=95655f9f9&_ss=r
 
#60
philipsmarantz said:
All else held equal, the USB sync vs async is pretty confusing -- not the technolgy, per se, but the benefits of one over the other.
Click to expand...

philipsmarantz said:
It might be down to how much computation a USB receiver can do cleanly. Supposedly, the latest XMOS can do async fairly quietly. But even older devices, like CM108, might be just fine given they only do the work of 16/44.1 and are supplied with clean power on Vcc pins with plenty of decoupling.
Like the long-used Buick’s 3800 engine. Overbuilt for the job. Might take a bit more fuel, but burns cleanly and runs smoothly.
Click to expand...
IMO USB isochronous sync/adaptive vs. async mode is quite simple and nothing controversial. It has nothing to do with adaptive/asynchronous or even synchronous resampling. It just defines which clock is used for overall transfer of the samples - either paced by the USB host controller clock (sync/adaptive) or paced by the USB device clock (async). In computer playback what determines the pace in which samples are processed is the sink. USB sync - the driver consumes samples at pace of the host controller clock, USB async - the driver consumes samples at pace of the device clock which will always slightly differ from the controller clock (like any two independent clocks always do). Both sample-consumption clocks would run at the selected nominal samplerate, no samplerate conversion involved.

If the Benchmark DAC runs at fixed 211kHz internally, of course there must be some resampling in the chain, either in the software or in the device HW. Since the manufacturer cannot expect any general-use operating system to accept 211kHz samplerate, such device must do the resampling internally. When already having to do fractional resampling to 211kHz in HW, it makes sense they would use adaptive/asynchronous resampling (which is fractional by design) and use the simpliest transfer - synchronous. For async USB mode they would have to generate some feedback control value which is redundant when the received stream is sent through async resampling anyway.

But that DAC may do things differently, I have not studied its details. But still resampling has nothing to do with the USB transfer mode.
 
You must log in or register to reply here.
Top Bottom