Folks. Keep in mind.
I brought it up on the other thread covering Ians DAC.
Ian's HAT DACs, as good as they look, don't come with Linux SW drivers! For all of you considering his DAC, keep in mind there are no control options via web-browser or application.
From that perspective Allo is lightyears ahead. And Ian will have a hard time to catch up. I actually doubt he's considering it.
If you're into computer based audio or streaming you simply can't neglect the SW part of your audio devices anymore.
Estimated 99% of all RPI HAT DAC manufacturers have realized that and did something about it. Several manufacturers
just built a DAC that was compatible with other companies drivers to cover that area.
Using the Katana or the Audiophonics iSabre9038Q2M driver would be difficult for Ian, since the MCU firmware is proprietary.
Ian would have to build into his controller MCU the Katana/Audiophonics firmware. I don't think he'll get access to these.
He might be able to do some reverse engineering. After all. This simply is not gonna work.
Ian has to write the driver himself, of course he can use the existing stuff as base. Perhaps he gets some help.
Enjoy.
Last edited:
Looking at the manual for the ESS controller, it states that volume control via ALSA should work if pcm5122 compatible driver is used. The controller also seems to have Tx and Rx pins, I wonder if that's a serial interface that can be used by something like Synchronator or some other interface for additional remote functionality.
And yes, this is DIY, if you expect a turnkey solution this is not for you.
And yes, this is DIY, if you expect a turnkey solution this is not for you.
One other thing to check is if the i2c bus is enabled, there are some settings in dietpi-config advanced section to deal with it, you might want to try and set it to use the fast i2c speed, 400 kHz if remember correctly. I'm not sure why Ian's controller would need the RPi i2c but the ALSA driver might not like it.
You mean i2c should be disabled? I recall it was disabled. I can check it later after reloading DietPi to the micro SD card but would like to see if there are anything else to test in piCorePlayer first.
No, I suspect it might have to be enabled.
One of the "features" of dietpi is it disables a lot of things in order to reduce the load on CPU and thus supposedly provide less interference and better audio experience. But disabling things can lead to things not working the way they do with mainstream distros.
One of the "features" of dietpi is it disables a lot of things in order to reduce the load on CPU and thus supposedly provide less interference and better audio experience. But disabling things can lead to things not working the way they do with mainstream distros.
Actually, thinking about this more, the more probable cause is the ALSA driver taking over I2C master duties and thus preventing Ian's controller from accessing the DAC. So, I would expect that I2c bus on the RPi should be disabled in order not to interfere with the controller.
In any case, if corepiplayer works then just use that, but it would probably be beneficial to troubleshoot this for others that might hit the same problem.
In any case, if corepiplayer works then just use that, but it would probably be beneficial to troubleshoot this for others that might hit the same problem.
Hi jacklee,
If you got both "fifoPi locks on, ESS DAC board locks on", but you still saw "NO SIGNAL" on controller's OLED screen, it could be an issue.
Please do one more test, plug the ESS controller into the GPIO of ESS DAC HAT rather than the non-isolated GPIO on FifiPi. Then, play music. Let me know what is happened.
No worry, I'm here to help.
Regards,
Ian
I see. I tested picoreplayer already and that doesn't work too so this is likely due to some other causes. It's very strange as in both DietPi and piCorePlayer the OS can detect the sound card and output audio data w/o any error. Even the fifopi and the DAC board themselves reported clock lock-on. Just no sound. 8(
I already tried bypassing the fifopi (by removing it from the stack) and it is exactly the same so not due to the fifopi.
Thanks for the help!
Yes. In that test the fifopi is not part of the system, i.e., the DAC board was plugged directly into the RPI and the controller on the DAC board's GPIO interface.
Did the dual mono ES9038Q2M DAC still have lock LED on for both channel, but ESS controller still show "NO SIGNAL" on the screen?
If that's the case, please one more test:
Set the PIN1 of the jumper switch to "ON" position on the ESS controller. Play music and let me know what is happening.
Regards,
Ian
With PIN1 in ON position there is sound, hurray! However the display remains the same, i.e., "NO INPUT". That's with the fifopi in place.
I reinstalled DietPi and as expected it works just fine, despite the NO INPUT display, as long as PIN 1 is ON (i.e., AutoMute disabled). The vol control on the ESS Controller also works.
Can't help but listen to a few songs. The sound is very promising. It has a very organic sound signature. I tried briefly the transformer output and also the Sparkos Lab Discrete Dual Opamp. Both works fine and sound smoother than the basic opamp.
The Sparkos opamps are very tight fit due to their size. I managed to fit all three with the second stage one tilted a tiny bit. No big deal.
Obviously needs run-in before any serious comparison can be made. And it's still on the basic clocks ... this is fun stuff! Thanks to Ian for the project!
Can't help but listen to a few songs. The sound is very promising. It has a very organic sound signature. I tried briefly the transformer output and also the Sparkos Lab Discrete Dual Opamp. Both works fine and sound smoother than the basic opamp.
The Sparkos opamps are very tight fit due to their size. I managed to fit all three with the second stage one tilted a tiny bit. No big deal.
Obviously needs run-in before any serious comparison can be made. And it's still on the basic clocks ... this is fun stuff! Thanks to Ian for the project!
My take on Ian's gear and Linux drivers...
First, I'll start with quoting @wealas: "And yes, this is DIY, if you expect a turnkey solution this is not for you."
I've been following Ian's work since 2012 when I purchased one of his original FIFO & Dual Clock board combos from his 1st GB. In post #8 of his 'Asynchronous I2S FIFO Project...', he describes himself as:
"I'm a R&D engineer. My job focuses on medical electronics. But I’m an audiophile also. In the past couple decades of years, I did quite a few audio projects, include tube/solid amplifiers, CD transports, antique/full range speakers, DACs, PC HIFI and something else. Now, what I’m interested in the most is the digital audio. I always believe we should get the better sound if we could do something perfect."
AND you know what? He's been VERY successful with this venture and improving the sonics of digital gear for hundreds to thousands of DIY'ers. AND based on his offerings, I suspect is also VERY successful in his daytime job too!
Ian's original intention was to provide some hardware that he developed and found to make a significant improvement in the SQ of his digital audio gear to friends and others to use in their DIY builds. Over the years Ian has expanded and improved his offering, mostly by offering new products, features, and capabilities, as the performance has always been present. AND his GB subscribers have grown from just a few in his initial GB (I estimate 20-40) to roughly 200 in his latest (and some previous ones may also be that large or larger, I did not go back to check).
I'm pretty sure Ian does not make money on this activity. I suspect he covers the costs of the boards and postage, but I seriously doubt he covers his R&D, development, and design costs, much less the support he provides both in the forums AND in repairs for people who have problems with their gear, even if THEY caused the problems. Oh, and occasionally firmware updates too! I suspect this is a labor of love and his committment to getting the best sound out of Digital AND sharing that.
AND it is DIY. People will use his gear in ways he hasn't even considered... go look at all the questions Ian gets on the various forums about his gear. THAT's another source of support time for Ian.
Having watched the process of writing a driver and getting out in the various Linux distros, it is work. Troubleshooting problems that occur as Linux is updated and revising and re-releasing that driver... more work. Troubleshooting issues that people encounter using that driver, much more work. AND dealing with angry users who just destroyed an expensive amp and pair of speakers because of one of those problems... MUCH more work plus costs plus headaches.
I suspect Ian keeps his offerings in the DIY realm for a reason. I don't think he intends to ever quit his likely VERY lucrative job to do this as a business. I suspect Ian well knows the common saying... "The fastest way to 1 million dollars as a small audio business is to start with 2 million... you'll get down to 1 million very quickly!"
Given all that, WHY would he want to write a driver? His gear follows the model of DIY HW suppliers such as Twisted Pear Audio who also provides local HW configuration for their DAC offerings. His development and maintenance costs start RELATIVELY low and stay that way over the lifespan of his products. YES, he has to deal with supporting people fumble-fingering his gear and other issues, but not the headaches of continual driver updates to keep it current with Linux updates AND the configuration / compatibility issues some users will encounter no matter how thorough and extensive the pre-release testing.
I respect his model and acknowledge the great service Ian has provided to the DIY Audio community. I know my digital gear sounds better now because of Ian's efforts and offerings.
Of course, I might be wrong about the above. Ian will chime in if I am, I am sure.
BUT I think his model works, makes sense for him, and developing a driver would add headaches I doubt Ian wants and needs.
Ian's RPi gear, as designed and provided to us, works VERY well with the basic I2S driver available in EVERY Linux distro out there. Personally, that plus his hardware DAC controller gives me the flexibility to use his gear with any distro/player SW I want and never have to worry if the driver is there or working right.
AND @soundcheck, just because YOU think ALL RPi DACS MUST have a driver to control the HW configurations does not mean it makes sense for these!
My 2 cents.
Greg in Mississippi
P.S. Speaking of "use his gear in ways he hasn't even considered", using a HW controller means that Ian's DACs can be used for non-computer based solutions, making them even more perfect for their intended market, DIY Audio enthusiasts. CD Player or DAC upgrades or builds can be done. For my part, I suspect I'll end up with at least one of Ian's DACs connected to a dedicated SD Card player, SDTrans384 or one of the ones they are currently modifying on TirNaHiFi. Ian's DACs (along with Allo's Katana) are sufficiently good to consider for this application... but doing it with a Katana will be a cludgy lash-up at best involving a necessary connection with a computer, while doing it with one of Ian's DACs just means you need to deal with connecting the I2S signals to the correct GPIO pins.
First, I'll start with quoting @wealas: "And yes, this is DIY, if you expect a turnkey solution this is not for you."
I've been following Ian's work since 2012 when I purchased one of his original FIFO & Dual Clock board combos from his 1st GB. In post #8 of his 'Asynchronous I2S FIFO Project...', he describes himself as:
"I'm a R&D engineer. My job focuses on medical electronics. But I’m an audiophile also. In the past couple decades of years, I did quite a few audio projects, include tube/solid amplifiers, CD transports, antique/full range speakers, DACs, PC HIFI and something else. Now, what I’m interested in the most is the digital audio. I always believe we should get the better sound if we could do something perfect."
AND you know what? He's been VERY successful with this venture and improving the sonics of digital gear for hundreds to thousands of DIY'ers. AND based on his offerings, I suspect is also VERY successful in his daytime job too!
Ian's original intention was to provide some hardware that he developed and found to make a significant improvement in the SQ of his digital audio gear to friends and others to use in their DIY builds. Over the years Ian has expanded and improved his offering, mostly by offering new products, features, and capabilities, as the performance has always been present. AND his GB subscribers have grown from just a few in his initial GB (I estimate 20-40) to roughly 200 in his latest (and some previous ones may also be that large or larger, I did not go back to check).
I'm pretty sure Ian does not make money on this activity. I suspect he covers the costs of the boards and postage, but I seriously doubt he covers his R&D, development, and design costs, much less the support he provides both in the forums AND in repairs for people who have problems with their gear, even if THEY caused the problems. Oh, and occasionally firmware updates too! I suspect this is a labor of love and his committment to getting the best sound out of Digital AND sharing that.
AND it is DIY. People will use his gear in ways he hasn't even considered... go look at all the questions Ian gets on the various forums about his gear. THAT's another source of support time for Ian.
Having watched the process of writing a driver and getting out in the various Linux distros, it is work. Troubleshooting problems that occur as Linux is updated and revising and re-releasing that driver... more work. Troubleshooting issues that people encounter using that driver, much more work. AND dealing with angry users who just destroyed an expensive amp and pair of speakers because of one of those problems... MUCH more work plus costs plus headaches.
I suspect Ian keeps his offerings in the DIY realm for a reason. I don't think he intends to ever quit his likely VERY lucrative job to do this as a business. I suspect Ian well knows the common saying... "The fastest way to 1 million dollars as a small audio business is to start with 2 million... you'll get down to 1 million very quickly!"
Given all that, WHY would he want to write a driver? His gear follows the model of DIY HW suppliers such as Twisted Pear Audio who also provides local HW configuration for their DAC offerings. His development and maintenance costs start RELATIVELY low and stay that way over the lifespan of his products. YES, he has to deal with supporting people fumble-fingering his gear and other issues, but not the headaches of continual driver updates to keep it current with Linux updates AND the configuration / compatibility issues some users will encounter no matter how thorough and extensive the pre-release testing.
I respect his model and acknowledge the great service Ian has provided to the DIY Audio community. I know my digital gear sounds better now because of Ian's efforts and offerings.
Of course, I might be wrong about the above. Ian will chime in if I am, I am sure.
BUT I think his model works, makes sense for him, and developing a driver would add headaches I doubt Ian wants and needs.
Ian's RPi gear, as designed and provided to us, works VERY well with the basic I2S driver available in EVERY Linux distro out there. Personally, that plus his hardware DAC controller gives me the flexibility to use his gear with any distro/player SW I want and never have to worry if the driver is there or working right.
AND @soundcheck, just because YOU think ALL RPi DACS MUST have a driver to control the HW configurations does not mean it makes sense for these!
My 2 cents.
Greg in Mississippi
P.S. Speaking of "use his gear in ways he hasn't even considered", using a HW controller means that Ian's DACs can be used for non-computer based solutions, making them even more perfect for their intended market, DIY Audio enthusiasts. CD Player or DAC upgrades or builds can be done. For my part, I suspect I'll end up with at least one of Ian's DACs connected to a dedicated SD Card player, SDTrans384 or one of the ones they are currently modifying on TirNaHiFi. Ian's DACs (along with Allo's Katana) are sufficiently good to consider for this application... but doing it with a Katana will be a cludgy lash-up at best involving a necessary connection with a computer, while doing it with one of Ian's DACs just means you need to deal with connecting the I2S signals to the correct GPIO pins.
Last edited:
Responses and some Random impressions...
First, an addition to my long tome above... those are entirely MY thoughts. Ian may have a driver already written and submitted to the distros... he's that kind of guy. BUT I felt there is a strong case for how Ian has configured his gear, largely based on his target audience (DIY'ers) and distribution method (no-profit GB's), and I wanted to clearly communicate that.
Next, some responses...
@jacklee, smashing that you've gotten your setup working. Glad to hear. AND good to hear your thoughts on the Sparkos versus the stock opamps in the IVStd. I bet you will like it more after upgrading the clock. What ones do you have? So far, I have tried Crystek CCHD-957 and NDK SDAs... and honestly, I somewhat prefer the NDKs. I do need to try some of the bypassing suggested by @diyiggy on Ian's main "Asychronous I2S FIFO project" thread in posts 4809, 4912, 4814, 4818, 4819, and 4841... that may change my impressions.
Also thanks for posting pix of your LiFePO4 supply build and how you insulated most of the posible accidental short points. I have my entire cell sets wrapped in tape now so I can't drop anything in between them and have it move around and short either.
@supersurfer, also thanks for your build pix. AND question on the LiFePO4 supply. Ian and others answered it well. I do want to mention that the non-isolated 5V supply is worth having and that would disappear if you used one or some of the cells to also power the board and the relays. I think Ian did a great job designing and producing a product with a specific intention in mind... and that is not as a mobile battery supply, but a high-quality battery supply for use with targeted equipment along with an integrated charging, monitoring, and control regime AND that non-isolated 5V supply.
@Gallen1119, if noone else answers soon, I'll post some recommendations.
@Markw4, no, my 'tweak mentor' is a different person than my 'audio friend'. BTW, based on 'audio friend's comments that I posted and others in some email exchanges, I doubt he will be trying the film cap bank on his Katana's +-15V. He expressed some concerns about adding much C after a fast shunt regulator. I share that, but since my main regulation setup for the Katana is with Sparkos series regulators, I do plan to try it at some point and also with some lower-quality monolythic regulators setups I have planned.
My 'tweak mentor' is a guy who makes much of his living from modifying audio gear. He's pretty far out there in much of the stuff he does and I've learned a lot OR had confirmed a lot from emailing / talking with him over many years. He uses discrete opamps as output buffers in some of his mod builds and it was in that context he prefers the LKS to the Sparkos. He specifically does not use them as I/V stages, which is why I cautioned his preference MAY not translate here.
Now, some impressions...
So I've been playing various combinations of Ian's GB gear and some of his prototype gear over the last couple of weeks, both to get it all broken in (not nearly there yet) and get some sonic impressions. Take all of this as largely preliminary, but here are some random thoughts from what I've experienced so far...
- Like @jacklee, I was not blown away by the sonics of the IVStd with the stock opamps. I won't get to opamp rolling for a week or so yet. Which opamps I have to try I posted a earlier in this thread.
- I have been playing Ian's prototype OPA861 I/V stage a good bit. I like it... very simple circuit, local on-board shunt regulation, no feedback, both balanced and single-ended outputs. I hope this one gets finalized for Ian's next offering. I have NOT tried Ian's prototype OPA1632-based I/V yet which I also have built-up here.
- LiFePO4 supply works well powering the stack and as far as I've taken it so far, produces good sonics.
- I say 'as far as I've taken it so far' because at first, I was not 'wowed' by the sonics I was getting. I tried various power combos, upgrade clocks, different output stages to no avail. AND then I remembered I was feeding the 3.3V from the LiFePO4 supply into the standard input of the FiFoPi. Ian is correct in that does 'bypass' the regulator. AND he said actually physically bypassing them is better. To find out how much degradation I was hearing, I used a couple of UCPi Ultracap supplies to power the FiFoPi / DAC combo... one charged to 5V for feeding into the 'non-LDO-bypassed' FiFoPi and the other charged to 3.3V for the DAC board. WOW, that made things POP! Now no disappointment in the sonics. While it does work to feed the 3.3V through the FiFoPi LDOs, my experience is that either feeding 5V into the LDOs so they are actually operating is much better. I suspect feeding 3.3V directly into the unit physically bypassing the LDOs will be another step up, but I have not tried it yet.
- As I said above on clocks, I've tried both Crysteks and NDK SDA and prefer the NDKs for a more dynamic, present and exciting sonic perspective. Neither sets have sufficient run-time to be fully broken in and there are some bypassing options to try, so more to come. But this is what I've heard so far. An interesting experience related to this... In preparation for starting to run the Ian GB gear, I did some mods to one of my Katana (bypassing the Microprocessor board's +-14V LDO) and listened a bit. Then I put in Ian's ES9028Q2M prototype DAC on an RPi -> IsolatorPi -> Allo Kali stack with Onetics transformer outputs. The IsolatorPi and the Kali were each powered by a 5V 6||LT3045 board from MPAudio, the DAC from a 3.3V charged UCPi. Sonics were very comparible to the Katana, perhaps even more comparible than the report I published a couple of months back when I used 3 UcPi, but with the NESSCAP parts that seemed to have an emphasis in the upper-mids / lower-highs.
When I first listened to one of the Ian actual GB DACs on an RPi -> FiFoPi stack with the Onetics, it was with the stock clocks and I was still feeding the LiFePO4 3.3V through the onboard LDO's. MEH. That combo of course was not up to what I heard previously, because of the 3.3V through the LDOs. I tried Crysteks and it was better, but still MEH+. BUT when I substituted the NDK SDAs (the same clocks as used on the Katana), while the LDO were still limiting the performance, the sonic signature was much more similar to that of the Katana. Call it MEH++. Hmmmm... clock's sonic signature matter more than I expected!. BUT THEN, when I fed the FiFoPi 5V via a UCPi, it was transformed and it was definitely roughly comparable to my prior setup with that DAC / output stage AND to the Katana.
- My main reason for using Ian's ES9028Q2M prototype DAC with the Onetics in the above comparison was to get a feel if the FiFoPi provided the same level of benefit an IsolatorPi / Allo Katana did. My 'preliminary' take on this is yes.
- Finally, my overall assessment SO FAR is that Ian's GB gear, with the right combination of clocks, output stage, and power has the potential to be as good or better than anything I have here, IMHO. BUT remember this is all very preliminary.
That's what I have so far.
Greg in Mississippi
First, an addition to my long tome above... those are entirely MY thoughts. Ian may have a driver already written and submitted to the distros... he's that kind of guy. BUT I felt there is a strong case for how Ian has configured his gear, largely based on his target audience (DIY'ers) and distribution method (no-profit GB's), and I wanted to clearly communicate that.
Next, some responses...
@jacklee, smashing that you've gotten your setup working. Glad to hear. AND good to hear your thoughts on the Sparkos versus the stock opamps in the IVStd. I bet you will like it more after upgrading the clock. What ones do you have? So far, I have tried Crystek CCHD-957 and NDK SDAs... and honestly, I somewhat prefer the NDKs. I do need to try some of the bypassing suggested by @diyiggy on Ian's main "Asychronous I2S FIFO project" thread in posts 4809, 4912, 4814, 4818, 4819, and 4841... that may change my impressions.
Also thanks for posting pix of your LiFePO4 supply build and how you insulated most of the posible accidental short points. I have my entire cell sets wrapped in tape now so I can't drop anything in between them and have it move around and short either.
@supersurfer, also thanks for your build pix. AND question on the LiFePO4 supply. Ian and others answered it well. I do want to mention that the non-isolated 5V supply is worth having and that would disappear if you used one or some of the cells to also power the board and the relays. I think Ian did a great job designing and producing a product with a specific intention in mind... and that is not as a mobile battery supply, but a high-quality battery supply for use with targeted equipment along with an integrated charging, monitoring, and control regime AND that non-isolated 5V supply.
@Gallen1119, if noone else answers soon, I'll post some recommendations.
@Markw4, no, my 'tweak mentor' is a different person than my 'audio friend'. BTW, based on 'audio friend's comments that I posted and others in some email exchanges, I doubt he will be trying the film cap bank on his Katana's +-15V. He expressed some concerns about adding much C after a fast shunt regulator. I share that, but since my main regulation setup for the Katana is with Sparkos series regulators, I do plan to try it at some point and also with some lower-quality monolythic regulators setups I have planned.
My 'tweak mentor' is a guy who makes much of his living from modifying audio gear. He's pretty far out there in much of the stuff he does and I've learned a lot OR had confirmed a lot from emailing / talking with him over many years. He uses discrete opamps as output buffers in some of his mod builds and it was in that context he prefers the LKS to the Sparkos. He specifically does not use them as I/V stages, which is why I cautioned his preference MAY not translate here.
Now, some impressions...
So I've been playing various combinations of Ian's GB gear and some of his prototype gear over the last couple of weeks, both to get it all broken in (not nearly there yet) and get some sonic impressions. Take all of this as largely preliminary, but here are some random thoughts from what I've experienced so far...
- Like @jacklee, I was not blown away by the sonics of the IVStd with the stock opamps. I won't get to opamp rolling for a week or so yet. Which opamps I have to try I posted a earlier in this thread.
- I have been playing Ian's prototype OPA861 I/V stage a good bit. I like it... very simple circuit, local on-board shunt regulation, no feedback, both balanced and single-ended outputs. I hope this one gets finalized for Ian's next offering. I have NOT tried Ian's prototype OPA1632-based I/V yet which I also have built-up here.
- LiFePO4 supply works well powering the stack and as far as I've taken it so far, produces good sonics.
- I say 'as far as I've taken it so far' because at first, I was not 'wowed' by the sonics I was getting. I tried various power combos, upgrade clocks, different output stages to no avail. AND then I remembered I was feeding the 3.3V from the LiFePO4 supply into the standard input of the FiFoPi. Ian is correct in that does 'bypass' the regulator. AND he said actually physically bypassing them is better. To find out how much degradation I was hearing, I used a couple of UCPi Ultracap supplies to power the FiFoPi / DAC combo... one charged to 5V for feeding into the 'non-LDO-bypassed' FiFoPi and the other charged to 3.3V for the DAC board. WOW, that made things POP! Now no disappointment in the sonics. While it does work to feed the 3.3V through the FiFoPi LDOs, my experience is that either feeding 5V into the LDOs so they are actually operating is much better. I suspect feeding 3.3V directly into the unit physically bypassing the LDOs will be another step up, but I have not tried it yet.
- As I said above on clocks, I've tried both Crysteks and NDK SDA and prefer the NDKs for a more dynamic, present and exciting sonic perspective. Neither sets have sufficient run-time to be fully broken in and there are some bypassing options to try, so more to come. But this is what I've heard so far. An interesting experience related to this... In preparation for starting to run the Ian GB gear, I did some mods to one of my Katana (bypassing the Microprocessor board's +-14V LDO) and listened a bit. Then I put in Ian's ES9028Q2M prototype DAC on an RPi -> IsolatorPi -> Allo Kali stack with Onetics transformer outputs. The IsolatorPi and the Kali were each powered by a 5V 6||LT3045 board from MPAudio, the DAC from a 3.3V charged UCPi. Sonics were very comparible to the Katana, perhaps even more comparible than the report I published a couple of months back when I used 3 UcPi, but with the NESSCAP parts that seemed to have an emphasis in the upper-mids / lower-highs.
When I first listened to one of the Ian actual GB DACs on an RPi -> FiFoPi stack with the Onetics, it was with the stock clocks and I was still feeding the LiFePO4 3.3V through the onboard LDO's. MEH. That combo of course was not up to what I heard previously, because of the 3.3V through the LDOs. I tried Crysteks and it was better, but still MEH+. BUT when I substituted the NDK SDAs (the same clocks as used on the Katana), while the LDO were still limiting the performance, the sonic signature was much more similar to that of the Katana. Call it MEH++. Hmmmm... clock's sonic signature matter more than I expected!. BUT THEN, when I fed the FiFoPi 5V via a UCPi, it was transformed and it was definitely roughly comparable to my prior setup with that DAC / output stage AND to the Katana.
- My main reason for using Ian's ES9028Q2M prototype DAC with the Onetics in the above comparison was to get a feel if the FiFoPi provided the same level of benefit an IsolatorPi / Allo Katana did. My 'preliminary' take on this is yes.
- Finally, my overall assessment SO FAR is that Ian's GB gear, with the right combination of clocks, output stage, and power has the potential to be as good or better than anything I have here, IMHO. BUT remember this is all very preliminary.
That's what I have so far.
Greg in Mississippi
Dear Greg,
Thanks for writing that down. Sometimes people take things for granted,for them great projects like Ian's GBs are just a toy, I expect someone to ask for a set that directly competes with Chord DAVE or MSB.
Ian, thanks for all the hard work, there are people who appreciate what you are doing and are grateful. Of course we will ask for more and more but man, thanks for being there.
Thanks for writing that down. Sometimes people take things for granted,for them great projects like Ian's GBs are just a toy, I expect someone to ask for a set that directly competes with Chord DAVE or MSB.
Ian, thanks for all the hard work, there are people who appreciate what you are doing and are grateful. Of course we will ask for more and more but man, thanks for being there.
Might not be too surprising if the Crystek clocks need lower power supply impedance vs the NDKs, in order to obtain best performance. Lots of inductance in some cases all the way from voltage regulator outputs, across circuit traces and through clock adapter board pins on the way to a clock module. Some caps that aren't too ringy with the inductance at RF seem like a good idea. Wouldn't be too surprising to find out diyiggy has a good point about putting some type of high quality 1uf film cap close to the clock module (it may be lossy enough at higher RF frequencies not to cause much problems, but still helpful for supplementing local ceramic bypass caps). Only way to find out would be to try it and see what happens.
@Markw4,
Good points. I do plan to try 1uF SMD film caps. Looking at Ian's original adapters, I believe I can also fit some larger ones... I have both 10uF & 20uF ones here, along with 220nF, along with much smaller ones. I'll try both 1uF alone and a cascade.
I DO want to stress that the Crystek are still good sounding, but a bit less exciting and engaging. Still very good technically. Others may prefer the sound of the Cryteks as I'm hearing them now.
Greg in Mississippi
Good points. I do plan to try 1uF SMD film caps. Looking at Ian's original adapters, I believe I can also fit some larger ones... I have both 10uF & 20uF ones here, along with 220nF, along with much smaller ones. I'll try both 1uF alone and a cascade.
I DO want to stress that the Crystek are still good sounding, but a bit less exciting and engaging. Still very good technically. Others may prefer the sound of the Cryteks as I'm hearing them now.
Greg in Mississippi
@Greg Stewart,
For clocks I have Crystek (2x/4xMhz), NDK (2x/4xMhz), and PulsarClock (2xMhz).
I have another setup using Soekris DAC board together with Ian's McFifo and clock board. I was unable to test the Crystek as somehow the Soekris DAC refuses to lock when using the Crystek. Between the NDK and Pulsar I actually preferred the NDK for the exact same sonic attributes you mentioned. Perhaps the Pulsar needs more run-in or better DC supply idk as I switched to some other projects and just stick with the NDK.
And thanks for the tip about bypassing the LDO on the fifopi. I'll definitely need to try that. This is exactly why DIY is fun!
For clocks I have Crystek (2x/4xMhz), NDK (2x/4xMhz), and PulsarClock (2xMhz).
I have another setup using Soekris DAC board together with Ian's McFifo and clock board. I was unable to test the Crystek as somehow the Soekris DAC refuses to lock when using the Crystek. Between the NDK and Pulsar I actually preferred the NDK for the exact same sonic attributes you mentioned. Perhaps the Pulsar needs more run-in or better DC supply idk as I switched to some other projects and just stick with the NDK.
And thanks for the tip about bypassing the LDO on the fifopi. I'll definitely need to try that. This is exactly why DIY is fun!