Hello everyone —
Thanks for your patience. There are several general questions and an overall concern regarding Android. I’ll address general questions and concerns first and save Android for last.
How many milliwatts do the DragonFlys output at 600ohm?
DragonFly Red is capable of a peak output of 2.1vac. Into 600ohms, that’s only about 7mW. But most 600-ohm headphones are usually less than that and we can drive these just fine, as well as drive any receiver or integrated amplifier.
How much battery power do the DragonFlys drain?
They both draw about 4-5ma, plus whatever power the headphone amp is using at that time. This makes them easily capable of working with mobile devices—without placing a heavy burden on battery life.
Are the DragonFlys USB Audio Class 1 or Class 2?
The DragonFlys are UAC1 devices.
Are the DragonFlys compatible with iPod Touch 5 and 6?
DragonFly Black and Red are compatible with all iOS devices.
DragonFly Black/Red is exhibiting pops, clicks, and intermittent distortion when connected to an iPhone/iOS device.
Pops and clicks from iOS devices can be attributed to one or both of the following:
• Defective Camera Connection Kit: We have had experiences with a few defective camera kits. Apple has been proactive in replacing any defective units. You can simply return a defective adaptor to any Apple store for an exchange. Be sure to purchase genuine Apple CCKs. There are a number of counterfeits on the market.
• On a few occasions, while listening to any app, such as iTunes, Tidal, or Netflix, I’ve experienced intermittent clicks. I’ve found that shutting down the iOS device (iPhone or iPad) and rebooting the unit solves the issue.
Hearing a crackling sound when using Spotify’s equalizer settings.
We’ve experienced the same thing with Spotify’s EQ, but not from other apps. I’ve sent a service request to Spotify and hopefully they will respond. If they’re willing, I’m certain this is something we can solve together.
What we know about our USB code’s compatibility – It works with the following:
• Apple OS X and iOS
• Microsoft XP, 7, 8.1 and 10
• Linux Ubuntu (we offer no support for Linux OS’)
• Android 4.1 and newer
*provided that the hardware manufacturer implements hardware, software, and device drivers in accordance with all agreed specifications. This is where things get sticky …
When Google releases a new OS, they tend to have everything buttoned up and compliant. That’s their goal. Yes, there will be problems; there always are. But that’s what updates are for. Where things get sticky are in implementation. When a hardware manufacturer gets hold of the OS, they can choose to keep, alter, or omit certain features. This creates fragmentation. I’ll give you an example: I bought a Samsung Galaxy tablet. It was a brand new and current model when I purchased it. As soon as I got it, I made sure it had all of the latest software updates. When I went to connect it to several USB DACs, it would not enumerate with any of them. So, I downloaded the following software to test the tablet’s compliance:
https://play.google.com/store/apps/details?id=eu.chainfire.usbhostdiagnostics .
This app confirmed that my tablet is not compliant with the USB Host specification. From here, I jumped to UAPP, an app that has all of its own appropriate solutions embedded into it, bypassing any limitations built natively into the devices OS.
With regard to volume control: The USB org defines very clearly how volume control is supposed to work:
3.5 Audio Function Topology
To be able to manipulate the physical properties of an audio function, its functionality must be divided into addressable Entities. Two types of such generic Entities are identified and are called Units and Terminals.
Units provide the basic building blocks to fully describe most audio functions. Audio functions are built by connecting together several of these Units. A Unit has one or more Input Pins and a single Output Pin, where each Pin represents a cluster of logical audio channels inside the audio function. Units are wired together by connecting their I/O Pins according to the required topology. … As an example, consider a Volume Control inside a Feature Unit. By issuing the appropriate Get requests, the Host software can obtain values for the Volume Control’s attributes and, for instance, use them to correctly display the Control on the screen. Setting the Volume Control’s current attribute allows the Host software to change the volume setting of the Volume Control.
5.2.2.4.3.2 Volume Control
T
he Volume Control is one of the building blocks of a Feature Unit. A Volume Control can support all possible Control attributes (CUR, MIN, MAX, and RES). The settings for the CUR, MIN, and MAX attributes can range from +127.9961 dB (0x7FFF) down to -127.9961 dB (0x8001) in steps of 1/256 dB or 0.00390625 dB (0x0001). The range for the CUR attribute is extended by code 0x8000, representing silence, i.e., -∞ dB. The settings for the RES attribute can only take positive values and range from 1/256 dB (0x0001) to +127.9961 dB (0x7FFF). The Volume Control honors the request to the best of its abilities. It may round the wVolume attribute value to its closest available setting. It will report this rounded setting when queried during a Get Control request.
In the first form of the request, a particular Volume Control within a Feature Unit is addressed through the Unit ID and Channel Number fields of the Set/Get Feature Unit Control request. The valid range for the Channel Number field is from zero (the ‘master’ channel) up to the number of logical channels in the audio channel cluster.
The DragonFly Red & Black follow standard USB protocol definitions for volume controls. This is a function of decibels with a unity gain output = 0dB. In the case of the Red the range is from -64dB to 0dB, were 0dB would equal full capable output of 2.1Vac.
Here’s an example of how this works (Apple):
DragonFly set to 0db (unity gain)
DragonFly set to -1db
DragonFly set to -64db (zero gain)
And here’s how this works on Windows:
DragonFly set to 0db (unity gain)
DragonFly set to -64db (zero gain)
So, we know for certain the following: Both Apple and Microsoft adhere to the USB Host specifications. We also know that UAPP adheres to this. That’s why DragonFlys work with the volume control on all of these systems.
A little bit more on why UAPP works on almost all Android devices: It is a driver in the purest sense, similar to an ASIO driver for windows. UAPP doesn’t write to Android’s media player, only to its own.
The issue with compatibility resides with Android and/or its hardware partners. All we can do is create a code that meets USB.org’s specification. From there it is up to parties on the other side to adhere as well. We’ve seen workarounds such as this …
http://www.techulk.com/2015/01/how-to-increase-default-volume-on-any.html . But this seems to be chip specific, so it won’t solve everyone’s problem. This is the challenge with a fragmented market.
I think in the long term we’ll need to find a developer who wants to create a universal device driver for Android; something akin to the ASIO driver for Windows. Until then the best solution we can recommend is UAPP. Thanks for reading.
Regards,
Steve Silberman
AudioQuest