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? 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
