Sorry I didn't point it out more clearly but my thinking on suggesting 22.x/24MHz was 'enough' is only that if you test at 44.1/48kHz you're still at 256*Fs which meets the datasheet requirement. This isn't fast enough to do anything interesting with OSF-bypass though.
I had missed noticing that the greater than didn't come with an equals sign, so good call there too qusp!
I have certainly clarified a lot of my understanding on these MCK issues from this discussion, thanks guys.
The one thing that I take away from all of this is that the source should provide the fastest and cleanest possible MCK, to let us consume media with higher Fs than redbook cd. The rest of what we have discussed is in the DAC implementation from what I can see.
From Lucian's perspective these clocks would be only for this new breed of DAC and he would still need to maintain his existing oscillator frequencies for DACs that are unable to perform at these clock frequencies.
I had missed noticing that the greater than didn't come with an equals sign, so good call there too qusp!
I have certainly clarified a lot of my understanding on these MCK issues from this discussion, thanks guys.
The one thing that I take away from all of this is that the source should provide the fastest and cleanest possible MCK, to let us consume media with higher Fs than redbook cd. The rest of what we have discussed is in the DAC implementation from what I can see.
From Lucian's perspective these clocks would be only for this new breed of DAC and he would still need to maintain his existing oscillator frequencies for DACs that are unable to perform at these clock frequencies.
Last edited:
I also have a suspicion that what we're saying here also calls for MCK to be 256*Fs, 512*Fs or 1024*Fs; ie log2(multiplier) should produce an integer result. That is perhaps going to come into the mix when deciding what the MCK that the source might need to provide.
In the end my preferred solution will probably involve the Si570 like qusp has said.
In the end my preferred solution will probably involve the Si570 like qusp has said.
qusp:
Yes, "effectively disabled", because they do nothing when the master clock and bit clcok are synchronous. To me, doing absolutely nothing, is the same as being turned off.
Yes, I have no difficulties playing at rates up to 24/192 with the DPLL on the B-III set to the most narrow setting with synchronous clocking. With the same USB interface, and the 80 MHz masterclock running the chip asynchronously, the DPLL bandwidth had to be opened up to play any high res stuff. And yes, the "best" (default) setting is actually "auto" where the ESS 9018 itself tries to automatically choose an optimum DPLL setting-this is confirmed in the Buffalo III integration manual.
Once again, as far as I can tell, synchronous clocking has entirely different clock requirements than running the ESS 9018 in normal (async) fashion. Like I said, mine works perfectly when running synchronously, providing the masterclock from my (XMOS) USB interface, at rates up to 24/192, with masterclock frequencies of 22.579 and 24.576. I have never, not even once, had a single click or pop playing 24/176.04 and 24/192 files.
I do suspect that I would get better sound with 45.158/49.152 oscillators for 24/176.4 and 24/192 files though (only because ESS says so, I suspect the filters are not running optimally). And, as mentioned, Russ White, who checks with Dustin from ESS, is planning on using 90.316/98.304 oscillators for his forthcoming USB interface in order to provide best possible performance for sample rates up to 384.
Yes, "effectively disabled", because they do nothing when the master clock and bit clcok are synchronous. To me, doing absolutely nothing, is the same as being turned off.
Yes, I have no difficulties playing at rates up to 24/192 with the DPLL on the B-III set to the most narrow setting with synchronous clocking. With the same USB interface, and the 80 MHz masterclock running the chip asynchronously, the DPLL bandwidth had to be opened up to play any high res stuff. And yes, the "best" (default) setting is actually "auto" where the ESS 9018 itself tries to automatically choose an optimum DPLL setting-this is confirmed in the Buffalo III integration manual.
Once again, as far as I can tell, synchronous clocking has entirely different clock requirements than running the ESS 9018 in normal (async) fashion. Like I said, mine works perfectly when running synchronously, providing the masterclock from my (XMOS) USB interface, at rates up to 24/192, with masterclock frequencies of 22.579 and 24.576. I have never, not even once, had a single click or pop playing 24/176.04 and 24/192 files.
I do suspect that I would get better sound with 45.158/49.152 oscillators for 24/176.4 and 24/192 files though (only because ESS says so, I suspect the filters are not running optimally). And, as mentioned, Russ White, who checks with Dustin from ESS, is planning on using 90.316/98.304 oscillators for his forthcoming USB interface in order to provide best possible performance for sample rates up to 384.
In my case, I only use ES9018 under a synchronous master clocking scheme.
My main transport, SDTrans384, outputs MCLK of both 22.5792/24.576 MHz and 90.3168/98.304MHz.
When I connect other transports for evaluation, I insert an automatic MCLK multiplier provided by Mr. Fujisawa.
http://easyaudiokit.hobby-web.net/bekkan/manual/DAC9018S_ADDON.pdf
(in Japanese)
His sub-board can convert 11.2896/12.288/22.5792/24.576 MHz to 90.3168/98.304 MHz automatically. The multiplier board has ICS570 chip( not Si570) and PIC. Its domestic price is 2,900 JPY.
The merit of synchronous master clocking is SQ.
If you require a play of DXD 352.8 kHz/ 24 bit with OSF = ON, you need MCLK higher than 90.3168 MHz. For a DSD256, you need MCLK higher than 45.1584 MHz. If you only play <= 192 kHz and allow OSF=OFF, 22.5792/24.576 MHz is enough. For 44.1 kHz, OSF = OFF, 11.2896 MHz is enough.
Bunpei
My main transport, SDTrans384, outputs MCLK of both 22.5792/24.576 MHz and 90.3168/98.304MHz.
When I connect other transports for evaluation, I insert an automatic MCLK multiplier provided by Mr. Fujisawa.
http://easyaudiokit.hobby-web.net/bekkan/manual/DAC9018S_ADDON.pdf
(in Japanese)
His sub-board can convert 11.2896/12.288/22.5792/24.576 MHz to 90.3168/98.304 MHz automatically. The multiplier board has ICS570 chip( not Si570) and PIC. Its domestic price is 2,900 JPY.
The merit of synchronous master clocking is SQ.
If you require a play of DXD 352.8 kHz/ 24 bit with OSF = ON, you need MCLK higher than 90.3168 MHz. For a DSD256, you need MCLK higher than 45.1584 MHz. If you only play <= 192 kHz and allow OSF=OFF, 22.5792/24.576 MHz is enough. For 44.1 kHz, OSF = OFF, 11.2896 MHz is enough.
Bunpei
I'm sorry. I made two mistakes. I need to correct them.
If you only play <= 384 kHz and allow OSF=OFF, 22.5792/24.576 MHz is enough. For 44.1 kHz only, 11.2896 MHz is enough.
If you only play <= 384 kHz and allow OSF=OFF, 22.5792/24.576 MHz is enough. For 44.1 kHz only, 11.2896 MHz is enough.
.. that's enough for me either so I'll go with Crysteks for now as I2C communication will complicate things in such a way that I would better avoid.
One small update to this list:
1. hirez69
2. analog_sa
3. m.massimo
4. ozlegend
5. luisbock
6. vitalica
7. palmito
8. gabanyayaya
9. danny_66
10. shoom
11. kp93300
12. lindamar
13. merlin el mago
14. Reo
15. arkadiush1
16. jmltinc
17. zibra
Best wishes,
L
Last edited:
Lorien
May be I too simplified my question and get equivalent answer. Sorry.
Let me clear it up: what I need is I2S bus with MCLK 192fs, that makes 36.864MHz for 48/96/192kHz thread and 33.8688MHz for 44.1/88.2/176.4 thread. As far as I understand, it can be made with 36.864MHz and 33.8688MHz generators instead of 24.576MHz/22.5792Mhz used in Your board. Is such replacement possible theoretically? Can XMOS chip work with such frequencies? And if it can be possible theoretically, can it be made practically?
I guess it could be made but I must change the code for it and I do not have any generators with such freq around to hear WaveIO singing as it should. You could start by buying a stock WaveIO and we will play with it later by using DFU and upload a new firmware with it. I guess the best proof would be to hear it working in your setup. If it doesn't then a refund could be taken into account. We can continue this discussion over PMs.
Cheers,
L
Last edited:
Lucian, great news !!
I have just received the board (you already know that) and .... tested with my IPad, and the result is .... pure gorgeous liquid music !!. It works great
It is an outstanding accomplishment given the fact you actually don´t have an Ipad to test it
Thank again for modifying the firmware and providing this option within the WaveIO card.
Cheers and thank you again for you effort,
Pepe
I have just received the board (you already know that) and .... tested with my IPad, and the result is .... pure gorgeous liquid music !!. It works great
It is an outstanding accomplishment given the fact you actually don´t have an Ipad to test it
Thank again for modifying the firmware and providing this option within the WaveIO card.
Cheers and thank you again for you effort,
Pepe
That was the point: to workLucian, great news !!
I have just received the board (you already know that) and .... tested with my IPad, and the result is .... pure gorgeous liquid music !!. It works great
It is an outstanding accomplishment given the fact you actually don´t have an Ipad to test it
Thank again for modifying the firmware and providing this option within the WaveIO card.
Cheers and thank you again for you effort,
Pepe
If you have some spare time please let us know what type of player are you using and with what settings. Maybe soon I'll have one iPad to play with for a short while (not mine) and want to take full advantage while I am with it. Thank you!I didn't searched yet but I have a strong will to try this option so if you have knowledge from where could I buy such generators/oscillators it would be a big help for me.
Kind regards,
L
sos
https://www.sellarz.co.kr:127/shopping/shopping-detail.php?pi=1856
im trying to use this tda1543 board with the direct out of waveio with no success. ive connected data, lrck, bclk accordingly and left mclk untouched. the grounds of the tda1543 goes to usb ground on waveio. and... there is no sound! help....
https://www.sellarz.co.kr:127/shopping/shopping-detail.php?pi=1856
im trying to use this tda1543 board with the direct out of waveio with no success. ive connected data, lrck, bclk accordingly and left mclk untouched. the grounds of the tda1543 goes to usb ground on waveio. and... there is no sound!
help....Hi Lorien,
My other friend wants a daughter board also. This is 2 boards for me then.
Any more details about the integration between the wave io and the duaghter board? We expect lower jitter ? Better ground isolation ? More music details ?
Another power supply needed. ? etc
thanks
kp93300
Can anyone please measure current for WaveIO board with NDK oscillators?
In first posts Lorien wrote current for board with FOX oscillators which consume much more power right?
I measured current connecting WaveIO to 4.5V battery and it shows 250mA. My friend measured it with hi-res files and it was up max. to 320mA.
It could be helpful information for setting up Salas shunt to work with WaveIO for example.
Jakub
In first posts Lorien wrote current for board with FOX oscillators which consume much more power right?
I measured current connecting WaveIO to 4.5V battery and it shows 250mA. My friend measured it with hi-res files and it was up max. to 320mA.
It could be helpful information for setting up Salas shunt to work with WaveIO for example.
Jakub
Hi Zibra
Yes Merlin that’s my take also.
I have my Salas BJT set up for a CCS of 670MA which seems to work well. From what I’ve read the Salas likes plenty on the CCS so just use a nice big heat sink.
I have my board and heat sink as follows
Franz Gysi style Salas
http://www.diyaudio.com/forums/power-supplies/192625-sslv1-1-builds-fairytales-10.html
Runs just warm and sounds sublime.
I used a linear reg previously and swapping in the Salas made a noticeable difference to the SQ
.I’ve had my WAVEIO for just over a year now and I’m still loving it.
I’m using my board with TP LVDS sender and receiver and that works very well indeed. Looking forward to WAVEIO’s Daughter.
Great work Lucien