Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[daberti]

Hello, using MC23 latest release with my Mojo, either ASIO or WASAPI, depending on situations.

MC23 defaults to 32bit bitdepth on the assumption that being the highest one supported by Mojo it is the best.
So I've 16 and 24 bit sources played at 32bit.

Now, I do want all the files to be played exactly at their own original bitdepth.

The point is: HOW?

Thanks for helping

[Awesome Donkey]

MC automatically pads the bit-depth on-the-fly to the highest bit-depth supported by your DAC. There's no dithering or anything like that happening, so it's still bit-perfect playback, even with the padding to 32-bit. It's simply just padded with zeros.

[daberti]

MC automatically pads the bit-depth of your files on-the-fly to the highest bit-depth supported by your DAC. There's no dithering or anything like that happening, so it's still bit-perfect playback, even with the padding to 32-bit.

Thanks for the reply.
Sorry but I quite don't get the rationale behind that.
I.e.: should I wish to do that I'd have a certain DAW SW at the ready.
I switched off any DSP whatsoever AND the usage of System Volume just to discover that MC23 pads to 32bit.

Of course no dithering is done, you dither when you go from i.e. 24bit to 16bit.

In the end, that DAW SW has a player and uses Asio->Mojo but listening to same 24bit sample tracks is delivering a more cohesive, faithful and less uselessly and unfaithfully forward audio rendition, frequency plots at hand.

Now, I'm into MC24 pre-order, having purchased MC23 recently (and other previous MC versions), please give it back to the educated users the chance of reproducing their music with the very same bitdepth as the original one, eventually reverting to your approach if they like.

Thanks for reading

Dan

[Hendrik]

There is no quality advantage to be gained from doing this, and it would overly complicate the entire process. Therefor, output bitdepth is fixed at the "native" rate of your DAC.
Note that DACs are usually not 32-bit, but many want 32-bit data through ASIO, which is why there is an option in the ASIO output plugin to always deliver 24-bit audio to them (because ASIO rarely ever communicates this requirement directly).

[RD James]

Sorry but I quite don't get the rationale behind that.

It means that you don't have to do any mode switching when changing bit-depth but not sample rate; e.g. 16-bit 44.1kHz to 24-bit 44.1kHz or vice-versa.
It also means that you don't have to switch modes if you enable DSP or even something as simple as reducing the volume. It would be ridiculous if you were playing a 16-bit file and then had to wait for the DAC to resync as it switches to 24/32-bit if you reduce the volume below 100%.
 
There's zero benefit to outputting 16-bit tracks as a 16-bit signal, and multiple downsides.

[daberti]

There is no quality advantage to be gained from doing this, and it would overly complicate the entire process. Therefor, output bitdepth is fixed at the "native" rate of your DAC.
Note that DACs are usually not 32-bit, but many want 32-bit data through ASIO, which is why there is an option in the ASIO output plugin to always deliver 24-bit audio to them (because ASIO rarely ever communicates this requirement directly).

Mojo (and Hugo FWIW) are a glad departure to many extents from usual chip type DACs.
I'll have to ask Rob about that, yet I can guess his own answer.

[daberti]

It means that you don't have to do any mode switching when changing bit-depth but not sample rate; e.g. 16-bit 44.1kHz to 24-bit 44.1kHz or vice-versa.
It also means that you don't have to switch modes if you enable DSP or even something as simple as reducing the volume. It would be ridiculous if you were playing a 16-bit file and then had to wait for the DAC to resync as it switches to 24/32-bit if you reduce the volume below 100%.
 
There's zero benefit to outputting 16-bit tracks as a 16-bit signal, and multiple downsides.

Well, about the volume: I did never use any kinda volume into MC and I never make any DSP whatsoever into it. I simply use a DAW to check if any EQing is needed and act accordingly. Never happened for EQing, happened for clipping and noise and spurious freq. removal many times.

Anyway, I've just noticed that the fresh install of MC23 had Internal Volume set. Just opted for No Volume and now audio rendition is pretty close to what it should be.

[RD James]

Well, about the volume: I did never use any kinda volume into MC and I never make any DSP whatsoever into it. I simply use a DAW to check if any EQing is needed and act accordingly. Never happened for EQing, happened for clipping and noise and spurious freq. removal many times.

Anyway, I've just noticed that the fresh install of MC23 had Internal Volume set. Just opted for No Volume and now audio rendition is pretty close to what it should be.

I'm not entirely sure what you mean about using a DAW, but it doesn't matter if you personally use volume control or not (though I highly recommend enabling Volume Leveling and TPDF dither).
The point is that matching the bit-depth to the source means that if someone were to adjust the volume - and most people probably do at some point - the DAC would have to resync as the bit-depth is increased from 16-bit to 24/32-bit.
It does no harm to pad a 16-bit track to a higher bit-depth, and it makes volume/DSP changes seamless, so there's no reason not to do it.

[AndyU]

Mojo (and Hugo FWIW) are a glad departure to many extents from usual chip type DACs.
I'll have to ask Rob about that, yet I can guess his own answer.

Last thing I heard was that Rob Watt uses MC by preference with all the DACs he designs, so it should be easy to guess his answer. The ASIO driver Chord supply wants 32 bits, so I would suggest you just use it and don’t select the 24 bit option in the ASIO plugin in MC. It’s up to you whether you use the volume control in your DAC or in MC. If you use the latter, or any DSP,  you might want to pay some attention to which dithering you go for in MC - either of the possibilities is better than none.

And are you saying that you can measure a difference in the frequency response of MC against a DAW? If so, can you provide the plots and more details about the DAW.

[daberti]

Last thing I heard was that Rob Watt uses MC by preference with all the DACs he designs, so it should be easy to guess his answer. The ASIO driver Chord supply wants 32 bits, so I would suggest you just use it and don’t select the 24 bit option in the ASIO plugin in MC. It’s up to you whether you use the volume control in your DAC or in MC. If you use the latter, or any DSP,  you might want to pay some attention to which dithering you go for in MC - either of the possibilities is better than none.

And are you saying that you can measure a difference in the frequency response of MC against a DAW? If so, can you provide the plots and more details about the DAW.

Right now I'm feeding it exactly the way MC wants. 32bit.
And having solved the issue the way I said (volume) in the most simple of ways I can say I'm happy.
DAW confirmed in my case that there was an upright bass incipit in a certain track, my ears (before the solution) delivered to me something else.
Before the solution I said.

EDIT:
So, thanks to everyone that shared his toughts, helping me to understand MC's own approach and -last but not least- to achieve a fully satisfying result.

[daberti]

And now I've got a reasonable answer about why I solved the way above:

https://www.head-fi.org/articles/chord-mojo-faq.18671/
"Q. Should I use the volume control on my computer/DAP/digital source or should I use the volume control on the Mojo?

rob watts said: ↑


  It is always better to give Mojo bit perfect files and let Mojo do the work, as the processing within Mojo is much more complex and sophisticated than a mobile or PC.
 
 So when you have an app that has a volume control, and no bit perfect setting, then set it to full volume on the app on the assumption that this will keep the data closer to the original file.
 
 The volume control function on Mojo is much more sophisticated than the PC as I employ noise shaping and I do the function at a very high internal sample rate. Hopefully using the volume set to max on the app will mean the volume coefficient is 1.0000000... so it will return the original data.
 
 Rob "

That is Rob's own thought and it proved true in reality to me.

[RD James]

The ideal scenario would be that the volume level is controlled via a driver on the PC which interfaces with the DAC and controls its internal volume level, rather than processing it on the PC.
The fact that the Chord DAC uses noise shaped dither is exactly why I would recommend using flat TPDF dither on the PC unless you know for sure that the DAC itself is using flat TPDF dither. Media Center does not use noise shaping, its TPDF option is flat (well, there's a very slight +3dB tilt, which is not going to have any impact).
Stacking multiple noise-shaped dithers on top of one another is what can lead to problems.
 
It's also true that, if you're going to use noise-shaped dither, it's probably best done in the DAC.
The internal sample rate of the DAC may be several times higher than the maximum format it accepts over a USB connection, which lets you push that noise shaping further from the audible range.
The fact that noise-shaped dither can be effective, is something to think about for people who believe there's any merit to "high res" audio (specifically high sample rates).
Of course you never know how an amplifier or speaker/headphones is going to handle that ultrasonic content, and it may introduce distortion in the audible range which would not be there if you used flat TPDF dither instead - so you do not always want to be using noise shaping.
 
However, Media Center's internal processing is 64-bit, your DAC accepts a 32-bit signal, and its analog output will be <24 bits.
No DAC has 24-bit performance in the analog domain, and very few approach 22-bits. Even if the output was 24-bit, the TPDF dithering from Media Center would be below the analog noise floor of the DAC.
So Media Center's processing for DSP features like Volume Leveling - which I highly recommend that you try - should have effectively no impact on audio quality whatsoever.
 
And even if you disable the internal volume controls and all DSP in Media Center, it still doesn't make a bit of difference to the audio quality whether you output a 16-bit track as a 16, 24, or 32 bit signal.
It only matters if the output bit-depth is lower than the source bit-depth. And if you're dithering that conversion properly - which Media Center does if dither is set to TPDF - the only difference will be a very minor hiss when played back at extremely loud volume levels.

[daberti]

Thanks for your reply RD James.

I tried MC Internal 64, System and no volume and with Mojo and CF Lyra II (and Oppo PM3 as well) a difference there was.
If I got Rob's comments right, written well before my "issue", basicly he says "Output to Mojo (or Hugo FWIW, my own note) the full (no app's volume Handling) and bitperfect signal, with no DSP whatsoever...".
Using an iPhone app (which I will NOT mention here for obvious reasons) in that way (bitperfect, no volume control) I double checked the truth of his own words. And with the DAW SW on PC (Mojo Asio driver as in MC) I triple checked.
I'm with you that theoretically Media Center's processing for DSP features like Volume Leveling - which I did try - should have had effectively no impact on audio quality whatsoever. But they audibly had.
And the lack of a bitperfect output by means of 32 bit padding from 24 bit sources possibly played a role as well.
The sources were from Aix Records, and we all know if Mark Waldrep is a badass of an Audio Engineer or not

I understand the rationale of padding to 32 bit as well. But, once again if I did get it right, Rob's words are adamantine: bitperfect output it has to be.

Dan

[RD James]

I'm with you that theoretically Media Center's processing for DSP features like Volume Leveling - which I did try - should have had effectively no impact on audio quality whatsoever. But they audibly had.

Did you ensure that the volume level was matched for this comparison? Not by ear - using hardware to measure it.
People often describe louder as better, and Volume Leveling typically reduces the playback level.
 
At a matched volume level there should be no difference in quality. If anything, Volume Leveling ensures that there will be no inter-sample clipping on playback.
I expect that the Chord DAC has internal overhead to prevent against inter-sample clipping, but many DACs do not.

I understand the rationale of padding to 32 bit as well. But, once again if I did get it right, Rob's words are adamantine: bitperfect output it has to be.

I'm sure he would agree that it makes no difference to output a 16-bit track padded to 24 or 32 bits when there is no DSP being applied to the output, and that it is better to use the highest bit-depth supported if DSP is being applied.

Code: [Select]

                1111111111111111
        000000001111111111111111
00000000000000001111111111111111

These all represent the same value and have no effect on sound quality.
If you're hearing a difference, it is in your head, and only because you believe that it is "not bit-perfect" and somehow worse.

[daberti]

Did you ensure that the volume level was matched for this comparison? Not by ear - using hardware to measure it.
People often describe louder as better, and Volume Leveling typically reduces the playback level.
 
At a matched volume level there should be no difference in quality. If anything, Volume Leveling ensures that there will be no inter-sample clipping on playback.
I expect that the Chord DAC has internal overhead to prevent against inter-sample clipping, but many DACs do not.
I'm sure he would agree that it makes no difference to output a 16-bit track padded to 24 or 32 bits when there is no DSP being applied to the output, and that it is better to use the highest bit-depth supported if DSP is being applied.

Code: [Select]

                1111111111111111
        000000001111111111111111
00000000000000001111111111111111

These all represent the same value and have no effect on sound quality.
If you're hearing a difference, it is in your head, and only because you believe that it is "not bit-perfect" and somehow worse.

James.
I'm able to easily spot a +/- 0.3dB difference in the 60Hz-14kHz range according to my last hearing test (professionally done at a local center) AND my girlfriend (a Nuclear Engineer) was at commands: all I knew was the environment (PC or iPhone) and obviously the headphones that were into or over my own ears (some form factor difference between IEM and PM3)
Padding is an agreed handy trick for CHIP DACs, but maybe (pending Rob's thought) NOT the same for the FPGA ones in the league we're talking about and it is NOT bitperfect. Bitperfect means delivering to DAC the very same stream under any extent, so that written on a file would produce the same CRC.
And yes, I'm thinking too that Chord DACs have a clipping protection algo/overhead.
I wouldn't be suprised given that remarks from Rob on other topics...
"PC's  CPU's are very restricted in what they can do for real time signals. You simply can't replicate the processing that even Mojo (let's leave Hugo or Dave apart) does in a PC - because PC processors are sequential serial devices with a very limited number of cores. When you are doing a doing a FIR filter (a tap) you need to read from memory the audio data; read from memory the coefficient data; multiply the numbers together;then read the accumulated data and add that to the previous multiplication; then save the result. Lots of things to do in sequence. With an FPGA you can do all of these things in parallel at once, so a single FIR tap can be accomplished within a single clock cycle (obviously pipelined) - you are not forced to do things in sequence."
Some exceptions can only be made to limited extent when offloading these tasks from CPU to GPU. There is a SW for Win and other OSs doing that.

Back to the egg: I wonder (just wonder for God's sake ) why something as plainly standard as PCM bitperfect playing is NOT available on MC if only to compare on each one's DAC against the 32bit padding solution.
Even on that iPhone app I'm given the option of padding to 32 bit or going bitperfect, afterall.

Anyway, I just let MC to do the least possible tasks and leave the rest -volume included- exclusively to Mojo.



 
What some people do not understand is how capable FPGA's are. ...... because an FPGA is fantastic at doing fixed real time processing - it takes small die area, and can do complex operations with very low power. Mojo for example has 44 dsp cores, uses sophisticated filtering to 104 MHz, and noise shapes at this rate...

[RD James]

It's hardly surprising that the guy trying to sell an FPGA DAC tells you how much better it is than anything else.
Companies marketing to audiophiles love to tell you how bad computers are for processing audio, for all sorts of made-up reasons.
 
Sometimes there is a kernel of truth there. You aren't going to have a computer upsample audio to 104MHz because no DAC has an interface to accept a 104MHz signal from one.
It's not really relevant to the discussion at hand though, since we are talking about bit-depth rather than upsampling, and it's questionable how relevant that is to actual playback. Big numbers though.
 
Padding to a higher bit-depth does not affect the "bit-perfectness" of the audio data in any way.
I ran a conversion from 16-bit to 32-bit, then from 32-bit back to 16-bit, and used dBpoweramp to calculate the audio CRC:

Code: [Select]

CRC32 MD5 Filename

5E0B789B 56C09ED895B502639E99000AF61C35DF C:\temp\16-bit source.wav
FA2DEA68 310ABFECB57615A8A2AEC32750BD7925 C:\temp\16-bit to 32-bit conversion.wav
5E0B789B 56C09ED895B502639E99000AF61C35DF C:\temp\32-bit to 16-bit conversion.wav
Padding to 32-bit results in a different audio CRC because it is padded with zeros.
Removing the padding results in a bit-perfect match to the original 16-bit track, proving that the audio data is unchanged.
It makes absolutely no difference to playback if the signal is padded to a higher bit-depth.
 
Whatever difference you think you are hearing is placebo.
You believe that it makes a difference, therefore you're hearing a difference.
There is no difference.
 
And it doesn't matter how good your hearing is. If you tried to match levels by ear, it's not a valid comparison. It only takes a very small difference to bias the comparison one way or the other.
I'm not even sure how you would set up a proper A/B/X test unless you had two of the devices; one using its internal volume control and the other using Media Center's Volume Leveling feature, both going through a switcher.
 
With a properly level-matched comparison and a 32-bit output I wouldn't expect anyone to be able to tell the two apart.
Having Volume Leveling enabled makes music playback a much nicer experience in Media Center though, since it means you don't have to play with the volume control all the time. Set a comfortable level and just enjoy the music.
 
There's really no point in worrying about "bit-perfectness" anyway. As soon as your DAC gets the signal, it's going to be applying its own processing to it rather than ensuring the playback is "bit-perfect".
The only exception to that is a NOS DAC, which your Chord DAC upsampling to 104MHz is antithetical to. And NOS DACs sound bad.
As long as the player is performing DSP with sufficient precision and dithers the signal correctly so that it does not harm audio quality - which Media Center does - it's not worth being concerned about.

[tyler69]

Thanks for the interesting discussion.
I wonder if a different perception of sound quality might be argumented with how the DAC internally processes 16bit vs. 32bit signals.
As far as I understand the OP wants to send 16bit signals when MC only sends 32bit signals (with padded 0's). So to me, the DAC's internal processing would be the only source of sound-altering, no?

[daberti]

It's hardly surprising that the guy trying to sell an FPGA DAC tells you how much better it is than anything else.

We discovered together that the CRC are different and that the 32bit padded sample can be brought back to 16bit without any digital difference. And that it was expected on my side. But you're saying I'm hearing a "placebo" difference: so, different CRC and placebo difference heard?

James, what if Mojo actually takes the 32bit Int and does NOT change it back to 16bit? Question asked to Rob.

The "Mojo does NOT output to 104Mhz" issue. The sentence "You aren't going to have a computer upsample audio to 104MHz because no DAC has an interface to accept a 104MHz signal from one." is not reproducing the whole picture, with no polemics whatsoever.

Let's say you are examining a PCM to find the True Peak Level. Usually SW just go 4x (that's actually the CPU limit for realtime) and call it a day. Some others will go above (offline) and some others notably above thus scoring the most faithful mapping of original analog sound available with CPU equipment. This does NOT mean that they will output to that oversampling factor. But means that they'll have mapped the PCM reasonably closer to the original analog source (with CPU equipment).

Mojo does that in realtime @104Mhz (maybe its bigger bros are going even higher) and arguing that the best possible reconstruction in digital form of original analog domain before feeding the DAC's own analog section is useless and overkill because there is no input or output for the oversampling frequency been used is something any serious Audio Engineer would disagree.
Even more: the rationale behind that multiplying factor is at the core of DSD rationale: as close as possible to analog.


But the point stands still: no PC can just make the same amount of work real-time.

Waiting for Rob, though

Dan

[JimH]

... the point stands still: no PC can just make the same amount of work real-time.

Stating that a DAC has superior performance compared with a PC seems questionable.

Even if "real-time" might be a factor, the DAC still has buffers.

[daberti]

Stating that a DAC has superior performance compared with a PC seems questionable.

Even if "real-time" might be a factor, the DAC still has buffers.

FPGAs are behind Internet backbones for a reason. CPU has limited parallel execution (and thanks to Spectre and Meltdown security issues even speculative execution has been disabled).

EDIT: (a little bit of digressing)
On the other hand there are times when offline editing is necessary and thus a DAW is called for.
When I used to use my 1st Gen. Oppo HA-2 I did know from their support that no filter whatsoever or DSP is used in PCM realm.
So, a good example is "The Yellow Brick Road" from "Down The Way" by Angus and Julia Stone, a 44/16.
1)My DAW shows it has Sample Peak Level at -0.07dB both channels, but True Peak Level is +2,70dB.
2)So I've to take the two readings aligned, which means in this case oversampling by an 8x factor to 352.8K and place a proper FIR filter shape to avoid a bunch of other problems like aliasing, ringing etc. Now I'm into the 32bit Float. precision realm.
3)Then I'll have to deal with Clipping with the De-Clip module, to re-construct the original waveform (which was heavily compressed in first place).
4)The TPL and Sample PL (now aligned) will raise to +3.5dB. Thus I've to apply a -4dB Gain.
Now I've to save: anything than 32Bit will call for dithering.

Just an example to show when a DAW can actually be handy. But all of this couldn't be done with that granularity on the fly by the best media player on earth.

[RD James]

We discovered together that the CRC are different and that the 32bit padded sample can be brought back to 16bit without any digital difference. And that it was expected on my side. But you're saying I'm hearing a "placebo" difference: so, different CRC and placebo difference heard?

The CRC of the file/container is different, because it has been padded.
The CRC of the audio is the same.

If it were altering the audio, the source file and the 16-bit file after conversion to/from 32-bit would not match.
If I encode a WAV file to FLAC I get a different file CRC too, but the audio CRC is the same.

James, what if Mojo actually takes the 32bit Int and does NOT change it back to 16bit? Question asked to Rob.

Devices don't play zeros.
It's not going to make any difference.

Let's say you are examining a PCM to find the True Peak Level. Usually SW just go 4x (that's actually the CPU limit for realtime) and call it a day. Some others will go above (offline) and some others notably above thus scoring the most faithful mapping of original analog sound available with CPU equipment. This does NOT mean that they will output to that oversampling factor. But means that they'll have mapped the PCM reasonably closer to the original analog source (with CPU equipment).

4x is all that's required to get a good result from analysis, and allows you to process files many times faster than real-time.
Real-time would be extremely slow for analyzing an audio library.
 
I set up a test and was able to analyze three hours of tracks in under four seconds from an SSD - roughly 2700x speed.
Media Center only uses 8 of the 16 cores my CPU has available, and my tests with other software shows that it would be about 70% faster if it used all of them (4600x).
Even if I run the analysis single-threaded, it's done in 25 seconds - over 400x speed.
 
4x is far from the limit of real-time playback for computers.
For one thing, Media Center itself offers up to 8xDSD upsampling, which is 22.6 MHz - though few DACs, and not all CPUs can handle it.

Mojo and bigger brothers do that in realtime @104Mhz and arguing that the best possible reconstruction in digital form of original analog domain before feeding the DAC's own analog section is useless and overkill because there is no input or output for the oversampling frequency been used is something any serious Audio Engineer would disagree.
Even more: the rationale behind that multiplying factor is at the core of DSD rationale: as close as possible to analog.

Any "serious audio engineer" would know that you don't need oversampling anything like that to get a clean analog output from a DAC.
Oversampling like that is one of those things I was talking about where there's a kernel of truth (higher oversampling rate = digital representation of the waveform being closer to the analog waveform) that these companies can use to claim that their product is the best, but which makes no practical difference when you can get the same analog output from a DAC operating at a much lower internal sample rate.
 
I recommend that you set aside 25 minutes to watch this presentation, as it does a good job of explaining the basics of digital sampling with excellent demonstrations: https://www.youtube.com/watch?v=cIQ9IXSUzuM

[daberti]

The CRC of the file/container is different, because it has been padded.
The CRC of the audio is the same.

If it were altering the audio, the source file and the 16-bit file after conversion to/from 32-bit would not match.
If I encode a WAV file to FLAC I get a different file CRC too, but the audio CRC is the same.
Devices don't play zeros.
It's not going to make any difference.
4x is all that's required to get a good result from analysis, and allows you to process files many times faster than real-time.
Real-time would be extremely slow for analyzing an audio library.
 
I set up a test and was able to analyze three hours of tracks in under four seconds from an SSD - roughly 2700x speed.
Media Center only uses 8 of the 16 cores my CPU has available, and my tests with other software shows that it would be about 70% faster if it used all of them (4600x).
Even if I run the analysis single-threaded, it's done in 25 seconds - over 400x speed.
 
4x is far from the limit of real-time playback for computers.
For one thing, Media Center itself offers up to 8xDSD upsampling, which is 22.6 MHz - though few DACs, and not all CPUs can handle it.
Any "serious audio engineer" would know that you don't need oversampling anything like that to get a clean analog output from a DAC.
Oversampling like that is one of those things I was talking about where there's a kernel of truth (higher oversampling rate = digital representation of the waveform being closer to the analog waveform) that these companies can use to claim that their product is the best, but which makes no practical difference when you can get the same analog output from a DAC operating at a much lower internal sample rate.
 
I recommend that you set aside 25 minutes to watch this presentation, as it does a good job of explaining the basics of digital sampling with excellent demonstrations: https://www.youtube.com/watch?v=cIQ9IXSUzuM

James you definitely don't need to argue any longer: 16bit (i.e.) audio is padded to 32bit. Different CRCs. Different stream.
Or, even better: padding to 32bit IS a DSP, in the way it does NOT allow the original i.e. 16bit  signal to reach unpadded thus with the same amount of data the DAC.

It can or cannot be converted back to the original 16bit (not important to this extent), but this is NOT bitperfect and introduces a 2x factor in stream size. So, if MC's own stringent compliancy with PCM bitperfect definition is a stream double the size of the original one just to deliver something to be stripped by DAC to reconstruct the original 16bit content...then I'll pad myself in advance so that I'll be in full control.
So should I output the double the original size (for a 16bit) to get the same musical content? And this to address possible mode switching problems that my DAC never experienced even with my own limited CPU limited RAM iPhone on the other side?

Until such time Rob will say something peculiar to Chord DACs in relation with padding, I'll just use MC without any volume control as already said.

I hope MC developers will enable us to choose among going the 32bit padding way or just keeping the original stream size (just to be clearer).
If not, I've alternatives at the ready for the PC environment and a single iPhone app already allows to try both worlds.

I welcome your recommendation and thanks for the link. Pretty buried under many projects right now and reading Mark Waldrep eight hundred pages book in spare time.

For other topics it is better to write directly your comments to Rob. He's quite responsive.

Thanks
Dan

[JimH]

I'm going to close this now.  Thanks for the discussion.