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