1. 18 Apr, 2013 6 commits
    • Daniel Mack's avatar
      ALSA: snd-usb: add support for bit-reversed byte formats · 44dcbbb1
      Daniel Mack authored
      There is quite some confusion around the bit-ordering in DSD samples,
      and no general agreement that defines whether hardware is supposed to
      expect the oldest sample in the MSB or the LSB of a byte.
      
      ALSA will hence set the rule that on the software API layer, bytes
      always carry the oldest bit in the most significant bit of a byte, and
      the driver has to translate that at runtime in order to match the
      hardware layout.
      
      This patch adds support for this by adding a boolean flag to the
      audio format struct.
      Signed-off-by: default avatarDaniel Mack <zonque@gmail.com>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      44dcbbb1
    • Daniel Mack's avatar
      ALSA: snd-usb: add support for DSD DOP stream transport · d24f5061
      Daniel Mack authored
      In order to provide a compatibility way for pushing DSD
      samples through ordinary PCM channels, the "DoP open Standard" was
      invented. See http://www.dsd-guide.com for the official document.
      
      The host is required to stuff DSD marker bytes (0x05, 0xfa,
      alternating) in the MSB of 24 bit wide samples on the bus, in addition
      to the 16 bits of actual DSD sample payload.
      
      To support this, the hardware and software stride logic in the driver
      has to be tweaked a bit, as we make the userspace believe we're
      operating on 16 bit samples, while we in fact push one more byte per
      channel down to the hardware.
      
      The DOP runtime information is stored in struct snd_usb_substream, so
      we can keep track of our state across multiple calls to
      prepare_playback_urb_dsd_dop().
      Signed-off-by: default avatarDaniel Mack <zonque@gmail.com>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      d24f5061
    • Daniel Mack's avatar
      ALSA: snd-usb: use ep->stride from urb callbacks · 8a2a74d2
      Daniel Mack authored
      For normal PCM transfer, this change has no effect, as the endpoint's
      stride is always frame_bits/8. For DSD DOP streams, however, which is
      added later, the hardware stride differs from the software stride, and
      the endpoint has the correct information in these cases.
      Signed-off-by: default avatarDaniel Mack <zonque@gmail.com>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      8a2a74d2
    • Daniel Mack's avatar
      ALSA: add DSD formats · ef7a4f97
      Daniel Mack authored
      This patch adds two formats for Direct Stream Digital (DSD), a
      pulse-density encoding format which is described here:
      https://en.wikipedia.org/wiki/Direct_Stream_Digital
      
      DSD operates on 2.8, 5.6 or 11.2MHz sample rates and as a 1-bit
      stream.
      
      The two new types added by this patch describe streams that are capable
      of handling DSD samples in DOP format as 8-bit or in 16-bit (or at a x8
      or x16 data rate, respectively).
      
      DSD itself specifies samples in *bit*, while DOP and ALSA handle them
      as *bytes*. Hence, a factor of 8 or 16 has to be applied for the sample
      rare configuration, according to the following table:
      
                                                        configured hardware
              176.4KHz   352.8kHz   705.6KHz     <----       sample rate
      
      8-bit                2.8MHz     5.6MHz
      16-bit    2.8Mhz     5.6MHz    11.2MHz
      
               `-----------------------------'
                   actual DSD sample rates
      Signed-off-by: default avatarDaniel Mack <zonque@gmail.com>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      ef7a4f97
    • Takashi Iwai's avatar
      ALSA: hda - Disable the sanity check in snd_hda_add_pincfg() · d5657ec9
      Takashi Iwai authored
      When pin default configs are overridden via patch option, these are
      evaluated before fixups are applied.  Since some fixups change the
      whole codec trees and/or add pins dynamically, this sanity check might
      not pass when pins aren't present at the time the function is called.
      
      We may reorder the execution, but an easier fix is simply to disable
      this sanity check.
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      d5657ec9
    • Wei Yongjun's avatar
      ALSA: hda - fix error return code in patch_alc662() · 6134b1a2
      Wei Yongjun authored
      Fix to return a negative error code from the error handling
      case instead of 0, as returned elsewhere in this function.
      Signed-off-by: default avatarWei Yongjun <yongjun_wei@trendmicro.com.cn>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      6134b1a2
  2. 17 Apr, 2013 2 commits
  3. 16 Apr, 2013 3 commits
    • Takashi Iwai's avatar
      ALSA: hda - Use the primary DAC for all aamix outputs · 5ead56f2
      Takashi Iwai authored
      When setting up the aamix output paths, use the primary DAC instead of
      the individual DAC for each output as default.  Otherwise multiple
      DACs will be turned on for a single aamix widget, which results in
      doubly or more volumes, because the duplicated signals will be sent
      through all these DACs for a single stream.
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      5ead56f2
    • Takashi Iwai's avatar
      ALSA: hda - Fix aamix activation with loopback control on VIA codecs · 65033cc8
      Takashi Iwai authored
      When we have a loopback mixer control, this should manage the state
      whether the output paths include the aamix or not.  But the current
      code blindly initializes the output paths with aamix = true, thus the
      aamix is enabled unless the loopback mixer control is changed.
      
      Also, update_aamix_paths() called by the loopback mixer control put
      callback invokes snd_hda_activate_path() with aamix = true even for
      disabling the mixing.  This leaves the aamix path even though the
      loopback control is turned off.
      
      This patch fixes these issues:
      - Introduced aamix_default() helper to indicate whether with_aamix is
        true or false as default
      - Fix the argument in update_aamix_paths() for disabling loopback
      Reported-by: default avatarLydia Wang <LydiaWang@viatech.com.cn>
      Cc: <stable@vger.kernel.org> [v3.9+]
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      65033cc8
    • Dylan Reid's avatar
      ALSA: hda - Add codec delay to the capture time stamp. · ae03bbb8
      Dylan Reid authored
      For capture, the delay through the codec contributes to the time stamp
      of the sample recorded at the A to D.  Rename the codec time stamp
      function appropriately.
      Signed-off-by: default avatarDylan Reid <dgreid@chromium.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      ae03bbb8
  4. 15 Apr, 2013 4 commits
  5. 13 Apr, 2013 1 commit
    • Calvin Owens's avatar
      ALSA: usb: Add quirk for 192KHz recording on E-Mu devices · 1539d4f8
      Calvin Owens authored
      When recording at 176.2KHz or 192Khz, the device adds a 32-bit length
      header to the capture packets, which obviously needs to be ignored for
      recording to work properly.
      
      Userspace expected:  L0 L1 L2 R0 R1 R2
      ...but actually got: R2 L0 L1 L2 R0 R1
      
      Also, the last byte of the length header being interpreted as L0 of
      the first sample caused spikes every 0.5ms, resulting in a loud 16KHz
      tone (about the highest 'B' on a piano) being present throughout
      captures.
      
      Tested at all sample rates on an E-Mu 0404USB, and tested for
      regressions on a generic USB headset.
      Signed-off-by: default avatarCalvin Owens <jcalvinowens@gmail.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      1539d4f8
  6. 12 Apr, 2013 24 commits