If you had built your DAC around a DAC chip capable of DSD playback without first converting to PCM (like for example an AK4490) it might matter. But in this case, not really.
Besides, there are advantages to software (vs. hardware) conversion from DSD to PCM. You might have more CPU resources that you can allocate to the task.
Besides, there are advantages to software (vs. hardware) conversion from DSD to PCM. You might have more CPU resources that you can allocate to the task.
What a pity, I just ordered the Pi-3 with allo BOSS yesterday, ....... so the new DAC will be compatible with Pi-3 if I caught it right?
Leucate this DAC is not yet finished . This is just a preliminary discussion. We have quite a long road before us. Meanwhile , I think you will enjoy your Boss.
Luckily Allo was able to reproduce the issues yesterday.
There'll be a driver update soon.
It'll probably take some says before we'll see that fix pushed into the official rpi git-kernel sources. From there it'll take some days to get it integrated and tested from our side.
Yep - the process is awful slow and time consuming. However. There's progress.
They are also working on the documentation. Yesterday I even received a draft for review -
No, No - I'm not an employee of Allo! 🙄
There'll be a driver update soon.
It'll probably take some says before we'll see that fix pushed into the official rpi git-kernel sources. From there it'll take some days to get it integrated and tested from our side.
Yep - the process is awful slow and time consuming. However. There's progress.
They are also working on the documentation. Yesterday I even received a draft for review -
No, No - I'm not an employee of Allo! 🙄
Congratulations to your new project.
You guys seem to be quite busy over at Allo. 😀
Things seem to get more complex project by project.
It seems we're facing a very complex power supply and a very complex output stage situation. I keep the fingers crossed that you can keep that under control.
As you know. Many of us over here prefer ( or used to prefer ) a well done ES9023 implementation over a complex ES9018 implementation. I'm still running a ES9023 DAC in sync mode from Kali.
As you stated in the beginning. What really matters is the power supply and output stage! Some of us learned: High complexity and quality not always go hand in hand.
Anyhow. By now you know what you're doing.
I'm confident that you'll come up with an interesting product.
However. I'd also add to above power and outputstage 1st priorities:
1. Filters - HW and SW - usually are also very intrusive animals (see AKM DACs, Soekris asf)
2. Noise/EMI/RFI removal
3. I2S quality enhancement
It's not just power and outputstage and 2nd the DAC chip to be looked at.
Everything matters! I know -- you'll cover most of it.
Q: Does people would still need a Kali and/or an isolator? Many of us experienced
in the past that the ESS claims of jitter immunity were nuked by improving the I2S situation.
Good luck with your new project.
You guys seem to be quite busy over at Allo. 😀
Things seem to get more complex project by project.
It seems we're facing a very complex power supply and a very complex output stage situation. I keep the fingers crossed that you can keep that under control.
As you know. Many of us over here prefer ( or used to prefer ) a well done ES9023 implementation over a complex ES9018 implementation. I'm still running a ES9023 DAC in sync mode from Kali.
As you stated in the beginning. What really matters is the power supply and output stage! Some of us learned: High complexity and quality not always go hand in hand.
Anyhow. By now you know what you're doing.
I'm confident that you'll come up with an interesting product.
However. I'd also add to above power and outputstage 1st priorities:
1. Filters - HW and SW - usually are also very intrusive animals (see AKM DACs, Soekris asf)
2. Noise/EMI/RFI removal
3. I2S quality enhancement
It's not just power and outputstage and 2nd the DAC chip to be looked at.
Everything matters! I know -- you'll cover most of it.
Q: Does people would still need a Kali and/or an isolator? Many of us experienced
in the past that the ESS claims of jitter immunity were nuked by improving the I2S situation.
Good luck with your new project.
Hi Soundcheck
yeah we are very busy. Had no vacation yet.. (its coming)
Filters... we are still studying the SW filters to see if they can be removed (but I am not confident). For HW filters on the output, we are taking great care (film capacitors and thin film resistors)
For noise removal, we know very well what we are doing. Every power rail is protected by at least one PI fiter using x7r and murata inductors. Great care is taken with the "chopper" will even have a shield to reduce EMI (as well we have a shield on clocks)
I2s...we know it very well. Clocks and buffers are present and we expect 0.5ps or less of jitter.
So this new design does not need a Kali since its a master DAC. We are still checking if we have enough space on bottom to add 2 isolator ICs
yeah we are very busy. Had no vacation yet.. (its coming)
Filters... we are still studying the SW filters to see if they can be removed (but I am not confident). For HW filters on the output, we are taking great care (film capacitors and thin film resistors)
For noise removal, we know very well what we are doing. Every power rail is protected by at least one PI fiter using x7r and murata inductors. Great care is taken with the "chopper" will even have a shield to reduce EMI (as well we have a shield on clocks)
I2s...we know it very well. Clocks and buffers are present and we expect 0.5ps or less of jitter.
So this new design does not need a Kali since its a master DAC. We are still checking if we have enough space on bottom to add 2 isolator ICs
If you choose to go the extra mile adding isolator chips please also add a few flip flops after them as well.. 😉
Dont forget that on master mode you only have the DATA coming in. The important part for jitter is only MCLK/BCLK
This is what most literature is saying....however practically , its my opinion that somehow it matters. Kali has improvement on SQ and everything is re cloaked (even DATA)
So I suspect that somehow it might improve..why? No idea
So I suspect that somehow it might improve..why? No idea
Also we have at this point 2 uUSB connectors. One is on the DAC pcb and second is on the controller/chopper PCB. You can either :
1. Feed power to DAC
2. Feed power to last stage
3. Feed power to both (2 independent psu)
For the 15v , you can either :
1. Use chopper
2. Disable chopper , solder wires (before LDOs)
1. Feed power to DAC
2. Feed power to last stage
3. Feed power to both (2 independent psu)
For the 15v , you can either :
1. Use chopper
2. Disable chopper , solder wires (before LDOs)
Hmmh.
Actually. As long as you guys leave us some soldering joints to apply high quality connections to be able to nicely bypass these usb-whatever-jacks, you can use whatever you want. 😉
Actually. As long as you guys leave us some soldering joints to apply high quality connections to be able to nicely bypass these usb-whatever-jacks, you can use whatever you want. 😉
We will try...but those new USB connectors are rated at 60W . Old microusb was rated at less than 10W. A lot more power available
I also support the idea! If you already made such big effort with the board it would be really the shame not to have possibility for HQ power line to it.
Hi,
From first post:
"At last..the driver. Its closed.So we got a very decent microcontroller that has the closed source driver. That micro controller communicates with the opensource driver thus allowing DAC control. Everything .."
Is this a separate HAT board? If so then could it be implemented as a universal interface to the DSP on ESS chips?
-Tim
From first post:
"At last..the driver. Its closed.So we got a very decent microcontroller that has the closed source driver. That micro controller communicates with the opensource driver thus allowing DAC control. Everything .."
Is this a separate HAT board? If so then could it be implemented as a universal interface to the DSP on ESS chips?
-Tim