I've worked with DACs from most (if not all) manufacturers, both directly and indirectly via customers. I have also had contact with DAC designers , but I cannot really discuss this I'm afraid (We have quite a few silicon and hardware designers in house also 😉 )
Edit: I see that you quite significantly modified your last post, I don't have time to re-reply now.
Edit: I see that you quite significantly modified your last post, I don't have time to re-reply now.
Last edited:
Btw its is important to realise we are coming from two separate angles, mine being building complete systems/products from scratch. Yours (I think) being adding external modules to existing DAC products.
Yes, that is probably the most detailed measurement on the "old" chip.
Yet many high end products have used this chip in their USB input implementation.
yes, I prefer to modify or add to one post, rather than making multiple posts, it happened long before you replied. maybe read the post instead of the notification email... your assumption would have been right a year or 2 ago. well not modifying in the way you mean it. i'm using someone elses design at the moment for buffering though that puts out ~1ps at the clock buffer for all of the signals and drives a dual mono ESS synchronously with dual clocks, so.... but most is built from blank PCBs along with a few bits and pieces of my own, only recently have I started on an integrated design of my own though, I admit.
I dont see how having a complete systems approach negates anything I said actually, just reads like an opportunity to beat your chest.
obviously, as I said, you would just do something about it with a clock buffer or logic/flip flops if you were doing a PCB of your own and its even more important to keep in mind that WE ARE TALKING ABOUT A MODULE, 2 modules even, not an integrated device; dont move the goal posts so as to more easily score...
I sure wouldnt leave that amount of jitter on there for the dac to clean up and if you would, regardless of the dac chip, then I will happily let you keep your trade secrets.
perhaps you are XMOS? ive seen them defending this very issue before
I dont see how having a complete systems approach negates anything I said actually, just reads like an opportunity to beat your chest.
obviously, as I said, you would just do something about it with a clock buffer or logic/flip flops if you were doing a PCB of your own and its even more important to keep in mind that WE ARE TALKING ABOUT A MODULE, 2 modules even, not an integrated device; dont move the goal posts so as to more easily score...
I sure wouldnt leave that amount of jitter on there for the dac to clean up and if you would, regardless of the dac chip, then I will happily let you keep your trade secrets.
perhaps you are XMOS? ive seen them defending this very issue before
Last edited:
this and the 'driverless' operation, plus multichannel. its an interesting range of parts, but using them bare, without reclocking at least the last ones, is dubious
to be clear, I would love if they had fixed the issue, the development environment looks very good and they have made a flexible, reasonably powerful set of parts that would require FPGA coding and maybe some glue logic to achieve otherwise. its completely solvable with adding a reclocking stage, sure, but it would be nice if it wasnt that bad to begin with. saying it (the BCK signal) doesnt matter, as is however, is another thing entirely
Last edited:
His affiliation is stated openly on his profile :
Occupation Senior Development Engineer, XMOS Semiconductor Ltd
Mr Owen,
I am very interested to know what improvement new xmos is. Have you done tests on old vs new ? Can you say or is it secret ? What is technical performance benefit of faster USB analogue node clock ? What Mhz speed is best ? Does integrated USB give performance benefit or is it for convenient/cost reasons ?
Thank you.
I am very interested to know what improvement new xmos is. Have you done tests on old vs new ? Can you say or is it secret ? What is technical performance benefit of faster USB analogue node clock ? What Mhz speed is best ? Does integrated USB give performance benefit or is it for convenient/cost reasons ?
Thank you.
Regarding the TDA1541A previously mentioned, please re-read what I wrote.
The TSA1541A does not have separate MCLK and BCLK inputs. In the case of the TAD1541A the bit clock used for audio rendering with no PLL involved, it is the master clock if you like, and therefore should be treated as such. If I was asked to design with this DAC IC (highly unlikely I suppose now...) the clocking methodology would of course allow for this, but this would be a special case. Sometimes these do happen - a recent implementation involving DSD support on a fairly old TI/Burr Brown DAC design did require some thought.
I believe the design of a all-things-to-all-men (or woman, there are a few out there!) module intended to be used with an external DAC product is very different to the design of a constrained system (I am normally involved in the latter). The previous statements seemed to be directed at XMOS implementations in general. That module does have an MCLK out which you are free to use however you see fit.
By the way, I do know know of the module provider, its performance or otherwise, but good luck to the chap 🙂
"Driverless" operation is based on full-speed Audio Class 1.0 operation to remain spec compliant so has its restrictions I'm afraid (stereo up to 96kHz for input OR output, 48kHz for input AND output). Multi-channel is obviously a big area for XMOS, especially recording.
Yes that is my day job, however, I signed up here in a personal capacity - but it is best to be open about who are I believe.
If I can help people with any projects then fantastic 🙂 I didn't really wish to be involved with discussions about clocking, but there seemed to be some confusion regarding the statement in the advert regarding the 48MHz oscillator on this thread, hence my involvement. It is often best to support people in the open, since everyone can benefit (and my email inbox is not as strained!). Im not really interested in "chest-beating" or "scores" I'm afraid.
rsowen said:
The TSA1541A does not have separate MCLK and BCLK inputs. In the case of the TAD1541A the bit clock used for audio rendering with no PLL involved, it is the master clock if you like, and therefore should be treated as such. If I was asked to design with this DAC IC (highly unlikely I suppose now...) the clocking methodology would of course allow for this, but this would be a special case. Sometimes these do happen - a recent implementation involving DSD support on a fairly old TI/Burr Brown DAC design did require some thought.
I believe the design of a all-things-to-all-men (or woman, there are a few out there!) module intended to be used with an external DAC product is very different to the design of a constrained system (I am normally involved in the latter). The previous statements seemed to be directed at XMOS implementations in general. That module does have an MCLK out which you are free to use however you see fit.
By the way, I do know know of the module provider, its performance or otherwise, but good luck to the chap 🙂
I don't believe so, I would say over 95 percent of designs I have been involved with don't use 384kHz. In fact a lot of designs actually restrict the rate of their products to 96kHz...Nanoloop said:
"Driverless" operation is based on full-speed Audio Class 1.0 operation to remain spec compliant so has its restrictions I'm afraid (stereo up to 96kHz for input OR output, 48kHz for input AND output). Multi-channel is obviously a big area for XMOS, especially recording.
abraxalito said:
Yes that is my day job, however, I signed up here in a personal capacity - but it is best to be open about who are I believe.
If I can help people with any projects then fantastic 🙂 I didn't really wish to be involved with discussions about clocking, but there seemed to be some confusion regarding the statement in the advert regarding the 48MHz oscillator on this thread, hence my involvement. It is often best to support people in the open, since everyone can benefit (and my email inbox is not as strained!). Im not really interested in "chest-beating" or "scores" I'm afraid.
The main benefits are integration of the USB phy and power-supplys (from a Bill of Materials point of view). The clock speed shouldn't make any difference, performance should be the same.
Cheers
Ross
No secret! 🙂 - No spidey senses required - It's in my profile (I guess you could google me also...)
Last edited:
Thank you. It is very helpful for you to comment.
So best performance is from best 22M and 24M mclk xo (diyinhk use Fox Xpresso), low noise psu (use LP5900 on usb psu) and good layout ?
Is diyinhk design / layout good ?
Thank you very much ! 🙂
I am very very happy to know rsowen share his professional technical knowledge here!
Fox Xpresso is not the best, but it's the best and only oscillator available in trustable retailer mouser/digikey etc, the very best should be crystek 957, it's usd30 each😱
I am very confident all NDK/KDS or whatever famous brand oscillator in <1k product are all actually shenzhen brand😉
low noise LDO should help, but external power supply should help more.
the layout is following the official datasheet design with some optimization, it's very simple.
The 500Mhz running frequency of all xmos is PLL from the oscillator. It's like compare 48MHz pll to 500MHz or 13MHz pll to 500MHz. Processing power of 500Mhz should be the same, but the clock jitter from the PLL should be lower.
Thank you for all, any improvement idea are welcome!
A cost doesn't matter and more advance PCB includes two crytek957 oscillator and reclocker is developing😀
Yes you are going to want a 22.5892MHz and 24.576MHz oscillators ideally. You can use other multiples, but most designs generally use these.
My understanding of the Fox Xpresso is that they are a crystal will a PLL?
diyinkhk, I guess you added your own 384kHz support? How did you find modifying the code? (I guess you based it from version 6.1?)
Good luck with the new board, let me know if I can be of assistance 🙂
My understanding of the Fox Xpresso is that they are a crystal will a PLL?
diyinkhk, I guess you added your own 384kHz support? How did you find modifying the code? (I guess you based it from version 6.1?)
Good luck with the new board, let me know if I can be of assistance 🙂
22.5792 and 24.576 is not suitable for ES9018 384khz (synchronous) with the oversampling filter on, you need to run sync mode using the clocks on the module with the OSF off, or run asyn mode and dont use the clocks on the xmos board.
figured you would know that... those speeds are only suited to 88.2/96khz if you want the oversampling filter on. which means you would have to have an MCU to set those registers, like arduino or equivalent. OSF is on by default
figured you would know that... those speeds are only suited to 88.2/96khz if you want the oversampling filter on. which means you would have to have an MCU to set those registers, like arduino or equivalent. OSF is on by default
Last edited:
@ rsowen: is XMOS capable of running with 90.316/98.304MHz clocks? does the quality (or even speed) of the audio clocks on the xmos board have any impact on the quality of the i2s output, the internal 500khz PLL upsampling is governed by the 3rd 48MHz clock? or they simply provide a higher quality MCLK output?
diyinhk:
there is no crystek in that speed either unless custom ordered, so no 384khz unless you specify it has to run OSF off, which IMO is not the best trade-off, better off running the 45.158/49.152MHz crystek 957 for 176/192khz with OSF on IMO. Given the lack of much (any really) true native 384khz samplerate audio, it seems preferable to have properly dealt with 192khz than break the bank to get 384 and get lower performance.
500khz goes into either one (12,13, or 48MHz) evenly as a multiple, so surely the jitter from the 500khz set PLL relation to the samplerate/audio clock is where the jitter is coming from, I cant see a 48khz XO making any meaningful difference
the NDK sideswipe at another competing XMOS board was 'stylish'... but true to your previous form. obviously you arent aware that NDK are a huge clock manufacturer, they make all sorts of clocks, some for only a few dollars. adding reclocking, perhaps isolation and higher spec clocks is just playing catchup for that device that has been around for years.
will you provide some meaningful close in phase noise plots of such a board when you release it? that board is using custom ordered NDK afaik, as they dont generally offer many in audio FS
diyinhk:
there is no crystek in that speed either unless custom ordered, so no 384khz unless you specify it has to run OSF off, which IMO is not the best trade-off, better off running the 45.158/49.152MHz crystek 957 for 176/192khz with OSF on IMO. Given the lack of much (any really) true native 384khz samplerate audio, it seems preferable to have properly dealt with 192khz than break the bank to get 384 and get lower performance.
500khz goes into either one (12,13, or 48MHz) evenly as a multiple, so surely the jitter from the 500khz set PLL relation to the samplerate/audio clock is where the jitter is coming from, I cant see a 48khz XO making any meaningful difference
the NDK sideswipe at another competing XMOS board was 'stylish'... but true to your previous form. obviously you arent aware that NDK are a huge clock manufacturer, they make all sorts of clocks, some for only a few dollars. adding reclocking, perhaps isolation and higher spec clocks is just playing catchup for that device that has been around for years.
will you provide some meaningful close in phase noise plots of such a board when you release it? that board is using custom ordered NDK afaik, as they dont generally offer many in audio FS
Last edited:
Yes! I have tried to use dedicated oscillator for each sampling frequency, so the MCK direct from the oscillator is always 512x the sampling frequency. 44.1/48/88.2/86/176.4/192/352.8/384 total eight 512x oscillator plus a 98MHz oscillator for the XMOS, totally 9 oscillator will be on the PCB😀 I do not know why no so call high-end already done like this😎
but the first attempt to modify the firmware to support 8 oscillator do not work, I do not know if I have time and motivation to finish this 8x dedicated oscillator project😱 this idea is open to the public now, I hope some good programmer can done it and open source to the other as the generous of XMOS to the usb audio firmware
Fox Xpresso is a crystal with ASICs according to the datasheet, I also think ASICs = PLL. Non-PLL oscillator should be better, but only FOX and crystek oscillator datasheet includes phase noise graph, it's more confident to use this kind of component.
The description inside the firmware code is very good for modification. I use a sox generated 384kHz wave file and verified that 384kHz is output at the I2S LRCK by an oscilloscope
Last edited:
because its a flawed idea...Yes! I have tried to use dedicated oscillator for each sampling frequency, so the MCK direct from the oscillator is always 512x the sampling frequency. 44.1/48/88.2/86/176.4/192/352.8/384 total eight 512x oscillator plus a 98MHz oscillator for the XMOS, totally 9 oscillator will be on the PCB😀 I do not know why no so call high-end already done like this
'so called' high end, elevating 'your original idea' above the high end, before you have even made it work? 512x 384khz? really, are you sure you are half way through this design? if so, are you really surprised that it didnt work? think about that for a minute...
Hard work, inspiration and innovation is what is needed for something hi-end (at least in my definition), not just overkill datasheet perversion. you highlighted via L as a jitter buggaboo, but replaced it with significant added trace inductance. the clock traces dont look 22-33Ω (did you calculate this? how much L for the via and how much L for your alternative?). the i2s output is unterminated and the pads you are supposed to cut (an act that will create unpredictable and inconsistent lumped elements) will look like a parasitic inductor + capacitor + dipole antenna at 200MHz.
a µvia (or a few in parallel) in pad in a 4 layer board is really not going to cause more jitter than a long trace to avoid it and is a whole lot more predictable. Given the jitter is in the ns range on all but mck, is that really worth focusing on?
MBL, Pioneer/TAD, Accuphase, Naim all did something with multiple uber dollar clocks. not for every single sample rate, why? thats what you need to ask yourself. i'd love to see the clean layout, ultra-low noise PSU, reclocking/buffering/MUX system for 8 clocks good enough to generate an advantage. the best ideas are often simple solutions.
using the lowest FS possible gives the lowest noise, why would you want it to be 512x FS? so its close to the 500khz? no reason to use 512x, use 256, any speed that the dac will see will go into 256x FS XO just as cleanly, more cleanly in fact, with lower noise; and it will actually work for 352.8/384khz
512 x 384khz is 196,608MHz, almost double the MAX clock speed SOA. Where will you find a custom low jitter 196,608MHz XO that somehow brings better performance than low jitter 90/98 that are already not easy to find.
are you sure you really did anything with this idea?
but thats enough fro me here, really and i'm sure thats welcomed; at least until some real objective information is proffered.
Last edited:
- Status
- Not open for further replies.