Topic sorta reminds me of: https://www.diyaudio.com/forums/digital-line-level/314935-es9038q2m-board-556.html#post6196234
Hi John,
In absolute terms, it would indeed be nice to compare a fine tuned AKM 2/3 chips solution, a fine tuned all in one AKM 4499 solution and your discrete solution (is that R2R or else?). R2R always intringuing...
Just to find out what is feasible today and how much improvement there is (or not) between these very different solutions on real life formats (CD and reasonably available higher rez)... and perhaps also with a good 1000$ commercial DAC, to evaluate gaps and VFM in real life.
Let's see if AKM is keen on that...
Claude
In absolute terms, it would indeed be nice to compare a fine tuned AKM 2/3 chips solution, a fine tuned all in one AKM 4499 solution and your discrete solution (is that R2R or else?). R2R always intringuing...
Just to find out what is feasible today and how much improvement there is (or not) between these very different solutions on real life formats (CD and reasonably available higher rez)... and perhaps also with a good 1000$ commercial DAC, to evaluate gaps and VFM in real life.
Let's see if AKM is keen on that...
Claude
I'll take your word over what the schematics posted there show (looks like some errors in them, and legibility of text is not very good).
Don't want to argue about it, we have too much of that around the forum already.
Bottom line for me is that I like AK4499 a lot, but don't know exactly how good it can sound at best. Still working on trying to find out, but taking my time doing it. Another experiment is in the works only this time I have learn Circuit Studio first. Something to do while home bound I guess
indeed, it is sometimes hard to read schematics and the text, especially if it is originally in Russian
ok, if we still continue to hijack this thread for AK4499 purpose, then one can take a look, how VDD supply is designed in AKM 4499 evalboard and how it is in Andrews AK4493 project ...
Attachments
Its funny, I have tried a few other regulators instead of the eval board NJM7805 regulators, and the eval board 7805s always sound best so far. However, they run off pre-regulated +15v so the power coming into them is has already been regulated once. Almost all other loads have been removed from my eval board's +15v rail, mostly it is just a pre-regulator for the NJM7805s. As I have said elsewhere, some years ago a couple of guys with good ears did a listening test of all 78xx regulator brands and found there were differences in sound quality. They rated NJM78xx the best sounding. So, I don't know. It works, what else can I say.
JohnW,
Regarding XMOS programming, so far no one with the know-how has volunteered. I still feel that in the absence of an XMOS programmer, an external USB to I2S board should be workable. I have been using JL Sounds I2SoverUSb: I2SoverUSB - I2S over USB Audio
...which optionally works fine with external 45/49MHz clocks. It is limited to stereo rather than 4-channel operation, but that's probably okay to start with, at least it seems so to me.
Regarding XMOS programming, so far no one with the know-how has volunteered. I still feel that in the absence of an XMOS programmer, an external USB to I2S board should be workable. I have been using JL Sounds I2SoverUSb: I2SoverUSB - I2S over USB Audio
...which optionally works fine with external 45/49MHz clocks. It is limited to stereo rather than 4-channel operation, but that's probably okay to start with, at least it seems so to me.
I attached the simulation schematic, open loop gain / phase and Zout plots here.
We plan to feed the OPA1611 from an LT3042 running at 15V output.
Attachments
Really depends on what you want to do with the XMOS. If a simple USB->I2S conversion is the goal you can quite easily adapt the samples supplied by XMOS to your needs. Although documentation is pretty minimal to say it politely. I managed to adapt the 8 channel example to provide 12 channels in a few hours. That the IDE is based on eclipse and is not very user friendly didn't help there
If you want to leverage the full potential of this chip you certainly will have to learn a completely new programming language (XC: XC (programming language) - Wikipedia), their C-variant for the parallel execution features of the Xcore architecture.
One thing that would bother me significantly though is that you're not allowed to publish source code you developed as the example and lib stuff must not be redistributed in source form. Not very helpful for a communitiy project.
Ah, a volunteer? One thing I would like to know is whether or not XMOS can work with 22/24MHz audio clocks, and if so what limitations would there be on maximum audio sample rates for PCM and native DSD? Also, is anything special necessary for ASIO compatibility?
it is hard to guess what's up not knowing what those few other regulators were. anyway, if one leaves everything solely to listening tests, then there is no way to find out what possibly may go technically wrong. methodologically this is nonsense of course, but we are not upon any kind of scrutiny here. If onboard regs sound best, then there is no need to look further of course.
Yes, it can, PCM 384, native DSD256. Diyinhk sells a board with those clock frequencies and claim it works with ASIO drivers and Foobar but I don't use Windows so can't confirm.
XMOS had an issue with DSD256, but they fixed it. Actually, their reference software is still the old one, but audio.xc file is slightly modified, so everything works right, including DSD512 (45MHz clock) and probably above, but I don't have a DAC to test it.
There is a problem with Windows ASIO driver, since the free stereo driver doesn't support DSD native and more than that, you cannot buy Thesycon driver as an end user. As I see, Thesycon are developing their own USB high-end audio firmware called U-HEAR.
There is a problem with Windows ASIO driver, since the free stereo driver doesn't support DSD native and more than that, you cannot buy Thesycon driver as an end user. As I see, Thesycon are developing their own USB high-end audio firmware called U-HEAR.
Using an XMOS chip sounds like it is not practical for a few hobby boards for multiple reasons, unless perhaps John has some idea or understanding we haven't thought about yet.
If it is not impractical then I still think an off the shelf USB board like I2SoverUSB should be workable. The question of clock frequencies comes up, and probably a few other odds and ends, but I think those things are all probably manageable.
By way of comparison, what Topping did with D90 was use 45/49MHz clocks and divided them in half for most AK4499 sample rates. In that case, the undivided clocks are compatible with XMOS and DSD512.
If it is not impractical then I still think an off the shelf USB board like I2SoverUSB should be workable. The question of clock frequencies comes up, and probably a few other odds and ends, but I think those things are all probably manageable.
By way of comparison, what Topping did with D90 was use 45/49MHz clocks and divided them in half for most AK4499 sample rates. In that case, the undivided clocks are compatible with XMOS and DSD512.
Mark, there is no practical usb->i2s solution for a few hobby boards, actually there are not so many solutions at all, but as I have found so far, XMOS is the most practical off them.
I don't want to talk about Windows ASIO driver, since for hi-q audio playback, an audiophile Linux distro is a must, but if you really want, for non-comercial uses and testing purposes, you can use such a Windows driver.
Speaking about I2SoverUSB, my concerns are related to CPLD. At first, I wondered why they took over Amanero's weakest point, but looking closely to the users opinion, I have been understanding why: marketing. Yes, using CPLD is an elegant solution to switch between time domains, to divide time, to realign different times (you can name it reclock, but is is not, since it doesn't have a fifo bufer), etc., but it is a false friend: CPLD is not a friend of time at all!
In this area, only 2 things matter: data and time.
Controlling source code gives you a lot of power related to data and precise time management: you can control hardware, you can do a proper PCB routing, you can do a proper ground management, you can control playback using HID, you can make a real reclock using a small buffer (it is not need for a huge fifo buffer here, since a small buffer can tell: foobar, I am 80 percent full, slow down!), etc.
My opinion is that: if you want to design a good DAC (or anything else), you have to start with its source.
I don't want to talk about Windows ASIO driver, since for hi-q audio playback, an audiophile Linux distro is a must, but if you really want, for non-comercial uses and testing purposes, you can use such a Windows driver.
Speaking about I2SoverUSB, my concerns are related to CPLD. At first, I wondered why they took over Amanero's weakest point, but looking closely to the users opinion, I have been understanding why: marketing. Yes, using CPLD is an elegant solution to switch between time domains, to divide time, to realign different times (you can name it reclock, but is is not, since it doesn't have a fifo bufer), etc., but it is a false friend: CPLD is not a friend of time at all!
In this area, only 2 things matter: data and time.
Controlling source code gives you a lot of power related to data and precise time management: you can control hardware, you can do a proper PCB routing, you can do a proper ground management, you can control playback using HID, you can make a real reclock using a small buffer (it is not need for a huge fifo buffer here, since a small buffer can tell: foobar, I am 80 percent full, slow down!), etc.
My opinion is that: if you want to design a good DAC (or anything else), you have to start with its source.
Thorp, Don't know if you have examined I2SoverUSB closely. It has a clean power and dirty power ground plane partitions on the PCB. The clean side (dac side) is where the clocks are and the only big chip on that side is an FPGA. Jittery I2S comes from the dirty side to the clean side through an isolator and is reclocked in the FPGA. Not perfect, but careful FPGA internal routing can make a big difference in performance. 45/49MHz NDK SDA clocks are also divided by 2 in the FPGA if needed by a dac. The unit's operating mode is programmed by pin header jumpers and zero-ohm resistors soldered on the back side. All in all, its the best sounding USB board I have heard, and it supports external 45/49MHz clocks if such is desired.
Other than that, Windows (not linux) is used for many professional DAWs, its just a matter of using ASIO drivers and knowing how to configure Windows.
One reason for not using a custom XMOS solution for a few hobby dacs is the cost of getting unique USB identifier. USB is not an open standard, IIRC it costs a few thousand dollars to get a legal USB ID.
Other than that, Windows (not linux) is used for many professional DAWs, its just a matter of using ASIO drivers and knowing how to configure Windows.
One reason for not using a custom XMOS solution for a few hobby dacs is the cost of getting unique USB identifier. USB is not an open standard, IIRC it costs a few thousand dollars to get a legal USB ID.
Last edited:
Mark, I only read about it here first, and they say that "Galvanic isolation (outputs, two oscillators and reclock, done by Xilinx CPLD are after the isolator)".
I know about isolation and I totally agree about what they made for reducing noise, but my previous post was mostly about time.
If this solution is suitable for your goal and you have trust in it, than use it. It will be a big advantage here, since all your efforts are focused on the DAC side.
Please note that all I said and all I will say are only my opinion, or my concerns, etc. and they might be wrong.
I know about isolation and I totally agree about what they made for reducing noise, but my previous post was mostly about time.
If this solution is suitable for your goal and you have trust in it, than use it. It will be a big advantage here, since all your efforts are focused on the DAC side.
Please note that all I said and all I will say are only my opinion, or my concerns, etc. and they might be wrong.
Thorp, Sorry, my bad. Just looked up the Xilinx part number on the chip (XC2C32A) and it is in fact a CPLD: https://www.xilinx.com/support/documentation/data_sheets/ds310.pdf
They say it can be configured to have D-Flip Flop functionality, which as we know is used for reclocking/relatching.
However it is programmed, still think I2SoverUSB is the best sounding USB board in stock form.
As stated before, it can be externally clocked, and also its I2S outputs could always be reclocked/relatched after leaving the board if lower I2S jitter is desired for use in a higher performance dac.
I don't see any issues that can't be dealt with, but then again, it can get to be about as complex as using Amanero to best effect.
They say it can be configured to have D-Flip Flop functionality, which as we know is used for reclocking/relatching.
However it is programmed, still think I2SoverUSB is the best sounding USB board in stock form.
As stated before, it can be externally clocked, and also its I2S outputs could always be reclocked/relatched after leaving the board if lower I2S jitter is desired for use in a higher performance dac.
I don't see any issues that can't be dealt with, but then again, it can get to be about as complex as using Amanero to best effect.
Last edited:
sure if PLL used, but CPLD/FPGA derived clocks are used in some fine designs, including DACs. on rubiola.org one can find some measurements on this matter.
yes, Amanero is not the best transport but on one can run it as isolated slave (both onboard clocks better removed then).
And it can be programmed to send I2C data, what is pretty handy to initiate and steer the DAC.
Last edited:
eziitis, of course CPLD/FPGA are used in many fine designs, actually this is the purpose for which they were designed.
But if you want to get the last drop of precision out of your design, they may not be the best solution. Think at CPLD and FPGA as a highly configurable circuits. Do you really want those hundreds/thousands devices/routes in your design?
Amanero is one of the best transport, IMHO. And yes, it takes advantage of the main CPLD purpose: with a simple CPLD reconfiguration, we can use other clocks, outside the Amanero board. In this case, CPLD is a very handy and elegant solution.
Let's say that I have decided to use external clocks only, for my specific project, and I don't need on board oscillators anymore, so other say, I don't need this beautiful CPLD functions called "reconfiguration", "divider", "oscillator switcher", etc. What if I will replace it (CPLD) with a better specs devices (flip-flops)? Why should I use a generic purpose, highly configurable device, instead of using a dedicated and fine tuned for a specific task device?
But if you want to get the last drop of precision out of your design, they may not be the best solution. Think at CPLD and FPGA as a highly configurable circuits. Do you really want those hundreds/thousands devices/routes in your design?
Amanero is one of the best transport, IMHO. And yes, it takes advantage of the main CPLD purpose: with a simple CPLD reconfiguration, we can use other clocks, outside the Amanero board. In this case, CPLD is a very handy and elegant solution.
Let's say that I have decided to use external clocks only, for my specific project, and I don't need on board oscillators anymore, so other say, I don't need this beautiful CPLD functions called "reconfiguration", "divider", "oscillator switcher", etc. What if I will replace it (CPLD) with a better specs devices (flip-flops)? Why should I use a generic purpose, highly configurable device, instead of using a dedicated and fine tuned for a specific task device?
