Indeed, what you can learn from Dragonfly's ads, and also its manual, is that "Dragonfly's LED lights up in different colours to indicate status or sample rate". So I would assume if the file played is 44.1kHz Dragonfly lights up in, i.e., red colour, if the file is 96kHz Dragonfly lights up in magenta colour.

But then there is another entry on the subject in the Dragonfly's manual: "Use the Format dropdown menu in your Windows to choose a sample rate, most likely 44.1kHz".

So basically, if you want Dragonfly to display what resolution is currently being processed, find it out and choose it manually yourself from the drop-down menu provided somewhere in the depths of your operating system.

Rubbish, isn't it?

The explanation should be: "Dragonfly's LED lights up in different colours, according to user's change of sample rate in operating systems". There should not be any implication that LED lights change automatically depending on which sample rate is currently being played.

Daz wrote:

There should not be any implication that LED lights change automatically depending on which sample rate is currently being played.

The DragonFly's LED does indeed switch color automatically to reflect the sample rate of the incoming data. What it doesn't tell is the bit depth.

John Atkinson
Editor, Stereophile

Audioquest Dragonfly will not change its LED light automatically to reflect the sample rate of the incoming data. I know this because I own and use this device. I have just played three files - 192kHz, 96kHz and 44.1kHz ones. Dragonfly only displays one colour, the one I set last time. To change Dragonfly's LED light one must use the operating system's format dropdown menu to switch to the required sample rate. There are four sample rate settings available: 44.1, 48, 88.2 and 96kHz. All this is reflected in Dragonfly's manual: "Use the Format dropdown menu in your Windows to choose a sample rate, most likely 44.1kHz". Why are you saying Audioquest Dragonfly is changing its LED colours automatically to reflect different sample rates incoming, when it is not doing this?

Daz wrote:

Audioquest Dragonfly will not change its LED light automatically to reflect the sample rate of the incoming data. I know this because I own and use this device. I have just played three files - 192kHz, 96kHz and 44.1kHz ones. Dragonfly only displays one colour, the one I set last time. To change Dragonfly's LED light one must use the operating system's format dropdown menu to switch to the required sample rate. There are four sample rate settings available: 44.1, 48, 88.2 and 96kHz. All this is reflected in Dragonfly's manual: "Use the Format dropdown menu in your Windows to choose a sample rate, most likely 44.1kHz". Why are you saying Audioquest Dragonfly is changing its LED colours automatically to reflect different sample rates incoming, when it is not doing this?

Check out AQ's FAQs:
audioquest.com /usb_digital_analog_converter/faqs
(remove space after .com)

At about 3/4 of the way down, begin reading at the section that says "DragonFly can play back audio data at four different sample rates. Which one should I choose?" and you'll have your answer.

Regarding the XP/whyTunes/Dragonfly setup, it may be time to upgrade. I would look in to:
- an Intel NUC (get a model with S/PDIF output and 24/192 support)
- a newer OS that supports 24/192 (Audiophile Linux or a later version of Windows)
- something *OTHER* than whyTunes (in Windows, foobar2000 with the Universal ASIO driver; in AP-Linux, there are PLENTY of options - read their forums.)

Daz wrote:

Audioquest Dragonfly will not change its LED light automatically to reflect the sample rate of the incoming data. I know this because I own and use this device. I have just played three files - 192kHz, 96kHz and 44.1kHz ones. Dragonfly only displays one colour, the one I set last time.

In which case you are not using playback software that changes the computer's output sample rate to match the file's rate, which is why you are having to do it manually. You are blaming the DragonFly for your app's problem.

John Atkinson
Editor, Stereophile

Since it has been established that Dragonfly is unable to adjust sample rates automatically on its own, unless supported by some suitable third party playback software, would you be able to recommend, as an example, such a suitable playback software, please?

I am currently using Foobar on Surface tablet (Windows 10). Perhaps there are some hidden settings within Foobar, which would wake my Dragonfly up but, I must admit, I was looking, I think everywhere, and couldn't find any, but, again, I agree, this doesn't mean that they might still be hidden there somewhere. I would appreciate your advice in this matter.

Meantime I will try to install the Universal ASIO driver next to Foobar, as advised above, and see how much of a difference this does.

Daz wrote:

I am currently using Foobar on Surface tablet (Windows 10)...

Meantime I will try to install the Universal ASIO driver next to Foobar, as advised above, and see how much of a difference this does.

My apologies for confusing your setup with the original poster's XP/iTunes/Dragonfly setup.

However, I still recommend combing through the FAQs and tinkering with the combination of foobar2000 and the Universal ASIO driver.

I, too, am a Surface Pro 4 owner, and its max native resolution is 24/48. Be confident that you are completely bypassing Windows' audio processing with your AQ DF.

Out of curiosity, to what are you connecting your DF: cans or an amp/AVR? If amp/AVR, make/model please.

mtymous1 wrote:

Out of curiosity, to what are you connecting your DF: cans or an amp/AVR? If amp/AVR, make/model please.

Both, to be honest, although the DF-amp connection occurs way more often. My red Dragonfly is using Russ Andrews interconnect to get connected to Cyrus integrated amplifier (Russ Andrews GQ-24, Cyrus 8twoDACQx + PSX-Rtwo power supply and again, Russ Andrews new Yello power cable). Sadly, there is nothing in Audioquest FAQ about Dragonfly switching automatically its lights. They only mention switching it manually. This is also what other users seem to confirm.

Daz wrote:

Sadly, there is nothing in Audioquest FAQ about Dragonfly switching automatically its lights.

To me, it's crystal clear in their FAQs:

"What does it mean when the DragonFly lights up in different colors?
As mentioned above, DragonFly performs best when audio data is sent to it at its native sample rate. To simplify this, DragonFly lights up different colors when it receives audio data at different sample rates: green for 44.1kHz, blue for 48kHz, amber for 88.2kHz, and magenta for 96kHz."

Not trying to nitpick here, but it might be best to state your assumptions and refine your question(s). The DF will light up to the frequency it receives. Period. If you're somehow expecting the hardware to dictate software design / logic / execution, that's a different story altogether.

Echo Atkinson's earlier comment.

John Atkinson wrote:

...you are not using playback software that changes the computer's output sample rate to match the file's rate, which is why you are having to do it manually. You are blaming the DragonFly for your app's problem.

chuckles304 wrote:

...if a file in iTunes is 44.1/16 and I have iTunes playback set to 96/24 what is it doing to that 44.1 file? Upsampling? Playing at 44.1?

The same applies to you. Check out AQ's FAQs:
http://audioquest.com/usb_digital_analog_converter/faqs

At about 3/4 of the way down, your answer is in the section that says "DragonFly can play back audio data at four different sample rates. Which one should I choose?"

John Atkinson wrote:

You are blaming the DragonFly for your app's problem.

No, it's not this easy, the problem is a bit more complex than you assume. Since both of you were unable to answer the question straight, possibly because due to lack of enough experience with the device in question, I decided to take matters in my own hands and investigate elsewhere what really is the problem. Thank you though for your good will of wanting to help. Now, listen, if you're interested, to what needs to be done if one wants their Dragonflies to work with PCs properly:
The culprit is neither an app, as suggested by Stereophile's editor, nor DAC as I was suspecting. The Audioquest FAQ section suggested by mtymous1 was also unhelpful as it suggested nowhere that Audioquest changes its colours automatically - it only appeared to confirm that if one manually changes resolution the DAC indeed is going to reflect this, but everyone already knew that. Mtymous1 was also too optimistic in announcing that the question has been already answered, as it hasn't been I am afraid. It is going to be answered now.
The culprit is an operating system. In my case it is Windows, but Apple systems are apparently also affected. I found out that by default systems are configured to use a single user-specified sample rate. Digital audio recorded at this sample rate will be played back without resampling, but digital audio at any other sample rate will be re-sampled to the configured sample rate before being sent to the DAC or other playback device. That's why my Dragonfly always lit one colour. I use Windows and Foobar, so let's have a closer look at this configuration. If one prefers to have their higher definition downloads played at their native sample rates in such setting, one must use a special mode called WASAPI - which is available in Windows. WASAPI mode is part of Windows, and there’s no need to install it or turn it on, but WASAPI mode can only be used by player programs specifically designed to use it (Foobar is among them), and each such program must be individually, and in not any particularly complicated way, configured to do so. Activate WASAPI in your Foobar, or other player, and Windows will start to send audio in its native sample rate to Dragonfly. Question is NOW answered, enjoy your experience.

I had assumed you knew some computing basics and had already ruled out WASAPI (or other drivers and APIs), so when you didn't report back on your Universal ASIO trials, that became a clue. Apologies for making those assumptions.

Below is a basic intro to DirectSound, WASAPI, and ASIO which was taken from a wiki page on xylio.com:

"The general rule of thumb is: if possible try to select in this order: ASIO, WASAPI, DirectSound (default mode).

DirectSound - this is the standard audio mode on Windows (along with MME but we don't use that in FutureDecks). It always works but it almost always works only in stereo mode and outputs only. What this means is that even if you have a soundcard with multiple inputs and outputs, you will most likely get working only 1 stereo output (without the other outputs and inputs). The latency is extremely big (usually between 50ms and 80ms) so you can't properly scratch or do any true real-time work. Also, you can't use timecodes (since you don't have any inputs and the latency is very bad). Getting separate heaphones/speakers signals is tricky since you almost always only get a single stereo output (maybe you can use split mode -- use left channel for speakers and right channel for headphones). You should use this only if your audio device doesn't support the other modes.

WASAPI - this is a lot better than DirectSound as it provides less latency (usually between 10ms and 30ms) so it's more suitable to real-time use. It also provides access to both inputs and outputs and multiple channels (if it's properly configured in Windows). There are some problems (like out of sync between outputs and inputs, pops, clicks, stutters, etc) in full-duplex mode (using both outputs and inputs) on some audio devices but in general it works ok. You should use this if your soundcard doesn't have an ASIO device.

ASIO - use this whenever you can. This is by far the best audio mode possible in Windows. It provides extremely low latencies (usually between 1ms-10ms) so it's perfect for timecodes, scratching and pretty much anything that you want to be real-time. Unfortunately not all audio devices (soundcards) have a driver for this. You need to check the CD that came with the device or look at the manufacturer's website for a specific driver for your device. Alternatively, you can use ASIO4ALL (a software which simulates ASIO for an audio device without one) but you might get mixed results - it might work perfectly or it may not. You should always choose this interface/mode when possible.

So, once more: use ASIO if it's available for your audio device. If not, use WASAPI and only as a last resort use DirectSound."

That said, keep in mind that drivers and APIs *ARE* software that dictate the performance of the hardware.

And again, apologies for assuming you had a basic understanding of these things.

Happy listening!

mtymous1 wrote:

I had assumed you knew some computing basics and had already ruled out WASAPI

You have only learned about WASAPI from my post otherwise you would surely mention it before. By stating you are "sorry" for assuming that someone doesn't know their basics, you are just being plain rude. I hope you will heal your frustrations one day. For now I am leaving your arrogant, ironic and incompetent lot to your "sorries". You are neither friendly nor helpful at all.

If my Cobalt is connected and the computer is turned on but the music is turned off, the color remains magenta (or blue, depending on the last music played). And also if the music is turned off and even the computer is turned off, the color remains the same (e.g. magenta or blue, depending on the last music played).

If I disconnect the computer, there will obviously be no any light, but I don't understand why there is no standby (I never have the color red) or you can give me some tips to fix this problem.