advertisement


MDAC First Listen (part 00100000)

Status
Not open for further replies.
I wonder how the RPi hardware differs from the Broadcom Application note for the IC?

TBH there really is very little to designing-in the Broadcom ARM MCU - the MDAC2 digital section with its FPGA & DSP engine is a far more complex "design". Our design criteria would be somewhat different then RPi's aim of an "Universal" cheap computer...

Really, from a hardware perspective the RPi is incredibly simple - we only need to insure that software compiled for the RPi would operate on the MDAC2 - we would not aim to make an exact RPi hardware - in fact we would not want to anyway as the idea is for a product optimised design - no need for the RPi expansion port etc.

As I say, it would boil down to how "customised" the RPi hardware is from the Broadcom BCM2835 ARM processor application note for the IC - Does RPi provide there own software / Bios or is it purely the Broadcom IC?
The RPi project has its own version of Debian, as far as I remember. However the BCM2835 kernel patches should be upstream, meaning that any distribution should basically work. There's a lot of community-based software work around the RPi, but most of it is not strictly limited to RPi, ... it's just that all the scripts, binary releases, bootloader config, ..., somehow expect the RPi hardware to some extent. It would really depend on how much you want to strip it down.

Please note that RPi is not just BCM2835, it includes additional memory (Samsung), USB hub (model B), external ethernet controller connected to the USB hub (ugly, I know, but BCM2835 doesn't have one), etc.

Did not the SBT use the same Broadcom IC (or atleast a device in the same family)?
Seems unlikely to me, BCM2835 is basically a "multimedia" GPU, designed *mainly* for video decoding (and therefore has a quite weak CPU part). Unless SBT was designed for 1080p video playback, I doubt anyone would use it there. :)
The RPi authors used it because their main developer works for Broadcom, so they got a discount.

edit: As for the bootloader, the GPU firmware is distributed in a binary form, http://elinux.org/RPi_Software#Overview. Meaning that for maximum compatibility with the RPi, you would probably need to use BCM2835 or a very close model (no idea how compatible the firmware is).
 
Please note that RPi is not just BCM2835, it includes additional memory (Samsung), USB hub (model B), external ethernet controller connected to the USB hub (ugly, I know, but BCM2835 doesn't have one), etc.

Yes, that's to be expected, there's nothing scary here - nothing that we don't handle everyday. Really at a hardware level its all basic Lego bricks... it does not even operate at such a fast bus speed - all sub 1GHz...

Having the Ethernet controller connected to the USB hub almost makes it easier from a design perspective with just a simple 2 wire link from the port "hub" to the BCM2835
 
Yes, that's to be expected, there's nothing scary here - nothing that we don't handle everyday. Really at a hardware level its all basic Lego bricks... it does not even operate at such a fast bus speed - all sub 1GHz...

Having the Ethernet controller connected to the USB hub almost makes it easier from a design perspective with just a simple 2 wire link from the port "hub" to the BCM2835
Then it seems you have it under control - you can always try a few distributions very easily (with complete sdcard images) to see if it works as expected. :)

Not sure what would be the use cases, though. All-in-one home theatre? More advanced MDAC control interface via HDMI + USB? Web-based control interface over Ethernet?
I guess these questions/decisions are not important at this point anyway.
 
RPi in depth hardware details its incredibly simple...

http://elinux.org/RPi_Hardware

The SOC and RAM Stack has made life very easy.

Dropping the following (not needed for MDAC2) and you have very little left:-

DSI interface

MIPI CSI-2 interface

Composite Video connector

Audio connector: 3.5mm stereo jack

26-pin (2x13) 2.54 mm header expansion

Just a cursory look at the PCB, and dropping the above signalling and there's really VERY little left!

Well for later thought - I'm working on the Lab bench with the MDAC2's Clock, which looks very promising :)
 
Not sure what would be the use cases, though. All-in-one home theatre? More advanced MDAC control interface via HDMI + USB? Web-based control interface over Ethernet?
I guess these questions/decisions are not important at this point anyway.

Constant request for Streaming & DLNA support etc - not to mention a decent display / keyboard option with UI...

Complete Recorder / Player in a single unit...

We would not get involved in any of the software, just the hardware - its for others to suggests ideas and applications :)

State of the art ADC / DAC front end combined with an open source Linux platform :) ... Nothing that effects the current MDAC2 L1-L3 only for later consideration once the MDAC2 has been released.
 
Constant request for Streaming & DLNA support etc - not to mention a decent display / keyboard option with UI...

Complete Recorder / Player in a single unit...

We would not get involved in any of the software, just the hardware - its for others to suggests ideas and applications :)

State of the art ADC / DAC front end combined with an open source Linux platform :) ... Nothing that effects the current MDAC2 L1-L3 only for later consideration once the MDAC2 has been released.
Sounds nice and reasonable for some cases. The problem I see is that there's not much real benefit in merging those two platforms without some added functionality (like i2s, some advanced control via GPIO, etc.), which would ultimately require you to make some software using it. Without such functionality, the "virtual" RPi would be basically connected to the MDAC via USB (internally), which is the same as buying a separate RPi and connecting it via USB.

I have no doubts that some people would want to use the MDAC(2) via RPi and embedding it makes for an interesting challenge, but I'm rather skeptical about the practical benefits of it, compared to a standalone RPi (which can be easily upgraded, connected to an external HDD, replaced by a different ARM board, etc.).

I guess time will tell. :) ... I can't stand the Windows Vista UI (or Mac UI or Gnome 3 UI for that matter), so what do I know about user experience.

PS: Another way would be to expand the USB interface - current MDAC already supports some basic mixer settings (volume + mute), but other sound cards often export much more tunables. Additionally, you could also expand the HID interface, add a serial line interface, etc., all over a single USB (with enough bandwidth, being USB2.0). There's so much one can do over USB, http://en.wikipedia.org/wiki/USB#Device_classes. ... Just some ideas for the future. :)
PPS: I'd *love* to configure my MDAC2 over the serial line, using a text interface. :D :D
 
The MDAC2 would be connected to BCM2835 via its I2S port (Clock-locked) with the MDAC2 FPGA PLL generating the 19.2MHz and 25MHz for the BCM2835 & its USB hub.

The advantage I see is that you could connect a Keyboard / Mouse and Monitor directly to the MDAC2 and have a self contained Media centre, recorder, Measurement system... what ever you wanted. Asides from the SD card you could also add an external HDD via USB.

Its a route to an embedded streaming device which is constantly requested for the MDAC2 with DLNA support etc. As the Squeezebox has been ported to the RPi then the MDAC2 could be a modern replacement with a state of the art DAC..

I like many others want a simple solution - just plug-in and go, no messing with computers & having many boxes and connections... this would allow streaming / DLNA without a computer.

I really have no time to mess about with computers & software etc, I just want to listen not worried if the computer causing interference to my Audio system etc... This might be a solution.

I hate computers....
 
Would it be possible to add an I2S interface on the L3 connection extender or would the cable be too long for it to work? If this is doable this may be the simplest way to get a good integrated streamer, albeit in a few boxes
 
The MDAC2 would be connected to BCM2835 via its I2S port (Clock-locked) with the MDAC2 FPGA PLL generating the 19.2MHz and 25MHz for the BCM2835 & its USB hub.

The advantage I see is that you could connect a Keyboard / Mouse and Monitor directly to the MDAC2 and have a self contained Media centre, recorder, Measurement system... what ever you wanted. Asides from the SD card you could also add an external HDD via USB.

Its a route to an embedded streaming device which is constantly requested for the MDAC2 with DLNA support etc. As the Squeezebox has been ported to the RPi then the MDAC2 could be a modern replacement with a state of the art DAC..

I like many others want a simple solution - just plug-in and go, no messing with computers & having many boxes and connections... this would allow streaming / DLNA without a computer.

I really have no time to mess about with computers & software etc, I just want to listen not worried if the computer causing interference to my Audio system etc... This might be a solution.

I hate computers....
Okay, okay, I just simply don't understand what's the difference of having an external computer (RPi) and embedding it on the digital PCB - both would need the same software. Though that's fine, I guess the convenience of having one box instead of two is also a valid reason. :) .. If you want a RPi-based measurement system and don't want to mess with computers/software, somebody else will have to write it.
If you want a ready-to-go Squeezebox system, it's just about downloading a ready-made image, copying it to the SD card and plugging it in the RPi - it doesn't matter if embedded or external, the "messing" would be the same.

Maybe the upcoming RPi Compute Module is worth to take a look at: http://www.raspberrypi.org/raspberry-pi-compute-module-new-product/
Reminds me of the Gumstix boards (https://store.gumstix.com/index.php/category/27/) from which I wanted to make a "smartphone" (with RJ-45!) some time in 2004. :D
 
The MDAC2 would be connected to BCM2835 via its I2S port (Clock-locked) with the MDAC2 FPGA PLL generating the 19.2MHz and 25MHz for the BCM2835 & its USB hub.

The advantage I see is that you could connect a Keyboard / Mouse and Monitor directly to the MDAC2 and have a self contained Media centre, recorder, Measurement system... what ever you wanted. Asides from the SD card you could also add an external HDD via USB.

Its a route to an embedded streaming device which is constantly requested for the MDAC2 with DLNA support etc. As the Squeezebox has been ported to the RPi then the MDAC2 could be a modern replacement with a state of the art DAC..

I like many others want a simple solution - just plug-in and go, no messing with computers & having many boxes and connections... this would allow streaming / DLNA without a computer.

I really have no time to mess about with computers & software etc, I just want to listen not worried if the computer causing interference to my Audio system etc... This might be a solution.

I hate computers....
I find this very interesting as streaming solution. I'm also intrigued about the question of how to access/control the M-Dac2 as this will be important given the sophistication of the dsp and other tuning options (like jitter monitoring).
 
A device such as the iPad would make a perfect "UI / controller" for the MDAC2's more advanced features...

I do hope this project won't get exclusively tied-in to Apple stuff. For me, there would need to be Android tablet support.

- Richard.
 
Would it be possible to add an I2S interface on the L3 connection extender or would the cable be too long for it to work? If this is doable this may be the simplest way to get a good integrated streamer, albeit in a few boxes

Yes, the L3 digital I/O Extender port can support a I2S interface.
 
I do hope this project won't get exclusively tied-in to Apple stuff. For me, there would need to be Android tablet support.

- Richard.

The current discussions about the RPi / external Display & UI relate to a "future" ideas to expand the flexibility of the MDAC2 - in no way does it effect MDAC2 L1 - L3, whose priority is to have the project wrapped up before the years end.

Any potential "Solution" will be implemented by upgrading the Digital PCB with new rear panel at a later date.
 
I find this very interesting as streaming solution. I'm also intrigued about the question of how to access/control the M-Dac2 as this will be important given the sophistication of the dsp and other tuning options (like jitter monitoring).

Yes, you understand where I'm going with the MDAC2 "L4" - really with such advanced features available in the MDAC2 analogue / Digital hardware it would really benefit from a more powerflu "Controller" / display.

We are too small to offer "multi-platform" support which is why an inbuilt architecture like RPi is attractive - its also "Plug and Play" no need to mess about with computers.
 
I just simply don't understand what's the difference of having an external computer (RPi) and embedding it on the digital PCB - both would need the same software. Though that's fine, I guess the convenience of having one box instead of two is also a valid reason. :)

For starters the onboard BCM2835 clock's would be derived from the MDAC2's Audio Clock - its always desirable from an EMI perspective (to control beating clocks etc).

An external RPi adds an extra layer of complexity to the user - not to mention extra box and cabling - inbuilt is neater and cleaner... Ideally, you would also want a high speed communications port between the MDAC2's FPGA / DSP engine and the BCM2835...

If you want a RPi-based measurement system and don't want to mess with computers/software, somebody else will have to write it.

If you want a ready-to-go Squeezebox system, it's just about downloading a ready-made image, copying it to the SD card and plugging it in the RPi - it doesn't matter if embedded or external, the "messing" would be the same.

We would offer the hardware with basic functionality and would rely upon experts such as yourself to build the applications - most users just want and expect "plug and go" - with ZERO knowledge required... certainly I do.

We just provide the hardware - the software and applications can be expanded upon with time.

I'm just discussing the possibility at this time...
 
The current discussions about the RPi / external Display & UI relate to a "future" ideas to expand the flexibility of the MDAC2 - in no way does it effect MDAC2 L1 - L3, whose propriety is to have the project wrapped up before the years end.

Any potential "Solution" will be implemented by upgrading the Digital PCB with new rear panel at a later date.

Is the requirement for L4 L3?
I didn't need L3. But L4 seems to be interesting.
 
For starters the onboard BCM2835 clock's would be derived from the MDAC2's Audio Clock - its always desirable from an EMI perspective (to control beating clocks etc).

An external RPi adds an extra layer of complexity to the user - not to mention extra box and cabling - inbuilt is neater and cleaner... Ideally, you would also want a high speed communications port between the MDAC2's FPGA / DSP engine and the BCM2835...
As an extra possibility, you might consider chips used by other popular ARM boards - Cubieboard, Odroid (supported by Squeezeplug), etc. Some of them might be better suited for the job while still providing a wide range of community-supported software.

We would offer the hardware with basic functionality and would rely upon experts such as yourself to build the applications - most users just want and expect "plug and go" - with ZERO knowledge required... certainly I do.
I understand the model, but make sure you have such experts, perhaps by asking in the DIY room. I'll keep my promise of testing Linux compatibility of the MDAC2 (via USB), but I'm bad at making user-facing programs (GUIs) and have other hobbies as well (helping at a local animal/dog shelter). Perhaps sam_cat or somebody else would be interested. :)

I'm just discussing the possibility at this time...
Sure, and I'm just trying to point out possible limitations. I should probably give up that QA job, it's making me grumpy. :)

edit: Basic functionality like DLNA renderer would be easy (via already existing community projects), it's the custom functionality (jitter visualization, general MDAC2 control) that you need manpower for.
 
Status
Not open for further replies.


advertisement


Back
Top