MQA on all iFi devices. AND on ANDROID!

[listas_fede]

Just now, AMR/iFi audio said:

Folks, just a quick update. In the not too distant future we'll have something MQA&measurements related. Stay tuned!

 OHHH! Pretty interesting! Specially for those (like myself) who still are on the fence between FW versions.

[firedog]

Are the non MQA firmware versions like 5,2 going to continue to be developed? Or will those that don’t want MQA or would rather have DSD 512 going to be felt behind in firmware terms?

[AMR/iFi audio]

10 hours ago, firedog said:

Are the non MQA firmware versions like 5,2 going to continue to be developed? Or will those that don’t want MQA or would rather have DSD 512 going to be felt behind in firmware terms?

 

If you look at the history of iFi firmware updates, because we do this in-house, we have always and will continue to provide customers with different versions to suit. We expect to eventually release 5.3A and 5.3B to mirror the previous 5.XX releases. These are being actively developed.  But the 'if' and 'when' an unknowns at this stage.

[bmoura]

15 hours ago, firedog said:

Are the non MQA firmware versions like 5,2 going to continue to be developed? Or will those that don’t want MQA or would rather have DSD 512 going to be felt behind in firmware terms?

 

I was wondering the same thing.  Would love to continue with the DSD 512 upgrades w/out any MQA.

 

[Fridolin]

I've just updated my nano iDSD LE to the 5.30 Firmware.

Tidal recognizes the new MQA device and plays through the nano iDSD LE after having done the correct settings.

 

All is fine so far, but streams that are originally in 24/192 from Tidal (verified with Audirvana), only play with 24/96 on the nano iDSD LE. This can be observed in the Audio-MIDI Setup window on the Mac as in Audirvana where the DAC-display turns to 24/96 as soon as a title is started. 

 

Is this the intended behavior for Tidal MQA?

[AMR/iFi audio]

On 2.04.2018 at 8:35 PM, mansr said:

As mud. The only rational explanation I can think of is that a firmware including both DSD512 and MQA support wouldn't fit in the XMOS flash memory. If that is the case, why not just say so?

 

Sorry, not the XMOS flash memory, which is copious. Please allow us to offer a brief technical explanation. While in many ways visionary (multi-threaded software with hardware-like guaranteed response times), the XMOS architecture like everything in life, is finite. And in this case, specifically available resources and MIPS are limited. The actual reason is that to implement MQA, digital processing is implemented as well and this consumes resources during runtime even in bypass mode (read: no MQA stream playing). While we would love so to speak, to feed 5,000 with two fish and five loafs of bread and have 12 baskets of leftovers (*), the joint software teams managed with the possible rather than the improbable . This is why we have offered our customers a choice MQA (v5.30) or non-MQA (v5.20).

 

(*) Mark 6:31-44

[mansr]

8 minutes ago, AMR/iFi audio said:

The actual reason is that to implement MQA, digital processing is implemented as well and this consumes resources during runtime even in bypass mode (read: no MQA stream playing).

Would it not be possible to disable all MQA related processing at the highest rates?

[crenca]

17 minutes ago, mansr said:

Would it not be possible to disable all MQA related processing at the highest rates?

 

Perhaps not. Is this evidence that MQA is processing your PCM and DSD no matter what you do? Does the architecture of MQA require the DAC manufacturer to allow in MQA to be doing something, essentially on all the time?

[mansr]

29 minutes ago, crenca said:

Perhaps not. Is this evidence that MQA is processing your PCM and DSD no matter what you do? Does the architecture of MQA require the DAC manufacturer to allow in MQA to be doing something, essentially on all the time?

There is no technical reason for such a requirement.

[AMR/iFi audio]

Measuring time!

MQA vs non-MQA streams – how iFi does it

 

This official iFi audio tech release is here to explain one thing and one thing only:

MQA and non-MQA streams are very much alike!

 

We’re here to show that firmware 5.3 does not change behavior of a DAC with non-MQA signals.

And we like our non-MQA signals unchanged.

The marketing department requested measurements to illustrate that for non-MQA signals there is no audible difference in audio signals output between firmware versions 5.20 and 5.30. Currently there is no agreed standard measurement that has been correlated with audible differences. Hence we elected to perform a set of basic tests as described below.

 

We feel our work below illustrates that electrically the test signals used are handled identically by both firmware versions; 5.20 and 5.30. As we also have access to internal firmware test versions that implement upsampling for all sample rates, though not actually using an MQA filter but our own proprietary experimental filter, we elected to show what the result WOULD BE, if (as has been queried) MQA processing was applied to all audio signals.

 

Methodology:

1. We selected a random micro iDSD Black Label from the units available in R&D.
2. The unit was set to Eco Mode, Positive Polarity and direct output.
3. The unit’s RCA outputs were connected to our Audio Precision System 2 model 2322.
4. Rigol DS2302A 300MHz oscilloscope was connected to the System 2’s monitoring outputs to capture a precise waveform reading to digital files.
5. The USB input was connected to the PC hosting the System 2.
6. The iFi Driver Version 2.26 was used, in order to support the System 2 this PC operates Windows XP SP3.
7. Wavegene V1.5 by efu was used as digital signal generator, using ASIO sound subsystem.
8. White noise at 44.1kHz sample rate and 24Bit word length was used as test signals. This clearly illustrates the actual shapes of the digital filters. This method was popularised by John Atkinson of Stereophile and originates with Jürgen Reis of MBL, in which the device under test decodes 44.1kHz data representing white noise. Additionally, an FFT of a -3dB 1kHz sinewave was performed. For contrast and to minimize time spent testing only standard and Bitperfect digital filters were tested.
9. All settings in System 2 were unchanged, the only change was which version firmware was flashed onto the micro iDSD Black Label.

Below we present each set of graphs side by side, version 5.2 (left screen) and version 5.3 (right screen).

 

• BitPerfect

    

•   Filter response: Standard vs Bitperfect

       

• Standard

 

No measurements for MQA streams are presented as we have no MQA encoded test signals available to us.

It can be observed that the audio output for non-MQA signals is identical between 5.20 and 5.30 firmware within the limits of the test setup. We conclude that there is no measurable difference between the ways audio signals are handled in case of both versions. There are no differences in levels, noise-floor, distortion or digital filter responses.

 

 

Separately we present the “What if the experimental firmware is applied?!?” scenario, in which oversampling to 352.8/384kHz is performed and an experimental set of digital filter coefficients is used.

It is clearly observable that the filter response using white noise is dramatically different from any of those presented for 5.20 & 5.30. Other than the precise waveform and filter response differing if MQA processing is engaged, these results parallel those expected if MQA processing was engaged for non-MQA streams.

 

Summary

1. No measurable difference between the ways audio signals are handled in case of both version firmware v5.20 and v5.30.
2. There are no differences in levels, noise-floor, distortion or digital filter responses.

We hope you do not mind this ‘super dry’ technical measurement note as we have been short-staffed over Easter and we have been responding to a small rise in customer enquiries.

 

[rickca]

4 hours ago, AMR/iFi audio said:

The actual reason is that to implement MQA, digital processing is implemented as well and this consumes resources during runtime even in bypass mode (read: no MQA stream playing).

What is the nature of this required digital processing?  It's hard to imagine that it is so resource intensive that you had to drop DSD512.

[Norton]

17 hours ago, Fridolin said:

Is this the intended behavior for Tidal MQA

 

I'm not familiar with your setup, but this sounds right to me.

 

If it's MQA 192, the initial decode on your Mac will only be to 96 ( which is what your Audio Midi is telling you)  the remaining "unfold" to 192 happens in the DAC.

I imagine that Audirvana is simply telling  you that it's tagged as a MQA 192 album, not that your Mac is outputting a 192 signal.

 

I use XXHE on a PC and see the same information.

[Norton]

8 hours ago, AMR/iFi audio said:

The marketing department requested measurements to illustrate that for non-MQA signals there is no audible difference in audio signals output between firmware versions 5.20 and 5.3

 

It's good that you are providing the option of MQA, but as a potential customer, I'd feel more reassured if the engineering department had deemed measurements necessary, prior to release.

 

[AMR/iFi audio]

13 hours ago, rickca said:

What is the nature of this required digital processing?  It's hard to imagine that it is so resource intensive that you had to drop DSD512.

 

We explained before that v5.30 is almost a complete re-write of the firmware (compared to v5.20). As such, this was not a trivial task - resource allocation, core loading etc.

 

If it was, then most audio companies would do the same as us and write their own customised XMOS code for their own machines.

[rickca]

37 minutes ago, AMR/iFi audio said:

We explained before that v5.30 is almost a complete re-write of the firmware (compared to v5.20). As such, this was not a trivial task - resource allocation, core loading etc.

That doesn't answer my question.  

[Fridolin]

9 hours ago, Norton said:

 

I'm not familiar with your setup, but this sounds right to me.

 

If it's MQA 192, the initial decode on your Mac will only be to 96 ( which is what your Audio Midi is telling you)  the remaining "unfold" to 192 happens in the DAC.

I imagine that Audirvana is simply telling  you that it's tagged as a MQA 192 album, not that your Mac is outputting a 192 signal.

 

I use XXHE on a PC and see the same information.

 

Thanks for your clarification.

So i would need a real MQA-DAC to get 24/192? I thought the iFi would do it for me with the 5.30 update.

[crenca]

1 hour ago, rickca said:

That doesn't answer my question.  

 

I think it probably does answer your and mine and @mansr question, in that the new code by accommodating new functionality (MQA), no longer has the ability to do DSD512.  Perhaps it is not MQA directly - only the new code was not optimized to the same extant...different goals, maybe even different coders, etc.

[crenca]

9 hours ago, Norton said:

 

It's good that you are providing the option of MQA, but as a potential customer, I'd feel more reassured if the engineering department had deemed measurements necessary, prior to release.

 

 

Norton, you flatter us with your common sense objectivist outlook 

[firedog]

18 minutes ago, Fridolin said:

 

Thanks for your clarification.

So i would need a real MQA-DAC to get 24/192? I thought the iFi would do it for me with the 5.30 update.

My understanding is that it should. Audirvana should do the first unold to 2X rates, and the iFi, as an MQA renderer, should do the second unfold to 4X rates and application of MQA filtering.

[mansr]

7 minutes ago, crenca said:

I think it probably does answer your and mine and @mansr question,

Nope.

 

7 minutes ago, crenca said:

in that the new code by accommodating new functionality (MQA), no longer has the ability to do DSD512.

Yes, that's the result. Some of would like to know why.

 

7 minutes ago, crenca said:

Perhaps it is not MQA directly - only the new code was not optimized to the same extant...different goals, maybe even different coders, etc.

We've been told that the problem is that the MQA code, for reasons unknown, insists on always doing some unspecified processing, even with non-MQA input, and this processing cannot be disabled, ever. If it could be disabled, then doing so for high-rate inputs (which can't be MQA anyway) would solve the lack of processing resources.

[crenca]

6 minutes ago, mansr said:

 

We've been told that the problem is that the MQA code, for reasons unknown, insists on always doing some unspecified processing, even with non-MQA input, and this processing cannot be disabled, ever. If it could be disabled, then doing so for high-rate inputs (which can't be MQA anyway) would solve the lack of processing resources.

 

I wonder if that is not a "layman's" explanation, as it were.  In other words MQA is just fat code and working it in is inelegant, and iFi only had limited man hours, etc.

 

IF it is really truly always processing, then we are back to the important question as to what, exactly, is it doing and why, and what it means for our PCM/DSD.

[jhwalker]

51 minutes ago, Fridolin said:

 

Thanks for your clarification.

So i would need a real MQA-DAC to get 24/192? I thought the iFi would do it for me with the 5.30 update.

 

With a "real" MQA DAC, you would disable the first "unfold" in software and your MIDI program would actually show only 24/48 (or 24/44).  The first unfold + any subsequent upsampling ALL happens in the DAC in that situation.

[Norton]

1 hour ago, Fridolin said:

 

Thanks for your clarification.

So i would need a real MQA-DAC to get 24/192? I thought the iFi would do it for me with the 5.30 update.

 

No I'm guessing you are fine with the iFi.  Audirvana should be doing the first "unfold" to 96KHz (which is what your midi setting is telling you) then your DAC is doing a second "unfold" to 192kHz.  Your Audio Midi doesn't  tell you this because it doesn't know what happens subsequently in the DAC.

 

 

[rickca]

27 minutes ago, mansr said:

We've been told that the problem is that the MQA code, for reasons unknown, insists on always doing some unspecified processing, even with non-MQA input, and this processing cannot be disabled, ever. If it could be disabled, then doing so for high-rate inputs (which can't be MQA anyway) would solve the lack of processing resources.

This is what I suspect is the issue:

https://www.computeraudiophile.com/forums/topic/30381-mqa-is-vaporware/?do=findComment&comment=767945

 

[Norton]

1 hour ago, crenca said:

Norton, you flatter us with your common sense objectivist outlook

 

I may not meet the definition of an objectivist, but in part that's because I take it as read that the manufacturers I buy stuff from will have engineered and measured the hell out of it before bringing it  to market.