Search This Blog


Friday, April 18, 2014

Fly the Dragon

Last week I received the Audioquest Dragonfly version 1.2.
It's out in the market since around November 2013.  Gordon Rankin from Wavelength Audio sits behind the design of the interface. The version 1.0 lost quickly ground against the thumbDAC competition. Gordon put some more brain into the tiny device to make it sing. Beside that Audioquest
stepped on the price break.  They must have realized that high volume sales is a key success factor in that market.

I thought I give it a try. Most reviews I read were quite positive. Especially those comments saying that the 1.0 weaknesses were more or less successfully addressed with 1.2.
The new pricetag seemed to be in a nice range. The old 1.0 DF sells around 99$ nowadays btw.

Below you'll find my point of view and some Linux related hints in the annex of that article. (Note: There is no Linux documentation for the Dragonfly)

I'm currently testing this or that "thumbDAC". My goal is to slim down my stereo as much as possible without taking compromises in terms of handling and soundquality. I do think it's possible in 2014.
There's IMO no need in invest in vastly overpriced audiophile gear anymore. 

My current reference, in terms of value for the money,  is a 99€ battery driven DIY DAC with PCM5102 DAC and XMOS receiver from (You'll find a lenghty thread over at DIY-Audio.) It also delivers up to 384khz SR and DSD. If you add the additional batteries etc. you'll end up in the same range as the naked Dragonfly.

The JLsounds interface does come with highest quality SPDIF (IMO better then Audiophilleo) and I2S outputs.
I tested a M2Tech USB DAC against the JLsounds IF earlier. The M2tech DAC was a real nice performer. What made me send the device back, was its price and the lack of features (SPDIF/I2S). 

At  200€+ the M2Tech is IMO too expensive in comparision to its 2014 competition.
 Even worse from a pricepoint are e.g. Meridian Explorer.  

Now back to the Dragonfly 1.2 .
The Dragonfly 1.2 comes at a rather reasonable rate of 150$/€ nowadays. 
The killer feature is its analog volume control. Which clearly differentiates that interface from others.

Obviously the device is facing fierce competition, when it comes to the thumbDAC market standards 
in terms of features.  It delivers up to 96khz and no DSD @ 24bit only.  That's far below most other devices. But. Who needs more than the Dragonfly delivers?? 

I  received a Dragonfly for testing (let see if I'll keep it). 

Even though Audioquest outlines Windows and iOS support only, the Dragonfly also works under Linux.  I did not run any tests on Android.

The DF allows 24bit only. Most current devices allow 32bit. 32bit might have slight advantages over 24 bit in terms of SW volume control, DSP outputs and bit depth conversions on the transport side.

The tricky part, from a handling perspective, is the DF internal "analog" volume control. You need to use the OS mixer to address the volume control on the interface. 

If your application uses an internal SW volume control, you won't take any "benefit" of that external analog volume control. You basically need to handle two volume controls at a time.  Better check twice, what volume control you are using!

With Linux "alsamixer" you can set the Dragonfly internal volume control.  Make sure the alsamixer is set at all. Otherwise you might have "No Sound".

Alsamixer shows a range from 0 - 100% and translates that into

db gain: 0.00-0.19 

Hmmh??? Not sure but something is wrong with the mapping I'd guess.

Beside that only 10 steps are offered.

I'd guess the USB driver needs an update/quirk. I hope that the 100% is 100% at least. 

The Dragonfly is therefore not 100% compatible with Android or Linux.

But. It is working.

You can use the DF analog control nicely to set a fixed "gain" for your chain  properly. 

Most of the amplifiers out there run a gain of 24-30db. Which is usually far too much considering the 2V+ supplied by most of the DACs and 89db/W+ speakers out there. 

Without that analog volume control, you'd be forced to run a pretty high SW attenuation. We don't want that. Therefore I do consider this analog volume control a real nice feature.

My current transport is a CubiTruck, running a tailormade ArchLinux and Squeezelite btw. The Dragonfly feeds straight into a double mono Hypex UCD180 amp for the time being.

I'm currently running the Dragonfly buspowered. External power might lift it's performance further up. I'll try that later. 

My current impression - after 3 days - soundwise: 

The DF sounds  really nice. It sounds pleasant, warm and natural without losing too much on e.g. percussive details. On percussion I experienced more micro dynamics with other DACs. The space between and around instruments is not that huge. Still instruments are nicely separated and not mixed or overlayed. 
On complex orchestral recordings I can hear some "flutter" distortions. Here an USB-isolator or a better power source might do the trick. 

Still.  Overall it's quite a nice lean-back experience.  

And it might even change to the better, if I use a better supply or USB filter. 
Perhaps the DF needs some more days to fully break-in.

To be honest I'm asking myself already now, if it's really worth to go the DIY route any longer. 

The Dragonfly (add  the M2tech USB DAC to the list) is more or less Plug'n and Play and performs quite well. Hook it up to the Raspberry Pi and you'll have the perfect replacement for a Squeezebox Touch at 200$/€. Soundwise it'll for sure be a nice step up to a Squeezebox Touch.

Note: Have a look at my iFi Nano iDSD review. The Nano IMO outperformed the Dragonfly. 



ANNEX: Linux Hints


There is no documentation about the Audioquest Dragonfly and Linux. 

I wrote up some points you might find interesting.

1. Find out card number

cat /proc/asound/cards

or store exact result in variable

cardnumber="(cat /proc/asound/cards | grep "\[Dragon" | tr -d " " | cut -f 1 -d "[" )"

2. Setting DF analog volume control from commandline with alsamixer/amixer

amixer -c $cardnumber sset "PCM" 50%

replace $cardnumber with result from 1.

and "50%" with value from range 0%-100%

or use alsamixer

alsamixer -c $cardnumber

3. Differentiate DF v1.0 and v1.2

"bcdDevice" variable shows DragonFly revision

[root@abcde ~]# lsusb -vv

Bus 002 Device 002: ID 21b4:0081 

Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 1.00
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0 
bDeviceProtocol 0 
bMaxPacketSize0 8
idVendor 0x21b4 
idProduct 0x0081 
bcdDevice 1.20
iManufacturer 1 AudioQuest inc.
iProduct 2 AudioQuest DragonFly
iSerial 3 (C) 2013 Wavelength Audio, ltd.
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 131
bNumInterfaces 2
bConfigurationValue 1
iConfiguration 0 
bmAttributes 0x80
(Bus Powered)
MaxPower 200mA

4. For those running squeezlite, below line will make the DF fly:

squeezelite -o hw:$cardnumber,0 -m xx:xx:xx:xx:xx:xx -a 40:4:24_3:1 -n squeezefly -b 60000:200000 -p 90 -r 96000



  1. Hi Klaus, can you elaborate (or post some links) on the tailormade ArchLinux for the CubieTruck?

  2. Klaus - Great article! When I was first setting my DragonFly v1.2 on a Cubox-i running ArchLinux and LMS with Squeezelite, this was one my key resources for getting Squeezelite configured correctly.Thank you!

    But in the process of chasing down some periodic click/pops in playback, it was suggested by Gordon Rankin that it was a ALSA problem. He pointed me right back to your blog as the expert on the topic.

    It's a problem that disappears with either a powered hub, or oversampling. And one I'm assuming you did not have from this DragonFly writeup. Having chased this problem down (to no avail) in all the logical support outlets (Audioquest and Solid Run support, Squeezebox forum, ALSA web articles), I'd be keen to know if you have any insights to share.

    Great blog post! Thanks.

  3. Hi Steve.

    I didn't have any problems with the Dragonfly on the Cubitruck.

    You might below tweaks. Add these options to your squeezelite command line.

    1. increase buffer size

    -a 40:4::1

    you can also try 80 or higher instead of 40

    2. increase the task priority to

    -p 85

    And check if your power supply is supplying sufficient voltage/current.

    Good luck.

  4. Thanks Klaus. I tried all that (and more) before I even posted.

    Have run priority at 80, 85, 90, 95, and 99 (RT). No change. Same thing for ALSA interrupts.
    Have user your recc'd buffer of 40, 80, 120, and much, much higher. No change.
    And have swapped in a confirmed clean power supply for the Cubox-I. And have measured both voltage and current between the Cubox-I and the DragonFly. All apparently within acceptable ranges.
    And am in touch with other Cubox-I/DragonFly/LMS/Squeezelite users, all with the same problem.

    I know you can't afford to let this excellent blog devolve into a user support forum. So if you have an interest in this problem, please drop me a line at Would love to hear from you.

    Otherwise, I love the blog, and will be digesting your re-sampling post to glean insight into how I can best re-sample, to make the best of this frustrating situation.


  5. Steve.

    I'm running the Cubitruck. It comes with a different processor (A20) and a pretty different layout.
    I can't be of much help here.

    They probably use a different kernel & usb-driver and overall setup.

    I tried the Udoo board with Freescale processor and wasn't really happy.

    Why don't you try Volumio. It's highly optimized for audio and should run on your Cubox-I.
    The guy in charge is supplying latest software/drivers and patches.

    Just give it a try first. If that one runs stable, you at least know that you don''t face a general issue with your board.

    I no longer run Arch Linux btw. I switched to Debian Wheezy and upgraded to Jessy.
    Debian might not offer bleeding edge stuff, however, it offers a much wider collection of software.
    With Jessy I'm almost up2date nowadays.

  6. One more.

    Have a look at my "Shoot the Trouble" article. At the bottom you'll find a chapter that focusses on XRUNS.

    I hope you'll find some more advanced guidance over there.

  7. Klaus - that XRUNS info is awesome! Thanks! Will be spending quality time with that.

    And thanks for the Volumio suggestion, but I've done that and the problem is just the same - normally there, but goes away with oversampling or a powered hub. If your XRUNS info does not lead to a solution, I may have to follow your lead with a cubitruck.

    Cubox-I's look cool. But there's only so many hours I'm willing to throw at a silly problem. Thanks for the help! Now off to digest that XRUN info...

  8. I just added a small chapter about ARM power issues to the USB troubleshooting article!

  9. Klaus - Really appreciate the help. That "Shoot the Trouble" article had SO much great stuff in it, I'm frankly quite surprised to say that nothing in it solved this problem. And the only stuff I did not try were those handful of things that required BIOS changes (no user accessible Cubox-i BIOS that I'm aware of). Bummer.

    So I guess I'll be looking forward to your forthcoming "Ride my Truck" article's Annex 3 "Wheezy Installation" write-up. Now have one slightly used Cubox-I4Pro up for grabs, keeping the DragonFly, and getting a Cubietruck...

    Really awesome XRUN info! Thanks for the help.

  10. You absolute Legend! Bought a Dragonfly 1.2 to use with Squeezelite on a Raspberry Pi, only to find that it was barely audible through amplified speakers and was super crackly. Using Alsamixer to "up" the sound, and then change the squeezlite buffer and process priority have totally done the trick - and it now sounds awesome. Thanks big time