mansr Posted July 8, 2019 Share Posted July 8, 2019 47 minutes ago, Jud said: I notice it and the Red feature a "bit-perfect digital volume control," which I guess is the same as the "bit-perfect variable output" mentioned above. Would be interested to learn more. It's meaningless. Digital volume control by necessity means bit are altered. Bit-perfect means bits are not altered. Can't have it both ways. tmtomh 1 Link to comment
Popular Post mansr Posted July 8, 2019 Popular Post Share Posted July 8, 2019 1 minute ago, Jud said: Which is why I said I'd be interested to learn more. Since the AQ description doesn't say anything, how (without giving away IP) does the volume control actually operate? The Dragonfly Red uses the built-in volume control in the ESS DAC. I assume it does a simple multiplication, since that's all a volume control needs to do. If you want to know for sure what the Cobalt does, send me one and I'll find out. 4est and tmtomh 1 1 Link to comment
mansr Posted July 11, 2019 Share Posted July 11, 2019 1 minute ago, MikeJazz said: I have a more question about usability. What exactly happens when we are listening to music with the dragonfly cobalt and we have a incoming call and we want to listen to it. Does the DAC (1) silence the music automatically (2) pass trough our sound, That's up to the phone and playback app. 1 minute ago, MikeJazz said: if the headphones have mics... The Dragonfly is a DAC only. It can't do anything with a microphone. Link to comment
mansr Posted July 15, 2019 Share Posted July 15, 2019 A word of caution: after plugging it in, the first volume change makes it jump to max regardless of what was requested. Over headphones, that could get unpleasant. Clearly a firmware bug. asdf1000 1 Link to comment
mansr Posted July 16, 2019 Share Posted July 16, 2019 7 hours ago, lucretius said: I noticed something like this on my Android phone -- fixed it by uninstalling, reinstalling UAPP, changing the volume steps from the default 20 to 100 within UAPP, and making sure the master hardware volume level was set for less than half of full output. I had a similar problem with the Red on my Android phone (never had this problem with an iPod touch). The problem seemed to reappear every time I loaded a new version of Android on my phone. I just assumed it was a problem with Android or Samsung hardware. My PC does not run Android. Link to comment
mansr Posted July 16, 2019 Share Posted July 16, 2019 Just now, lucretius said: I also tried on Windows. However, I did not have my phones to my ears, when first plugging in the Cobalt. I did notice that it played loud and I just thought the volume control was too high. I lowered the Windows volume control and all was fine. Rebooting and/or reinsertions of the Dragonfly did not bring back the experience of jumping to full volume. OTH, the volume range of the Dragonfly Cobalt appears to map to a Windows volume range of 1 - 10 and not 1- 100. (That was similar for the Red as well.) That should be fixed in the Cobalt's firmware. The hardware range is 0-64. Software may choose to map that onto a different scale. Link to comment
mansr Posted July 16, 2019 Share Posted July 16, 2019 44 minutes ago, lucretius said: Yes. Could it be that the firmware implements a linear control when that should be logarythmic? It's a dB scale. That's easy to verify by measuring the output level. Link to comment
Popular Post mansr Posted July 16, 2019 Popular Post Share Posted July 16, 2019 OK, here's the proof it's a firmware bug. I connected a logic analyser to the USB and I2C ports. Then I sent a command to set the volume to the minimum of -64 dB (zero on the 0-64 scale). The volume control registers in the ESS DAC are coded as attenuation from max in half-dB steps. The requested volume thus corresponds to a value of 128. This is what actually happened: The ESS volume control is first set to the correct value (80 hex = 128 decimal). Then it is immediately set to zero, which is maximum volume. The USB traffic is easier to see in a table view: The highlighted line show the correct value being requested (C0 interpreted as a signed 8-bit value is -64). The remainder is the DAC indicating that it doesn't want to return any data to the host. The Computer Audiophile and lucretius 2 Link to comment
mansr Posted July 16, 2019 Share Posted July 16, 2019 The max value is written to the volume control register after a somewhat random delay. In the capture above, it happened almost immediately. Sometimes it takes a few milliseconds. Link to comment
mansr Posted July 18, 2019 Share Posted July 18, 2019 4 hours ago, Gus141 said: Anyone else not getting a magenta color on the LED for 96kHz music? My LED is white for 96kHz. I get all the other colors as described in the manual but 96kHz tracks make the Cobalt’s LED show white. Now, maybe it’s just a really faded magenta, but I’ve changed out enough printer cartridges to know what magenta looks like. Just thought I’d ask. I’ll post in other forums as well and report back. I get white or possibly pale blue. The colour for 88.2 kHz is something I'd describe as yellow rather than amber, but I guess that's close enough. Link to comment
mansr Posted July 18, 2019 Share Posted July 18, 2019 6 hours ago, lucretius said: You said earlier that this happens after plugging in the device and making the first volume change. I assume that subsequent volume changes are fine (seems to be the case with my testing). The first volume change after plugging in causes the glitch. After that it's fine. 6 hours ago, lucretius said: However, I still noticed that at a volume of about 10 or 11 or 12 in Windows, the actual volume was insanely loud and it was hard to notice any difference when moving the Windows system fader among the higher values. So I am assuming there is another issue in addition to the firmware issue you pointed out. The volume control runs from max (no attenuation) to -64 dB in 1 dB steps for a total of 65 different levels. I have no idea how Windows maps those onto its scale. It might not even be a linear translation. Does it use a custom Windows driver or the built-in Audio Class support? Link to comment
mansr Posted July 18, 2019 Share Posted July 18, 2019 6 minutes ago, lucretius said: There is no proprietary driver for the Dragonfly. When plugging in the device for the very first time, Windows sets up an endpoint configured to use WASAPI -- I don't think Windows has it's own customized driver for this device. Also, are you sure those are 1db steps (or is each step just a percentage of full volume)? I'm sure. The values go straight into the ESS chip where they (supposedly) represent dB attenuation. Also, the measured output level agrees. lucretius 1 Link to comment
mansr Posted July 18, 2019 Share Posted July 18, 2019 24 minutes ago, Gus141 said: As for the volume discussion, I’ve only tried the DFC on an iPad so far and have not encountered the problem there. Should I expect it on a MacBook Pro? I'd say, be prepared for it anywhere. lucretius 1 Link to comment
mansr Posted July 18, 2019 Share Posted July 18, 2019 7 minutes ago, lucretius said: For my Dragonfly Red, the Windows volume control maxes out at about 30 to 35 (after 35 it's all full volume). I could live with that, since there's still enough room to make meaningful sound level adjustments; however, for the Dragonfly Colbalt I tested, the Windows volume control maxed out much sooner -- making meaning sound level adjustments much more difficult. Is that on a 0-100 scale? Guess I should hook it up to a Windows machine and see what's going on. The Windows driver could very well be doing something strange. Link to comment
Popular Post mansr Posted July 29, 2019 Popular Post Share Posted July 29, 2019 4 minutes ago, miguelito said: I measured the current draw produced by the DF Red and DF Cobalt. I found that the Cobalt draws MORE current than the Red, contrary to AudioQuest claims. Specifically, I found the current draw to be 40mA-60mA for the Red (higher current with higher sampling rate, MQA rendering draws the most), and 60mA-80mA for the Cobalt. Tried both easy to drive (AKG-K7xx) and hard to drive (HD-650) headphones - the headphone did not make a difference in the current draw. Voltage was the same in all cases (5.16V) I can confirm this. With a 50 Ω load, the current draw goes up even more, but that's just physics. The current supplied to the load has to come from somewhere. miguelito and The Computer Audiophile 2 Link to comment
mansr Posted July 29, 2019 Share Posted July 29, 2019 @miguelito What volume level do you find comfortable with your headphones? Link to comment
mansr Posted August 4, 2019 Share Posted August 4, 2019 6 minutes ago, miguelito said: The clipping at 100% volume is a really bad bug if it is common to all units. Mine clips at full volume only with a load of 5 kΩ or less, so there's apparently some variability. It's still bad. Link to comment
mansr Posted August 5, 2019 Share Posted August 5, 2019 3 hours ago, firedog said: Archi says if you run it at 98% volume you get around the problem. So not so serious, IMO. The more serious issue is if the $300 version is not as good on only just as good as the $200 one. Or the $100 one, in some cases. lucretius 1 Link to comment
mansr Posted August 5, 2019 Share Posted August 5, 2019 1 minute ago, miguelito said: I would regard this as an awful bug. Having said this, it is good to know that with a high impedance load (>5kOhm) it doesn’t clip. In most cases where you’d want to set the volume to 100%, you’d be going to an additional amplification stage, and most those would be pretty high impedance (>>5kOhm). Thx for checking this. Archimago's sample clips even with a 1 MΩ load. There appears to be some variation in production. miguelito 1 Link to comment
mansr Posted August 26, 2019 Share Posted August 26, 2019 7 minutes ago, miguelito said: Saw a firmware update for both Cobalt (v1.10 latest) and Red (v1.07 latest). No mention of a Cobalt update on the AQ website. Link to comment
mansr Posted August 26, 2019 Share Posted August 26, 2019 6 minutes ago, miguelito said: What firmware is reported for your Cobalt on the AQ app? I haven't checked, but the 'bcdDevice' field in the USB device descriptor says 1.10. That field matches the firmware version on the Black. Link to comment
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now