Sorry if i am being slow, but given that the device is going to have ethernet input anyway, what would the advantage be in using a usb dongle (especially one which looks like a separate box, not a neat little key) rather than a conventional wireless bridge connected via ethernet?
Welcome to the world of more than one possibility (TM).
If a separate box suits you better, go for it.
I guess I mixed up two slightly different things - wireless functionality and the "look & feel" of the solution. From my point of view, having the wifi "card" directly accessible from the target system is just more flexible (in terms of what I can do with it from software) and possibly more secure (also welcome to the world of
many security holes where vendors just don't care).
I'm not sure if the above has already answered my question (a lot of this tech detail has gone over my head), but how is the digital music stream going to be sent from the RPi to the MDAC? Is there going to be some dedicated clock-locked internal (internal to the MDAC case I mean) connection, or is the plan to use async USB? If Async USB, then is the physical connection going to be internal, or will there by some way to connect the RPi to the MDAC's external USB input?
JohnW would have to answer that. My guess is either via i2s (internal bus, via several pins) or using USB or SPDIF somehow (likely via some internal connection as well).
Either way, MDAC should appear just like a regular ALSA device in the system.
The RPi code is of dubious quality and not upstream Linux. An alternative to using it would be going with an iMX6 board. They have very good upstream support (just install debian armhf) and come in various size and shapes.
For example:
http://www.dh-electronics.com/DHCOM_iMX6_DE.DHElectronics
or
http://www.variscite.com/products/system-on-module-som/cortex-a9/var-som-mx6-cpu-freescale-imx6
Both seem to have the same board and pin layout for the different configurations, meaning people can order a 'cpu' to size and plug it into their MDAC2. Some can do a quad core with 4GB, others a single core with 512MB, whatever they fancy.
A single core configuration should be well powerful enough to decode FLACs I think.
Yes, the RPi code is not what gets normally accepted upstream (IIRC it doesn't even pass checkpatch.pl), yes, I know what it's like to maintain out-of-tree modules, yes, I would much prefer cleaner engineering solutions (like not having to pass Ethernet via USB), but the target audience isn't Linux/Unix hackers, it's mostly (pardon the term) Apple-grown people, who expect stuff to "just work", and the vast community behind RPi with their ready-made images is more powerful (in this case) than a bare-bone board with basic Linux distribution.
I would personally prefer the latter (as I hate maintaining non-upstream hacks), but I'm not going to be one of those L4 people as the
one embedded solution I already have (with OpenWRT) is more than enough for me.
Also, the target audience is going to be anywhere from ~10 to ~50 people.
In the end, it depends on the use cases John decides to address.
