Yeah the NAA system is pretty good. If you can get it to work that is. Much easier to use a small form factor SOM computer he has already built a turn key image for. Such as:
mikroBUS on HummingBoard-Gate | SolidRun
That mikroBUS system sure is cool. It would be awesome if someone built a I2S/DSD interface with awesome clocks on a" Clickboard" that could just plug in to one of these mini computers. It's looking like it would be doable for someone who knew what he was doing. Easy rapid prototyping available as well.
Last edited:
I've tried two varieties of NAA and both were discovered by HQPlayer without any problems.
The first is based on an Intel Atom motherboard running audiolinux and works perfectly icw a JLSounds USB board (which includes isolation and reclocking). I've been upsampling CD FLAC rips to DSD256 on HQPlayer and streaming the results to this NAA unit - very nice too.
For the second I am trying to use a Beaglebone Black with miero's Botic driver, allowing external isolation/reclocking, that would dispense with the USB board as I2S/DSD data would be available on the BBB's pins. By installing the HQPlayer NAA module on top of a standard Botic image I came within a gnat's whisker of it all working; it was discovered by HQPlayer and I was able to configure output for it but it just wouldn't play because of a 'bug' in the NAA code. The bug has now been fixed but only released on a later version (Stretch) of Debian Linux and won't be back-ported (Botic uses Debian Wheezy, which is two versions older). That means that Botic will have to be upgraded to Stretch to use with NAA and that is unlikely to be trouble free - shame as I don't have the skills to fix any problems. On the other hand, the theory says that is should be simple to build something with the functionality to the SOtM device (which uses a USB output) by installing a Debian Stretch ISO on the BBB (or similar board of your choice) and just installing the latest NAA release onto it. As I understand it, Debian Stretch is the first version of Debian with a native DSD-ready kernel out of the box. I'm pondering how to tackle the Botic upgrade at the moment. In case anyone is wondering why; I already have a NW renderer based on the BBB/Botic that uses Acko's SO3 reclocker and a TP Buffalo IIIse DAC and it would be handy to get that interfaced to HQPlayer.
Ray
The first is based on an Intel Atom motherboard running audiolinux and works perfectly icw a JLSounds USB board (which includes isolation and reclocking). I've been upsampling CD FLAC rips to DSD256 on HQPlayer and streaming the results to this NAA unit - very nice too.
For the second I am trying to use a Beaglebone Black with miero's Botic driver, allowing external isolation/reclocking, that would dispense with the USB board as I2S/DSD data would be available on the BBB's pins. By installing the HQPlayer NAA module on top of a standard Botic image I came within a gnat's whisker of it all working; it was discovered by HQPlayer and I was able to configure output for it but it just wouldn't play because of a 'bug' in the NAA code. The bug has now been fixed but only released on a later version (Stretch) of Debian Linux and won't be back-ported (Botic uses Debian Wheezy, which is two versions older). That means that Botic will have to be upgraded to Stretch to use with NAA and that is unlikely to be trouble free - shame as I don't have the skills to fix any problems. On the other hand, the theory says that is should be simple to build something with the functionality to the SOtM device (which uses a USB output) by installing a Debian Stretch ISO on the BBB (or similar board of your choice) and just installing the latest NAA release onto it. As I understand it, Debian Stretch is the first version of Debian with a native DSD-ready kernel out of the box. I'm pondering how to tackle the Botic upgrade at the moment. In case anyone is wondering why; I already have a NW renderer based on the BBB/Botic that uses Acko's SO3 reclocker and a TP Buffalo IIIse DAC and it would be handy to get that interfaced to HQPlayer.
Ray
Last edited:
Ray, perhaps Miero could help with this Botic upgrade. Heard of a Botic6 planned but not sure if this will use Debian Stretch?
The MikroBus does not have audio interface. Just meant for communications control... so I am not sure how I2S/DSD can be made to fit here?
I'm already posting on the Botic thread Acko. I think miero s planning to upgrade to Jessie at some point but hasn't thought too much about Stretch yet.
Ray
These are slow devices with I2C/SPI interfaces, great for reading temperatures etc, not high speed digital audio.
Ahh. Well cool concept anyways. I guess the best bet would be to use mPCIe cards instead. Should have enough juice through that bus. 🙂
Probably could be done but why start from there when so much work has already been done on the Beaglebone Black/Botic combo?
My NAA uses a five year old Atom D510 motherboard in a repurposed home server. Works fine as a learning/development platform.
http://www.diyaudio.com/forums/digital-line-level/273474-best-dac-no-dac-23.html#post4380943
Ray
I assume you mean the Intel Atom device? JLSounds USB board will only go to DSD256 currently. I have no idea how it compares to a reclocked Amanero, never having heard one. I believe the Atom motherboard will cope with DSD512 as loading isn't that high with DSD256. That project is only a stepping stone to learn/develop pending Acko's new units.
BTW, with BBB/Botic I believe resource constraints will limit to DSD256.
Ray
I was talking about the BBB. Wondering if they can sound as good or better than USB. Like with Acko's cape and reclocker. It would sure be cool to program a BBB as an NAA, and send out DSD direct via Acko's cape and reclocker! 🙂
Last edited:
Sorry, I wasn't sure.
I'm already using BBB/Botic with Acko's SO3 feeding a TP Buffalo IIIse/Legato and it sounds incredibly good. Acko's SO3 also provides the clocking to the BBB and the Buffalo III - full sync mode! I can't say whether it is better than USB set-ups as I've not that much experience of them but intuitively I feel that it must be good to remove the USB board from the processing chain.
I also haven't done any direct comparison between the BBB/Atom projects yet.
I have played DSD256 recordings through the BBB project and it worked fine with wired Ethernet connection.
I described my experience so far with trying to use BBB/Botic with NAA a few posts back - looks like there's a way to go on that journey.
Ray
Talking of your new 'no-DAC' modules Acko, how is it going with them?
Sorry if I asked this before but will they still have the 1.6V DC offset? I ask because I'm starting to assemble my tube-based filter/buffer that I plan to use on the output of your new units (sans onboard filter) and components will vary depending on whether the DC is available for tube biasing (or not).
Ray
Sorry if I asked this before but will they still have the 1.6V DC offset? I ask because I'm starting to assemble my tube-based filter/buffer that I plan to use on the output of your new units (sans onboard filter) and components will vary depending on whether the DC is available for tube biasing (or not).
Ray
The idea was the more direct the path the better it is. So, i2s direct from audio processors will be better than going through the USB layer and then getting converted back to I2S. Likewise going through Ethernet layers like NAA, renderers may have some impact on the SQ. More tests needed to confirm these but as you have already seen with your Mirus DAC, the SDCard direct outperforms USB and network renderers.
In my experience, on quad Buffalo with Andrea Mori tube output in asinc mode, BBB/Botic cape and Chronus, is slightly worse than Paul Pang V3 and Jlsounds with reclock cape and Crystek oscillators. The winner combination is a bit more expensive than the worse. Probably, sound improvement don´t justify money difference.
The player in both cases is Foobar. To play with BBB, I use Unpn Foobar component. Play only PCM.
Cheers
Mostly sorted now with the dc offset, the servo is nulling it nicely gain but then again this is an active circuit so I would think a cap will be needed just in case the servo acts up. The offset is not constant because of the DSD PPM signal so needs to be tracked quickly and also when music is stopped it goes one leg up to 3.3V if not nulled quickly! Most Amps already have an input coupling capacitor so this is sufficient. I have connected it direct to my Amps that has its own input caps and no issues so far.
Last edited:
Thanks Acko. I guess you null the DC before passing the signal to the LP filter?
I'm just installing a fresh Debian Stretch image on my BBB as the first step towards another attempt at getting it working as an HQPlayer NAA - will report back in due course.
Ray
I'm just installing a fresh Debian Stretch image on my BBB as the first step towards another attempt at getting it working as an HQPlayer NAA - will report back in due course.
Ray
- Status
- Not open for further replies.