advertisement


MDAC First Listen (Part 00101001)

Status
Not open for further replies.
This is very interesting. That's how I thought data was extracted in the modern world.
I'm not quite sure what mechanism it leaves for interface jitter to affect the conversion clock. I can see why you are sceptical about the "swenson hypothesis" for transmission.

Can I ask a question? This is a 2012 paper - it's hardly the mechanism that is incorporated into the majority of existing USB 2 receiver chips, most of which were manufactured before 2012 (not to mention the fact that the timeframe for this sort of research into new methods being incorporated into mainstream chips is longer than 3 years)?
 
John

You have had the ReGen and JB for a while now and have undertaken a number of evaluation tests and measurements to understand their workings and processes, which have been very interesting to read and understand.

Well both the ReGen and JB perform as expected - its just nice to see some measurements confirming their performance as nothing of any interest has been atleast publicly published before.

Taking all of that into account have you connected either of them into an audio system and heard any improvements/changes in the SQ as reported/claimed by the manufactures, Hi Fi mags and various individuals?

I've not had the time to setup my reference listening system above the lab - in fact I still need to complete the wiring in the listening room (I have about 20 AC wall sockets left to install) :( after wiring the 50 or so for the lab downstairs I had no will left to complete the upper floor!

There is little point in listening to the ReGen as its very different to the DeTox design, once I have the Detox prototyped then I'll listen to the JB, ReGen & Detox :)

I know the DeTox will provide an optimised USB signal to the FDAC / MDAC so I don't question its need - when people spend crazy money on USB cables etc, atleast the DeTox can be shown to measurably optimise the USB signal.
 
@John,

It's probably been mentioned before, memory is short. As for the digital board, what type of digital inputs have you considered for the FDAC?

Give me a week or so to answer as I'll be working on the connector arrangement so the vendor can produce the completed ID drawings and start on the chassis prototypes.
 
Can I ask a question? This is a 2012 paper - it's hardly the mechanism that is incorporated into the majority of existing USB 2 receiver chips, most of which were manufactured before 2012 (not to mention the fact that the timeframe for this sort of research into new methods being incorporated into mainstream chips is longer than 3 years)?

I doubt it because the normal method is to sample the input data with 3 times oversampling frequency - this papers suggest a method that by oversampling at x5 oversampling rate you can reduce a portion of the input circuit block transistor count by 50% - I'm sure most USB designs will be operating at the conventional x3 times oversampling frequency especially as they will be manufactured upon older and thus larger silicon geometries with an upper frequency limit.

5x oversampling requires an internal clock rate of 2.4GHz which is pushing it for the older / larger silicon geometries, but the whole point being is that no PLL is used to extract the data on USB 2.0 PHY's.
 
I doubt it because the normal method is to sample the input data with 3 times oversampling frequency - this papers suggest a method that by oversampling at x5 oversampling rate you can reduce a portion of the input circuit block transistor count by 50% - I'm sure most USB designs will be operating at the conventional x3 times oversampling frequency especially as they will be manufactured upon older and thus larger silicon geometries with an upper frequency limit.

5x oversampling requires an internal clock rate of 2.4GHz which is pushing it for the older / larger silicon geometries, but the whole point being is that no PLL is used to extract the data.

OK, thanks, so the blind oversampling isn't the new concept, just the 5X oversampling rate. Any idea when this concept became popular - I thought ESS were the only ones doing it, I didn't know it was in operation on chips prior to their use of the technique on the front end of the DAC chip?

I just got a bit confused by your earlier post "When you oversample the input Data, SI Rise & fall times absolutely has no effect on internal circuit conditions,...." I was always under the impression that OS increases sensitivity to jitter, not reduces it - but I see it's the blind recovery technique that is the critical element
 
Give me a week or so to answer as I'll be working on the connector arrangement so the vendor can produce the completed ID drawings and start on the chassis prototypes.

Perfectly fine John. My long wishlist would look something like this:

USB, RJ45 (I2S), RCA Coax (S/PDIF), BNC Coax (S/PDIF), AES/EBU Balanced

/Lars
 
OK, thanks, so the blind oversampling isn't the new concept, just the 5X oversampling rate. Any idea when this concept became popular - I thought ESS were the only ones doing it, I didn't know it was in operation on chips prior to their use of the technique on the front end of the DAC chip?

Yes, its an old technique used when you only need to recover the Data and when you don't need to generate a stable system clock recovered from the input data (such as with the MCLK output on a SPDIF receiver which is used to clock the DAC).

We used this method with FPGA SPDIF receiver designs sometime around 2000 and its was common back then... The 2011 paper references x3 oversampling designs from 1998... I'd be the wrong person to ask as I mainly work with the "Analogue" portions of Digital designs :)
 
Perfectly fine John. My long wishlist would look something like this:

USB, RJ45 (I2S), RCA Coax (S/PDIF), BNC Coax (S/PDIF), AES/EBU Balanced

/Lars

I'm not sure about the I2S port, but the FWC allows us to fit x2 expansions slots on the rear, one's planed for the RF module and the second for the HDMI board - but the expansion slots can be used for other I/O interfaces in the future if required (I'll design them to be universal - who knows what the future holds) :)
 
Can I ask a question? This is a 2012 paper - it's hardly the mechanism that is incorporated into the majority of existing USB 2 receiver chips, most of which were manufactured before 2012 (not to mention the fact that the timeframe for this sort of research into new methods being incorporated into mainstream chips is longer than 3 years)?
it appears that this is simply a revision of an existing "traditional blind oversampling data recovery circuit"

I claim no expertise, but I was under the impression that quite a few dacs use this methodology from data recovery (not just for usb). I think that how the ps audio perfectwave does it & maybe the dspeaker antimode
 
Yes, its an old technique used when you only need to recover the Data and when you don't need to generate a stable system clock recovered from the input data (such as with the MCLK output on a SPDIF receiver which is used to clock the DAC).

We used this method with FPGA SPDIF receiver designs sometime around 2000 and its was common back then... The 2011 paper references x3 oversampling designs from 1998... I'd be the wrong person to ask as I mainly work with the "Analogue" portions of Digital designs :)

Much appreciated!
 
We used this method with FPGA SPDIF receiver designs sometime around 2000 and its was common back then... The 2011 paper references x3 oversampling designs from 1998... I'd be the wrong person to ask as I mainly work with the "Analogue" portions of Digital designs :)
Am I misunderstanding the point here, but it seemed to me that if you use this design then interface jitter becomes irrelevant except for the issue of matching the data flow (which is a longer term clock matching issue).
 
it appears that this is simply a revision of an existing "traditional blind oversampling data recovery circuit"

I claim no expertise, but I was under the impression that quite a few dacs use this methodology from data recovery (not just for usb). I think that how the ps audio perfectwave does it & maybe the dspeaker antimode

Ok, thanks!
 
Am I misunderstanding the point here, but it seemed to me that if you use this design then interface jitter becomes irrelevant except for the issue of matching the data flow (which is a longer term clock matching issue).

For data recovery yes - but with an audio system we face the extra dimension of what I've call "second order effects" where the incoming data contains "unwanted" phase noise modulation (and other noise products) as the input circuits of the USB PHY process this data they create RF, PSU and Ground currents directly modulated by the extraneous "Noise" on the input datastream - the USB LF modulation can observed directly on the PSU pins of the USB device (as would be expected).

The aim of the Detox is to attenuate the extraneous USB packet timing modulation, attenuate unwanted RF, Galvanic isolation of the USB1.1 Port & proved a low noise 5V USB power.
 
I might be wrong but I think Adamdea was asking a more generalised question about the use of this technique (Blind Oversampling clock & data recovery -BO CDR for short) in devices where the accuracy of clock recovery is critical? Not just about it's use in USB where clock recovery is only concerned with long term drift.

I'm not being adversarial - just trying to clear up my misunderstandings - is noise not equivalent to jitter?
 
If I can summarise my understanding of the USB scenario:
- Blind oversampled clock & data recovery (BOCDR) techniques are used in current USB PHY to recover the clock & data samples (clock accuracy is not hugely important because it's only longer term drift that matters between USB transmitter & receiver)
- BOCDR does not work any harder if the signal integrity of the signal is worsened
- signal integrity does come into play if it is the result of extraneous noise riding on the USB signal & this does have knock-on "second order effects" on ground plane, clock & ultimately on sound

Is this an accurate summary of the USB scenario?

With regard to the use of BOCDR in other audio devices where clock recovery accuracy is critical, is the following correct?
- this form of clock recovery isn't as accurate the best PLL
- devices that use BOCDR also use an ASRC to effectively remove this clock jitter issue (but introduces other issues)- or uses another mechanism for clock recovery in addition to the BOCDR for data recovery
 
Hi JohnW What PC transport are you using when testing your dac? Curious if you have been exposed to optimized,fanless PC's with battery or LS supplies and if you have formed any view on them.
 
Newbie to the forum and thread but have read many of the posts with particular interest in REGEN discussion. I see that John W is working on DETOX.

Is this part of the upcoming MDAC2 (which I see staged out to March '14) or a standalone unit which can be used with any DAC?

Tried to find a link by googling on Westlake + Detox but most were for drug rehab programs. I know our hobby is addictive but I am not in need of personal treatment...yet! ;-)
 
Status
Not open for further replies.


advertisement


Back
Top