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. > 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. 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 :-/ Daniel ------------------------------------------------------------------------------ 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
