Yes, there are two fully separated ground regions otherwise it would make no sense for me eitherI assume that the two sides of the LVDS have each their own ground. Otherwise it wouldn't really make sense anyway
At some point it does not really matter anymore as there's the reclocking stage after the XMOS processor. Even so, when it comes to jitter LVDS is my preferred choice and I thought that, if I can, it would be better to try and improve all the clock chains, including this XMOS feeding one.
Kind regards,
L
In my work I am often invelved in trying to identify problems at an early stage so that they can be corrected before the consequences become too big. But perhaps I am just seeing ghosts here, and there are no problems.
You could of course also consider a backup solution, e.g. a TI ISO7220M or similar. With this one there would also be a return path for the input data channel
You could of course also consider a backup solution, e.g. a TI ISO7220M or similar. With this one there would also be a return path for the input data channel
I simply squeezed my brain to find a viable solution here so far this is the best I can think of. I am aware about the fact that there are isolators with four channels (3 + 1) still when you have four signals following the same path (I2S bit Clock / I2S Word Clock / I2S Data / Oscillator Select) and the XMOS clock needed to follow the opposite path then the four way isolator is simply not enough
Five channels or more is too expensive in this case.
As for ISO7220M, it is already taken into account, thank you for the tip
Cheers,
L
Edit:
Five channels or more is too expensive in this case.
As for ISO7220M, it is already taken into account, thank you for the tip
Cheers,
L
Edit:
Hmm, hard to believe! I simply wish to be this way.., but these days I'll find out what I've done
Last edited:
ESS clock rates follow up
Lorien,
To follow up on the clock rates discussion for best compatibility with synchronous operation of ESS based DACs, found the relevant information. The ESS needs masterclock at >192 Fs and synchronous/in phase with bit clock. So for proper performance with ESS based DACs you would want to provide 45.1584 and 49.152 masterclock frequencies for playback of 24/176.4 and 24/192 files.
No need to respond to this, I just wanted to get you the information.
Lorien,
To follow up on the clock rates discussion for best compatibility with synchronous operation of ESS based DACs, found the relevant information. The ESS needs masterclock at >192 Fs and synchronous/in phase with bit clock. So for proper performance with ESS based DACs you would want to provide 45.1584 and 49.152 masterclock frequencies for playback of 24/176.4 and 24/192 files.
No need to respond to this, I just wanted to get you the information.
my...
understanding is that to take advantage of synchronous clocking on the ESS, the Master Clock and the Bit Clock must be in phase. The point is to keep the ASRC/DPLL from being active-my opinion is that it sounds better this way (assuming a very low jitter source). But this should be the case anyway if the output data (I2S) is re-clocked by the MC just before output as Lorien is saying, right? Or am I misunderstanding something?
understanding is that to take advantage of synchronous clocking on the ESS, the Master Clock and the Bit Clock must be in phase. The point is to keep the ASRC/DPLL from being active-my opinion is that it sounds better this way (assuming a very low jitter source). But this should be the case anyway if the output data (I2S) is re-clocked by the MC just before output as Lorien is saying, right? Or am I misunderstanding something?
Usually there will be a spec for timing between the master clock edge that matters and the bit clock edge that matters. It will be tight since the clock has a 20 nS period so gate delays etc. will be critical. There may also be registers in the chip where you can lock the mode of operation. Finding those registers will be a challenge if they aren't in the datasheet.
Thank you Barrows! Your help is highly appreciated!
I thought at that too but I'm still not convinced about the synchronicity of those signals.
Well, reclocking is the main idea and I had do it as the XMOS is a mess.
Even so, I liked to have the Master clock in sync but this means to divide it by 2. Anyway, the downside is that NDK oscillator family that I'm using now (NZ2520SD) are not able to source clocks higher than 60 MHz so 90s freqs. are out of the question. Given this, I somehow have to manage all this by using the 45.1584 and 49.152 masterclock freqs. One solution would be to buffer the master clock and make sure that the buffer delay will be close to the FF delay (but I already know that it's hard to achieve...) I am fully agree with you but beating the ESS DACs to death could be fun for most of us and lead to redesigning the entire chip if needed
Anyway, I am simply relying on the ESS designer's work here hoping that they knew what they were doing in that chip.Huh, inverted MCLK now...
I have to start looking for an inverter and a buffer in the same package just to be able to switch the chips in case that needed.
Thank you,
L
Unfortunately the phase relationships between the master clock and the other clocks are not specified in the data sheet. But since it is claimed that it works, even with a master clock, which is not synchronized at all with the other clocks, I would also assume that the phase of a synchronized clock is not critical. There should be plenty of possibilities to reclock the slower signals internally to also avoid the risk of metastability.
For other DAC's it is clearly specified. Here are a couple of examples:
CS4398:
MCLK can be at any phase in regards to LRCK and SCLK. SCLK, LRCK and SDATA must meet the phase and timing relationships outlined in Section 2.
PCM1794A:
The PCM1794A requires the synchronization of LRCK and the system clock, but does not need a specific phase relation between LRCK and the system clock.
For other DAC's it is clearly specified. Here are a couple of examples:
CS4398:
MCLK can be at any phase in regards to LRCK and SCLK. SCLK, LRCK and SDATA must meet the phase and timing relationships outlined in Section 2.
PCM1794A:
The PCM1794A requires the synchronization of LRCK and the system clock, but does not need a specific phase relation between LRCK and the system clock.
Arduino lcd for WaveIO
I implemented the lcd display idea of Doede posted in this thread some days ago (and fully described on his website DDDAC site) based on Arduino Uno and 16*2 lcd.
It's easy to build, affordable and customizable. You can show any message you want, provided a very basic knowledge of programming code.
I was comfortable with leds, but this is really fine.
If anyone is interested in building it and need some help or advice, feel free to ask.
Thank to Doede for the input.
I implemented the lcd display idea of Doede posted in this thread some days ago (and fully described on his website DDDAC site) based on Arduino Uno and 16*2 lcd.
It's easy to build, affordable and customizable. You can show any message you want, provided a very basic knowledge of programming code.
I was comfortable with leds, but this is really fine.
If anyone is interested in building it and need some help or advice, feel free to ask.
Thank to Doede for the input.
Attachments
qusp...
Thanks for that info. You can confirm that the masterclcok needs to be exactly 180 degrees to bit clock for synchronous clocking of the ESS 9018?
I know the ESS DAC will work with masterclock not synched to bit clock, but my understanding is that doing this will allow the ASRC and DPLL to become active-the entire reason I, and others, want to synchronously clock the ESS is that we want to make the ASRC and DPLL idle, because we do not want the DAC to re-sample the data asynchronously. Using an out of sync MC would defeat the purpose of synchronous clocking as I understand it-If one is OK with the ESS' onboard ASRC being active, then one can just go ahead and provide an independent 80 MHz-100 MHz masterclock for all sample rates and be done with it, but my experience is that synchronous clocking sounds better given a low jitter source.
Is Dustin (ESS designer team member) still active here? Lucien, you could try sending Dustin an inquiry via PM here.
Thanks for that info. You can confirm that the masterclcok needs to be exactly 180 degrees to bit clock for synchronous clocking of the ESS 9018?
I know the ESS DAC will work with masterclock not synched to bit clock, but my understanding is that doing this will allow the ASRC and DPLL to become active-the entire reason I, and others, want to synchronously clock the ESS is that we want to make the ASRC and DPLL idle, because we do not want the DAC to re-sample the data asynchronously. Using an out of sync MC would defeat the purpose of synchronous clocking as I understand it-If one is OK with the ESS' onboard ASRC being active, then one can just go ahead and provide an independent 80 MHz-100 MHz masterclock for all sample rates and be done with it, but my experience is that synchronous clocking sounds better given a low jitter source.
Is Dustin (ESS designer team member) still active here? Lucien, you could try sending Dustin an inquiry via PM here.
I am currently building an active crossover setup with the miniDSP mini sharc and need to fix the sample rate to the 48Khz i2s input of that board. Is there a way of forcing the waveio to output a fixed sample rate or is it always going to pass the sample rate of the file it is given?
Thanks
Thanks
Lucien, update
I have heard from two reliable sources now, that for synchronous clocking of the ESS 9018, the master clock and bit clock need to be synchronous, but that inverted phase as mentioned above is not necessary. I consider these sources trustworthy (one is a manufacturer who makes ESS based DACs, and produces their own USB interface). Apparently Dustin from ESS has mentioned that there may be a performance advantage to having the rising edge of the master clock signal aligned with the falling edge of the bit clock signal; but no one appears to have observed any actual advantage from doing so.
I have heard from two reliable sources now, that for synchronous clocking of the ESS 9018, the master clock and bit clock need to be synchronous, but that inverted phase as mentioned above is not necessary. I consider these sources trustworthy (one is a manufacturer who makes ESS based DACs, and produces their own USB interface). Apparently Dustin from ESS has mentioned that there may be a performance advantage to having the rising edge of the master clock signal aligned with the falling edge of the bit clock signal; but no one appears to have observed any actual advantage from doing so.
Well, there was a case when I had to change the base firmware and allow the card to work with 44.1 & 48 Khz sample rates. At that time I forced the WaveIO to report maximum sample rate to be 48 Khz @ USB enumeration. Any higher fs tracks than 48 will force the player to report an error/warning. I guess I could do that for you too.. free of charge, of course
@ barrows: Thank you and thank you! I didn't managed to talk with Dustin but I guess things are quite settled for now... I'll see what path do I have at disposal to implement all the MC/I2S clock requirements.
Thank you again,
Lucian
Last edited:
Hi Lucian, That could work but the sample rate need to be fixed rather than allowing anything bellow (x)Hz through.
I guess there is no way of Implementing ASRC code with the waveio. I ask as there does seem to be some XMOS implementations out there specifically working as an ASRC.
Cheers
Stefan
Lorien.
I know you're busy with squeezing the last 0,2% of quality out of your product.
I'm wondering if you finally considered to go multichannel I2S or SPDIF?
Multichannel SPDIF in particular. There is no such interface in the market.
The USB Streamer from MiniDSP comes with 8 channel I2S. But that would require an I2S to SPDIF interface to be build. And I'm wondering how that USB streamer would compare in quality to your interface.
Many people could replace stuff like Behringers, MiniDsp Nano Digi asf. and use existing DACs, full digital amps etc. and use the PC as DSP which much higher flexibility and performance then MiniDSP products.
Subwoofer integration could easily accomplished. Multichannel and speaker activation would be much easier.
Cheers
I know you're busy with squeezing the last 0,2% of quality out of your product.
I'm wondering if you finally considered to go multichannel I2S or SPDIF?
Multichannel SPDIF in particular. There is no such interface in the market.
The USB Streamer from MiniDSP comes with 8 channel I2S. But that would require an I2S to SPDIF interface to be build. And I'm wondering how that USB streamer would compare in quality to your interface.
Many people could replace stuff like Behringers, MiniDsp Nano Digi asf. and use existing DACs, full digital amps etc. and use the PC as DSP which much higher flexibility and performance then MiniDSP products.
Subwoofer integration could easily accomplished. Multichannel and speaker activation would be much easier.
Cheers
Under Windows it is JRiver. There is a lot going on currently.
Uli Brueggemann with his Acourate filter software is pretty active to get
stuff working on the PC side.
You can also use foobar etc.
I'd use brutefir and MPD on a headless Linux system.
Unfortunately squeezelite doesn't offer a PIPE (stdout) output (yet). Otherwise I could route the traffic from squeezelite right into brutefir on a headless client.
The NANO Digi of MiniDSP, after all, is still a nice and probably the cheapest solution. You can hook it up to basically to any SPDIF output, which would include my SB Touch. But MiniDSP NanoDigi resamples - in most case you'll resampling twice, since your DAC will usually again resample to higher than 96khz. The MiniDSP got limited processing power.
Alternative solutions are Oppo 93 and soon 103 with the 4*SPDIF output extension Vanity 93 of Audiopraise. Here you can go the multichannel HDMI -> SPDIF route.
Or you buy a 1000$ RME HDSPe AES-32 PCIe card.
Cheers
Uli Brueggemann with his Acourate filter software is pretty active to get
stuff working on the PC side.
You can also use foobar etc.
I'd use brutefir and MPD on a headless Linux system.
Unfortunately squeezelite doesn't offer a PIPE (stdout) output (yet). Otherwise I could route the traffic from squeezelite right into brutefir on a headless client.
The NANO Digi of MiniDSP, after all, is still a nice and probably the cheapest solution. You can hook it up to basically to any SPDIF output, which would include my SB Touch. But MiniDSP NanoDigi resamples - in most case you'll resampling twice, since your DAC will usually again resample to higher than 96khz. The MiniDSP got limited processing power.
Alternative solutions are Oppo 93 and soon 103 with the 4*SPDIF output extension Vanity 93 of Audiopraise. Here you can go the multichannel HDMI -> SPDIF route.
Or you buy a 1000$ RME HDSPe AES-32 PCIe card.
Cheers