Hi Daniel and list; Still a bit more experimenting, please see below. On Wed, Feb 6, 2013 at 5:34 PM, chris hermansen <clhermansen@xxxxxxxxx> wrote: > Hi Daniel and list; > > A bit more experimenting this afternoon, please see below. > > On Wed, Feb 6, 2013 at 1:20 PM, chris hermansen <clhermansen@xxxxxxxxx> wrote: >> 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. > > Further to my comments above, my "other project" is to get my Schiit Bifrost > working properly. Today I tried a brand-new ASUS DX in my older Dell desktop > hooked up to the Bifrost with a TOSLINK "cable". > > What does this have to do with the Dragonfly etc above? > > Well, the ASUS DX -> Bifrost on my Dell (32 bit Ubuntu 12.10) behaves the > same weird way as the Dragonfly on my System76 (64 bit Ubuntu 12.10), ie > fine on 44.1 / 16 bit files but weird loud static on the 96 / 24 bit files. > > All the weirder because the Dell + Dragonfly seems to work perfectly. > > Now more puzzled than ever. Could this be Pulse Audio weirdness? Ok, I am pretty sure it is not Pulse Audio. I set the Pulse client.conf to not respawn and killed the daemon; I then checked that it was no longer running. Then I tried aplay on my two files. Seemingly no difference; the 44.1 played fine through the plughw interface; the 96 played with static, through both the plughw and the hw interfaces. Given that it seems to work ok on one Ubuntu 12.10 machine and not on the other, perhaps I should try the usbmon thing on both machines? Thanks ------------------------------------------------------------------------------ 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
