On Wed, Feb 6, 2013 at 11:08 PM, Daniel Mack <zonque@xxxxxxxxx> wrote: > On 07.02.2013 03:56, chris hermansen wrote: >> 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? > > What kernel versions do all these machines use exactly? Kernel versions: The System76 laptop, where the Dragonfly does not work, and which I have tested with Pulse turned off: Linux avignon 3.5.0-23-generic #35-Ubuntu SMP Thu Jan 24 13:15:40 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux The Toshiba laptop, which is nevertheless running Ubuntu 12.10 Server and only Alsa, where the Dragonfly works: Linux marseille 3.5.0-23-generic #35-Ubuntu SMP Thu Jan 24 13:05:29 UTC 2013 i686 i686 i686 GNU/Linux The Dell desktop, where the Dragonfly works (where I observed similar static with its ASUS Xonar DX connected by TOSLINK to the Schiit): Linux madrid 3.5.0-23-generic #35-Ubuntu SMP Thu Jan 24 13:05:29 UTC 2013 i686 i686 i686 GNU/Linux (I just checked this last one again and it is still working fine) ------------------------------------------------------------------------------ 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
