XMOS-based Asynchronous USB to I2S interface

[TheShaman]

Originally Posted by Wolfsin

@TheShaman: Nice position. What I meant, however, is whether a mathematician is a failed philosopher or the philosopher a failed engineer

Not sure. I do know that someone who goes deep into mathematics is bound to become a philosopher sooner or later (which is a nice way to say he/she'll go wacko )!

Originally Posted by qusp

@ TheShaman: as i see it there was no useable solution in that thread. well nothing i dont already have beat for my portable dac project using the ltc2935 and an external fast charger/balancer, i could use one of my spare pcbs but populated in a different manner and pirate the low battery shutdown signal to switch a relay either directly, or by biasing a transistor on. i'd be more inclined to have 2 batteries and the signal switches over to the other one and connects to the charge input, but maybe turn the charger on manually, because my charger pwns anything resembling diy

Yes, unfortunately the bulk of communication (or information leeching ) must have been via PMs etc.
With enough digging I'm sure we'll find a way.
I bought a smart (programmable etc.) charger as well and lost interest but perhaps I should restart my research. It'd be nice to have everything done automatically.

[rsdio]

Originally Posted by regal

Well the clock would be at the DAC chip, but you align the critical input(s) to the DAC with it. You can't just pump a 20+ mhz clock into a dac chip and expect it to do the synchrous alignment (maybe the ESS's can, don't know). It also depends on how the oversampling filter and dac combo works as to which dac inputs you would align . I agree the challenge is getting the clock back to the Xmos. I think we are saying the same thing?

The only critical signal is the clock, so there is no need to align the other inputs. You can't align them if they're late, anyway, because that would require that your circuit know the future and provide those inputs before they arrive. The only alternative is to delay all signals by one clock cycle to make sure that they all arrive on time or early, but that's already happening inside the DAC anyway, so there's no real need to duplicate the process outside the chip.

However, I believe there are some chips which only reference the master bit clock, while other chips reference both the bit clock and the word clock. If the latter, or any variation like that, then you really need to know which clock is the master and the consequences of other signal being late. However, the general principle with multi-signal serial links is that all the signals should be updated slightly ahead of the clock so that the clock can reliably read the other signals.

Maybe if you can point to a circuit example of how you would align the non-clock serial signals to the DAC clock then I would understand what you're trying to accomplish.

EDIT: Also, if there is another critical signal besides the clock that I'm missing, then please mention it. In my estimation, if you have a critical input that isn't aligned, then you've not successfully distributed the DAC master clock back to the driving circuits.

[regal]

Originally Posted by rsdio

The only critical signal is the clock, so there is no need to align the other inputs. You can't align them if they're late, anyway, because that would require that your circuit know the future and provide those inputs before they arrive. The only alternative is to delay all signals by one clock cycle to make sure that they all arrive on time or early, but that's already happening inside the DAC anyway, so there's no real need to duplicate the process outside the chip.

However, I believe there are some chips which only reference the master bit clock, while other chips reference both the bit clock and the word clock. If the latter, or any variation like that, then you really need to know which clock is the master and the consequences of other signal being late. However, the general principle with multi-signal serial links is that all the signals should be updated slightly ahead of the clock so that the clock can reliably read the other signals.

Maybe if you can point to a circuit example of how you would align the non-clock serial signals to the DAC clock then I would understand what you're trying to accomplish.

EDIT: Also, if there is another critical signal besides the clock that I'm missing, then please mention it. In my estimation, if you have a critical input that isn't aligned, then you've not successfully distributed the DAC master clock back to the driving circuits.

I think we are saying the same things. Most of the DAC chips I play with never see the master clock, only the filter chip does. When you have a separate digital filter it does get more complicated because you want to do an alignment of the critical signal after the filter so as to remove the instrinsic jitter of the filter's output. As well as not feed jitter to the filter on its inputs because that jitter is encoded into the data..

Sidly, on the other site has a very good DIY CDP digital section that is a good example for a schematic and a good read if you are interested in alternatives to the modern all-in-one wonder chips.

But we're getting off topic For this thread the key indgrediant is somehow moving the masterclock(s) to the right. Diyers can figure out the rest.

[rsdio]

Originally Posted by regal

Most of the DAC chips I play with never see the master clock, only the filter chip does. When you have a separate digital filter it does get more complicated because you want to do an alignment of the critical signal after the filter so as to remove the instrinsic jitter of the filter's output. As well as not feed jitter to the filter on its inputs because that jitter is encoded into the data..

Well, I would say that the DAC chip needs to see the master clock if you want minimal jitter. Not sure how the DAC can operate without a master clock.

Meanwhile, a pure digital filter should be immune to jitter because it should process the data and not the clock. The only class of filter that reacts to jitter on its inputs would be ASRC, which should be avoided in a properly-clocked DAC system. I'm not saying there's no place for a digital filter, just that the problems you describe should be avoided rather than hacked around.

[regal]

Originally Posted by rsdio

Well, I would say that the DAC chip needs to see the master clock if you want minimal jitter. Not sure how the DAC can operate without a master clock.

Meanwhile, a pure digital filter should be immune to jitter because it should process the data and not the clock. The only class of filter that reacts to jitter on its inputs would be ASRC, which should be avoided in a properly-clocked DAC system. I'm not saying there's no place for a digital filter, just that the problems you describe should be avoided rather than hacked around.

Not hacks, classic synchronous reclocking as used with Digital Filters and Multibit dac chips inside CDP's for the past 15 years. The key of course being able to share the masterclock with the Xmos chip.

Hey at least we agree ASRC should be avoided

I think we are confusing each other when referring to a DAC, sometimes meaning the complete unit and other times meaning the dac chip.


Forget about my experiements with the old chips, Probably the xmos isn't the best for those anyway. All they need is a single clock for rbcd typically
256xfs=11289.6 (instead of the 2 512fs clocks on the waveio.)

I am also slowly tinkering with a fairly modern chip the WM8741. Do you know if there will be truncation with the I2S format? Does the WaveIO output 32+32 word length I2S or is it the standard phillips 24+24 I2S? I know the WM8741 has a few dither modes but don't think it can dither past beyond the 24th bit. I think only the Sabre's, new AKM, and new BB can handle 32 bits without truncating?

[reo]

On another note.,
in the USB Audio Class Driver Control Panel., the Stream Formats are both grayed out, is it the same for everyone who is using this driver ?. Sure would be nice to see the Input and Output Stream Formats functioning.,
thanks for your taught s on this .
regards
reo

[Wolfsin]

My Stream Formats are grayed but output of 2 channel, 24 bits is correctly displayed and nothing is displayed for input. I believe this is functioning correctly. There are no other options for WaveIO with the revision I have.

[Porfido]

So, made a cheap box for trying the spdif transport capabilities of Waveio and connected to the (also very cheap) PSU with JLH Ripple Eater...



Tried with ASIO in my Audio-GD NFB-12 and worked flawlessly...
Brought my inexpensive dac another level, I must say...
If also a cheap DAC like that can have such an improvement, a Buffalo and I2S connection are coming next!
Thank you, Lucian!

[regal]

Originally Posted by Porfido

So, made a cheap box for trying the spdif transport capabilities of Waveio and connected to the (also very cheap) PSU with JLH Ripple Eater...



Tried with ASIO in my Audio-GD NFB-12 and worked flawlessly...
Brought my inexpensive dac another level, I must say...
If also a cheap DAC like that can have such an improvement, a Buffalo and I2S connection are coming next!
Thank you, Lucian!

I am surprised it helped the nfb-12, I have one but it measures high distortion (starts with -80dB 2H) stock. Was planning on adding an arudino along with the WaveIO with a new enclosure and better output stage. Glad this turned out good for you.

[hochopeper]

Originally Posted by regal

I am also slowly tinkering with a fairly modern chip the WM8741. Do you know if there will be truncation with the I2S format? Does the WaveIO output 32+32 word length I2S or is it the standard phillips 24+24 I2S? I know the WM8741 has a few dither modes but don't think it can dither past beyond the 24th bit. I think only the Sabre's, new AKM, and new BB can handle 32 bits without truncating?

If Lorien or someone who knows the answer could answer this question about waveio output being 24+24 or 32+32 I'd be interested also.