Hello Daniel, list; Thanks for the reply and the ideas. I have some more information, please see below. On Wed, Feb 6, 2013 at 8:22 AM, Daniel Mack <zonque@xxxxxxxxx> wrote: > On 06.02.2013 17:02, chris hermansen wrote: >> On Wed, Feb 6, 2013 at 7:18 AM, Daniel Mack <zonque@xxxxxxxxx> wrote: >>> >>> Hi, >>> >>> On 06.02.2013 00:13, chris hermansen wrote: >>>> I wonder if any of you have any experience yet with the Audioquest >>>> Dragonfly, specifically under Ubuntu 12.10 which is running this kernel >>>> GNU/Linux 3.5.0-23-generic x86_64 >>>> >>>> This device sounds fine with 44.1 kHz / 16bit files but the 88.2 and 96 >>>> kHz / 24bit files do not. Specifically, I can hear the music for both >>>> of those files, but there is a loud kind of "static" thing going in the >>>> foreground. >>>> >>>> A "cat /proc/asound/DragonFly/stream0" when playing at all three bit >>>> rates seems to show "reasonable" parameters. Also, the LEDs on the >>>> Dragonfly show the correct color corresponding to the bit rate. >>>> >>>> One thing I note is that Alsa seems to want to run at 24 bits even for >>>> the 16 bit files ie one is forced to use plughw:1,0 for the output. >>> >>> What is forced exactly? The Linux driver sends data in 24bit if the >>> device requests 24bit sample format, and it lets the driver know through >>> its descriptors. I wonder why specifing a certain output device should >>> change anything in that regard. >> >> It seems that the combination of driver and Dragonfly only offer S24_3LE, >> so a file that is S16_LE needs to be converted to S24_3LE. >> >> This doesn't seem right to me, as according to this author for instance >> >> http://www.stereophile.com/content/audioquest-dragonfly-usb-da-converter-measurements > > I only read briefly over this, but that article doesn't seem to measure > the actual samples on the bus. If you tell CoreAudio (or ALSA for that > matter) to operate on 16 bits, the software layer will cut off the lower > 8 bits and that will of course affect the audio performance in > applications. That has nothing to do with actual hardware format spoken > to the device). Same happens on Linux when you use plughw:. > >> the Dragonfly accepts 16 bit data as well as 24 bit data. > > No, the software layer does, not the device itself. Since I am nearly completely clueless on the above, I certainly would not argue with you! > >> Anyway, the evidence: >> >> When I try >> >> sudo aplay -vD hw:1,0 06*.wav >> >> I get >> >> Playing WAVE '06_-_Amadou & Mariam_-_Artistiya.wav' : Signed 16 bit >> Little Endian, Rate 44100 Hz, Stereo >> aplay: set_params:1081: Sample format non available >> Available formats: >> - S24_3LE >> >> Conversely, with >> >> sudo aplay -vD plughw:1,0 06*.wav >> >> I get >> >> Playing WAVE '06_-_Amadou & Mariam_-_Artistiya.wav' : Signed 16 bit >> Little Endian, Rate 44100 Hz, Stereo >> Plug PCM: Linear conversion PCM (S24_3LE) > > Because ALSA converts that to S24_3LE. > >> The hw:1,0 device operates with a 24 bit file, giving >> >> Playing WAVE '2L50SACD_tr1_96k_stereo.wav' : Signed 24 bit Little >> Endian in 3bytes, Rate 96000 Hz, Stereo >> Hardware PCM card 1 'AudioQuest DragonFly' device 0 subdevice 0 > > And here, no conversion is necessary. > >>>> When I was debugging my Schiit Bifrost (still not working the way I want >>>> FWIW) I recall some patching that Daniel Mack was applying to the kernel >>>> in 3.6 (I think). Perhaps I need a newer kernel...? >>> >>> Do you see similar behaviour with the DragonFly than with the Bifrost, >>> in a way that stopping and restarting the stream would recover it? >> >> Stopping and restarting the stream does not improve things. >> >> Also, the LED colour, which indicates the bit rate, is correct on the >> first try and does not change on second or subsequent tries. >> >>> >>> Also, did you test the device with Mac OS X maybe, without installing >>> any third-party driver? >> >> I don't have access to a Mac unfortunately. I will try with a Windows XP >> we have here and report back later today. > > That doesn't help, as Windows does not ship with any usable USB audio > driver at all. So vendors are forced to ship their own, proprietary one, > which only has to work for their own hardware of course. Consequently, > they can ignore all the crucial details in the descriptor and hard-code > whatever constants they want in the driver. I recall reading in some bit of info that this device is a USB-1.0 device. Does this mean special drivers are not required for Windows? I think so. > > OS X is different, as they have a fully compliant driver natively. Hence > it would be interesting to see whether it works there. > >>> You can of course, if you're able to, hack the driver and force a >>> certain output format, just to see if that stops the static noise for >>> you. Then you know where exactly to look for possible misbehaviour of >>> the driver. Most likely though, we need to work around a hardware bug >>> with a quirk here. >>> >>> Could you send the output of 'lsusb -v', please? >> >> http://paste.ubuntu.com/1616929/ > > AudioStreaming Interface Descriptor: > bLength 20 > bDescriptorType 36 > bDescriptorSubtype 2 (FORMAT_TYPE) > bFormatType 1 (FORMAT_TYPE_I) > bNrChannels 2 > bSubframeSize 3 > bBitResolution 24 > bSamFreqType 4 Discrete > tSamFreq[ 0] 44100 > tSamFreq[ 1] 48000 > tSamFreq[ 2] 88200 > tSamFreq[ 3] 96000 > > The only audio streaming format offered in the descriptors is 24 bits > (bSubframeSize == 3), so the driver does the right thing by sending only > that format on the wire. > > Anyway, I doubt this is the reason for the broken audio on higher sample > rates. > > Lacking a good explanation, the only hint I can give you is to boot a > Windows instance in a Virtual box, pass-through that USB device to the > guest OS and use usbmon to trace the communication for 96KHz streaming. > Then do the same thing with Linux and look for the differences. We might > most probably end up with a quirk for that device :-/ I don't have a Windows I can run in a virtual box, so I tried a few other things, which may narrow down the problem. On Windows XP using Foobar 2000 (erm) I get LED colours that match the sample rates of the music and NO CRACKLING. Ie seems to work there. Because I can, I guess, I tried the Dragonfly on a couple of 32 bit Ubuntu machines I have around, one a server 12.10 and one a fresh desktop install of 12.10. Both of those work just fine! Ie I can play 16 bit / 44.1 files through plughw and 24 bit / 88.2 and 24 bit / 96 through hw or plughw and I get fine sound, what appears to be the correct behaviour from aplay -v, and the colours of LEDs that are expected. So something is either weirdly configured on my 64 bit machine or ...? One other thing I have tried on the 64 bit machine - using sound settings to make the Dragonfly the active card and playing Guayadeque through the default device, I get 44.1 files playing at that bit rate (according to the colour of the LED on the Dragonfly), and 96 files playing at 48 kHz (according to the colour of the LED on the Dragonfly). Neither the 44.1 nor the 48 music includes static. The above behaviour seems to make sense, as Pulse is configured to use 44.1 as the default sample rate and 48 as the alternative sample rate. So I am left wondering if I have some kind of weird configuration issue where pulseaudio is somehow interfering with the Dragonfly, or some similar thing. Thanks again for any ideas. ------------------------------------------------------------------------------ Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb _______________________________________________ Alsa-user mailing list Alsa-user@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/alsa-user
