It seems that every month or two a new flavor of single board computer (SBC) is launched. One that recently caught my eye was the NanoPi A64 by FriendlyArm. This uses the four-core A64 chip from Allwinner. On paper this seems to be roughly equivalent to the Pi 3 in terms of processing power, however, the AllWinner chip includes onboard audio, and FriendlyArm's board brings out the DAC lines to a headphone jack. The chip's 24/192 codec means that you don't need to add a DAC, although I have yet to test the output for audio performance. I have used a similar onboard codec on a different AllWinner based board and I have been pleased with the sound quality (but again have not done any actual quantitative testing).
One interesting difference between this board and the Pi is that the AllWinner chip also provides an SPDIF output, and this has been brought out to a GPIO pin on the board. See the section "Layout" in the WIKI for the NanoPi A64 for more info. This means that if the quality of the onboard codec is not sufficient, you should be able to connect an external DAC with SPDIF input to the board. This provide flexibility for audio reproduction that the Pi platform just cannot offer.
In addition and like the Pi 3, the NanoPi A64 has onboard WiFi, so connectivity to internet streams or to local resources on your LAN is already included - no head scratching to figure out if your WiFi dongle will be supported by the OS!
Other connectivity on the board includes:
* NOTE: For USB there is a single USB ver2.0 controller. If you choose to use multiple USB DACs (an approach I have been using to achieve synchronized multi-channel playback from a Pi) all devices will remain in sync (when using a DAC having a USB controller running in adaptive mode). This was reported to be a problem with an Orange Pi board, which had three separate controllers and so could not be used for synchronous playback without adding a hub.
Currently there are two operating system options: Ubuntu Core and Ubuntu with the Mate desktop. The latter one is what one would want to use, although the current image available from FriendlyArm uses Ubuntu 15.10, which is recent but not the newest. This shouldn't really matter for audio applications. Installing the image is much like Raspberry Pi - you download the file and transfer it to a SIM card that fits in a slot on the board.
Physically the board is a bit smaller than the Raspberry Pi footprint. Power is supplied via the now almost standard miniUSB female connector, which makes it much more user friendly than, for instance, an OrangePi board that has a laptop-like pin-style connector.
I placed an order for two boards ($25 each) from FriendlyArm and received them in about 2-3 weeks time just past the Christmas/New Year rush. These came packed very well, with USB type A to mini B power cables. They may also be supplying an external WiFi antenna for free with new shipments but I did not receive one. Combine this board with a $5 power supply from MCM or other supplier, connect to your HDMI monitor, install the image, and you should be off and running.
I will post additional info about these boards when I have had a chance to set up and evaluate one in a little more detail. For now I thought I would raise the awareness of this SBC as an interesting alternative to the Pi for audio and DSP processing.
.
One interesting difference between this board and the Pi is that the AllWinner chip also provides an SPDIF output, and this has been brought out to a GPIO pin on the board. See the section "Layout" in the WIKI for the NanoPi A64 for more info. This means that if the quality of the onboard codec is not sufficient, you should be able to connect an external DAC with SPDIF input to the board. This provide flexibility for audio reproduction that the Pi platform just cannot offer.
In addition and like the Pi 3, the NanoPi A64 has onboard WiFi, so connectivity to internet streams or to local resources on your LAN is already included - no head scratching to figure out if your WiFi dongle will be supported by the OS!
Other connectivity on the board includes:
- Raspberry Pi "compatible" 40-pin GPIO header
- separate, dedicated I2S lines
- external WiFi antenna connector
- HDMI
- Gigabit ethernet via RealTek RTL8211E
- two USB 2.0 ports*
- IR receiver
* NOTE: For USB there is a single USB ver2.0 controller. If you choose to use multiple USB DACs (an approach I have been using to achieve synchronized multi-channel playback from a Pi) all devices will remain in sync (when using a DAC having a USB controller running in adaptive mode). This was reported to be a problem with an Orange Pi board, which had three separate controllers and so could not be used for synchronous playback without adding a hub.
Currently there are two operating system options: Ubuntu Core and Ubuntu with the Mate desktop. The latter one is what one would want to use, although the current image available from FriendlyArm uses Ubuntu 15.10, which is recent but not the newest. This shouldn't really matter for audio applications. Installing the image is much like Raspberry Pi - you download the file and transfer it to a SIM card that fits in a slot on the board.
Physically the board is a bit smaller than the Raspberry Pi footprint. Power is supplied via the now almost standard miniUSB female connector, which makes it much more user friendly than, for instance, an OrangePi board that has a laptop-like pin-style connector.
I placed an order for two boards ($25 each) from FriendlyArm and received them in about 2-3 weeks time just past the Christmas/New Year rush. These came packed very well, with USB type A to mini B power cables. They may also be supplying an external WiFi antenna for free with new shipments but I did not receive one. Combine this board with a $5 power supply from MCM or other supplier, connect to your HDMI monitor, install the image, and you should be off and running.
I will post additional info about these boards when I have had a chance to set up and evaluate one in a little more detail. For now I thought I would raise the awareness of this SBC as an interesting alternative to the Pi for audio and DSP processing.
.
Last edited:
Looks interesting. Do you need cooling fan for audio apps? IMHO having just pins to connect IR sensor would be more convenient for DIYers. WiFi on Pi 3 doesn't work well for me. Have you tried it here? Also missing USB 3. You can get it in the most expensive ODROID board Hopefully they will add USB 3 and Gigabit network in the next Pi generation 
.
.Well don't get too excited yet...
I've been playing around with one of the boards using the Ubuntu-MATE image from NOV 2016 that you can download via the FriendlyArm web site.
I was able to log on and cut up some internet streaming audio stations using VLC, which comes installed. Audio quality is good. Have not yet done much testing. But the OS port is a little less than stelllar. Firefox would crash upon launch, so I installed a very small browser called Dillo to get some basic internet utility working but its very basic.
I think that the hardware on this board has some very good potential. I would wait until the next OS release comes out before getting too excited about this board. Hopefully that will happen in the next couple of months (after Chinese new year is over).
In the meantime, I will still play around and see what I can do with it.
I've been playing around with one of the boards using the Ubuntu-MATE image from NOV 2016 that you can download via the FriendlyArm web site.
I was able to log on and cut up some internet streaming audio stations using VLC, which comes installed. Audio quality is good. Have not yet done much testing. But the OS port is a little less than stelllar. Firefox would crash upon launch, so I installed a very small browser called Dillo to get some basic internet utility working but its very basic.
I think that the hardware on this board has some very good potential. I would wait until the next OS release comes out before getting too excited about this board. Hopefully that will happen in the next couple of months (after Chinese new year is over).
In the meantime, I will still play around and see what I can do with it.
I spent a little more time with the A64 board. I got WiFi working and that was pretty straightforward. I installed gstreamer1.0 and I was able to stream audio using my GSASysCon streaming controller script. Quality seems excellent. There is some odd glitch in which the audio does not begin for about 30-60 seconds but then is perfectly synchronized with other streaming audio network clients. Very strange. This could be due to the fact that I can't seem to get NTP working.
There are some other glitches, and they all point to a not quite well put together operating system port. I'm not too surprised, because the board has only been available for a month or two. These things will probably shake out. I did find a blog entry by someone who was able to get Ubuntu upgraded to 16.04 so I might try to contact them for some ideas or to see if they can put up their image on the web where it can be downloaded.
I think it is really great to have an onboard codec available for audio use. This makes the board really interesting for me, but the OS needs to be a little more reliable before I can say it is ready for the general public.
There are some other glitches, and they all point to a not quite well put together operating system port. I'm not too surprised, because the board has only been available for a month or two. These things will probably shake out. I did find a blog entry by someone who was able to get Ubuntu upgraded to 16.04 so I might try to contact them for some ideas or to see if they can put up their image on the web where it can be downloaded.
I think it is really great to have an onboard codec available for audio use. This makes the board really interesting for me, but the OS needs to be a little more reliable before I can say it is ready for the general public.
There are numerous better boards than a PI out there.
That's well known since years.
What they have pretty much all in common:
1. Software (supoort) sucks!!
2. Community support sucks!
3. Add-On gadgets/HW/HATS/.... close to not existing
The only way I see around it, would be a board that'd be pretty
much compatible (HW and SW) with a PI.
Basically a PI SW image (kernel) should work on such a board.
################################
If you want SPDIF out - buy a HifiBerry Digi+ HAT.
That'll be 10 times better than any onboard solution.
That's well known since years.
What they have pretty much all in common:
1. Software (supoort) sucks!!
2. Community support sucks!
3. Add-On gadgets/HW/HATS/.... close to not existing
The only way I see around it, would be a board that'd be pretty
much compatible (HW and SW) with a PI.
Basically a PI SW image (kernel) should work on such a board.
################################
If you want SPDIF out - buy a HifiBerry Digi+ HAT.
That'll be 10 times better than any onboard solution.
+1 on that sentiment!
Far and away the Pi is the platform that works pretty much exactly as it should and if not you can find someone who has reported/posted about the problem before, and people posting solutions, etc. Although I had used command line linux back a couple of decades and so was (faintly) familiar with it, because the Pi can boot up into a GUI and then you can start to dabble in the terminal, the Pi really helped me ease through the transition back into non-GUI configuration and programming. I'm not any kind of expert, but I am now comfortable doing what I need to do.
Sure, you can buy, buy, buy all manner of add-on HATs and USB dongles for WiFi, DACs, etc. but when a capable board comes along with these already included on-board it gets my attention.
Believe me. I got my eyes on the market. And I spent numerous hours on getting other platforms up2speed. The problems usually pop up on the 2nd glance.
E.g. PiCorePlayer and Moode come with a special PI kernel that has over 60 patches applied (Clive Messers I2S/audio patch set)
It's one thing to get something working. Another thing is to get something properly working.
"...when a capable board comes along..."
Hmmh. Again. It's one thing to offer a certain feature. Another thing is to offer a feature at highest quality.
(That's why I consider e.g. PI3 Audio, Bluetooth and WLAN useless features.)
Obviously your level of expectations sets the frame.
E.g. PiCorePlayer and Moode come with a special PI kernel that has over 60 patches applied (Clive Messers I2S/audio patch set)
It's one thing to get something working. Another thing is to get something properly working.
"...when a capable board comes along..."
Hmmh. Again. It's one thing to offer a certain feature. Another thing is to offer a feature at highest quality.
(That's why I consider e.g. PI3 Audio, Bluetooth and WLAN useless features.)
Obviously your level of expectations sets the frame.
Last edited:
I forgot to add that I got NTP running and after that the delay in the audio coming on is gone. I left the board running overnight and this morning when I started streaming audio to it, it worked immediately, as expected. Again, with the onboard codec and 4-cores like the Pi 3 this makes for a great on-board DSP crossover and DAC for a 2-way speaker. Just connect it to your amps and you can be up and running.
By streaming audio to it, the lack of an ADC is no concern. That is one very important reason why I do streaming audio in all of my projects!. I am able to stream uncompressed PCM audio at bit depths and samples rates that provide high quality audio, although they are not the highest available (because you don't need those formats for high quality audio playback), all over 2.4G WiFi (no special or expensive hardware is needed). Even if the source and speakers are only 3 feet apart I would do this, because it doesn't matter how far apart they are as long as you have a sufficient WiFi signal.
By streaming audio to it, the lack of an ADC is no concern. That is one very important reason why I do streaming audio in all of my projects!. I am able to stream uncompressed PCM audio at bit depths and samples rates that provide high quality audio, although they are not the highest available (because you don't need those formats for high quality audio playback), all over 2.4G WiFi (no special or expensive hardware is needed). Even if the source and speakers are only 3 feet apart I would do this, because it doesn't matter how far apart they are as long as you have a sufficient WiFi signal.
UPDATE on NTP:
As I mentioned above I got NTP working... but the weird thing was that I couldn't get the status of the sync with peers/servers. When I typed:
The command would just hang for awhile and then come back with the error message "Name or service not known" after timing out.
I finally solved the mystery. The /etc/hosts file was completely empty. No entry for localhost means the machine is not aware of how to access itself. I changed this to:
and thereafter ntpq started working as expected. Previously I could only check that ntpd was running and active using systemctl, but that told me nothing of how well it was sync'd to my other computers on the LAN. Now I can see all the gory details and sync is well under 100 usec, typically less than 25 usec. I have been listening to streaming audio all day and it's working great.
I like this new board, even with the hiccups I have experienced. Also, it seems to run very cool using the OnDemand setting for frequency scaling. Without heatsink, the chip is barely warm to the touch. Temp monitor reports 30C after long use. Nice.
As I mentioned above I got NTP working... but the weird thing was that I couldn't get the status of the sync with peers/servers. When I typed:
Code:
ntpq -pnI finally solved the mystery. The /etc/hosts file was completely empty. No entry for localhost means the machine is not aware of how to access itself. I changed this to:
Code:
::1 localhost
127.0.0.1 localhostI like this new board, even with the hiccups I have experienced. Also, it seems to run very cool using the OnDemand setting for frequency scaling. Without heatsink, the chip is barely warm to the touch. Temp monitor reports 30C after long use. Nice.
Last edited:
More progress...
I wanted to be able to not only stream audio to the A64 board but also run some DSP filters using ecasound+LADSPA (I use these routinely on other boards like the Pi). The only problem was that the operating system port for the A64 included ALSA but no the snd-aloop (ALSA loopback) module and I needed that to transfer the audio from the gstreamer streaming audio receiver process to the ecasound process. I found some instructions on the web outlining how to recompile and install alsa but I could not get these to work.
So I took another path. I used GsaSysCon and modified the client side output to send the audio data to a named pipe and then launch ecasound with input set to the named pipe, and raw audio streaming through the pipe. At first I could not get the audio to work correctly - I got full volume noise. This was telling me that there was some miscommunication with the audio format. After trying lots of different options I figured out that the audio must be formatted to float32 for the pipe to work. I was able to make the format change in the CLIENT_SINK string of the client configuration file used by GsaSysCon and then direct it to launch a script to create the pipe and fire up ecasound. Now it's working like a charm!
I can now say that, with a little additional tweaking and configuration, it's possibly to get the NanoPi A64 board to work with both the GASSysCon streaming audio system and ecasound. I hope to test out the system more in the upcoming days and hopefully get some measurements on the audio output from the board. This really seems like it could make a nice embedded crossover board for an active speaker project.
I wanted to be able to not only stream audio to the A64 board but also run some DSP filters using ecasound+LADSPA (I use these routinely on other boards like the Pi). The only problem was that the operating system port for the A64 included ALSA but no the snd-aloop (ALSA loopback) module and I needed that to transfer the audio from the gstreamer streaming audio receiver process to the ecasound process. I found some instructions on the web outlining how to recompile and install alsa but I could not get these to work.
So I took another path. I used GsaSysCon and modified the client side output to send the audio data to a named pipe and then launch ecasound with input set to the named pipe, and raw audio streaming through the pipe. At first I could not get the audio to work correctly - I got full volume noise. This was telling me that there was some miscommunication with the audio format. After trying lots of different options I figured out that the audio must be formatted to float32 for the pipe to work. I was able to make the format change in the CLIENT_SINK string of the client configuration file used by GsaSysCon and then direct it to launch a script to create the pipe and fire up ecasound. Now it's working like a charm!
I can now say that, with a little additional tweaking and configuration, it's possibly to get the NanoPi A64 board to work with both the GASSysCon streaming audio system and ecasound. I hope to test out the system more in the upcoming days and hopefully get some measurements on the audio output from the board. This really seems like it could make a nice embedded crossover board for an active speaker project.
headphone output 1kHz spectrum and THD+N measurement
I did a quick measurement of the audio spectrum and THD+N level with a 1kHz stimulus. I used gstreamer's built in audiotestsrc to generate the sine wave stimulus. I really do not know how pure of a signal it will generate, but I am not trying to be too obsessive about it at this point, just get some numbers. To measure the spectrum I used REW on another computer.
At 0.009%, the THD is not bad at all. THD+N is higher at 0.045%. There is some high frequency crap (hey this is a $25 single board computer) but I would not worry about it too much because the level is 100dB below the maximum input level of my audio interface (on the computer taking the measurement). That's lower than I expected, really. The problem is that the maximum output level from the NanoPi A64 is rather low. It's on the order of 0.3Vrms judging from the input sensitivity of my interface. This is lower than another board that I own from a different manufacturer that uses a slightly different single core Allwinner SOC.
I should say that I did not take any special precautions when making this test with how the DUT and test system were arranged. They are plugged into the same circuit but at different wall receptacles and are about 8 feet apart. A 3.5mm to dual RCA cord of the cheap variety was strung between them. The NanoPi A64 was powered with the garden variety 2A 5V smps.
I'd say that this is not bad for a $25 SBC with onboard 24/192 codec.
I did a quick measurement of the audio spectrum and THD+N level with a 1kHz stimulus. I used gstreamer's built in audiotestsrc to generate the sine wave stimulus. I really do not know how pure of a signal it will generate, but I am not trying to be too obsessive about it at this point, just get some numbers. To measure the spectrum I used REW on another computer.
At 0.009%, the THD is not bad at all. THD+N is higher at 0.045%. There is some high frequency crap (hey this is a $25 single board computer) but I would not worry about it too much because the level is 100dB below the maximum input level of my audio interface (on the computer taking the measurement). That's lower than I expected, really. The problem is that the maximum output level from the NanoPi A64 is rather low. It's on the order of 0.3Vrms judging from the input sensitivity of my interface. This is lower than another board that I own from a different manufacturer that uses a slightly different single core Allwinner SOC.
I should say that I did not take any special precautions when making this test with how the DUT and test system were arranged. They are plugged into the same circuit but at different wall receptacles and are about 8 feet apart. A 3.5mm to dual RCA cord of the cheap variety was strung between them. The NanoPi A64 was powered with the garden variety 2A 5V smps.
I'd say that this is not bad for a $25 SBC with onboard 24/192 codec.
Attachments
Last edited:
Comparison with a low cost but good quality USB DAC
I wanted to put the DAC output measurement I showed in the last post into perspective by comparing it with that from a USB DAC that I use, the HiFiMeDIY Tiny SABRE DAC. It uses a PCM2706 USB receiver (limited to 16bits/48kHz) and the ES9023 DAC IC. I first tried this in the NanoPi A64, but the OS did not seem to recognize it when I plugged it in. So instead I plugged it into my $9 CHIP (a single core AllWinner based SBC from TheNextThing Co) and it worked flawlessly there.
I used the same protocol as in the last post to generate a 1kHz sine wave and measure the spectrum and THD+N. The performance is much better all around with the TINY SABRE DAC. First off, the level is much higher. The ES9023 can output just over 2Vrms on its unbalanced outputs, and this is reflected in the higher signal level. But the THD at 0.006% and especially the lower noise floor component of the THD+N of 0.007% is much improved, and the noise floor itself looks cleaner in the spectrum. Even though this is just a $30 USB powered DAC (and a really small one at that!) the performance is excellent. The second order harmonic towers above the higher order components by 20dB, so in the real world the performance is even better than these numbers indicate (because the lowest order harmonic dominates). See the attached plot for all the details.
While I was playing around I also measured the CHIP's onboard DAC (not shown). This was slightly better than the DAC in the A64, but neither are in the league with the ES9023 based USB DAC. Still, for casual headphone listening or for a small low-powered 2-way active speaker the onboard codecs in the A64 and CHIP SBCs are adequate for decent, if not quite audiophile quality, audio output.
I wanted to put the DAC output measurement I showed in the last post into perspective by comparing it with that from a USB DAC that I use, the HiFiMeDIY Tiny SABRE DAC. It uses a PCM2706 USB receiver (limited to 16bits/48kHz) and the ES9023 DAC IC. I first tried this in the NanoPi A64, but the OS did not seem to recognize it when I plugged it in. So instead I plugged it into my $9 CHIP (a single core AllWinner based SBC from TheNextThing Co) and it worked flawlessly there.
I used the same protocol as in the last post to generate a 1kHz sine wave and measure the spectrum and THD+N. The performance is much better all around with the TINY SABRE DAC. First off, the level is much higher. The ES9023 can output just over 2Vrms on its unbalanced outputs, and this is reflected in the higher signal level. But the THD at 0.006% and especially the lower noise floor component of the THD+N of 0.007% is much improved, and the noise floor itself looks cleaner in the spectrum. Even though this is just a $30 USB powered DAC (and a really small one at that!) the performance is excellent. The second order harmonic towers above the higher order components by 20dB, so in the real world the performance is even better than these numbers indicate (because the lowest order harmonic dominates). See the attached plot for all the details.
While I was playing around I also measured the CHIP's onboard DAC (not shown). This was slightly better than the DAC in the A64, but neither are in the league with the ES9023 based USB DAC. Still, for casual headphone listening or for a small low-powered 2-way active speaker the onboard codecs in the A64 and CHIP SBCs are adequate for decent, if not quite audiophile quality, audio output.
Attachments
Well, upon further review...
I posted some gripes about the board and OS support on the FriendlyArm forum. The response I got was, essentially, like this:
Sorry we can't get any help from AllWinner so this is the best we can do.
I take this to mean that I should not expect any improvements anytime soon, or ever.
Despite the promise of the hardware this is another example of poor OS porting and product support. Reminds me of OrangePi, another manufacturer using AllWinner SOCs. Until there is much better mainstream kernel support for these products I can't really recommend them after all...
Instead of using it as a streaming audio client I will just re-purpose it as a NTP server for my LAN.
I posted some gripes about the board and OS support on the FriendlyArm forum. The response I got was, essentially, like this:
Sorry we can't get any help from AllWinner so this is the best we can do.
I take this to mean that I should not expect any improvements anytime soon, or ever.
Despite the promise of the hardware this is another example of poor OS porting and product support. Reminds me of OrangePi, another manufacturer using AllWinner SOCs. Until there is much better mainstream kernel support for these products I can't really recommend them after all...
Instead of using it as a streaming audio client I will just re-purpose it as a NTP server for my LAN.
So, "FriendlyArm" isn't so friendly after all. Too bad.
Long term, my OrangePi is still working just fine... Tinkerer types willing to mess with it will be rewarded with success. At least I was. Once you figure out which OS port to install for the particular board, it's just like a desktop PC.
Long term, my OrangePi is still working just fine... Tinkerer types willing to mess with it will be rewarded with success. At least I was. Once you figure out which OS port to install for the particular board, it's just like a desktop PC.
I bought the OrangePi PC. I did get it working OK but I was not excited about it at all. I think you had a different (more capable) model, which seems to be more of a success.
Well, I've decided to sell off all three of the A64's that I bought since I am no longer using them. The set is for sale on Ebay now...
Three quad-core NanoPi A64 single board computers. Onboard WiFi+HDMI+sound | eBay
Three quad-core NanoPi A64 single board computers. Onboard WiFi+HDMI+sound | eBay
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.