MDAC First Listen (part 00110100)

[Nick1881]

Nick,

The MDAC2 will be very decent especially now we have the HQ PSU as standard...

If you itching for an upgrade and are OK with RCA outptus - hold off for a month or so and I'll arrange the little DAC for you it will more then tie you over until May and MDAC2

The "little Dac" uses a pair of the latest hyperstream II DACs from ESS and are sonically a big step up

Hi John, thanks for the offer but my amps are fully balanced.

What is MDAC 2 cost going to be again, then how much more will it cost for me to get an FDAC when that is ready? Just don't want to commit to too much spending or miss out on the FDAC, at the same time I know I'm going to be jealous of MDAC2 deliveries.

Also I still have your Quad amp here, do you still want this or if you want to sell it someone would be welcome to pick it up, or I could drop it off on my travels.

John, please try to take some time off for Christmas, I wish you and Renata a great Christmas and new year.

All the best
Nick

 

[Superior]

Hello everybody,

first I have to say that I can understand all the doubtfully PFM members here. I´m also waiting for two FDACs and two Detox for over 4 years now. But now I think it´s worthwhile to wait, till John is completely happy with his designs.

I always hoped that my little blown MDAC cabs last as long till Johns new designs are ready for shipping. Sadly the cabs failed earlier. Then I send my MDAC over to John for replacing the bad cabs and after a few days, he offered me to fit a new analoge stage similar to the FDAC design called Superior Board. One or two month ago, I got my fixed MDAC back. It was packed up like a little present For the guys who now will ask how it sounds: I can tell you it is really really good and I can promise everybody a really big smile when hearing Johns design skills. Although I only have the „simple version“ of the superior board, without any vishay resistors or a special power supply, it makes so much fun. Playing with low volumes levels (below -50dB) also makes much more fun than before.

Of course I also have had a look inside to get an idea of Johns work. As an electrical engineer I can confirm Johns design skills and his love for details. The PCB is perfectly fitted inside between all the components. The symbiosis between the old MDAC PCB and the superior board is amazing. Also Johns soldering skills are really remarkable. In my eyes, the price I had payed for the superior pcb upgrade is much less than the effort and time it takes to design, built and test such an upgrade.

So thank you John for your great work!
Every day anew, we have much joy with your special superior creation

Ps: Have you heard something new from audiolab and the spare remotes?

 

[iansr]

Very pleased with the move to RPi, as there is a lot of expertise out there for that platform, and it makes for a relatively future-proof solution, which is important for the small community of FDAC users, as I think we are all looking at this as a long term, or maybe for some of us, final DAC.
The delays, for me, have saved me a lot of money. I allocate a small amount of money each month for "luxuries" and normally what goes in, comes out, and it never amounts to much. Although my VFET and FDAC contributions emptied the fund, and other savings, since then I've not spent money chasing the "holy grail", because I think I know where it is, and I'm just patiently waiting for it to arrive.
I understand the frustration of those eager for new toys (as we all are) but to be really cynical, anyone on the FDAC list will, eventually, be the owner of possibly one of the best, and rarest DACs on the market. If you really don't want it at that time, there will be plenty of people out there prepared to spend way more than we have invested to join our exclusive club.

And it's also worth remembering how much these cutting edge products would cost if we were buying through the usual channels. It's no exaggeration to say that we are paying only a fraction of what we would otherwise pay. Am I being a "fanboy"? No, just realistic.

 

[Rune]

Native DSD (not DoP) will need a modified kernel (at least initially, I'll send patches upstream when MDAC2 is released), but I know what to modify. However I'll need to ask Jarek what endianess he decided to use for the raw mode when programming the XMOS chip. The supported formats/bitrate is something that the XMOS needs to announce via USB (I could theoretically override it, but it would be a hack).
Also note that I don't think any of the streaming services/protocols support DSD and I'm not sure if volumio / other software does - I can get it working on the "low level", but we may still need some GUI player software that can play it as most people probably won't want to type commands on the console.

I could (and would like to, maybe over time) create a minimalistic ~50MB system (everything in RAM) that would basically run all the streamer services with as low overhead as possible (ie. no GUI on HDMI), to hopefully cut on the RF radiation. I can even use the realtime kernel patchset if necessary. This could be used for FDAC as well, as long as the custom GUI is written in a language that doesn't eat all the RAM (ie. C++, not Java ).

Regarding CM3 on FDAC - as long as Jarek can wire everything else up to the other MCU (some UART connection for programming the digital IO, etc.), it should be fine. The protocol for the embedded display should be well documented as there are several 3rd party displays for the RPi. Having Ethernet and SATA via internal USB sucks, but the speeds are not much better on the Allwinner, which still offloads most of the work to software (saving costs on dedicated HW) - you can't compare SATA speeds of a high end Intel desktop using a hardware-based controller with the ARM SoC emulating it in software.

Are there any real SQ difference between playing Native DSD or DoP?

Both Roon and LMS can stream Native DSD or DoP to the endpoints RoonBridge and Squeezelite.

Latest versoin of DietPi has UI for installing RoonBridge or Squeezelite so might be a good starting point and the developer seem very keen to support it.
I has just recently added support for Roon and when some one asked for HQPlayer NAA support he added it in a few days. He is active on the Roon forum.

My only concern with RPI is can it reliably stream DSD256?

 

[BrianPK]

For the guys who now will ask how it sounds: I can tell you it is really really good and I can promise everybody a really big smile when hearing Johns design skills. Although I only have the „simple version“ of the superior board, without any vishay resistors or a special power supply, it makes so much fun. Playing with low volumes levels (below -50dB) also makes much more fun than before

Great to hear such positivity.
You are really whetting my appetite.

Very interesting comment about listening at very low volume.I've experienced the same very recently when I had my amp upgraded with extra capacitors. . . no great need to use my headphones late at night now.

 

[BE718]

BE718

from my point of view there are two kinds of participants here.
Ther first one is knowing about Johns Know How and experience and the confidence that he would do everything possible to deliver the best possible solution and try to satisfy every ones personal requirements ( thats one of the resons why such open discussed projects are very, very, very hard to be managed)
This type of participant is thankful for the chance to be part of such an unique project, beeing involved in technology discussion to find best solutions for all and sometimes recieving a product with an amazing price performance ratio.
The second one is the one who is not directly interested in all technical discussions and knowledge and he does not care about someone who pours his heart and soul into his work . He has only one reason for participating. Bying a superb product for as little money as possible.
But there is nothing you recieve as a gift. The second type should have been
clear on taking a risk with his participation.
So it is up to you to decide to which kind of participant you belong.

Christmas is just around the corner an I try to go for my good deed today.
So BE718 I can jump in for a second investment and take over yours but only on one condition. Please stop undermining this project.

Hi eernie

There simply comes a point when one has to draw the line. I have reached my limit with a project that has gone way beyond what I would consider reasonable. I think i have been more than patient.

Thank you for your offer, I will contact you to see what we can arrange. Please undetstand my only objective is to get out of a project that, as far as I am concerned, has gone way beyond what any reasonable person would expect to wait for.

Whatever others are claiming there was never an indefinite timescale, there was never a license for John to take as long as he pleases to deliver.

Frankly he should be grateful to have the benefit of my cash for such a period of time.

Its actually Johns failure to deliver that has undermined the project, not my reasonable request for a refund because he hasnt delivered.

Rest assured that once I have got my money back I am gone, I have zero interest in following the project further or engaging in any way with it. Others are perfectly entitled to spend their money and time as they wish. This isnt a vendetta.

Regards

Alan

 

[jirij]

Are there any real SQ difference between playing Native DSD or DoP?

Probably not, both transfer exactly the same bits and as long as they are clocked by the DAC, any difference is going to be down to secondary effects, which are hopefully going to be minimal / nonexistent on the MDAC2 or especially FDAC.

The advantage of native DSD is that it doesn't have the 1/3rd overhead present in DoP (to ensure safe playback of white-ish noise on non-DoP devices). Plus DoP is really standard only up to DSD128 and even then, there are two separate incompatible ways to do DSD128. Anything above is left to imagination (more channels? higher rate?).

So use DoP only where you don't have any other option, that would be my advice.

Both Roon and LMS can stream Native DSD or DoP to the endpoints RoonBridge and Squeezelite.

Then DSD support should be reasonably easy to implement as long as roonbridge/squeezelite use the standard ALSA libraries.

Latest versoin of DietPi has UI for installing RoonBridge or Squeezelite so might be a good starting point and the developer seem very keen to support it.
I has just recently added support for Roon and when some one asked for HQPlayer NAA support he added it in a few days. He is active on the Roon forum.

My only concern with RPI is can it reliably stream DSD256?

Yeah, I imagine most of the work is done and just flashing the image onto the SD card is all that's needed for basic PCM+DoP support. Native DSD will need a tiny kernel patch (for the time being), but other than that, no software changes needed - that's the idea of using USB/XMOS, that people can just use off-the-shelf OS images. Ideally.

We'll see if the 400MHz CPU on CM1 can handle DSD256, but IMHO there's no reason it shouldn't. While you might associate DSD with high sampling frequencies, those are calculated for 1-bit values. The OS doesn't work with them like that, it uses 8b/16b/32b words which align to CPU register sizes, so it can batch-transfer those bits much faster than it would seem - the XMOS uses 32b words, that means 352.8KHz rate for DSD256, which seems perfectly doable.

 

[adamdea]

I see that something approaching normal service has resumed. I hope that this relates only to good humour and not what might most kindly be described as over-perfectionism. I do think that we are all largely in here for the ride; but the ride does have to come to an end, or at least a definite stage.
I have a lot of sympathy for Alan's position but my major concern is that we can avoid a polarisation into a choice between anger and frustration on the one hand, and self-deluding adulation on the other.

I think John does deserve our support and encouragement, but that has to include encouragement to finish things off. I for one know that if I didn't have any deadlines I wouldn't get things done in my life. What we all really need encouragement for is the work we don't want to do, not our favourite parts.

It's quite obvious for that mission creep plays a big part in the delays, but equally obvious that it is not the whole story. I'm not interested in post mortems (or vivisections for that matter): I just want the project to be completed, which means constant bit by bit progress. I'm sure that John's genius has done its bit already.

In the long run we are all going to be happier once we have the mdac2 and the detox (which I plan to use to flatten creased record sleeves) and can then look forward to the Fdac properly.

 

[Mark Dirac]

Hello John. I have just signed up to the Detox project. I never really understood why the Detox was needed for the FDAC, but have nonetheless decided that the interim MDAC2 is likely to need all the help it can get.

Regards, Mark.

 

[Rune]

We'll see if the 400MHz CPU on CM1 can handle DSD256, but IMHO there's no reason it shouldn't. While you might associate DSD with high sampling frequencies, those are calculated for 1-bit values. The OS doesn't work with them like that, it uses 8b/16b/32b words which align to CPU register sizes, so it can batch-transfer those bits much faster than it would seem - the XMOS uses 32b words, that means 352.8KHz rate for DSD256, which seems perfectly doable.

The CM1 will work with squeezelite but not Roon because it requires Armv7.
But that is not a problem since it will work with CM3 which is the one we will use.

 

[jirij]

The CM1 will work with squeezelite but not Roon because it requires Armv7.
But that is not a problem since it will work with CM3 which is the one we will use.

I've heard roon can use squeezelite on the streamer side - if that's true, we theoretically need just squeezelite (and airplay server and whatever else for dlna, hqplayer, etc.).

 

[Rune]

I've heard roon can use squeezelite on the streamer side - if that's true, we theoretically need just squeezelite (and airplay server and whatever else for dlna, hqplayer, etc.).

Yes Roon can stream to squeezelite but there are advantages with Roonbridge such as better protocol that handles clock and multiple devices. Just settle on testing squeezelite. Those that want roonbridge like me can istall it themselves self.
It would be neat to be able to select squeezebox or Roon from the remote just as any other source (future feature request)

 

[Mark Dirac]

(future feature request)

No more feature requests please. Not today, anyway.

 

[BE718]

Hi John

Your mailbox is full. Can you please get in touch with PFM member Eeerni

http://www.pinkfishmedia.net/forum/member.php?u=21202

regarding the transfer of my MDAC and detox slot to him. I believe he is also contacting you to confirm my payments. I have sent copies of my paypal invoices to him.

regards

Alan

 

[jadidih101]

JohnW,

Wishing you, Renata and other Lakewest projects' participants a happy Christmas and a happy, successful and productive new year.

Thanks for all your hard works.

Cheers.

 

[fred sonnen]

JohnW,

Wishing you, Renata and other Lakewest projects' participants a happy Christmas and a happy, successful and productive new year.

Thanks for all your hard works.

Cheers.

This %-)
And again thanks for repairing my Mdac / Cap Exchange so fast!!!

Greetings
f.s.

 

[Jason_PFM]

Hi John

Your mailbox is full. Can you please get in touch with PFM member Eeerni

http://www.pinkfishmedia.net/forum/member.php?u=21202

regarding the transfer of my MDAC and detox slot to him. I believe he is also contacting you to confirm my payments. I have sent copies of my paypal invoices to him.

regards

Alan

Good for you Alan
I thought you made your point very clear and you didn't deserve to be bashed by the self-proclaimed disciples/soldiers.
We all have some limit in the end, and you just made it clear you had reached yours. Credits for standing up even though you knew the crowd would be there to crucify you; man these are religious times, pun intended ;-)

Respect for Eeerni for really following through instead of just some hollow promise.

Hope that's sorted, so we can go all back to our usual show.
Enjoy the Holidays

 

[Steven Toy]

I take MDAC2 as a "demo" version of FDAC - if FDAC never happens because of the enormous scope (DSP/room correction, zillions of software features, etc.), then at least there's MDAC2 where the focus isn't (or shouldn't be) on feature set (as FDAC), but on delivery time. I had some concerns about the (IMHO unnecessary) streamer board slowing things down, but if it's really put aside until the main version ("Stage 1" as mentioned above) is done, then I guess it's fine.

I too would rather have the FDAC right away, but we don't live in an ideal world.
From a theoretical PM view, XMOS-only MDAC2 with simple UI focusing just on the DAC part seems much more of an achievable goal with much less risk. And that's IMHO what John needs right now - something to finally get out there as a product.

The built-in streamer is unnecessary, adds ominous complication and has served only to delay the project.

It could be an entirely separate project that would have neither delayed (until when?) nor compromised FDAC.

 

[iansr]

The built-in streamer is unnecessary, adds ominous complication and has served only to delay the project.

It could be an entirely separate project that would have neither delayed (until when?) nor compromised FDAC.

I think you forgot something.

 

[stephengrenfell]

Probably not, both transfer exactly the same bits and as long as they are clocked by the DAC, any difference is going to be down to secondary effects, which are hopefully going to be minimal / nonexistent on the MDAC2 or especially FDAC.

The advantage of native DSD is that it doesn't have the 1/3rd overhead present in DoP (to ensure safe playback of white-ish noise on non-DoP devices). Plus DoP is really standard only up to DSD128 and even then, there are two separate incompatible ways to do DSD128. Anything above is left to imagination (more channels? higher rate?).

So use DoP only where you don't have any other option, that would be my advice.


Then DSD support should be reasonably easy to implement as long as roonbridge/squeezelite use the standard ALSA libraries.


Yeah, I imagine most of the work is done and just flashing the image onto the SD card is all that's needed for basic PCM+DoP support. Native DSD will need a tiny kernel patch (for the time being), but other than that, no software changes needed - that's the idea of using USB/XMOS, that people can just use off-the-shelf OS images. Ideally.

We'll see if the 400MHz CPU on CM1 can handle DSD256, but IMHO there's no reason it shouldn't. While you might associate DSD with high sampling frequencies, those are calculated for 1-bit values. The OS doesn't work with them like that, it uses 8b/16b/32b words which align to CPU register sizes, so it can batch-transfer those bits much faster than it would seem - the XMOS uses 32b words, that means 352.8KHz rate for DSD256, which seems perfectly doable.

Why bother with RPi CM1 ?.

Sure you can probably run the RPi/CM1’s 32 bit ARMv7 SW in compatability mode on the RPi3/CM3’s 64bit ARMv8. But why run « old SW » on a newer Platform ?.

AFAIK there are some driver issues between RPi1 / CM1 to RPi3 / CM3.

Better to use an RPi3 as SW development platform since it is fully compatible SW wise with the RPi CM3.

MDAC2 delivery is still six months away according to the latest info on some boards reday for Munich. If RPi CM3 isn’t available by then (and it probably will be) MDAC2 can be delivered with the SoC converver card and the RPi CM3 added later by the user (it’s SODIMM connector is the same as installing a memory module). This would decouple the MDAC2 delivery and RPi CM3 SW project.

Delivering MDAC2 with and RPi CM1 and then migrating to RPi CM3 also adds costs for everyone.