• WANTED: Happy members who like to discuss audio and other topics related to our interest. Desire to learn and share knowledge of science required as is 20 years of participation in forums (not all true). Come here to have fun, be ready to be teased and not take online life too seriously. We now measure and review equipment for free! Click here for details.

AudioQuest Dragonfly Cobalt Review (Portable Headphone Adapter)

mansr

Major Contributor
Joined
Oct 5, 2018
Messages
3,884
Likes
8,727
Location
Hampshire
What is a clear differentiator for a DFC, and an actual reason I've bought it - it has been designed with power consumption in mind. Instead of using an off the shelf USB Driver IC, the designer went for a customized solution, using a general purpose MCU in order to keep the power consumption low (remember, the newest cut of ESS chips combining USB driver+DAC+HPAmp in one IC was not available at that time).
Target achieved, even in 2021 DFC has a lowest measured power consumption among the non-single-chip dongles that can deliver around 2Vrms. And this is really important if you use it with a smaller iPhone or even an iPod Touch - the battery in those devices is not exactly huge.
The DFC uses more power than the Red or Black. AQ claim it uses less. I measured them, and it's a lie. The Black is also better than the Red and Cobalt at driving loads below about 35 Ω.
 

A-lexx

Member
Joined
May 31, 2021
Messages
13
Likes
7
The DFC uses more power than the Red or Black. AQ claim it uses less. I measured them, and it's a lie. The Black is also better than the Red and Cobalt at driving loads below about 35 Ω.

Yes, I know it uses more power, as I have both and DFR is giving me longer play times. AQ never claimed it uses less. You need to read between marketing lines. AQ claims the MCU they went for uses less power. There is a reason they are talking only about the MCU. Because the new DAC chip is actually using more. So overall, DFC is indeed using more power than DFR. Still less than anything else.

This is the exact wording from Audioquest's page, not changed since Day 1:

"
Microchip's superb PIC32MX274 microprocessor draws less current and increases processing speed by 33%.
"

The reviewers around the world read this in a way that DFC consumes less power, and the myth was born. Many were then disappointed when actual measurements started to pop up showing it's not the case.

And this is a trade-off I bought into, even having a DFR, because what I‘ve got for it was a silent "DFR" with non-audible noise levels. At the time of the release, DFC was an only option combining low-power consumption, very low noise levels, 2Vrms output and compact battery-less design. Now there are more, but now is 2021, not 2019.
 
Last edited:

mansr

Major Contributor
Joined
Oct 5, 2018
Messages
3,884
Likes
8,727
Location
Hampshire
Yes, I know it uses more power, as I have both and DFR is giving me longer play times. AQ never claimed it uses less. You need to read between marketing lines. AQ claims the MCU they went for uses less power.
That's not true either, at least not according to the datasheets. Besides, they clearly intended to give the impression that the Cobalt uses less power than the Red. Why else would they have mentioned it at all?
 

Veri

Master Contributor
Joined
Feb 6, 2018
Messages
8,054
Likes
9,815
That's not true either, at least not according to the datasheets. Besides, they clearly intended to give the impression that the Cobalt uses less power than the Red. Why else would they have mentioned it at all?

You need to read between marketing lines.

:p
 

A-lexx

Member
Joined
May 31, 2021
Messages
13
Likes
7
That's not true either, at least not according to the datasheets. Besides, they clearly intended to give the impression that the Cobalt uses less power than the Red. Why else would they have mentioned it at all?

There are no 'specs' for any of them. Audioqest never publishes any. Just some esoteric mumbo-jumbo. So no specs means no specs can be violated. I don't like that neither. Nowadays even every Chinese company publishes full specs, but Audioquest does not. And I agree, the impression they made with that talk about the MCU (that almost no consumer knows anything about or cares about) is probably intended. But well, that's marketing...

Who in the world does care what the speed of MCU is, if the only thing it's doing is taking USB stream in and sending this into the DAC? Whether it's 33% or 333% faster - who cares as long as it's fast enough? There is no post processing happening, it's not doing any fancy DSP stuff... Just marketing mumbo-jumbo.

Actually I do know why they rave about it as at that time I did some research to find out why the hell they wanted to change the MCU.
Apparently, according to Gordon Rankin, DFC is operating on USB in a High-Speed-Mode, vs. DFR in Full-Speed-Mode.
High-Speed-Mode needs A LOT more power just for the USB, as it allows transfer rates of up to 480 Mbps vs 12 Mbps in Full-Speed-Mode, has shorter latencies, more complicated packet structure and so on.

So, the question is: WHY?
At it's highest rate, DFC can work at 96/24, which means around 4.6 Mbps in terms of a data stream. This is almost 3 times less, than Full-Speed-Mode would allow to transmit. My conclusion is, Audio Quest must be planning to make higher sampling rates available, up to 384 Ksps, which indeed would require High-Speed-Mode. Probably later on with a FW update. But maybe that will never happen, no one knows.

Some years ago, before DFC has been released, people were asking Gordon, whether there will be a FW update for DFR/DFB to make them 384 Ksps-capable. At that time, he replied, don't hold your breath, as the HW is just not capable of processing 384ksps via USB.
Obviously, the new requirement for DFC was, to make this option possible for the future. The new HW definitively can do this, the USB protocol used now on DFC already would allow it, it is just a matter of switching this on. I guess they reserved this option for a later point of time in the life cycle of DFC...
 
Last edited:

mansr

Major Contributor
Joined
Oct 5, 2018
Messages
3,884
Likes
8,727
Location
Hampshire
You need to read between marketing lines lies.
FTFY

In my opinion, manufacturers' claims should be judged against the impression they intend to convey, even if the literal meaning of the words is technically true.
 
Last edited:

Raindog123

Major Contributor
Forum Donor
Joined
Oct 23, 2020
Messages
1,209
Likes
2,404
Location
Melbourne, FL, USA
AQ never claimed it uses less. You need to read between marketing lines. AQ claims the MCU they went for uses less power.

Why else would one use a statement like this on their product-description page?! You and I can read 'between those lines', the 99% of consumers can't. And this is simply sad.

[EDIT: Continuing reading through, saw @mansr has made this point already... Leaving it anyway, as reinforcement :) ]
 

A-lexx

Member
Joined
May 31, 2021
Messages
13
Likes
7
Why else would one use a statement like this on their product-description page?! You and I can read 'between those lines', the 99% of consumers can't. And this is simply sad.

[EDIT: Continuing reading through, saw @mansr has made this point already... Leaving it anyway, as reinforcement :) ]

Why? Well, because the marketing department was tasked with saying something positive about it, and they didn´t know what to say, so they used the specs Of the MCU.
You know, that new MCU is actually a big thing. They (Audioquest) paid Gordon Rankin lots of money because of that. Since Gordon had to use a different MCU and implemented a different USB protocol, that was lots of work, a complete re-programming, no code parts from the old MCU could be reused. Here, the SW was actually much more work than the HW.
And, at the end of the day, they cannot even sell it as a feature, because someone in the company has decided not to enable 384Ksps capabilities? So, instead of selling 384Ksps, they had to sell at least something, even though it doesn‘t matter at all…
 

mansr

Major Contributor
Joined
Oct 5, 2018
Messages
3,884
Likes
8,727
Location
Hampshire
Actually I do know why they rave about it as at that time I did some research to find out why the hell they wanted to change the MCU.
Apparently, according to Gordon Rankin, DFC is operating on USB in a High-Speed-Mode, vs. DFR in Full-Speed-Mode.
High-Speed-Mode needs A LOT more power just for the USB, as it allows transfer rates of up to 480 Mbps vs 12 Mbps in Full-Speed-Mode, has shorter latencies, more complicated packet structure and so on.

So, the question is: WHY?
At it's highest rate, DFC can work at 96/24, which means around 4.6 Mbps in terms of a data stream. This is almost 3 times less, than Full-Speed-Mode would allow to transmit. My conclusion is, Audio Quest must be planning to make higher sampling rates available, up to 384 Ksps, which indeed would require High-Speed-Mode. Probably later on with a FW update. But maybe that will never happen, no one knows.

Some years ago, before DFC has been released, people were asking Gordon, whether there will be a FW update for DFR/DFB to make them 384 Ksps-capable. At that time, he replied, don't hold your breath, as the HW is just not capable of processing 384ksps via USB.
Obviously, the new requirement for DFC was, to make this option possible for the future. The new HW definitively can do this, the USB protocol used now on DFC already would allow it, it is just a matter of switching this on. I guess they reserved this option for a later point of time in the life cycle of DFC...
You know, that new MCU is actually a big thing. They (Audioquest) paid Gordon Rankin lots of money because of that. Since Gordon had to use a different MCU and implemented a different USB protocol, that was lots of work, a complete re-programming, no code parts from the old MCU could be reused. Here, the SW was actually much more work than the HW.
Where are you getting that so-called information? The microcontroller used, PIC32MX274F256B, doesn't support high-speed USB. The chip is a minor performance upgrade over the PIC32MX270F256B used in the Black. The two variants are almost entirely software compatible.
 

Raindog123

Major Contributor
Forum Donor
Joined
Oct 23, 2020
Messages
1,209
Likes
2,404
Location
Melbourne, FL, USA
@A-lexx I've read and re-read all your points. And thought about every one of them. All I am asking in return is you re-reading mine (and mansr's), and think about them a bit too...

After that, I am fine with whatever opinion you and I still have left with. I am not here to argue, or to change you. DIXI
 

A-lexx

Member
Joined
May 31, 2021
Messages
13
Likes
7
Where are you getting that so-called information? The microcontroller used, PIC32MX274F256B, doesn't support high-speed USB. The chip is a minor performance upgrade over the PIC32MX270F256B used in the Black. The two variants are almost entirely software compatible.
There was a long article with an interview with Gordon Rankin, multiple pages long, published in 2019, where he described in details his struggles with the implementation, how he was tasked with implementing high-speed USB, was trying and failed in doing this with an original MCU because of the performance, almost gave up on this, then in the process Microchip released a new PIC32 version that was faster and just fast enough for him to squeeze the protocol in.
I was actually trying to find this interview, but it seems it has been already taken offline because it discussed some touchy details… If I find it, I will for sure add a link to it. Trust me I‘m not making this up, that wouldn‘t make any sense…
 

A-lexx

Member
Joined
May 31, 2021
Messages
13
Likes
7
@A-lexx I've read and re-read all your points. And thought about every one of them. All I am asking in return is you re-reading mine (and mansr's), and think about them a bit too...

After that, I am fine with whatever opinion you and I still have left with. I am not here to argue, or to change you. DIXI

I actually share your opinion. I‘m just playing a devil‘s advocate here. I‘m not saying it is ok what they are doing, I don´t like it neither and find it not a good way of doing business. I was just answering to the portion of ‚why‘ they did it, because it‘s how marketing works, from my experience… I know my writing is sometimes difficult to understand, as English is my 4th language. I tend to think in long sentences, and when writing the things down with all the mistakes I make, sometimes the idea of what I‘m trying to say is not exactly coming through a way I intended ;-)
 

mansr

Major Contributor
Joined
Oct 5, 2018
Messages
3,884
Likes
8,727
Location
Hampshire
There was a long article with an interview with Gordon Rankin, multiple pages long, published in 2019, where he described in details his struggles with the implementation, how he was tasked with implementing high-speed USB, was trying and failed in doing this with an original MCU because of the performance, almost gave up on this, then in the process Microchip released a new PIC32 version that was faster and just fast enough for him to squeeze the protocol in.
I was actually trying to find this interview, but it seems it has been already taken offline because it discussed some touchy details… If I find it, I will for sure add a link to it. Trust me I‘m not making this up, that wouldn‘t make any sense…
None of the PIC32 chips can do high-speed USB, lacking the necessary hardware blocks. I can see how trying to make it work anyway would be a struggle.
 

A-lexx

Member
Joined
May 31, 2021
Messages
13
Likes
7
None of the PIC32 chips can do high-speed USB, lacking the necessary hardware blocks. I can see how trying to make it work anyway would be a struggle.

He wasn‘t using the embedded USB controller. He actually programmed the protocol, using general purpose IOs.
That was a point of using the MCU vs. an already available simple USB driver. Now you are starting getting personal for no reasons. I said I will try to find that interview. Using custom USB implementation was Gordon Rankin‘s „stick“ starting with DFB/DFR
 

mansr

Major Contributor
Joined
Oct 5, 2018
Messages
3,884
Likes
8,727
Location
Hampshire
He wasn‘t using the embedded USB controller. He actually programmed the protocol, using general purpose IOs.
Nonsense. That can't be done for a multitude of reasons. Besides, anyone can see that the USB connector is wired to the D+/D- pins of the chip:
index.php


Pin assignment from the datasheet:
1622648528308.png


Now you are starting getting personal for no reasons.
Sorry, I didn't mean to have a go at you.
 

threni

Addicted to Fun and Learning
Joined
Oct 18, 2019
Messages
695
Likes
787
Location
/dev/null
This is a very strong statement and especially in this forum requires elaboration and evidence.

It's a weird look telling this site's owner what's required on his own site!

It doesn't take much to see What Hi-Fi for what it is.
 

A-lexx

Member
Joined
May 31, 2021
Messages
13
Likes
7
Nonsense. That can't be done for a multitude of reasons. Besides, anyone can see that the USB connector is wired to the D+/D- pins of the chip:
index.php


Pin assignment from the datasheet:
View attachment 133412


Sorry, I didn't mean to have a go at you.

indeed, clearly routed directly to USB. In a meanwhile, between burning some burgers on a grill an a couple beers I found a copy, or a part of that interview, on John Darko‘s page (I remember however reading a longer version somewhere else).

https://darko.audio/2019/07/a-short-film-about-the-audioquest-dragonfly-cobalt/

I need to correct myself, at the end we were both wrong, I made a bigger mistake though: there is indeed a high-speed USB version of PIC32, that‘s the MZ, but they didn‘t go with it, it didn‘t work out, they ditched the project. Instead, they went for a new cut of MX, that is full-speed only. I misread that one sentence, I thought they found a new version that was high-speed at the end.
 
Last edited:

Brab

Member
Joined
Jun 2, 2020
Messages
90
Likes
42
"It doesn't take much to see What Hi-Fi for what it is."

Well argued!
 
Top Bottom