Hi Ed,
today is it back.
@Lucian
many thanks for your perfect support!
DSD Support?
@all,
Good news!
And now....back to the music!
I have sent a return request to Lorien.
Ed
2x Clock rates...
Hi Lorien:
I have a suggestion for the new design. Please consider the option of using 2X clock rates, as this is necessary for anyone using an ESS DAC via synchronous clocking (taking masterclock from the interface). My understanding is that this should be a very easy option to implement in the code, and right now there are not good options available for the many ESS chip DACs for people who want to run them synchronously.
Hi Lorien:
I have a suggestion for the new design. Please consider the option of using 2X clock rates, as this is necessary for anyone using an ESS DAC via synchronous clocking (taking masterclock from the interface). My understanding is that this should be a very easy option to implement in the code, and right now there are not good options available for the many ESS chip DACs for people who want to run them synchronously.
Hi there!
I wanted to use The WaveIO over spdif with the Subbu Dac v3 but now you are cutting the SPDIF port for the next WaveIO revision which I wanted to wait for. So there will not be any SPDIF Port on the WaveIO Note. Should I consider the current Version or should I look somewhere else because of some issues regarding WaveIO and SPDIF!
Thank you very much.
I wanted to use The WaveIO over spdif with the Subbu Dac v3 but now you are cutting the SPDIF port for the next WaveIO revision which I wanted to wait for. So there will not be any SPDIF Port on the WaveIO Note. Should I consider the current Version or should I look somewhere else because of some issues regarding WaveIO and SPDIF!
Thank you very much.
Hi Ed,
today is it back.
@Lucian
many thanks for your perfect support!
DSD Support?
@all,
Yes, DSD.. my oldest enemy. I'm still waiting for news regarding it as I'm not the one "in charge" to make this update. Sorry but there are no news so far! Anyway, when it will be available, few clicks will solve the "issue"
Huh, one year back
The I2S input is already taken into account, including few PSU upgrades as well. Anyway, I'll take them one at a time as my first priority now (besides finishing daughter board) is to see this new board working as expected. Few missing parts are on the way thus I hope at the end of next week to have an (hopefully, positive) answer...
Answered, thank you!
Hi barrows! The first WaveIO board have 22.5792 and 24.576 MHz local clocks buffered to output master clock signal. This new one has 45.1584 and 49.152 MHz oscillators divided by 2 by a flip-flop just because I want ALL the output I2S signals (especially Master clock one) to be in sync with each other. Should I understand that 2x.x freqs are not good for ESS and you want at output the double of it? If not, please tell me what frequencies do you need for ESS to work properly and I'll see what I can do about it!
Hi rondadon, please let's not rush on conclusions yet!
Current version will have DB on it which will address SPDIF too (I finally found a way to pick the signal from the actual WaveIO board without too much hassle - whatever that means!) Be back with news when I'll have it!Hi Walter! Well, the new board is not finished assembled so there is no description attached nor even a picture too clearly see how it looks like. Next week hope to have some which will be posted here.
Best wishes to all,
L
Current version will have DB on it which will address SPDIF too (I finally found a way to pick the signal from the actual WaveIO board without too much hassle - whatever that means!) Be back with news when I'll have it!
Well done Lorien. That's great news for all us current owners tied to S/PDIF (no option) and who want the benefits of the DB upgrade.
Thanks
Jonathan
Well done Lorien. That's great news for all us current owners tied to S/PDIF (no option) and who want the benefits of the DB upgrade.
Thanks
Jonathan
For all those who are using WaveIO with Windows there are new drivers for you available here. I didn't had time to properly test them so any feedback will be appreciated! BTW, Doede you're next
On another hand it seems that 32/384 feature is working beautifully so soon enough I'll start to supply WaveIOs with it enabled by default.
Cheers,
L
On another hand it seems that 32/384 feature is working beautifully so soon enough I'll start to supply WaveIOs with it enabled by default.
Cheers,
L
Wave Note with ESS 9018
Lorien:
"Hi barrows! The first WaveIO board have 22.5792 and 24.576 MHz local clocks buffered to output master clock signal. This new one has 45.1584 and 49.152 MHz oscillators divided by 2 by a flip-flop just because I want ALL the output I2S signals (especially Master clock one) to be in sync with each other. Should I understand that 2x.x freqs are not good for ESS and you want at output the double of it? If not, please tell me what frequencies do you need for ESS to work properly and I'll see what I can do about it!"
For synchronous clocking of the ESS 901x DACs, the masterclock needs to be 45.1584 and 49.152 or higher, for proper operation with 176.4 and 192 sample rates. So the masterclock output on I2S needs to be at least those frequencies. If you provide masterclock output at 45.1584 and 49.152, that will work fine (but not for sample rates above 192 kHz).
Lorien:
"Hi barrows! The first WaveIO board have 22.5792 and 24.576 MHz local clocks buffered to output master clock signal. This new one has 45.1584 and 49.152 MHz oscillators divided by 2 by a flip-flop just because I want ALL the output I2S signals (especially Master clock one) to be in sync with each other. Should I understand that 2x.x freqs are not good for ESS and you want at output the double of it? If not, please tell me what frequencies do you need for ESS to work properly and I'll see what I can do about it!"
For synchronous clocking of the ESS 901x DACs, the masterclock needs to be 45.1584 and 49.152 or higher, for proper operation with 176.4 and 192 sample rates. So the masterclock output on I2S needs to be at least those frequencies. If you provide masterclock output at 45.1584 and 49.152, that will work fine (but not for sample rates above 192 kHz).
Hi Lorien - a couple of questions on the new Windows driver 1.67 -For all those who are using WaveIO with Windows there are new drivers for you available here. I didn't had time to properly test them so any feedback will be appreciated! BTW, Doede you're next
On another hand it seems that 32/384 feature is working beautifully so soon enough I'll start to supply WaveIOs with it enabled by default.
Cheers,
L
- What is new compared with the last version?
- Should one uninstall the existing driver before installing 1.67?
Many thanks
Jonathan
Okay, that should be enough!
I guess 352.8 and 384 requires 90.3168 and 98.304 respectively. So much with the synchronous I2S signals in my apps... Thank you barrows for the info!I'm afraid that it will only complicate things. I am studying the option to have both freqs working but only one available at a time. As barrows said above, synchronizing the I2S signals is no longer an option if I want to address ESS DACs.
It's a new Thesycon release, I guess they have fixed few bugs (among other things) as reading through their 'Revision History' doc. Please see below:
Code:
-----------------------------------------------------
V1.67.0 (April 4, 2013)
-----------------------------------------------------
* Fix: Invalid feedback values can cause BSOD.
Driver now ignores invalid values.
Error statistics added.
* Fix: Problem with optional volume characteristics correction
and audio class requests through API.
* Fix: incorrect AddAndClipInt32bSamples in integer plugin
-----------------------------------------------------
V1.66.0 (March 22, 2013)
-----------------------------------------------------
* New: optional volume value cache in driver implemented
* New: optional volume characteristics correction
-----------------------------------------------------
V1.65.0 (February 6, 2013)
-----------------------------------------------------
* New: Multichannel record through WDM is supported now.
* Chg: MIDI OUT pipe sends 2 and 3 byte events now
as defined by the MIDI spec.
Single Byte event (0xF) is not used anymore.
* Chg: multichannel playback profile in XMOS_EVAL_KITS_PRO
-----------------------------------------------------
V1.64.0 (December 17, 2012)
-----------------------------------------------------
* Internal engineering release.L
I don't think it will be complicated. If you start out with 45.1584/49.152 MHz you can still divide those frequencies by two using a flip-flop. The divided clock can then be used to clock your LRCK, SCLK and DATA as you would normally do (the DATA hopefully in both directions
). All that is needed is that you output these signals + the divide by two MCLK (22.5792/24.576 MHz), and the 45.1584/49.152 MHz clock.The 45.1584/49.152 MHz does not have to switch at exactly the same time as the other signals. It will still be synchronous, just with a small phase shift, which converters normally can handle without problems.
Who knows, maybe there is even a small advantage by shifting the switch point a little, so that the master clock to the converter has its edges at a point in time, where nothing else switches, thereby potentially getting less interference from the other switching signals, leading to less jitter at the converter input. This of course also depends on the PCB layout for the converter and the cables between the converter PCB and the WaveIO.
Seem that your ideas are close to what I thought about... the only difference is that I like to clock all the i2S outputs and input having as a reference the same clock signal: 4x.x one (hoping it will work). That's because dividing 4x.x signals by 2 to get 2x.x and then using it to reclock the I2S will end up in cascading the Flip-Flops. I know that every FF will add its own jitter (regardless on how good is decoupled and powered) so I strongly want to avoid that.
On another hand, phase shifting the signals is very good in minimizing the ground bouncing but, as you said, it all comes down to how good the layout is made (and what type of/how wires are used to connect the board). In my opinion this is still a problem regarding WaveIO's implementation.
Until now, I will buffer the oscillator's 4x.x signal directly to output while use the same oscillator signal to reclock all the remaining I2S data streams. The divider for XMOS it also be done in Hardware just to avoid any nasty things in firmware...
So, one question remains: are these 4x.x oscillators capable to drive five FF gates in parallel (XMOS divider / I2S WDCK / I2S BCLK / I2S DATA IN / I2S DATA OUT) and how good is this approach when it comes to jitter?
On another hand, phase shifting the signals is very good in minimizing the ground bouncing but, as you said, it all comes down to how good the layout is made (and what type of/how wires are used to connect the board). In my opinion this is still a problem regarding WaveIO's implementation.
Until now, I will buffer the oscillator's 4x.x signal directly to output while use the same oscillator signal to reclock all the remaining I2S data streams. The divider for XMOS it also be done in Hardware just to avoid any nasty things in firmware...
So, one question remains: are these 4x.x oscillators capable to drive five FF gates in parallel (XMOS divider / I2S WDCK / I2S BCLK / I2S DATA IN / I2S DATA OUT) and how good is this approach when it comes to jitter?
Last edited:
OK, I got the impression that you planned to use a 2x.x. clock to clock the I2S signals.
For delta-sigma converters I think the only critical clock is normally the MCLK.
For a non oversamling DAC it is probably the I2S BCLK, which is critical, but I am not an expert in this kind of DAC.
Maybe a suitable buffer scheme should be used, letting one buffer drive a number of uncritial flip-flops (for less critical signals) or perhaps a device with a number of flip-flops in one package, but only one clock input to drive? And then the crystal oscillator (or multiplexer?) could drive the critical flip-flops directly.
For delta-sigma converters I think the only critical clock is normally the MCLK.
For a non oversamling DAC it is probably the I2S BCLK, which is critical, but I am not an expert in this kind of DAC.
Maybe a suitable buffer scheme should be used, letting one buffer drive a number of uncritial flip-flops (for less critical signals) or perhaps a device with a number of flip-flops in one package, but only one clock input to drive? And then the crystal oscillator (or multiplexer?) could drive the critical flip-flops directly.
@ JensH: All have to be synchronously here yes? ... otherwise with two clock domains it will be a mess! So, the answer is affirmative: I have routed the clock from oscillators back to XMOS chip by means of a AC-coupled LVDS path. You can see the LVDS TX and RX chips right under the isolator itself: just look at the bottom side of the card - in upper-left corner :U15 and U16 (ICs have the same footprint).
All have to be synchronously here yes? ... otherwise with two clock domains it will be a mess! So, the answer is affirmative: I have routed the clock from oscillators back to XMOS chip by means of a AC-coupled LVDS path. You can see the LVDS TX and RX chips right under the isolator itself: just look at the bottom side of the card - in upper-left corner :U15 and U16 (ICs have the same footprint).@ Lorien
OK, I see it now. I did wonder if U15 could have something to do with it, but I had not guessed the connection to U16.
Why do you use AC coupled LVDS and not the same kind of digital isolator as the ones used for the other signals?
Is it robust against common mode noise like mains hum, ESD and RF radiation?
OK, I see it now. I did wonder if U15 could have something to do with it, but I had not guessed the connection to U16.
Why do you use AC coupled LVDS and not the same kind of digital isolator as the ones used for the other signals?
Is it robust against common mode noise like mains hum, ESD and RF radiation?
I assume that the two sides of the LVDS have each their own ground. Otherwise it wouldn't really make sense anyway
But will the generally good properties of the LVDS connection still be there?
I assumed that the clock for the XMOS was not terribly sensitive to jitter and duty cycle etc., but perhaps I am wrong?
But will the generally good properties of the LVDS connection still be there?
I assumed that the clock for the XMOS was not terribly sensitive to jitter and duty cycle etc., but perhaps I am wrong?