Hello Daniel, list; Solved, sort of! See below. On Thu, Feb 7, 2013 at 8:17 AM, chris hermansen <clhermansen@xxxxxxxxx> wrote: > 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) I have a solution, which is kind of weird but anyway... My System76 laptop has 1 USB-2 and 2 USB-3 ports on it. This morning I decided to see what happened if I plugged the DragonFly into one of the USB-3 ports, instead of the USB-2 port I had been using to date. And that worked! No problems that I can detect. I don't know what this "means" - is the USB hardware on the System76 defective in some way, or...? But anyway, I have music, and it sounds just fine! Daniel, thanks for all your help. Now back to the Schiit.... -- Chris Hermansen · clhermansen@xxxxxxxxx C'est ma façon de parler. ------------------------------------------------------------------------------ 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
