MDAC First Listen (part 00100111)

[JohnW]

MDAC2 Update:-

I resolved the bias stability issue and am just optimizing the stability into capacitive loads.

I powered up the Audio Precision to see if I could measure the MDAC2's output stage "real" THD (not limited by the test generator) and for best results used my R&S as the analyser and the AP as the signal Generator. Measured THD at 1KHz 2Vrms into 50 Ohms load is 0.000038%.

I'll add the results later once I get to my Dropbox PC.

Nice to see, but when THD is this low its like chasing butterfly's...

As promised, the FFT Measurements + a snapshot of result screen

Results:-

FFT:-

I'm now building up the balanced symmetrical gain stage which is the heart of the design and the most complex / highest risks... rather nervous....

 

[peterzz]

Thank you for the link, I'll forward it to Dominik, I had a brief look and there was not much that would be useful for the MDAC2. I'd like to have the MDAC2 DSP platform Open to a certain degree so that features can be added by 3rd partys.

I would suggest picking the most powerful chip you can; the more head room you have the more features / mucking about one can do.

If you want 'open' I would suggest you pick a platform for which the specs are feely available and there exist free compilers. (For instance C6x, Blackfin, hexagon have Linux ports, which means these things are likely true).

The XMOS stuff (which I think you were planning on using earlier) has a feely available C/C++ compiler in LLVM and there appears to be a fairly large community on github.

Also, specify as much as possible of the MDAC2 platform, and provide an 'easy' means of building custom firmware and uploading it into the MDAC2. Also make it brick proof; iow. always allow uploading new firmware etc.

I can imagine you would want to keep some filters as proprietary code and not provide source code for all of it, you could think of providing those as linkable object files.

But again, let me stress this, pick the most powerful chip you can get away with. In my experience people never seem to have any trouble at all saturating CPU cycles; and remember 384KHz / 32bit audio is a lot of bits to munge every second.

 

[travelfotografe]

Hi John,

PM Sent. It is about my Premium Fusion OLED Display.

Excited about MDAC2,
Leon

 

[JohnW]

I would suggest picking the most powerful chip you can; the more head room you have the more features / mucking about one can do.

If you want 'open' I would suggest you pick a platform for which the specs are feely available and there exist free compilers. (For instance C6x, Blackfin, hexagon have Linux ports, which means these things are likely true).

The XMOS stuff (which I think you were planning on using earlier) has a feely available C/C++ compiler in LLVM and there appears to be a fairly large community on github.

Also, specify as much as possible of the MDAC2 platform, and provide an 'easy' means of building custom firmware and uploading it into the MDAC2. Also make it brick proof; iow. always allow uploading new firmware etc.

I can imagine you would want to keep some filters as proprietary code and not provide source code for all of it, you could think of providing those as linkable object files.

But again, let me stress this, pick the most powerful chip you can get away with. In my experience people never seem to have any trouble at all saturating CPU cycles; and remember 384KHz / 32bit audio is a lot of bits to munge every second.

Hi Peter,

Yes the XMOS looks good and the dual cores are pretty powerful for there cost. I'm an "hardware" man so while I have a basic understanding of the various DSP processors I don't what to get to evolved with the DSP software etc.

The only limitation we have is that the device must be a leaded package (no BGA) as I need to me able to service the MDAC2's 10 years down the line, and we need to consider the total power requirements.... Poor MDAC2 PSU.

The more powerful Highend DSP's tend to be BGA and require significant power - the XMOS looks good from this perspective.

Don't forget that we still have the FPGA for the really intensive operations such as DSD manipulation.

 

[JohnW]

Hi John,

PM Sent. It is about my Premium Fusion OLED Display.

Excited about MDAC2,
Leon

Leon,

PM sent

 

[JemHayward]

Warning: I'm about to reveal my rather scant understanding of things digital...

Would it be possible/desirable to have an external processor "loop" a bit like we had for three head tape decks so we could add in things like DSP processors, or not, without interfering with the fundamental quality of the MDAC2 itself?

If this is totally daft I'll go and stand in the corner.

 

[peterzz]

Hi JemHayward,

I think something like that should be 'trivially' possible by simply shipping out the stream over USB to a computer, use the computer to run whatever DSP computation, and then ship it back out to the MDAC2 over the same USB connection.

Of course, that requires you have a computer attached over USB, which is something some people might object to (both the having a computer around and having it connected over USB).

Then again, John has been talking about a digital expansion port; and I would be surprised if a similar thing could not be done over that as well, but to a 'dedicated' DSP addition.

 

[JemHayward]

Hi JemHayward,

I think something like that should be 'trivially' possible by simply shipping out the stream over USB to a computer, use the computer to run whatever DSP computation, and then ship it back out to the MDAC2 over the same USB connection.

Of course, that requires you have a computer attached over USB, which is something some people might object to (both the having a computer around and having it connected over USB).

Then again, John has been talking about a digital expansion port; and I would be surprised if a similar thing could not be done over that as well, but to a 'dedicated' DSP addition.

I think the "keep the computer away from the hifi" battle has been lost... I use a wandboard based streamer, the MDAC is essentially a computer, and there are probably computers inside my speakers doing something clever. Noisy cheap switch mode PSUs are the enemy, though some systems seemed to be more bothered by them than others. I rejected the Mac Mini as a source because I'd got a cheap and nasty 3rd party PSU pumping pollution into my Naim system, that really didn't like that sort of thing. Having said that, I've no room for a laptop on my rack, but as Raspberry Pi would fit in fine.

 

[ChrisPa]

I'm not sure why the stream would need to be/should be "shipped out"

If an "off board processor" is going to perform dsp, then let it do it to the signal before it's fed into the mdac(s). And that sort of configuration can be used with any DAC(s)

The mdac2 will contain DSP capability, because that's what John has said he will use for things like advanced clock features (IIRC). He's also said that (at some indeterminate point in the future) the DSP functionality can be expanded to provide other features/capability. So the mdac2 or a set of mdacs can be used as "straight" DACs in conjunction with some other DSP device or with the in-built DSP capability when it's developed.

 

[JemHayward]

My MDAC is my Preamp and so I have two sources. I'd need two DSP units - so built in DSP, or a DSP loop would be easier. All theoretical, as I gave up on room correction (of which I remain a big fan...) when I got some speakers that really don't need it, and needed the unit for my kitchen speakers.

 

[rtrt]

iirc John talked about the DSP capability supporting basic room equalisation via something like REW. REW would do the calculations, with the profile then downloaded to the MDAC2, so that other sources other than a computer could also benefit from the equalisation.

Obviously that may have developed somewhat with the recent thoughts posted around mini-dsp, but my working assumption is that there'll be something of that ilk enabled by the MDAC2 DSP option.

For me i can't think of another use right now for DSP that would interest me and I'm currently holding off on other non MDAC2 DSP solutions, not wanting to effectively 'do it twice'.

Appreciate others may well have different interests.

 

[ChrisPa]

My MDAC is my Preamp and so I have two sources. I'd need two DSP units - so built in DSP, or a DSP loop would be easier. All theoretical, as I gave up on room correction (of which I remain a big fan...) when I got some speakers that really don't need it, and needed the unit for my kitchen speakers.

What is happening to the signal before it goes out to the "DSP loop"?
The volume comes after the DSP calculations, the last step in the chain.

So if you have the need for external/additional DSP, then you chose a multi input dsp unit (all the main current contenders are multi input) then feed the outputs of that into the desired DAC(s)

You can perform the volume calculations in the DSP unit, or if your requirements are only for a total of 2 DAC channels, in the DAC.

 

[peterzz]

One of the things the DSP loop could be used for is to replace any one (or more) stages of the MDAC2's processing and run it on a 'real' computer for R&D purposes.

I bet its easier to prototype filters etc. on the stupid fast machines of today in say Python than it is to hand craft them in some DSP assembler.

Once you have a filter that you like, you can put the effort into writing them in assembly or whatever the DSP/FPGA likes.

 

[ChrisPa]

One of the things the DSP loop could be used for is to replace any one (or more) stages of the MDAC2's processing and run it on a 'real' computer for R&D purposes.

I bet its easier to prototype filters etc. on the stupid fast machines of today in say Python than it is to hand craft them in some DSP assembler.

Once you have a filter that you like, you can put the effort into writing them in assembly or whatever the DSP/FPGA likes.

Think about the first question in my post:

What is happening to the signal before it goes out to the "DSP loop"?

Put the "loop" before the DAC rather than feeding a signal straight into it and straight back out again

 

[peterzz]

Think about the first question in my post:

Put the "loop" before the DAC rather than feeding a signal straight into it and straight back out again

Well, that all really depends on what your source is and how many stages the actual processing will have.

For instance, remember that people wanted to do a RIAA curve on the ADC in, with a linear phono amp. Or you're getting your data from an SPDIF source. In these cases where the source is not the USB its easy to see you have to stream your data out first.

But also in cases where the MDAC2 processing pipeline will have to do a number of stages and you only want to replace one in the middle, irrespective of the source, the MDAC2 will do some processing, then ship out the intermediate stream, you muck it about with a computer and hand it back, and it does another few passes on it.

Imagine something like (pure illustration, take actual stages with a large rock of salt; DSP stuff is not my forte):

<source> -> [RIAA stage] -> [ROOM Eq] -> [low-pass/cut-off filter] -> [digital volume control] -> [modulator control] -> 6bit SDM

And you really fancy trying a blackman windowed sinc filter instead of optimal trancient. So you cut out the MDAC2's filter stage and let your computer do it, while leaving the MDAC2 doing all the rest it normally does.

 

[jansen]

Dear John,
I will take it as it comes... Do you have any idea of updated timescales for the release of mdac2 and vfet monos? I am patient enough but I am just curious what yourself are thinking about that.

 

[JohnW]

Both the MDAC2 and VFET amps will be completed and shipped before Christmas at the very latest.

By this weekend I hope to have the first results of the MDAC2 Analogue gain stage. Once the topology of the MDAC2 has been confirmed and tested then I'll spilt my time 50:50 between the MDAC2 and VFET designs.

While the MDAC2 PCB was being manufactured I progressed with the VFET amplifier output stage design:-

https://dl.dropboxusercontent.com/u/86116171/VFET A03bbb 150mm.jpg

The measured results of the MDAC2 output stage are important feedback relevant for the VFET output stage design, so I need to complete the MDAC2 test first.

 

[ChrisPa]

Peterzz

Ah! The ADC. I wasn't thinking about that

In which case, I'm sure there will be an option to feed the adc output to one of the digital outputs. All existing as/da converters are like this.
(Do I remember correctly that the digital i/o would be selectively configured to be either input or output)

In which case my comments I believe still apply - do all the external processing on the digital signal before it's fed into the DAC.

Effectively multiple DSP manipulation is like multiple multiplication stages and, apart from maintaining gain structure, it doesn't matter what order you do them in. And to a great extent you are/can bundle lots of "stages" into a single calculation. With regards gain structure, as far as possible you leave your attenuating functions until later in the processing so that you maintain as high resolution as possible throughout the calculations.

I can't see any reason why you should split the mdac's manipulation into "before" and "after". Especially since internally it will be using something like 48, 56 or 64 bit internal data for DSP, and there's no ready standard way to get that in and out to other "standard" devices

 

[JohnW]

Update on the DSP side of things....

I had a very constructive conversation with miniDSP guys and I'm very - shall I say even "excited" as the DSP side of the MDAC2 platform has the possibility of being better then we envisaged.

No NDA has yet been signed so I'm not sure how much miniDSP will be happy about me discussing in public, but the loose idea is that we design our MDAC2's DSP hardware to be compatible with miniDSP framework - in fact I'll design in the DSP based upon MiniDSP recommendation, something along the lines of one of their existing platforms (or as common as possible).

The MDAC2 would be in-essences a subset of one of their DSP boards - only with the MDAC2 ADC / DAC as integrated frontend / backend hardware.

MiniDSP will provide a "authentication processor" which can be embedded within the MDAC2's existing MCU as a way of protecting and enabling their own software IP.

The direction of the discussions is that MiniDSP will directly support their package of DSP features via their own website and provide future DSP software support - MDAC2 owners can visit the miniDSP website and purchase / download any of the supported DSP software features.

We discussed about offering a basic "get you going" DSP package included as part of the initial MDAC2 release (downloadable via the miniDSP website as an introduction to the "world" of miniDSP), I'm thinking about basic tone controls, and possibly the RIAA EQ for the L3 units.

For MDAC2 owners who have no interest in the DSP this has Zero impact on you, the DSP will still control the Advanced clock etc. you have no extra cost involved by having the miniDSP door open - but for those who wish to explore the more serous side of DSP can visit the MiniDSP website and explore to your hearts content

I just want to stress that enabling the MiniDSP support does not add ANY additional cost to the MDAC2 hardware (it just needs to be considered and enabled during design). As I've not yet started the Digital PCB it does not introduce any delay, in fact its helpful as it clarifies our DSP path - which will now based upon miniDSP's recommendation.

The MDAC2 will be software / firmware upgradable via the USB - each unit will have its own "authentication processor" with serial no. so its between miniDSP and MDAC2 owner what extra DSP features they choose to pay for and install at anytime in the future - it be nice if we receive a small commission for each software download to keep the lights on here in Czech Rep. but not a condition

I'm excited because this opportunity vastly expands the MDAC2 DSP feature set with SERIOUS room correction and other professional DSP features.

Its early days in the discussions, but we still will be able to offer DSP functions that miniDSP might not be interested in (so the MDAC2's DSP is still open for our own developments) - but when it comes to DSP software, miniDSP are in a totally different category to what would be our basic Mickey Mouse offerings... We design hardware and have no infrastructure or desire to support advanced DSP software.

We would support Multi channel (Daisy-chained) MDAC2's for speaker crossover design via miniDSP etc...

MDAC2 with its "Reference grade" DAC conversion, very decent ADC's and now advanced DSP support is going to be a very unique and stunning platform - I like the way its "naturally" developed and grown into such a impressive unit - thank you for your patience and support

I should lastly add, that nothings confirmed yet as miniDSP need to time to sit down and discuss amongst themselves if their is a strong enough businesses case. I have no idea what will happen with MDAC2 beyond the initial units, maybe someone will licence the design... who knows my only concern is our "few" PFM units after 3 years of my life developing the design, it be nice if the MDAC2 platform saw life beyond the initial batch but nothing I've made any serious consideration for ATM - I'm a designer not a production manufacturer....

 

[KevinNZ]

Wow John! This is all getting scarily exciting...

Just out of interest, is there a possibility at least that advanced DSP could further improve the performance of the clock (w.r.t. jitter I suppose)..?

Cheers,
Kevin.