advertisement


MDAC First Listen (part 00100000)

Status
Not open for further replies.
Well Lady's and Gentlemen :) - guess what I found! we now have a practical solution :)

"NEW Raspberry Pi Compute Module Development Kit"

The new Compute Module from Raspberry Pi delivers greater flexibility for professional embedded applications. This new Raspberry Pi board has been developed specifically for engineers in the professional market to create their own embedded system. The Compute Module fits into a standard DDR2 SODIMM socket and provides the same basic features of a standard Raspberry Pi, including a Broadcom BCM2835 processor and 512 Mbyte of RAM. It replaces the SD card with an onboard 4 Gbyte eMMC Flash device, and integrates everything on to a compact 67.6 x 30 mm board. The Compute Module is initially available as part of a development kit, bundled together with the IO Development Board, which brings out all of the IO connectivity to form a prototyping platform for electronics design engineers. The Compute Module as a stand-alone product will be available from the autumn.

WOW!! this means we can design into the MDAC2 L4 - MDAC2 with streamer etc!!!!

Timing is perfect!
 
Well Lady's and Gentlemen :) - guess what I found! we now have a practical solution :)

"NEW Raspberry Pi Compute Module Development Kit"

The new Compute Module from Raspberry Pi delivers greater flexibility for professional embedded applications. This new Raspberry Pi board has been developed specifically for engineers in the professional market to create their own embedded system. The Compute Module fits into a standard DDR2 SODIMM socket and provides the same basic features of a standard Raspberry Pi, including a Broadcom BCM2835 processor and 512 Mbyte of RAM. It replaces the SD card with an onboard 4 Gbyte eMMC Flash device, and integrates everything on to a compact 67.6 x 30 mm board. The Compute Module is initially available as part of a development kit, bundled together with the IO Development Board, which brings out all of the IO connectivity to form a prototyping platform for electronics design engineers. The Compute Module as a stand-alone product will be available from the autumn.

WOW!! this means we can design into the MDAC2 L4 - MDAC2 with streamer etc!!!!

Timing is perfect!

Awesome! One box solution! Do you have the space?!!

Also does this mean that there will be an Ethernet connection. And will it be raspify that you run as the client?

And WiFi? Will it require a dongle like the current raspberry pi?
 
Awesome! One box solution! Do you have the space?!!

Yes, its perfect timing to consider such a solution for the Digital board - the digital board will "Develop" like the analogue board has once I start working on it.

Its going to be fun arranging the rear panel connectors.

Also does this mean that there will be an Ethernet connection. And will it be raspify that you run as the client?

Yes, I'll design in a wired Ethernet connection - then its up to others (Jiri, Jem, Sam :) ) to work on the software - I''ll just design the hardware.

And WiFi? Will it require a dongle like the current raspberry pi?

Yes a WiFi USB Dongle for certification reason :)
 
Yes, I'll design in a wired Ethernet connection - then its up to others (Jiri, Jem, Sam :) ) to work on the software - I''ll just design the hardware.

Hmmm will anyone be writing up any requirements for a music streaming client? I'd be interested to see them, could be a fun side project. I design TV EPG's for a living and have always wanted to design a music client.
 
I miss a week and now we have raspberry pie inside! Sounds good though :)

Well looks like it... it does allow many requested features such as DLNA Streamer and SBT replacement.

Maybe there's also a Room correction package....

Internet Radio etc...

Current priority is to complete the L1-L3 versions - but we can certainly put everything in place for the RPi L4
 
Hmmm will anyone be writing up any requirements for a music streaming client? I'd be interested to see them, could be a fun side project. I design TV EPG's for a living and have always wanted to design a music client.

I'll leave the "software" to others I'm just happy to stream via USB which is simple plug and play :) but then I'm rather old fashion and still using XP on my PC :D

I'd like to be able to support 384KHz / 768KHz 32bits and DSD via the streamer / RPI hardware so Dominik will need to study how to implement this at hardware level - then Ill leave the rest to you "Software guys" to have fun - but it would make a great little platform :)
 
I'd just like to have the amplifiers first, ... pretty please? :)

I'd like to be able to support 384KHz / 768KHz 32bits and DSD via the streamer / RPI hardware so Dominik will need to study how to implement this at hardware level - then Ill leave the rest to you "Software guys" to have fun - but it would make a great little platform :)
From a software standpoint, the most compatible way is still USB (UAC). Anything, say, PCI-based needs its own driver, just like those integrated sound cards have - my desktop has Realtek (SND_HDA_CODEC_REALTEK, ALC880-compatible), but my laptop has some Connexant thing, SND_HDA_CODEC_CONEXANT, CX20549-compatible). The USB UAC driver (SND_USB_AUDIO) is universal. And this is not just Linux, take a look at the driver DLLs used by various sound cards on Windows.
If we take the ARM world as an example ... well, we better not. The kernel side got better over the recent months (years), but it's still mostly a ****ton of per-device exceptions and hooks, because there's no standardization.

Therefore my advice would be to "simulate" an external USB connection (not necessarily using up the "USB" input as seen from the front panel menu), at least for the things that can be done using USB (playback, HID, mixer controls, firmware upgrade, possible other features) and have the extra bits that need non-USB interface separate.
This - in my opinion - simplifies the design (one input path for internal/external USB) while sharing as much of the features as possible with the outside world via USB, ie. an external board or a computer.
If you're running short on bandwidth, use USB3, which has (IIRC) the same audio streaming model.

The problem with software is that it's not about what's theoretically possible, but what's realistically doable in terms of standards and common interfaces. You can design a super fast bus, allowing 100x the speed of 256fs DSD, but you also need to make a (kernel) driver for it *and* maintain it.
 
I'll leave the "software" to others I'm just happy to stream via USB which is simple plug and play :) but then I'm rather old fashion and still using XP on my PC :D

I'd like to be able to support 384KHz / 768KHz 32bits and DSD via the streamer / RPI hardware so Dominik will need to study how to implement this at hardware level - then Ill leave the rest to you "Software guys" to have fun - but it would make a great little platform :)

OK. May propose some designs and see what the response is :D
 
Is the DSP still relevant when it's possible to use the GPU?
As a side note, the BCM chip has its own DSP section, http://www.raspberrypi.org/forums/viewtopic.php?f=2&t=290 , but without a public API (meaning that it's mostly useless for now). However using this unit instead of a dedicated DSP unit would mean no room correction for anything that doesn't go through the system on the RPi (anything networkless, like SPDIF or external USB).

Lots of fun anyway,
http://www.raspberrypi.org/digital-signal-processing-with-teeny-tiny-tap-dancers/
http://www.raspberrypi.org/accelerating-fourier-transforms-using-the-gpu/
 
JohnW, jirij,

The RPi has a 'funny' USB host controller, they needed to implement a FIQ driver to sort-of make it work, but afaik it still drops packets on the floor if you push it hard enough (and USB 2.0 isn't _that_ fast), and remember that its network device is also on the USB bus, so all streaming traffic goes over it twice.

It should work for redbook stuff, but I worry it'll come apart for the high bandwidth stuff.
 
Hi John

I have been lurking for a long time, just signed and paid the 1st 3 installments for MK2 PCB + Toy option.

I will possibly choose some of the other options in due course, but it would be helpful if there was a concise summary of all the options/their benefits.

There is probably already a post somewhere in the thread someone could point to :)

thanks
 
Well looks like it... it does allow many requested features such as DLNA Streamer and SBT replacement.

Maybe there's also a Room correction package....

Internet Radio etc...

Current priority is to complete the L1-L3 versions - but we can certainly put everything in place for the RPi L4

Sounds brilliant John... it just gets better and better!
 
JohnW, jirij,

The RPi has a 'funny' USB host controller, they needed to implement a FIQ driver to sort-of make it work, but afaik it still drops packets on the floor if you push it hard enough (and USB 2.0 isn't _that_ fast), and remember that its network device is also on the USB bus, so all streaming traffic goes over it twice.

It should work for redbook stuff, but I worry it'll come apart for the high bandwidth stuff.

Peter,

Yes, I've heard the same - however the RPI USB port would not be used for audio Streaming only Storage / Keyboard and Mouse etc.

The MDAC2 has its own dedicated USB 2.0 Audio port.
 
Hi John

I have been lurking for a long time, just signed and paid the 1st 3 installments for MK2 PCB + Toy option.

I will possibly choose some of the other options in due course, but it would be helpful if there was a concise summary of all the options/their benefits.

There is probably already a post somewhere in the thread someone could point to :)

thanks

BE718,

Thank you for the payment & welcome to the MDAC2 project - Renata should Email you in the next few minutes with confirmation.

https://dl.dropboxusercontent.com/u/86116171/MDAC2 Options.jpg

I'm just working on the MDAC2 Clock section (whos performance is looking very good) - I'll then promise to spend a couple of days updating the Website, I'm sorry for the delay.
 
As a side note, the BCM chip has its own DSP section, http://www.raspberrypi.org/forums/viewtopic.php?f=2&t=290 , but without a public API (meaning that it's mostly useless for now). However using this unit instead of a dedicated DSP unit would mean no room correction for anything that doesn't go through the system on the RPi (anything networkless, like SPDIF or external USB).

Lots of fun anyway,
http://www.raspberrypi.org/digital-signal-processing-with-teeny-tiny-tap-dancers/
http://www.raspberrypi.org/accelerating-fourier-transforms-using-the-gpu/

Having on-board processing for FFT is brilliant - it would allow a simple way to visually confirm that any "Hi Resolution" audio file is not just an "upsampled" CD Wave file etc.

FFT can also be used for Distortion analysis etc (useful for some as a self contained audio test system using the MDAC2's ADC)...

We would still use the MDAC2 L2 / L3 own dedicated DSP for Audio processing where required.
 
Status
Not open for further replies.


advertisement


Back
Top