MDAC First Listen (part 00110010)
- Thread starter 44000khz
- Start date
- Status
Well, it's complicated.
Jarek gave me the board(s) on Friday along with a microSD card and an UART USB interface and I wanted to get something done during the weekend.
I definitely wanted to work with the ARM board first, get it running before connecting the DAC. The problem is that the debug UART is on the DAC board and the one on the M1 doesn't have a header soldered and I don't have such header here to solder it on. Additionally, it turned out that I have two HDMI cables, but both of them were miniHDMI to HDMI.
That's fine, I just wanted to get a headless system going over the network, but I found myself lacking a card reader - I have one which seems to work only in read-only mode, then there's the Zoom H1 audio recorder which froze my system when I tried to write to the SD card and my Nikon camera, which - after a few hours looking for the special USB cable - turns out to not export the card to the desktop OS. So I was basically unable to even write the image to the card.
I had this tiny microSD-to-USB reader, which I gave away as a present a month ago.
Ordering everything necessary, I now have a HDMI-HDMI cable, three new microSD readers and a bunch of other things. Trying various images, none wants to boot - there's nothing on HDMI or even the network. Then I read up that this board needs 5V/2A power, as if everybody has a personal power plant for an iPad at home (I don't even have a smartphone!).
Scrambling all my ~5V DC PSUs, I have one 4.5V/0.55A microUSB for my phone, another one 5V/0.55A for my camera, 5V/0.38A for my powered USB hub, a linear PSU of unknown origins (measured 4.7V open) and my desktop computer. No USB Y-cable, unfortunately.
None seem to work, not even my desktop PC. Ordering one personal nuclear power plant today, to power the board on thursday if everything goes according to plan.
Jarek gave me the board(s) on Friday along with a microSD card and an UART USB interface and I wanted to get something done during the weekend.
I definitely wanted to work with the ARM board first, get it running before connecting the DAC. The problem is that the debug UART is on the DAC board and the one on the M1 doesn't have a header soldered and I don't have such header here to solder it on. Additionally, it turned out that I have two HDMI cables, but both of them were miniHDMI to HDMI.
That's fine, I just wanted to get a headless system going over the network, but I found myself lacking a card reader - I have one which seems to work only in read-only mode, then there's the Zoom H1 audio recorder which froze my system when I tried to write to the SD card and my Nikon camera, which - after a few hours looking for the special USB cable - turns out to not export the card to the desktop OS. So I was basically unable to even write the image to the card.
I had this tiny microSD-to-USB reader, which I gave away as a present a month ago.
Ordering everything necessary, I now have a HDMI-HDMI cable, three new microSD readers and a bunch of other things. Trying various images, none wants to boot - there's nothing on HDMI or even the network. Then I read up that this board needs 5V/2A power, as if everybody has a personal power plant for an iPad at home (I don't even have a smartphone!).
Scrambling all my ~5V DC PSUs, I have one 4.5V/0.55A microUSB for my phone, another one 5V/0.55A for my camera, 5V/0.38A for my powered USB hub, a linear PSU of unknown origins (measured 4.7V open) and my desktop computer. No USB Y-cable, unfortunately.
None seem to work, not even my desktop PC. Ordering one personal nuclear power plant today, to power the board on thursday if everything goes according to plan.
timola
pfm Member
I can sympathise with your frustrations, sometimes even the smallest hurdle annoys. Perhaps the substantial energy of your frustration can be redirected to positive, effective, unstoppable determination.
Good luck!
stephengrenfell
pfm Member
So back on topic
Jarek listened to the Dual ES9038 XMOS board yesterday (so basically the same DAC arrangement you have on the "H3 SOC" Audio Development board) with DSD and was very excited with the sound stage
Yesterday I visited the H3 board vendor in China (having to drive though the edge of a typhoon which was pretty interesting) - and the meeting was very promising, we discussed a custom board for Audio application that we will design for them - with onboard clock synchronization etc.
From their perspective, the board has been reliable, but needs a heatsink fitted (they gave me a few so I can fit one to your board) - and documentation / support from AllWinner is VERY poor.
Once we get the Green light (hopefully) from you then we can goto the next stage and develop a custom M1-Audio version of the PCB to be manufactured and sold by them (we could never manufacture the PCB at there cost).
Asides from the Clock synchronization of the onboard SOC and regulators, I also requested onboard eMMC and to repostion the SDCard slot to the rear panel (Connector plane) making it perfect for MDAC2 type applications
Hi John,
This maybe a stupid question but is there a reason to choose the NanoPi M1 and not for example the NanoPi M2, or NanoPi M3.
The M2 uses the Samsung S5P4418 with Quad-core Cortex-A9 1.4GHz. And so is a bit faster and has double the L2 cache than the AllWinner M3.
The M3 uses the Samsung SP56818 with Octa-core Cortex-A53 1.4GHz. And uses the ARMv8 64 bit instruction set - which may, or may not, be useful from a SW point of view.
Looking at the S5P4418 and SP56818 data sheets (>1400 pages) there is a ton more information for example on the I2S interface (20 pages) compared to the AllWinner H3 data sheet.
Also if the SoC board is to be respinned to add-in your audio changes do you plan to add any more RAM, since up to 2GB can be accessed.
Just a couple of thoughts.
Have a safe trip back to base.
Samsung SP56818 data sheet
http://wiki.friendlyarm.com/wiki/images/8/8b/SEC_S5P6818X_Users_Manual_preliminary_Ver_0.00.pdf
Samsung S5P4418 data sheet
http://wiki.friendlyarm.com/wiki/images/a/a7/Pi2_SOC_DS_0.1.pdf
AllWinner H3 data sheet
http://dl.linux-sunxi.org/H3/Allwinner_H3_Datasheet_V1.0.pdf
See - the question isn't how easily we could implement support for it in the Linux kernel, but rather what board already has support or for what board is the support being implemented.
To answer why use H3 and not something even more obscure and recent, I have to make an analogy that this forum will hopefully understand - using iPhones.
The way nearly all (Chinese) manufacturers release ARM SoCs is that they take some existing Linux kernel version at the time, heavily modify it to work with the new hardware, and then ship it, years later, as a "reference" kernel. All advertised features "work", but the world has since moved on and newer Linux kernel versions may have significant advantages, but as the customizations to the old version are so badly documented, so vast and so horribly monstrous in code design, they cannot be really "updated" to a newer version.
This is as if some manufacturer designed, say a DAC, for iPhone 3 and the DAC worked only with iPhone 3 because there would be no drivers for a newer one. This is staggering, because with iPhones, as well as the Linux kernel, things usually work "out of the box", because HW manufacturers spend the extra effort to work with Linux/Apple to implement their driver into the base OS kernel. But most ARM SoC manufacturers don't.
So you get to choose to either stay with iPhone 3 and use the DAC, or upgrade and not use the DAC.
Another option is that somebody external, paid or a hobbyist, analyses the iPhone 3 driver and works with Linux/Apple in their own time to implement a clean and "proper" solution which would work for all iPhones. This however takes time, money and manpower.
And so it is now, ~2 years after the H3 release, that we're slowly getting support for it in the "upstream" Linux kernel, so that newer versions work out-of-the-box and Linux distributions can support H3 boards natively.
(On MDAC2, we still have to go the "iPhone 3" route as the native support isn't enough for our use case and the support will likely come after christmas, which is too late. This would not be the case if we chose something slightly older like A10/A20.)
And now consider the case of something not ~2 years old, but ~3 months old, like the SoCs you linked. Even armbian, which usually supports tons of boards, doesn't list the SoC type and the support for ie. Cortex-53A based Allwinner A64 is even worse than H3 at this point in time.
This is not Windows XP, you can't just install a driver which will work for the next 10 years.
Also if the main use case for the SOC is to be able to work as a squeezebox or RoonBridge endpoint. Then the H3 is sufficient.
To compare with something The Auralic Aries uses a 1GHz quadA9 SOC with 1Gb RAM and that seems to be sufficient to run their server software and streamer software.
To compare with something The Auralic Aries uses a 1GHz quadA9 SOC with 1Gb RAM and that seems to be sufficient to run their server software and streamer software.
Richard Kimber
pfm Member
I guess I'd prefer something standard like a Raspberry Pi 3, which is well supported
- Richard
- Richard
stephengrenfell
pfm Member
So if I understand correctly (and maybe I dont) you cannot really use either the two Samsung SoCs mentioned because there is no Armbian code build for these SOCs. And writing the required drivers for the ESS DACs / build a unique code build is not realistic.
Another stupid question why use Armbian and not another form of linux ?.
How does this work with the Raspberry Pi - is it the same ?.
These are not meant to by annoying questions I am just trying to understand.
Thanks.
Another stupid question why use Armbian and not another form of linux ?.
How does this work with the Raspberry Pi - is it the same ?.
These are not meant to by annoying questions I am just trying to understand.
Thanks.
stephengrenfell
pfm Member
Or maybe another SoC board that uses the same Broadcom BCM2387 chipset as Raspberry Pi 3 (if it exists).
adamdea
You are not a sound quality evaluation device
Yes. I can only assume that it was rejected for good reasons. But no idea what they were.
JohnW
pfm member
As far as I understand Raspberry pretty much has soul rights to the BCM2387 chipset, and in practice it's a dog of an SOC really not designed as a general purpose computing platform. To fit onto the MDAC2 rear panel we need all the connectors on the same side - RPi's don't have a solution.
I'm not fixated on the M1 - but at the moment it's looking like the most practical solution - however I'll be the first to put my hands in the air and say I only have a glancing understanding of the whole Linux / streamer game. We will manage the hardware - but leave it to others to develop and play with the software.
JohnW
pfm member
The FDAC / MDAC2 is a "PFM" based project, so much in is posted here. Yesterday I meet with a vendor here in China to discuss the small scale manufacture of the iMX6 PCB for FDAC - so it's very much actively progressing.
As I right this reply I'm sitting in a magnetics vendors meeting room in China during there lunch break.... in discussions WRT the MDAC2 / FDAC / Detox custom magnetics......
stephengrenfell
pfm Member
Thanks for your reply John.
As I understand now the key issue WRT to the SW is having an OS build that is adapted (drivers, etc..) to the SoC HW platform. And that this SW build exists and is / will be maintained by someone - and this a not a small work to do. I didn't realise this yesterday - so apologies for barking up the wrong tree.
It is a shame RPi's have connectors are on two sides, and all the clone boards seem to be like this too.
Well, the RPi 3 compute module (upgraded version of the original RPi1 module) is coming out pretty shortly, too bad it's probably not going to be in time - http://hackerboards.com/rpi-compute-module-3-revealed-tapped-for-nec-signage/ .
Even if it was, there's the question of cost and availability, both of which were an issue for the original module, IIRC.
Such is the cost of a custom design.
Even if it was, there's the question of cost and availability, both of which were an issue for the original module, IIRC.
Keep in mind that any custom pinout will (probably, if I understood this correctly) need a custom fex/devicetree definitions, so any existing OS has no chance of working unless explicitly customized. Hopefully this won't be the case of the M1 (as it uses an existing 3rd party board), but I kind of expect it to be for FDAC.
Such is the cost of a custom design.stephengrenfell
pfm Member
The RPi3 CM capabilities are way beyond the spec of the M1 and offers a standard / mainstream platform for the SW.
Would the trade-off of delay vs a far more future proof / flexible solution make sense ?.
Getting things faster is always better. But what happens if the Armbian community gives up on the M1 build (I mean in a few years time for example) and the M1 SW build needs to be updated to support say the latest version of RoonBridge / Squeezebox end point for example .
Sorry I am not trying to pooh all over things. Just trying to ask what might be sensible questions.
Well the armbian community might give up on the M1, but by that time it will have upstream kernel support, so you can just install any normal distro on it (debian/fedora/ubuntu/etc.) and whatever streaming endpoints necessary.
The problem of RPi3 CM is that it even if it was cheap and readily available on release, it won't release for a few more weeks/months, which is too late for MDAC2, which has to be here by christmas.
I doubt very much that MDAC2 will be here by christmas (in eight weeks). Inaddition delivery times are considerably longer just before christmas.
Sibbers
Earthling
I think I recall first production to be at or around Christmas with testing being planned, but given this is a journey with many slips, pinning hopes to a date right now would be unwise. It is at least tearing ahead and entering the final stages tho I'm beginning to wonder if I'm losing sound quality due to failing caps now as the sound stage appears to have started diminishing a little bit, but then I have just moved house and have a totally different room.
I'm beginning to wonder if I'm losing sound quality due to failing caps now as the sound stage appears to have started diminishing a little bit, but then I have just moved house and have a totally different room.stephengrenfell
pfm Member
Good to hear the M1 will not become a SW cul-de-sac.
Don't forget the M1 SoC PCB has to re-spinned to allow for John's changes to move the SD card slot etc.. and so is not ready today.
It would not be stupid to consider the RPi 3CM for MDAC2, and even potentially FDAC.
The RPi 3CM could plug into the MDAC2 board via an adapter card to mate with the M1 header (and so not delay the MDAC2 board manufacture).
Sure this adapter board will require some design work since it would have the external SoC connectors on. But this would mean a much better longer term SW platform.
And depending on the SoC solution for FDAC could mean a common SoC / SW approach if the RPi 3CM were to be used for FDAC too.
Worth noting that both RPi CMs use the same 200pin SO-DIMM header, and therefore if this strategy continues (like the 40pin RPi) would possibly allow to swap out the SoC with future RPi CMs as they become available / needed.
Just my two pence worth.
- Status