Hi Daniel and list; Thanks for taking a look at this. 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 the Dragonfly accepts 16 bit data as well as 24 bit data. 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) Its setup is: stream : PLAYBACK access : RW_INTERLEAVED format : S16_LE subformat : STD channels : 2 rate : 44100 exact rate : 44100 (44100/1) msbits : 16 buffer_size : 22050 period_size : 5513 period_time : 125011 tstamp_mode : NONE period_step : 1 avail_min : 5513 period_event : 0 start_threshold : 22050 stop_threshold : 22050 silence_threshold: 0 silence_size : 0 boundary : 6206523236469964800 Slave: Hardware PCM card 1 'AudioQuest DragonFly' device 0 subdevice 0 Its setup is: stream : PLAYBACK access : MMAP_INTERLEAVED format : S24_3LE subformat : STD channels : 2 rate : 44100 exact rate : 44100 (44100/1) msbits : 24 buffer_size : 22050 period_size : 5513 period_time : 125011 tstamp_mode : NONE period_step : 1 avail_min : 5513 period_event : 0 start_threshold : 22050 stop_threshold : 22050 silence_threshold: 0 silence_size : 0 boundary : 6206523236469964800 appl_ptr : 0 hw_ptr : 0 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 Its setup is: stream : PLAYBACK access : RW_INTERLEAVED format : S24_3LE subformat : STD channels : 2 rate : 96000 exact rate : 96000 (96000/1) msbits : 24 buffer_size : 48000 period_size : 12000 period_time : 125000 tstamp_mode : NONE period_step : 1 avail_min : 12000 period_event : 0 start_threshold : 48000 stop_threshold : 48000 silence_threshold: 0 silence_size : 0 boundary : 6755399441055744000 appl_ptr : 0 hw_ptr : 0 but this includes the very loud static overtop of the music. > > > 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. > > 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/ Thanks again! ------------------------------------------------------------------------------ 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
