advertisement


MDAC First Listen (part 00110111)

Status
Not open for further replies.
For the OS, would a standard linux distro boot on the board, allowing kernel/driver patching & compiling 'in-situ'.
As far as I know, ... maybe. There's some conflicting documentation on whether a different bootcode.bin is needed for eMMC boot compared to SD boot. If it is, you'd need to modify the OS image and replace the bootloader before "flashing" it into the eMMC.

The must significant difference between the RPi3 and our streamer board (from an RPi software perspective) is that the GPIO pin used for Ethernet Reset has been moved to free up an I2C port, so Linux Config file (what ever its called) will need to be modified to reassign the GPIO used for the LAN Reset pin to the new I/O port pin.
Well, the Broadcom SoC AFAIK doesn't have Ethernet built in, so I'm assuming you mean the RST from LAN9514. The "config file" here would be a Device Tree file, https://github.com/raspberrypi/firmware/tree/master/boot , these are compiled binaries, an example of the source would be https://github.com/torvalds/linux/blob/master/arch/arm/boot/dts/bcm2835-rpi.dtsi (just a small part of the result, it's an "include" file, the official rpi binaries can be de-compiled and modified, which would be probably easier). My idea was to build the daughterboard like it was RPi3, so we could use the RPi3 device tree file without modification (with just an added overlay for the eMMC). Otherwise we would have to define most of the hardware manually (if we were to start with a CM3 device tree file).

The syntax looks easy (and is documented), but it's really not, at least not for a regular sysadmin like me, the pin definitions and addresses and aliases and interrupt controllers are all over the place. But it's an "open" and documented format, so somebody should be able to reconfigure the Ethernet RST pin after some reading and trying. Then the modified version can be manually specified in config.txt (read by bootcode.bin) or through u-boot (or a different second (?) stage loader).
 
I've almost completed my passive switchbox and will continue my listening tests tomorrow.

 
In that case, you would only need to order the streamer PCB and not also the "Temporary" DAC :)

Like Tim, I'd like an MDAC2 Streamer PCB with Modified CM3 module but I don't need it until MDAC2 is ready, so please hold it for me. When will you put up the PayPal payment options John?
 
Well, the Broadcom SoC AFAIK doesn't have Ethernet built in, so I'm assuming you mean the RST from LAN9514. The "config file" here would be a Device Tree file, https://github.com/raspberrypi/firmware/tree/master/boot , these are compiled binaries, an example of the source would be https://github.com/torvalds/linux/blob/master/arch/arm/boot/dts/bcm2835-rpi.dtsi (just a small part of the result, it's an "include" file, the official rpi binaries can be de-compiled and modified, which would be probably easier). My idea was to build the daughterboard like it was RPi3, so we could use the RPi3 device tree file without modification (with just an added overlay for the eMMC). Otherwise we would have to define most of the hardware manually (if we were to start with a CM3 device tree file).

The syntax looks easy (and is documented), but it's really not, at least not for a regular sysadmin like me, the pin definitions and addresses and aliases and interrupt controllers are all over the place. But it's an "open" and documented format, so somebody should be able to reconfigure the Ethernet RST pin after some reading and trying. Then the modified version can be manually specified in config.txt (read by bootcode.bin) or through u-boot (or a different second (?) stage loader).

I would prefer if DietPi could be made to run on it, because it seem to be the best/versatile distribution at the moment and I do not know enough Linux to be able to build my own kernel.

With DietPi it is easy to install almost anything including Roon, Kodi etc. her is the list of software http://dietpi.com/phpbb/viewtopic.php?f=8&t=5#p5

The developer seem to be keen on supporting many SOCS and DAC HATS. He has recently been active on the Roon forum and now supports Roon in his configuration.

To get DietPi support might be a matter of giving him a DEVDAC and Streamer.

@John: Is it correct to assume that if it works on the DEVDAC and streamer it will also work on MDAC2 and FDAC?
 
I would prefer if DietPi could be made to run on it, because it seem to be the best/versatile distribution at the moment and I do not know enough Linux to be able to build my own kernel.
A custom kernel will be needed regardless if you want native DSD support. If not, then the stock one should suffice. Using a modified device tree file doesn't require kernel rebuild.
 
Hi JohnW,

I am in for the DETOX, VFETS and for the matching FDAC (or TDAC or whatever it will be) but might skip the MDAC2 as I don't own an MDAC and will definitely want the bigger version.

If the Streamer board is not compatible with the FDAC I can't see a point of buying it in my specific case.. Can you please provide an alternative for such cases to help you setup the P&P machine and therefore have the items quicker?
 
Hi John, thanks for answering my questions the other day, I've now managed to read back the last 6 months to get a better feel for where we are :eek:. Is it still possible for me to join the Detox list? Also to use the FDac as a preamplifier would I need to move to the L3? as it states on the webpage, '14MHz Real-time Digital Preamplifier' under the features. I don't think I have any need for the ADC. Finaly, if i understand correctly the VFETS that you are working on before the FDac are for the 10 original subscribers? or are they another project, I recall seeing miniVFETS somewhere? :confused:
 
I apologize in advance for this post knowing that it may be a distraction from John's other activities.

Given that a little knowledge is a dangerous thing, I have read product promo information on the plethora of USB dongles touting:
USB data regeneration (REGEN, DETOX for which I am in line);
Galvanic isolation (ISO REGEN, ADNACO);
LPS power downstream (VARIOUS);
Defeating 5V to DAC (SBOOSTER)
2-headed cables (PANGEA, ETC);
Solid connectors (UPTONE, SONORE, SBOOSTER);
Shielding from EMI/RFI (VARIOUS);
USB3.0;
Etc;

As someone not knowledgeable about the application of USB specifically to audio but as a subscriber to the DETOX project, I would be interested in a better understanding of which issues are truly relevant since most companies addressing these issues seem to be taking various approaches. I have even read where users are daisy-chaining multiple devices and, even in some cases, multiple and expensive power supplies. At some point, logic suggests that a better DAC might be in order!

Galvanic isolation between source and DAC makes sense to me but the others less so.

Thanks.
 
I would prefer if DietPi could be made to run on it, because it seem to be the best/versatile distribution at the moment and I do not know enough Linux to be able to build my own kernel.

With DietPi it is easy to install almost anything including Roon, Kodi etc. her is the list of software http://dietpi.com/phpbb/viewtopic.php?f=8&t=5#p5

The developer seem to be keen on supporting many SOCS and DAC HATS. He has recently been active on the Roon forum and now supports Roon in his configuration.

To get DietPi support might be a matter of giving him a DEVDAC and Streamer.

@John: Is it correct to assume that if it works on the DEVDAC and streamer it will also work on MDAC2 and FDAC?

+1 for DietPi if relevant/feasible. Thanks!
 
I apologize in advance for this post knowing that it may be a distraction from John's other activities.

Given that a little knowledge is a dangerous thing, I have read product promo information on the plethora of USB dongles touting:
USB data regeneration (REGEN, DETOX for which I am in line);
Galvanic isolation (ISO REGEN, ADNACO);
LPS power downstream (VARIOUS);
Defeating 5V to DAC (SBOOSTER)
2-headed cables (PANGEA, ETC);
Solid connectors (UPTONE, SONORE, SBOOSTER);
Shielding from EMI/RFI (VARIOUS);
USB3.0;
Etc;

As someone not knowledgeable about the application of USB specifically to audio but as a subscriber to the DETOX project, I would be interested in a better understanding of which issues are truly relevant since most companies addressing these issues seem to be taking various approaches. I have even read where users are daisy-chaining multiple devices and, even in some cases, multiple and expensive power supplies. At some point, logic suggests that a better DAC might be in order!

Galvanic isolation between source and DAC makes sense to me but the others less so.

Thanks.

Quoting myself...
Almost forgot:
USB Ground Loops (SBOOSTER VBUS3)
 
John is this true?

I do like the look of the unit and in particular the remote...cool..:cool::cool:

Yes its Jareks and my design - the original basis of the design is our FDAC / MDAC2 XMOS "software" development board.

Sadly the first production batch (and being reviewed) was manufactured without our approved components (Note the Pink / Silver organic capacitors) - and a few other changes.

I brought this to Heinz attention and he's insured me that changes will be made and correct parts used in the future production. As a designer, no one likes to see unapproved design changes - I was VERY surprised at the "political" issues we faced working with a Czech / Slovak production company's - it does make me appreciate working in China more and its kind of sad to say that!

Using my contacts I ordered the correct capacitors - so it appear Heinz a man of his word :) and I very much appreciate that :)

Its a good little DAC, Dual ESS9038Q2M, Multi regulated PSU, Polypropylene capacitors and precision MELF resistors etc... but you have to consider its small size and theres only so much that can be squeezed into such as design and yet still keeping it simple for production in Europe.

You want a small no nonsense DAC for your Office / Bedroom etc its perfect.

Supports MQA and is Roon certified...

The DAC really appreciates a good clean PSU - and works very well with the Detox.

Its also works well with DSD :) DSD performance has been much improved with the new Hyperstream II DAC's from ESS - I'm glad that we are able to use the latest Hyperstream II devices in MDAC2 / FDAC.
 
@John: Is it correct to assume that if it works on the DEVDAC and streamer it will also work on MDAC2 and FDAC?

YES 100% - thats the reason for the "DEVDAC and streamer" to give us a jump start on the software development for MDAC2.

Its been crazy busy, Jarek and I just pulled a 36 hour working "day" to complete the streamer PCB - I'll collect the bare boards on Friday so that I can at least show the built boards at Munich - not sure if we will have much time to test them...

So here is the first completed MDAC2 PCB :)

https://www.dropbox.com/s/eiv2dx48892wqpn/MDAC2 Streamer A01.jpg?dl=0

The rendering is shown with the 4 RF screened tin sections openframe (No tin cover), in reality they will be covered / sealed for RF screening.

The Audio Sub system, LAN / USB HUB, PSU's and Clock circuits are each "isolated" in there own screened Tin sections.

The vertically mounted CR2032 Coin Cell is to power the RTC (Real Time Clock) when the MDAC2 is powered off.

This PCB is design to be mounted upside down in the MDAC2, so the HDMI video connector is on the far right hand side when looking at the MDAC2 rear panel.

https://www.dropbox.com/s/vjlxpuazqrhv3zr/MDAC2 stage 1 to 4 RPiCM3 ADC Slave.JPG?dl=0

Rear panel connectors:-

BNC Video Output

3x USB Host ports (for USB Flash Drives, Keyboard, mouse, External powered HDD, WiFi / bluetooth dongle (at your own risk to system sound quality) etc.)

Ethernet port

HDMI Video Output

Other "system" connectors on the PCB are for the DAC /ADC/ External Clocks, and various Touch panel LCD displays, front panel support for future products and the (Later) planned MDAC2 Front panel upgrade etc.

The RPI CM3 module is seated in the large DIMM200 connector above the "LakeWest" logo.
 
Like Tim, I'd like an MDAC2 Streamer PCB with Modified CM3 module but I don't need it until MDAC2 is ready, so please hold it for me. When will you put up the PayPal payment options John?

Bruce,

Jarek and I just completed a 36 hour "shift" to complete the MDAC2 streamer PCB so I can have something to show PFM'ers at Munich.

Its the first Completed PCB design for MDAC2 :) PCB will back from the vendor on Friday, if we already had the PnP machine installed it would be able to build the PCB in about 30 minutes! instead Jarek and I will build it up over the weekend - I'm not sure if we can get it tested before Munich as we not only have build and test it electronically but also work on installing Linux...

https://www.dropbox.com/s/eiv2dx48892wqpn/MDAC2 Streamer A01.jpg?dl=0

I'll put the streamer on the Lakewest Website later today - as I'll be ordering the PnP machine as soon as its possible.

We also need to quickly spin the DEVDAC PCB - its not easy testing this PCB without the DAC / Clock section.
 
Hi JohnW,

I am in for the DETOX, VFETS and for the matching FDAC (or TDAC or whatever it will be) but might skip the MDAC2 as I don't own an MDAC and will definitely want the bigger version.

If the Streamer board is not compatible with the FDAC I can't see a point of buying it in my specific case.. Can you please provide an alternative for such cases to help you setup the P&P machine and therefore have the items quicker?

Rjpcardoso,

I'll try and think of away we could structure this - I'd prefer to be able to charge for something we can deliverer in the short term, so I'm thinking that we get the pricing confirmed for the long leadtime items from China for Detox and then open the first "portion" of the "At Cost" Detox payment that includes the SMT/testing charges which will help contribute towards the PnP costs.

Someone asked me yesterday why I did not think about in-house SMD before, and quite simply I had no idea that they where now so relatively "affordable".

I first looked at Chinese manufactured PnP machines, but soon realised that they where simply a step below what we needed - then I found an incredible unit manufactured locally in Europe and this set the whole ball rolling!

Quite simply if I had known, Detox would have been delivered a year ago! and we would have spun some other simple designs...
 
I would prefer if DietPi could be made to run on it, because it seem to be the best/versatile distribution at the moment and I do not know enough Linux to be able to build my own kernel.

With DietPi it is easy to install almost anything including Roon, Kodi etc. Here is the list of software http://dietpi.com/phpbb/viewtopic.php?f=8&t=5#p5

The developer seem to be keen on supporting many SOCS and DAC HATS. He has recently been active on the Roon forum and now supports Roon in his configuration.

To get DietPi support might be a matter of giving him a DEVDAC and Streamer.

Yes good idea, no problem to get a DEVDAC / Streamer to the DietPi developer if it would be helpful :)
 
Status
Not open for further replies.


advertisement


Back
Top