So I'm quoting myself
Of cource I have read the product presentation that reveals a lesser possible
sampling frequency and a bit higher thd / dnr. The available samplingfrequency is
high enough since it's usually limited by the usb reciver anyway so that shouldn't
matter, -110 thd and -128db dnr should be more than enough as well.
Schould I be expecting a lesser soundquality with this chip ?
Are the dsp/volumecontrol funtions identical ? (seem so from the presentation).
Could you elaborate on clock alternatives ?
So I'm quoting myself
Of cource I have read the product presentation that reveals a lesser possible
sampling frequency and a bit higher thd / dnr. The available samplingfrequency is
high enough since it's usually limited by the usb reciver anyway so that shouldn't
matter, -110 thd and -128db dnr should be more than enough as well.
Schould I be expecting a lesser soundquality with this chip ?
Are the dsp/volumecontrol funtions identical ? (seem so from the presentation).
Could you elaborate on clock alternatives ?
Did you mean what is diff between 9016 and 9018? There was also some discusion around there of 9023.
9016 has less of the proprietary features in terms of jitter rejection and the price of the chip is half of the cost of a 9018 so the value you place on those changes can only really be determined by the user IMO. Basically yes, it will be measurably less than the performance of a well built 9018; it may well perform better than a poorly built 9018 though IMO.
Clock options depend on your transport and your choice of synch or asynch clocking. If you have a usb transport with good onboard clocks you may chose to use that and use synchronous clocking.
I suspect that I have created more questions than answers for you unfortunately ...
Cheers,
Chris
AKD23P
Just finished putting my AKD23P in a temporary case with a few other bits and pieces
Need a shorter u.fl cable for mclk, the ones for signal weren't long enough to reach the mclk, probably only short by ~10mm or so, next bigger size I had was a 200mm long monster.
Just finished putting my AKD23P in a temporary case with a few other bits and pieces
Need a shorter u.fl cable for mclk, the ones for signal weren't long enough to reach the mclk, probably only short by ~10mm or so, next bigger size I had was a 200mm long monster.
Attachments
Last edited:
Yeah I got a one off tx of my own made up by sumr, made one mistake and ended up with one of the secondaries being a bit higher than I'd like and the LT1085 I use for the WaveIO runs a bit hot even with the larger heatsink on it, not the end of the world and all runs at safe temps how it is. Considering I ordered the tx with a totally different DAC and without FIFO in mind it still turned out pretty much perfectly and will use all of the secondaries.
Yeah I thought you'd like those regs
The extra LT1963 reg board will power FIFO later on and the other half of the seemingly half populated Wire PSU board is set up as another rectifier+filter and will probably power a sjostrom super reg for isolated side of the FIFO. I grabbed a spare set of shoelaces from qusp for analogue signal wire too!
Oh and the JG jfet buffer+filter for the dac output still to come yet too
I'll be taking this as it is to the Brisbane head-fi meet so hopefully will be able to compare to whatever others bring along to that, should be interesting! It has just taken the place of a usb powered 'open source usb interface' that had the same 9023 dac chip and I was using an O2 amp on the output. WaveIO->AKD23P->Wire are a fairly substantial improvement over that setup.
Last edited:
I am not familiar with any of the asynch clocking options since I have never investigated them. Would be worth asking Acko about the 'Turbo Master Clock' though. I am not sure if it is able to work in asynch mode, its description has reference to modifications needed on transport end, which may or may not suit your application.
@nattonrice, sounds like a great plan!
@nattonrice, sounds like a great plan!
DAC Master Clock
The AKD12P DAC module has provisions for an on-board XO or an external unit. I am leaning more towards the external one as it give options to experiment with different clock modules. Also, if the transport provides MCLK, this can be used and saves the cost of a dedicated Clock module.
As for the Turbo Clock, see how it is connected to the DAC as in the pic. The Master Clock output of the unit is connected directly to the DAC Master Clock input. There is no interaction with the EXA2UI transport at this stage, so in effect this is Async mode. Of course, you could just whack in a much cheaper clock module for this case.
The SQ of the setup is really good, so it goes to indicate that the NDK XOs and signal processing of the Turbo Clock are working well. I haven't done direct comparisons yet but based on memory, appears sounding better the Crystek types used previously with this DAC. So standard Async mode with low jitter XOs does sound very good. The other thing I have noted is that the DPLL BW of the DAC has to be at least Medium-High @192KHz and possibly Highest BW for 384KHz for stable lock.
Based on the above results, I am still undecided as to whether to go further and mod the EXA unit for synchronous operation. For this case, 2 slave clock outputs from the Turbo Clock goes into the Clock inputs of the EXA unit. The two on-board XOs need to come out. Then I have got to tap the embedded Fs signals of the EXA to switch the Turbo Clock accordingly. Fairly, intrusive process and may cause damage or void any warranty of this fairly expensive EXA unit, so treading carefully
Anyway, the benefits of going forward will be to get the DAC to lock at the lowest BW in the Synchronous mode. Plus DAC operating at 98.304MHz would make the jitter reduction even better compared to just using the simpler 24.576MHz MCLK directly from the EXA unit.
Also, the Master Clock from the Turbo unit is inverted w.r.t. the Slave Clocks to reduce noise further as indicated in one of the ESS App note, so all lined up!
Will all these translate to noticeable improvements?
Will find out soon ...
The AKD12P DAC module has provisions for an on-board XO or an external unit. I am leaning more towards the external one as it give options to experiment with different clock modules. Also, if the transport provides MCLK, this can be used and saves the cost of a dedicated Clock module.
As for the Turbo Clock, see how it is connected to the DAC as in the pic. The Master Clock output of the unit is connected directly to the DAC Master Clock input. There is no interaction with the EXA2UI transport at this stage, so in effect this is Async mode. Of course, you could just whack in a much cheaper clock module for this case.
The SQ of the setup is really good, so it goes to indicate that the NDK XOs and signal processing of the Turbo Clock are working well. I haven't done direct comparisons yet but based on memory, appears sounding better the Crystek types used previously with this DAC. So standard Async mode with low jitter XOs does sound very good. The other thing I have noted is that the DPLL BW of the DAC has to be at least Medium-High @192KHz and possibly Highest BW for 384KHz for stable lock.
Based on the above results, I am still undecided as to whether to go further and mod the EXA unit for synchronous operation. For this case, 2 slave clock outputs from the Turbo Clock goes into the Clock inputs of the EXA unit. The two on-board XOs need to come out. Then I have got to tap the embedded Fs signals of the EXA to switch the Turbo Clock accordingly. Fairly, intrusive process and may cause damage or void any warranty of this fairly expensive EXA unit, so treading carefully
Anyway, the benefits of going forward will be to get the DAC to lock at the lowest BW in the Synchronous mode. Plus DAC operating at 98.304MHz would make the jitter reduction even better compared to just using the simpler 24.576MHz MCLK directly from the EXA unit.
Also, the Master Clock from the Turbo unit is inverted w.r.t. the Slave Clocks to reduce noise further as indicated in one of the ESS App note, so all lined up!
Will all these translate to noticeable improvements?
Will find out soon ...
Attachments
Last edited:
AKD16 Series- 9016 DAC
In response to enquires, this 9016 DAC will be used in mid-range products with more integration like IV and controller to follow soon. This chip itself is only a tad lower in performance than the big brothers 9012/18 but has simpler power supply requirements. Other differences are no dual mono capability or lock indicator
Also planned, USB DAC based on Amanero.
In response to enquires, this 9016 DAC will be used in mid-range products with more integration like IV and controller to follow soon. This chip itself is only a tad lower in performance than the big brothers 9012/18 but has simpler power supply requirements. Other differences are no dual mono capability or lock indicator
Also planned, USB DAC based on Amanero.
just wait for your fifo for sync mode mate. only thing you lose is multichannel and DSD and you can then have it on everything
strange, I can get stable lock at 192 running async with fifo in 'lowest' DPLL but as with anything, the dac needs some time to warm up, perhaps you havent given it this time in your testing? much research has been undertaken to get to the bottom of this, it seems environmental effects, RF, spill from mains, ground bounce etc all affect this, as it exists still in what should effectively be jitter free conditions.
To this end, one thing you might consider mate is putting a digital isolator on the MCU, i'll be running the MCU USB connection and its i2c through an isolator, a spare isolator position was put on the fifo ISO board for just this sort of thing.
are you planning multichannel versions of the 9016?
strange, I can get stable lock at 192 running async with fifo in 'lowest' DPLL but as with anything, the dac needs some time to warm up, perhaps you havent given it this time in your testing? much research has been undertaken to get to the bottom of this, it seems environmental effects, RF, spill from mains, ground bounce etc all affect this, as it exists still in what should effectively be jitter free conditions.
To this end, one thing you might consider mate is putting a digital isolator on the MCU, i'll be running the MCU USB connection and its i2c through an isolator, a spare isolator position was put on the fifo ISO board for just this sort of thing.
are you planning multichannel versions of the 9016?
Thanks for the info on your work Acko!!
I am a bit confused if dahlberg has been asking about AKD16 or AKD12 though. Earlier questions were about the differences between the two, and my responses were about trying to implement an external clock with the AKD16. Then it seemed like he was referring to the onboard osc, which is only on the AKD12.
Though I am a bit puzzled, what is the implication of having no lock indicator? Is it purely a user interface feature or does it have some technical significance that I'm not noticing having only had limited experience of hearing 9012 DACs of others and studying their datasheets. What is the lock indicator typically used for?
Regardless I think Acko's covered most bases in the discussion above!
I am a bit confused if dahlberg has been asking about AKD16 or AKD12 though. Earlier questions were about the differences between the two, and my responses were about trying to implement an external clock with the AKD16. Then it seemed like he was referring to the onboard osc, which is only on the AKD12.
Though I am a bit puzzled, what is the implication of having no lock indicator? Is it purely a user interface feature or does it have some technical significance that I'm not noticing having only had limited experience of hearing 9012 DACs of others and studying their datasheets. What is the lock indicator typically used for?
Regardless I think Acko's covered most bases in the discussion above!
Last edited:
nah just user interface and it also gives visual indication of dropped connections etc, its a bit annoying, I wonder if it can be deduced/sniffed some other way? of course most transports used with it will have some form of lock indication.
in case part of your confusion was related to my reply, I was referring to this line from post 511
in case part of your confusion was related to my reply, I was referring to this line from post 511
acko said:
Lock Indicator
Actually, I found it useful.
In my earlier post on lock issue with low DPLLBW @192KHz, it is the tiny intermittent blink on the indicator that tells it. No dropouts actually heard, possibly smeared as noise and affecting the SQ.
Even if transport has lock indication, it is the DAC that does the final processing.
BTW, the Hiface USB connected this way did better with BW down to 'low' and stable lock @192KHz. Some complex interaction is happening! There is this main board shield surrounding the DAC that is still floating. I will try to ground or earth this and see.
Thanks for all your feedback and suggestions
Actually, I found it useful.
In my earlier post on lock issue with low DPLLBW @192KHz, it is the tiny intermittent blink on the indicator that tells it. No dropouts actually heard, possibly smeared as noise and affecting the SQ.
Even if transport has lock indication, it is the DAC that does the final processing.
BTW, the Hiface USB connected this way did better with BW down to 'low' and stable lock @192KHz. Some complex interaction is happening! There is this main board shield surrounding the DAC that is still floating. I will try to ground or earth this and see.
Thanks for all your feedback and suggestions
Last edited:
I was asking about the "akd16".
There are pads on the board marked "mlck", I was assuming they where
supposed to be populated by "the simpler 24.576MHz MCLK" or some
"semi high end solution".
Not at all if an external master clock is used. Maybe a misstake on my part or... ?
I will try to make a description of how I'm going to use these things.
The center of all functions will be the dsp filter that "Chapark" is working on
and at the I2S input I will have "Loriens" usb reciver. I will also be in need of
both digital and analog inputs of the dsp. If I'm not misstaken that will
disqualify the possibility to use the Wave IO as a masterclock, right? The
plan for outputs are to connect two stereo dacs to I2S and use ESS digital
volume control before sending this to four channels of John Broskie's "Unballancer".
People are giving the ess volumecontrol god reviews, I really hope that this is true.
I have also read somewhere that if syncronus mode failes it will be quite
nasty, so I'm leaning to asyncronus mode for now.
If I'm going for the "akd16" do I really have to get an external clock to get a
decent result? And if so, can I run both "akd16" on the same master as
asyncronus or will I need two external clocks?
There are pads on the board marked "mlck", I was assuming they where
supposed to be populated by "the simpler 24.576MHz MCLK" or some
"semi high end solution".
Not at all if an external master clock is used. Maybe a misstake on my part or... ?
I will try to make a description of how I'm going to use these things.
The center of all functions will be the dsp filter that "Chapark" is working on
and at the I2S input I will have "Loriens" usb reciver. I will also be in need of
both digital and analog inputs of the dsp. If I'm not misstaken that will
disqualify the possibility to use the Wave IO as a masterclock, right? The
plan for outputs are to connect two stereo dacs to I2S and use ESS digital
volume control before sending this to four channels of John Broskie's "Unballancer".
People are giving the ess volumecontrol god reviews, I really hope that this is true.
I have also read somewhere that if syncronus mode failes it will be quite
nasty, so I'm leaning to asyncronus mode for now.
If I'm going for the "akd16" do I really have to get an external clock to get a
decent result? And if so, can I run both "akd16" on the same master as
asyncronus or will I need two external clocks?
Last edited:
haha so do I, I meant its a bit annoying its gone, sorry for the confusion =)
with the fifo with the isolator and running synchronously it makes it so the clock belongs to the dac again, not USB ground, or subject to the high slewing FPGA, but the reclock stage is after the isolator, so no jitter added by the isolator like normally.
with the fifo with the isolator and running synchronously it makes it so the clock belongs to the dac again, not USB ground, or subject to the high slewing FPGA, but the reclock stage is after the isolator, so no jitter added by the isolator like normally.
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.