AudioQuest adds MQA Support to Dragonflies via firmware

[crenca]

2 hours ago, Wavelength said:

Plissken,

 

No the metadata is not sent over USB in a wrapper. It's also not decompression, what ever that means.

 

Applications can send MQA material to any DAC for playback. The output just will not benefit from the MQA decoding if the DAC and application is not MQA enabled.

 

Thanks,

Gordon

 

 

 

Keep yelling at your customers...let me know how that works out for ya.

[plissken]

Hear is my next question:

 

When I have 10MByte / second connection what is my upside for streaming MQA vs 24/192? Or even DSD for that matter? 

 

And if the 'Cell Data' angle is going to be provided... I'm listening on a freaking cell phone for pete's sake. 

 

This whole 'origami', 'unfolding', etc... etc... is simply marketers. 

 

MQA doesn't solve a problem and it certainly isn't going to transcode and fix poor PCM or Tape Masters. 

[crenca]

11 minutes ago, plissken said:

Hear is my next question:

 

When I have 10MByte / second connection what is my upside for streaming MQA vs 24/192? Or even DSD for that matter? 

 

And if the 'Cell Data' angle is going to be provided... I'm listening on a freaking cell phone for pete's sake. 

 

This whole 'origami', 'unfolding', etc... etc... is simply marketers. 

 

MQA doesn't solve a problem and it certainly isn't going to transcode and fix poor PCM or Tape Masters. 

 

How can AudioQuest/Gordon answer this or any other question about MQA with substance?  All they can do (because of the very nature of MQA as a legal and IP entity) is claim you don't know what you are talking about, that your "speculation" (though it is often much more than that) is "misinformation" (though it is often the very truth of the matter) and answer you with complete and total marketing speak/non-information.

 

With MQA, it's just as Gordon says and just shut up and listen...don't worry, he and Bob have it ALL under control.  

 

Like he says, it is "stupid questions" that is the biggest problem in computer audio

 

 

 

[DarwinOSX]

3 minutes ago, crenca said:

 

How can AudioQuest/Gordon answer this or any other question about MQA with substance?  All they can do (because of the very nature of MQA as a legal and IP entity) is claim you don't know what you are talking about, that your "speculation" (though it is often much more than that) is "misinformation" (though it is often the very truth of the matter) and answer you with complete and total marketing speak/non-information.

 

With MQA, it's just as Gordon says and just shut up and listen...don't worry, he and Bob have it ALL under control.  

 

Like he says, it is "stupid questions" that is the biggest problem in computer audio

 

 

 

 

You are not helping.

[crenca]

Just now, DarwinOSX said:

 

You are not helping.

 

And you are?  Tell me, what ARE the answers to the substantial questions raised by several here?

 

Are you saying Gordon has in any way actually answered those questions - if so, how did you confirm this?  Have you signed the (apparently several) NDA's MQA requires and if so, are you part of the "just shut up and listen/trust us" now?

[Rt66indierock]

3 hours ago, Wavelength said:

 

If you choose pass through then the MQA is basically not enabled.

 

Why do people think this is all about upsampling and decompression.

 

Guys if the files were compressed and require decompressing in a certain format then how do NON-MQA DACS playback MQA files?

 

Look it's much more than what everyone is speculating about. This is probably part of the problem with companies who think MQA is a bad thing. Maybe not, they might be a lot smarter than I am. But as a musician for some 50 or more years, I can tell you this is the real deal. Lowering the noise floor is a real undertaking.

 

Anyway, before you pass judgement you should listen.

 

Thanks,

Gordon

 

 

Gordon,

 

I’d love to listen with your DAC and MQA firmware but there is no music to buy in the United States for 80 to 90 percent of the music buying public. So when do you think I’ll be able to buy some classic rock and country music? I would like to evaluate MQA the same way I evaluate any audio piece of equipment but I’ve given up that all nine of my reference albums will ever be available to download in MQA.

 

As of last night there are less than 2,800 albums you can listen to on TIDAL so why bother with the format? After people have been pushing hi-res albums for years and we have less than 16,000 albums out in the world. Maybe it’s time to actually face up to high resolution audio will never be mainstream product.

 

Take care it was nice meeting you at RMAF 2016.

[ShawnC]

Crenca, grow up!

[MarkS]

21 minutes ago, Rt66indierock said:

As of last night there are less than 2,800 albums you can listen to on TIDAL so why bother with the format?

 

At the risk of being unhelpful, I think some would answer your question by saying that MQA sounds better and more MQA titles will come.

[MarkS]

Oh, and on all the DF stuff, I hope that iOS apps (like the Tidal app) will soon be able to do on an iOS device what the DF needs to get the best out of the DF.  That will be cool.  If that is already happening, could someone let me know.  I don't think iOS is yet at that stage.

[Rt66indierock]

40 minutes ago, MarkS said:

 

At the risk of being unhelpful, I think some would answer your question by saying that MQA sounds better and more MQA titles will come.

 

There are 46 million plus tracks on TIDAL. MQA will be failure at a lot larger number than you would like. Some people say it sounds better, Jud says it doesn't. I'll listen when that is possible and make up my own mind.

[revand]

9 hours ago, Wavelength said:

Gang,

 

A couple of things to understand with the DragonFly and the new 1.06 version of firmware.

 

As always the sample rates are the same:

Green = 44.1

Blue = 48

Yellow = 88.2

Magenta = 96.

 

When an MQA file is played back with a player that supports the DragonFly MQA the LED will go to Purple. The problem of course is that this color is very close to Magenta. It is a little easier to tell on DragonFly BLACK, but on RED it is much harder to tell. We did not have a choice in the color, that was MQA decision.

 

DragonFly only supports sample rates over USB up to 96K, therefore DragonFly does not do the full unfold. Therefore applications such as Tidal and Audirvana are currently the only applications that support MQA and DragonFly. Expect Amara to introduce products next month and expanded Audirvana soon.

 

The passthrough in Tidal will just send the MQA file as is to the DragonFly. You must have Exclusive mode checked for MQA to work with Tidal and DragonFly.

 

DragonFly 1.0, 1.1 and 1.2 do not have MQA capabilities, sorry.

 

I am not sure where content is available right now. I think 2L might have some stuff. You may want to check on MQA's website for content providers.

 

If you have specific questions I can try and explain them.

 

I have been using MQA for several months now in testing. The MQA files on Tidal are great. I have to thank everyone at MQA for making this happen. It has also been a pleasure working with Tidal the last couple of months.

 

All of you should give Audirvana 3.0 a try as well.

 

Thanks,

Gordon

 

First of all many thanks Gordon for creating the Dragonflys. I have the Red and I am enjoying this little wonder since I bought it last summer. Great sound quality from such a small device.

Being an MQA fan I was eagerly waiting the firmware update. I did it yesterday, but at the first moment there was a confusion. I checked both exclusive mode and Passthrough MQA and could see only blue and green colours, not any amber. Today morning I unchecked Passthrough MQA since I realized that this option is good only for those devices full decode MQA, which the Red does not do. Amber colour (frankly speaking it looks like magenta) appeared immediately.

Am I right that in the TIDAL desktop app settings at streaming at Audioquest Dragonfly Red the only option to be cheked is Use Exclusive Mode to reach the highest quality available with the Dragonfly Red?

Many thanks

Andras 

My thoughts on MQA can be found here: The digital music revolution

 

[citsur86]

5 hours ago, revand said:

 

First of all many thanks Gordon for creating the Dragonflys. I have the Red and I am enjoying this little wonder since I bought it last summer. Great sound quality from such a small device.

Being an MQA fan I was eagerly waiting the firmware update. I did it yesterday, but at the first moment there was a confusion. I checked both exclusive mode and Passthrough MQA and could see only blue and green colours, not any amber. Today morning I unchecked Passthrough MQA since I realized that this option is good only for those devices full decode MQA, which the Red does not do. Amber colour (frankly speaking it looks like magenta) appeared immediately.

Am I right that in the TIDAL desktop app settings at streaming at Audioquest Dragonfly Red the only option to be cheked is Use Exclusive Mode to reach the highest quality available with the Dragonfly Red?

Many thanks

Andras 

My thoughts on MQA can be found here: The digital music revolution

 

 

I just did the same this morning.  The desktop Tidal App is actually doing the first unfold, or the Core Decoding.After that, the Dragonfly is unpacking once more.  So the MQA masters I am listening to all show in Magenta coloring and display as 96,000Hz in my Mac's Audio MIDI Setup.  When I have Passthrough MQA, I get 44,100Hz.  So it seems something is going wrong somewhere.  I was expecting with the MQA update for the Dragonfly Red, that I would be getting 192,000Hz for the Tidal Masters.   Anyone able to shed some insight here?

 

 

 

[citsur86]

Ah never mind - I see the Dragonfly Red can only go up to 96,000Hz, though I could have sworn that I read the update would open it up to 192,000Hz for MQA....

 

Anyways I can see the difference between "Purple" and Magenta when I turn the lights off.

 

MQA Purple

 

96,000Hz Manually set for lower bitrate output music.

[ShawnC]

13 minutes ago, citsur86 said:

 

I just did the same this morning.  The desktop Tidal App is actually doing the first unfold, or the Core Decoding.After that, the Dragonfly is unpacking once more.  So the MQA masters I am listening to all show in Magenta coloring and display as 96,000Hz in my Mac's Audio MIDI Setup.  When I have Passthrough MQA, I get 44,100Hz.  So it seems something is going wrong somewhere.  I was expecting with the MQA update for the Dragonfly Red, that I would be getting 192,000Hz for the Tidal Masters.   Anyone able to shed some insight here?

Not all Tidal Masters are 24/192, many if not most would be 24/96.  This is still the problem with TIdal, your not exactly sure what version of a Master your getting.  There could also be 24/14, 24/48 like on HDtracks.

 

Nice screen shots above

[citsur86]

1 minute ago, ShawnC said:

Not all Tidal Masters are 24/192, many if not most would be 24/96.  This is still the problem with TIdal, your not exactly sure what version of a Master your getting.  There could also be 24/14, 24/48 like on HDtracks.

I see!  Do you happen to know of any of Tidal's songs offhand that are 24/192?  I'd like to try some out.  Also, how would I even know if I was listening to 192,000Hz if the Audio MIDI Setup only goes to 96,000Hz?

 

[miguelito]

2 minutes ago, citsur86 said:

I see!  Do you happen to know of any of Tidal's songs offhand that are 24/192?  I'd like to try some out.  Also, how would I even know if I was listening to 192,000Hz if the Audio MIDI Setup only goes to 96,000Hz?

 

Audio midi will not know anything about MQA. It only displays the raw PCM rate to the device - it will never be higher than 96KHz for a Dragonfly (the current ones obviously).

 

Example: https://tidal.com/album/2400318

[miguelito]

11 hours ago, plissken said:

MQA doesn't solve a problem and it certainly isn't going to transcode and fix poor PCM or Tape Masters.

In my view MQA serves a sort of "quality remaster" tag... In the many examples I have heard, I have the impression that most of the improvement in quality comes from careful remastering rather than any technology improvements in MQA itself. I'm totally fine with that.

[ShawnC]

10 minutes ago, citsur86 said:

I see!  Do you happen to know of any of Tidal's songs offhand that are 24/192?  I'd like to try some out.  Also, how would I even know if I was listening to 192,000Hz if the Audio MIDI Setup only goes to 96,000Hz?

 

Unfortunately with the Dragonfly it's hard to figure out what exactly your getting.  It would help if Tidal listed what it was sending you if you could unfold it to it's maximum potential.  I think something like Audirvana shows this and the Mytech Brooklyn DAC does this too.

[Wavelength]

7 hours ago, revand said:

 

Am I right that in the TIDAL desktop app settings at streaming at Audioquest Dragonfly Red the only option to be cheked is Use Exclusive Mode to reach the highest quality available with the Dragonfly Red?

Many thanks

Andras 

My thoughts on MQA can be found here: The digital music revolution

 

 

Correct inside of Tidal your only setting should be exclusive mode.

 

MQA libraries in all the applications that support it have a data base of known MQA devices. They match the interface to each device so that it correct and aligns everything going to that particular DAC.

 

I would check with other companies on the pass through option. But I think you would want this off for any MQA capable DAC. Checking this will basically bypass the MQA content.

 

Thanks,

Gordon

[mansr]

18 hours ago, Wavelength said:

Plissken,

 

Really!!! If you don't know something then why are you confusing people. A song does not carry metadata over USB.

 

 

Sorry no we are not going to do that. There are many more applications coming out with MQA support for DragonFly.

 

mansr,

 

The same, really if you don't know don't say anything. Assumption on how something works is the biggest problem with computer audio. I get more of the stupidest questions asked on emails from stuff read here and on other forums.

 

 

Totally incorrect!

 

 

Also totally incorrect!!!

 

~~~~~~~

 

Look everyone, you can guesstamate all you want about what is or what isn't done here. OR!!! you could sit down and listen and judge for yourself.

 

No more misinformation from people who don't know what's going on here. I have 33 emails in my inbox about people asking questions from users and links to your posts.

 

Be sane, have fun!

Gordon

Wow, such hostility. Everything I've said about the MQA rendering process is true. I learned it by studying the actual code. I obviously don't know exactly how it is implemented on the Dragonfly, but here's what I do know:

• The Dragonfly has a PIC32MX microcontroller based on a MIPS CPU. Anyone can open the case and see this.
• MQA rendering in real time needs 100 MHz of CPU time on a more efficient ARM system.

Based on this, I find it unlikely that the DF microcontroller is actually performing the calculations. The PIC32MX simply doesn't have enough CPU power.

[mansr]

2 hours ago, Wavelength said:

MQA libraries in all the applications that support it have a data base of known MQA devices. They match the interface to each device so that it correct and aligns everything going to that particular DAC.

Correct and align? What is that supposed to mean?

2 hours ago, Wavelength said:

I would check with other companies on the pass through option. But I think you would want this off for any MQA capable DAC. Checking this will basically bypass the MQA content.

Passthrough in Tidal means it sends the MQA-encoded stream as is to the DAC. This is what you want with a DAC that supports full decoding such as the Explorer 2 or Mytek Brooklyn. For a DAC with partial (e.g. Dragonfly) or no MQA support this options should be off in order to enable software decoding.

[Wavelength]

1 hour ago, mansr said:

Wow, such hostility. Everything I've said about the MQA rendering process is true. I learned it by studying the actual code. I obviously don't know exactly how it is implemented on the Dragonfly, but here's what I do know:

• The Dragonfly has a PIC32MX microcontroller based on a MIPS CPU. Anyone can open the case and see this.
• MQA rendering in real time needs 100 MHz of CPU time on a more efficient ARM system.

Based on this, I find it unlikely that the DF microcontroller is actually performing the calculations. The PIC32MX simply doesn't have enough CPU power.

 

mansr,

 

The reason I get frustrated with you is simple. Your making assumptions about products that you either don't have or don't know enough about. This in the end will mislead users and causes false claims.

 

For instance your claim about 100MHz ARM processor is very vague. There are a boat load of different ARM processors and they vary vastly in performance and Audio capabilities. I can think of M series, A series, 9 series processors with some that have great capabilities and others that don't. Some have HS USB, others only FS USB. Some have cable I2S, others have really poor implementations. The poor ones require significantly more MIPS than a 100Mhz version would have and therefore would preform less than any Microchip MX processor would.

 

Take for instance most XMOS single core (what marketing calls 8 core, really 8 threads) that are the basis for a number of products in the industry. Six of those cores are used for USB & I2S, and almost 90% of the MIPS of those processors are used up and therefore are not really good candidates for MQA.

 

In the DragonFly line with the Microchip MX32 processor we wanted to make a product that was really low power that would work with all platforms. Something both the XMOS and ARM processors cannot do. When we started to work with MQA, we talked to the engineers at Microchip and they sent us DSP algorithms written in assembler. The reason being is that these processors have specific DSP functions which standard programming under C/C++ would not have access to. The engineers at MQA took that source code and optimized it for this implementation.

 

MIPS don't equal MIPS when you are talking about processors. You have to look at the entire system as a whole.

 

Heck take an iMX7 ARM processor from NXP/Freescale and compare it to say an iMX6UL. The iMX6UL will beat the pants on the 7 because of the IP it has for Audio. Just like the MX270 from Microchip will beat the pants off the MX795. You can't just make blanket statements about performance and suggest you know what's going on here.

 

That leads to misinformation and everybody that reads your posts will get confused.

 

Thanks,

Gordon

[mansr]

6 minutes ago, Wavelength said:

mansr,

 

The reason I get frustrated with you is simple. Your making assumptions about products that you either don't have or don't know enough about. This in the end will mislead users and causes false claims.

 

For instance your claim about 100MHz ARM processor is very vague. There are a boat load of different ARM processors and they vary vastly in performance and Audio capabilities. I can think of M series, A series, 9 series processors with some that have great capabilities and others that don't. Some have HS USB, others only FS USB. Some have cable I2S, others have really poor implementations. The poor ones require significantly more MIPS than a 100Mhz version would have and therefore would preform less than any Microchip MX processor would.

 

Take for instance most XMOS single core (what marketing calls 8 core, really 8 threads) that are the basis for a number of products in the industry. Six of those cores are used for USB & I2S, and almost 90% of the MIPS of those processors are used up and therefore are not really good candidates for MQA.

 

In the DragonFly line with the Microchip MX32 processor we wanted to make a product that was really low power that would work with all platforms. Something both the XMOS and ARM processors cannot do. When we started to work with MQA, we talked to the engineers at Microchip and they sent us DSP algorithms written in assembler. The reason being is that these processors have specific DSP functions which standard programming under C/C++ would not have access to. The engineers at MQA took that source code and optimized it for this implementation.

 

MIPS don't equal MIPS when you are talking about processors. You have to look at the entire system as a whole.

 

Heck take an iMX7 ARM processor from NXP/Freescale and compare it to say an iMX6UL. The iMX6UL will beat the pants on the 7 because of the IP it has for Audio. Just like the MX270 from Microchip will beat the pants off the MX795. You can't just make blanket statements about performance and suggest you know what's going on here.

 

That leads to misinformation and everybody that reads your posts will get confused.

 

Thanks,

Gordon

I measured the CPU cycles required to run the rendering code on a Cortex-A7 ARM device. It needed about 100 million cycles per second of audio. This CPU is more efficient per cycle than the MIPS M4K core in the PIC32. It also has bigger caches and better memory bandwidth. I read somewhere that the Dragonfly uses a PIC32MX270 which runs at 50 MHz. It would take one hell of an optimisation to run the upsampling algorithm on that and still have time for handling the usual tasks (USB communication etc). Assembly optimisation is something I have a great deal of experience with, for what it's worth.

[crenca]

39 minutes ago, Wavelength said:

 

mansr,

 

The reason I get frustrated with you is simple. Your making assumptions about products that you either don't have or don't know enough about. This in the end will mislead users and causes false claims.

 

For instance your claim about 100MHz ARM processor is very vague. There are a boat load of different ARM processors and they vary vastly in performance and Audio capabilities. I can think of M series, A series, 9 series processors with some that have great capabilities and others that don't. Some have HS USB, others only FS USB. Some have cable I2S, others have really poor implementations. The poor ones require significantly more MIPS than a 100Mhz version would have and therefore would preform less than any Microchip MX processor would.

 

Take for instance most XMOS single core (what marketing calls 8 core, really 8 threads) that are the basis for a number of products in the industry. Six of those cores are used for USB & I2S, and almost 90% of the MIPS of those processors are used up and therefore are not really good candidates for MQA.

 

In the DragonFly line with the Microchip MX32 processor we wanted to make a product that was really low power that would work with all platforms. Something both the XMOS and ARM processors cannot do. When we started to work with MQA, we talked to the engineers at Microchip and they sent us DSP algorithms written in assembler. The reason being is that these processors have specific DSP functions which standard programming under C/C++ would not have access to. The engineers at MQA took that source code and optimized it for this implementation.

 

MIPS don't equal MIPS when you are talking about processors. You have to look at the entire system as a whole.

 

Heck take an iMX7 ARM processor from NXP/Freescale and compare it to say an iMX6UL. The iMX6UL will beat the pants on the 7 because of the IP it has for Audio. Just like the MX270 from Microchip will beat the pants off the MX795. You can't just make blanket statements about performance and suggest you know what's going on here.

 

That leads to misinformation and everybody that reads your posts will get confused.

 

Thanks,

Gordon

 

Hhhmm, all true but what is the relevance to the specific implementation of MQA we are talking about on this thread - the particular Dragonflies produced by AudioQuest? 

 

Sure, "it depends" (within limits) but how does it depend in your implementation (i.e. your "entire system as a whole")?  

 

Besides, your wrong - mansr is both knowledgeable about the chips you are referring to (and are found in your products) and is in no way "misleading" or "making false claims" or sowing "confusion".  I would say if anything, your generalities above lean far more in the direction - certainly in the "confusion" dept.  This appears to be a kind of regular cloud hanging over almost everything about MQA.

 

So get specific - what is it about your specific implementation and the MIPS involved that are relevant to the substantial questions raised in this thread by several (which I won't repeat for brevity's sake)?

[Wavelength]

18 minutes ago, mansr said:

I measured the CPU cycles required to run the rendering code on a Cortex-A7 ARM device. It needed about 100 million cycles per second of audio. This CPU is more efficient per cycle than the MIPS M4K core in the PIC32. It also has bigger caches and better memory bandwidth. I read somewhere that the Dragonfly uses a PIC32MX270 which runs at 50 MHz. It would take one hell of an optimisation to run the upsampling algorithm on that and still have time for handling the usual tasks (USB communication etc). Assembly optimisation is something I have a great deal of experience with, for what it's worth.

 

mansr,

 

So you are admitting you don't have a DragonFly, correct? Then why are you even commenting here?

 

Actually the A7 has the same problems as the A5 does. With the MX DSP functions you can do a multiply and add which is a requirement for filtering in 1T state. On the A5/A7 processor that takes a ton more!

 

Thanks, but no thanks,

Gordon