I’ve been planning to order WandBoard while ordering some components too. Hardware wise it is very close to CuBox-i (same SoC), but the surrounding support peripherals are just different.
Supporting it with another variant of the same image shouldn’t be a be big problem, but I will only do it once I have the hardware myself to test with. I’m not expecting the results to be much different from CuBox-i.
These kind of problems are usually due to some compatibility issues with the USB hardware. Similar kind of pain I’ve had with USB3 ports on iMac (also frequently solved by plugging DAC to the USB2 hub on the wired Apple keyboard). Extreme example being that iMac locks up during boot if Resonessence Labs HERUS DAC is plugged in while booting up… And now due to USB stack rewrites on El Capitan some new issues with some other gear…
And compatibility problems are not limited to just USB. Firewire things are very sensitive, for that reason TCAT lists the specific supported Firewire adapter chips for their Dice chip. And I have one PCIe sound card that refuses to play a single sample out on my Xeon workstation, although it is recognized and all software controls work (worked fine on older machine though).
What I’ve tested, XMOS-based USB Audio Class implementations have been working flawlessly with CuBox-i.
Apart from these, I have one NAA running on Atmel’s ARM SoC. But it is not yet at level of having easy image available, currently running NAA on Debian Stretch.
So I’d say there’s no universal “works everywhere” solution.
Thank you…I look forward to it. My system sounds better than ever thanks to HQPlayer!
I can’t find these images. Considering spending some time making a beaglebone setup today . . .
The clicks on the Pi using DSD aren’t going away. I just ordered a BeagleBone Black.
Andybob - as mentioned, I’m not a Pi guy. But have you tried running your USB connection through a powered USB hub? Often makes such sonic artefacts go away on little ARM audio devices. And I’m referring to an AC wall socket powered hub, not USB powered. Also, changing DACs (if you’ve got the option) sometimes eliminates such noise also.
None of this should matter, I know. But am bringing it up because it often does.
I’m using an UpTone Regen, which is powered. I think the clicks get in before it.
In a little ARM based device, I’d bet dollars to doughnuts that you are right. But if you are using a Regen (nice), then I very much doubt a powered USB hub would make a whit of difference. After all, a Regen IS a powered single-port USB hub, with a little extra goodness sprinkled in.
Can anyone suggest any command line entries to show the current status of the NAA service?
Hi Erik
ps (process status) is the linux command that shows the status of services (or daemons). There are various ways of using it explored here and here.
If you are using the NAA Raspberry Pi image provided by Jussi then you won’t be able to PuTTY in to the device to run that command but if you are running any of the usual Linux distros on the Pi then it should work fine.
Thanks, I’m running Ubuntu Trusty on an Atom PC for the moment. I was going to run the NAA on a Raspberry PI until I read about the pops, so I have a Cubox-i on order. I’ll eventually migrate over to the Cubox-i. But I’m not sure if it better to use Jussi’s image or one distros like Trusty.
I havent had any issues with Jussi’s NAA image on the Pi or the BBB. It’s extremely lightweight compared even to the most minimal linux installation.
If I wanted to use the Pi or BBB for other purposes, or needed Wi-Fi capability I would run linux, but in the absence of those things the NAA image ticks the boxes for me.
Hi Andrew.
You seems to have better success with the Pi as a NAA device than me…and several others.
Are you streaming DSD256 to this?
DSD128 to a Pi 2 seems to almost work for me but I still gets faint pops or clicks once in a while here.
I haven’t given up on the Pi yet and I’m still trying to make it work perfectly as a NAA.
In the mean time I’m using an older Atom dualcore Asrock pc with Debian Stretch. That works perfectly…
I should clarify. I DO get soft occasional pops and clicks with the Pi when streaming DSD128 (can’t test DSD256 on my DAC) regardless of which NAA software is being used. I now believe that is because of the USB implementation in the Pi. What I had intended to say was that the NAA image software was causing zero issues compared with the Linux NAA daemon but both still leave me with pops and clicks.
I’m currently using a BeagleBone Black as an NAA (no pops or clicks) and over the weekend will be trying out a CuBox-i2e. There are separate threads in this section for each device.
Newbie here but having issues…I followed andybob’s instruction and got the image loaded onto SD into rpi b+. Booted it up and at login and password prompt but can’t get by. Tried login: rpi pass: raspberry and other combinations but no luck. Am I missing something here?
What is the exact image you have used? We all tried a few different approaches during the Great Post X-mas Pi Frenzy… 
Recent DietPi images use root/dietpi. Signalysts own image for the Pi is entirely selfrunning and has user logins disabled.
It’s NAA 3.1.1 2.0 but appears to still ask for login.