In theory, in a single ESS chip inside, the two channels may also cause jitter in a different time, resulting in poor listening. In contrast, if two ESS chips are used, jitter in the different time will only be more serious, making the sound more confusing, so that Dual Mono is not a good design. Many brands of DACs do not use Dual Mono, of course not because ESS chip is too expensive to afford. The data is not necessarily beautiful, I hope the next version can only use a single ESS chip, but it is better to listen.
@ofswitched
I understood what you are concern about. But I think it really doesn't make sense.
DAC in mono block configuration improves the over all performance but doesn't introduce additive jitter as long as using same MCLK source.
I designed the single ES9038Q2M DAC as the first generation. But found some issue by comparing with my other DAC HAT. That's why I re-designed this ES9038Q2M dual mono DAC HAT as the second generation. If you ask me which is better, I can tell you that I'm really happy with the new dual mono one.
A lot of high-end DACs use dual mono configuration. They based on the same principle. if you want to know more about the principle, you can search my previous posts.
Regards,
Ian
I understood what you are concern about. But I think it really doesn't make sense.
DAC in mono block configuration improves the over all performance but doesn't introduce additive jitter as long as using same MCLK source.
I designed the single ES9038Q2M DAC as the first generation. But found some issue by comparing with my other DAC HAT. That's why I re-designed this ES9038Q2M dual mono DAC HAT as the second generation. If you ask me which is better, I can tell you that I'm really happy with the new dual mono one.
A lot of high-end DACs use dual mono configuration. They based on the same principle. if you want to know more about the principle, you can search my previous posts.
Regards,
Ian
Thank you for your reply, but I can't find your previous posts, so you can explain further it doesn't introduce additive jitter as long as using same MCLK source?
Last edited:
Hi Ian,
I'm very interested in using your Transformer I/V PCB mini KIT with LL1544A Transformers.
My doubt is: do I have to pay attention to the input impedence of my Amplifier ?
I understand that using these trasformers the output impedence is higher the the "standard" OPA board.
May I have an impedence problem ?
Which is the output impedence using your Dual Mono ES9038Q2M DAC HAT with the transformer KIT with LL1544A Transformers ?
I'm very interested in using your Transformer I/V PCB mini KIT with LL1544A Transformers.
My doubt is: do I have to pay attention to the input impedence of my Amplifier ?
I understand that using these trasformers the output impedence is higher the the "standard" OPA board.
May I have an impedence problem ?
Which is the output impedence using your Dual Mono ES9038Q2M DAC HAT with the transformer KIT with LL1544A Transformers ?
Hi there.
I'm a bit late to the party. I usually just lurk around inside Ians kingdom once in while.
I just read the FifoPiUltimate doc and found this:
What r u trying to tell us?
I also found that DSD1024 and 784kHz is supported, which surprises me a little.
At least my obvious outdated wisdom was telling me that DSD-DoP256 would be max and 386kHz on the PCM side would be max for RPI I2S HATs.
Please explain.
Thx
I'm a bit late to the party. I usually just lurk around inside Ians kingdom once in while.
I just read the FifoPiUltimate doc and found this:
What r u trying to tell us?
I also found that DSD1024 and 784kHz is supported, which surprises me a little.
At least my obvious outdated wisdom was telling me that DSD-DoP256 would be max and 386kHz on the PCM side would be max for RPI I2S HATs.
Please explain.
Thx
Last edited:
Soundcheck,
Since you are one of the people I rely on to say what can and can't happen in a Raspberry Pi, I believe you are entirely correct on the maximum DSD-DoP and PCM rates on the RPi. IF there are any setups that will support DSD1024 and 784 PCM, I don't know of them.
BUT what I believe Ian is saying is that his hardware is capable to those higher rates and ready for them when they arrive in the RPi world.
Since I did the last editing on that document, I'll update after a few more days running FiFoPi's so I can include any other changes I find.
Hoping you are well.
Greg in Mississippi
Since you are one of the people I rely on to say what can and can't happen in a Raspberry Pi, I believe you are entirely correct on the maximum DSD-DoP and PCM rates on the RPi. IF there are any setups that will support DSD1024 and 784 PCM, I don't know of them.
BUT what I believe Ian is saying is that his hardware is capable to those higher rates and ready for them when they arrive in the RPi world.
Since I did the last editing on that document, I'll update after a few more days running FiFoPi's so I can include any other changes I find.
Hoping you are well.
Greg in Mississippi
If "you" write a document about a RPI HAT product:
The RPI offers theoretically 384kHz over I2S max - at best!
For DoP it'd mean, DSD128 max (=352,8kHz PCM)
DoP requires double the bandwidth compared to DSD-native.
The DAC drivers have to support these samplerates though.
There are several DAC manufacturers limiting their DACs to 192kHz.
That means. The document can state:
The HAT supports, in line with the RPI capabilities, up to 384kHz, which covers DoP up to DSD128 (5,6MHz)
If Ian's HAT offers a DoP decoder, allowing, beside I2S-PCM, a DSD-native interface/stream towards true DSD capable DACs (no ESS Sabres) that
should be stated accordingly.
Everything else I'd consider misleading and confusing.
Looking forward to an update of the documentation.
The RPI offers theoretically 384kHz over I2S max - at best!
For DoP it'd mean, DSD128 max (=352,8kHz PCM)
DoP requires double the bandwidth compared to DSD-native.
The DAC drivers have to support these samplerates though.
There are several DAC manufacturers limiting their DACs to 192kHz.
That means. The document can state:
The HAT supports, in line with the RPI capabilities, up to 384kHz, which covers DoP up to DSD128 (5,6MHz)
If Ian's HAT offers a DoP decoder, allowing, beside I2S-PCM, a DSD-native interface/stream towards true DSD capable DACs (no ESS Sabres) that
should be stated accordingly.
Everything else I'd consider misleading and confusing.
Looking forward to an update of the documentation.
@soundcheck,
That is of course the question on many people's minds. I have some thoughts on that, but have asked both Allo and Ian for an ok to directly compare their products before sharing them.
ALSO, there are a lot of configurations to check and test on Ian's gear and while I've been playing with them for several days (and have used some of the items in prototype form), I feel I have barely begun to get a strong hint of their eventual performance. Power supplies, clocks, DAC configuration, output board choice and their configuration will all play important parts in Ian's GB gear's ultimate performance.
Ask again in 4-6 weeks or so and I expect I will be able to answer that question very decisively. Remember, the period of time from when the Katana reached some beta testers and when the configuration was finalized was almost 5 months.
BUT I think I can say now with some certainty that both will be in the top rank of RPi digital playback units if setup right. AND that they will appeal to somewhat different customer bases.
Greg in Mississippi
That is of course the question on many people's minds. I have some thoughts on that, but have asked both Allo and Ian for an ok to directly compare their products before sharing them.
ALSO, there are a lot of configurations to check and test on Ian's gear and while I've been playing with them for several days (and have used some of the items in prototype form), I feel I have barely begun to get a strong hint of their eventual performance. Power supplies, clocks, DAC configuration, output board choice and their configuration will all play important parts in Ian's GB gear's ultimate performance.
Ask again in 4-6 weeks or so and I expect I will be able to answer that question very decisively. Remember, the period of time from when the Katana reached some beta testers and when the configuration was finalized was almost 5 months.
BUT I think I can say now with some certainty that both will be in the top rank of RPi digital playback units if setup right. AND that they will appeal to somewhat different customer bases.
Greg in Mississippi
The biggest drawback of Ians Dual Mono DAC, which I really like by looking at it, is the lack of a Linux driver.
That control panel approach seems to be from ancient times.
Soekris is facing the same issue btw.
The SW part is Allos real strong side. No other manufacturer can compete here.
I do know that Audiophonics is working on it. Although I doubt they'll be able
to catch up.
And for Ian, as a one-man show, it's gonna get tricky to gain any ground on that account I'd guess.
Ian's with his boards usually takes things further then most others out there.
That keeps these boards attractive.
That control panel approach seems to be from ancient times.
Soekris is facing the same issue btw.
The SW part is Allos real strong side. No other manufacturer can compete here.
I do know that Audiophonics is working on it. Although I doubt they'll be able
to catch up.
And for Ian, as a one-man show, it's gonna get tricky to gain any ground on that account I'd guess.
Ian's with his boards usually takes things further then most others out there.
That keeps these boards attractive.
Interesting. I actually think ians external controller is the biggest advantage. No Linux hassle. I use Tidal. I like native app. I use Chromecast audio for streaming because of its usability and stability. I can connect it via toslink to some spdif decoder and then to ians stack. With katana this scenario it is impossible since it is copuled to RPI.
Just waiting until someone will come up with spdif receiver of RPI footprint to make this scenario even more convenient.
Of course there are also audio geeks out there who got stuck in ancient times. The right lid for every pot.
Numerous RPI DACs are simply configurable via WEB browser or app. That's
pretty much state of the art.
Using the internal Sabre volume control via WEB browser or app I'd consider quite convenient.
By choosing Sabre chips you're facing huge challenges of course on the driver side. That's been discussed earlier.
Writing a driver is pretty much a one off exercise. (of course it still requires an MCU on the board for Sabres)
I'd say it's still more efficient than attaching controller boards with external controls to every single DAC.
Which
a. increase cost and
b. system complexity
Of course it requires quite a volume and related sales numbers to justify the investments. And I'd guess that's Ian's main issue.
By choosing a different DAC, I'm sure he'd see plenty of community support to have a look at the driver
and then he could knock off that MCU thing altogether.
Numerous RPI DACs are simply configurable via WEB browser or app. That's
pretty much state of the art.
Using the internal Sabre volume control via WEB browser or app I'd consider quite convenient.
By choosing Sabre chips you're facing huge challenges of course on the driver side. That's been discussed earlier.
Writing a driver is pretty much a one off exercise. (of course it still requires an MCU on the board for Sabres)
I'd say it's still more efficient than attaching controller boards with external controls to every single DAC.
Which
a. increase cost and
b. system complexity
Of course it requires quite a volume and related sales numbers to justify the investments. And I'd guess that's Ian's main issue.
By choosing a different DAC, I'm sure he'd see plenty of community support to have a look at the driver
and then he could knock off that MCU thing altogether.
Last edited:
Glad that there is a great product for ancient geeks thenOf course there are also audio geeks out there who got stuck in ancient times. The right lid for every pot.
Numerous RPI DACs are simply configurable via WEB browser or app. That's
pretty much state of the art.
Using the internal Sabre volume control via WEB browser or app I'd consider quite convenient.
By choosing Sabre chips you're facing huge challenges of course on the driver side. That's been discussed earlier.
Writing a driver is pretty much a one off exercise. (of course it still requires an MCU on the board for Sabres)
I'd say it's still more efficient than attaching controller boards with external controls to every single DAC.
Which
a. increase cost and
b. system complexity
Of course it requires quite a volume and related sales numbers to justify the investments. And I'd guess that's Ian's main issue.
By choosing a different DAC, I'm sure he'd see plenty of community support to have a look at the driver
and then he could knock off that MCU thing altogether.
For Tidal streaming RPI is just overkill. Chromecast delivers you best user experience by supporting native Tidal app and Ians product allows you to simply squeeze out HiFi juice out of it. Thats it. That what I need and I believe I am not the only one Happy that there is a product like katana for modern geeks
@TioFrancotirador, I'm with you on Ian's ESS Controller. I prefer local HW control of my DAC HW (and other configurable HW components). Less to go wrong there. And use the player driver and SW side for configuring that world.
I do like how Ian's got the controller on the input side of the isolators. Nice touch.
In other news, I've gotten the ok from Allo to do a comparison between their offerings and Ian's, so that hurdle's cleared.
My current status is getting some run-time on everything, including upgrade clocks. I have both Crysteks and NDK SDA's here to try. An interesting preliminary observation... using the NDK's on the FiFoPi has the sonic signature of an Ian GB stack remind me a bit of that of the Katana, which uses the same clocks. Using Crysteks in the FifoPi has them sound less alike.
I guess I should have expected that, but then I didn't expect that much of a signature difference between the two.
Greg in Mississippi
I do like how Ian's got the controller on the input side of the isolators. Nice touch.
In other news, I've gotten the ok from Allo to do a comparison between their offerings and Ian's, so that hurdle's cleared.
My current status is getting some run-time on everything, including upgrade clocks. I have both Crysteks and NDK SDA's here to try. An interesting preliminary observation... using the NDK's on the FiFoPi has the sonic signature of an Ian GB stack remind me a bit of that of the Katana, which uses the same clocks. Using Crysteks in the FifoPi has them sound less alike.
I guess I should have expected that, but then I didn't expect that much of a signature difference between the two.
Greg in Mississippi
Whichever can play the highest sample rate DSD would seem to stand a good chance of winning. However, Katana has harmonic distortion compensation, and Ian's controller doesn't have a way of setting it, IIRC, so that might help Katana. Should be interesting.
One final comment.
As far as I understand Ian's overall approach: He's not targeting high volume sales. It seems he's happy by running some little group buys once in a while to keep his cost in balance and to get new projects financed.
From that perspective it makes sense to provide a controller like the one
being offered.
The vast majority out there wouldn't be happy with that approach.
IMO that's the issue why the quite nice Audiophonics iSabre ES9038Q2M is not really that popular.
As a consequence Ian will just continue to act in in a very narrow niche segment - as intended.
Which is a pity considering what kind of quality stuff he's developing!
If he ever intends to go commercial on a larger scale, he won't get around looking into the driver subject - especially if offering HAT DACs.
Enjoy.
As far as I understand Ian's overall approach: He's not targeting high volume sales. It seems he's happy by running some little group buys once in a while to keep his cost in balance and to get new projects financed.
From that perspective it makes sense to provide a controller like the one
being offered.
The vast majority out there wouldn't be happy with that approach.
IMO that's the issue why the quite nice Audiophonics iSabre ES9038Q2M is not really that popular.
As a consequence Ian will just continue to act in in a very narrow niche segment - as intended.
Which is a pity considering what kind of quality stuff he's developing!
If he ever intends to go commercial on a larger scale, he won't get around looking into the driver subject - especially if offering HAT DACs.
Enjoy.
My two cents on this area i personally do prefer the hardware controller method by far over any half cooked custom linux driver on which i have waisted already way too much precious live time. I do not need any webbased volume control or any other fancy stuff like Roon or Itunes or other offer.
Call me oldschool, i just want a remote control and a display which Ians solution can offer and i like his hardware and open approach ...
Call me oldschool, i just want a remote control and a display which Ians solution can offer and i like his hardware and open approach ...