1. 30 4月, 2013 1 次提交
  2. 29 4月, 2013 2 次提交
  3. 26 4月, 2013 1 次提交
  4. 25 4月, 2013 5 次提交
  5. 22 4月, 2013 1 次提交
  6. 18 4月, 2013 4 次提交
    • D
      ALSA: snd-usb: add quirks handler for DSD streams · 126825e7
      Daniel Mack 提交于
      Unfortunately, none of the UAC standards provides a way to identify DSD
      (Direct Stream Digital) formats. Hence, this patch adds a quirks
      handler to identify USB interfaces that are capable of handling DSD.
      
      That quirks handler can augment the already parsed formats bit-field,
      by any of the new SNDRV_PCM_FMTBIT_DSD_{U8_U16} and setting the dsd_dop
      flag in the audio format, if the driver should take care for the DOP
      byte stuffing.
      
      The only devices that are known to work with this are the ones with
      a 'Playback Designs' vendor id.
      Signed-off-by: NDaniel Mack <zonque@gmail.com>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      126825e7
    • D
      ALSA: snd-usb: add support for bit-reversed byte formats · 44dcbbb1
      Daniel Mack 提交于
      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: NDaniel Mack <zonque@gmail.com>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      44dcbbb1
    • D
      ALSA: snd-usb: add support for DSD DOP stream transport · d24f5061
      Daniel Mack 提交于
      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: NDaniel Mack <zonque@gmail.com>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      d24f5061
    • D
      ALSA: snd-usb: use ep->stride from urb callbacks · 8a2a74d2
      Daniel Mack 提交于
      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: NDaniel Mack <zonque@gmail.com>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      8a2a74d2
  7. 15 4月, 2013 1 次提交
    • C
      ALSA: usb-audio: disable autopm for MIDI devices · cbc200bc
      Clemens Ladisch 提交于
      Commit 88a8516a (ALSA: usbaudio: implement USB autosuspend)
      introduced autopm for all USB audio/MIDI devices.  However, many MIDI
      devices, such as synthesizers, do not merely transmit MIDI messages but
      use their MIDI inputs to control other functions.  With autopm, these
      devices would get powered down as soon as the last MIDI port device is
      closed on the host.
      
      Even some plain MIDI interfaces could get broken: they automatically
      send Active Sensing messages while powered up, but as soon as these
      messages cease, the receiving device would interpret this as an
      accidental disconnection.
      
      Commit f5f16541 (ALSA: usb-audio: Fix missing autopm for MIDI input)
      introduced another regression: some devices (e.g. the Roland GAIA SH-01)
      are self-powered but do a reset whenever the USB interface's power state
      changes.
      
      To work around all this, just disable autopm for all USB MIDI devices.
      
      Reported-by: Laurens Holst
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NClemens Ladisch <clemens@ladisch.de>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      cbc200bc
  8. 13 4月, 2013 1 次提交
    • C
      ALSA: usb: Add quirk for 192KHz recording on E-Mu devices · 1539d4f8
      Calvin Owens 提交于
      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: NCalvin Owens <jcalvinowens@gmail.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      1539d4f8
  9. 10 4月, 2013 1 次提交
  10. 07 4月, 2013 1 次提交
    • E
      ALSA: usb-audio: fix endianness bug in snd_nativeinstruments_* · 889d6684
      Eldad Zack 提交于
      The usb_control_msg() function expects __u16 types and performs
      the endianness conversions by itself.
      However, in three places, a conversion is performed before it is
      handed over to usb_control_msg(), which leads to a double conversion
      (= no conversion):
      * snd_usb_nativeinstruments_boot_quirk()
      * snd_nativeinstruments_control_get()
      * snd_nativeinstruments_control_put()
      
      Caught by sparse:
      
      sound/usb/mixer_quirks.c:512:38: warning: incorrect type in argument 6 (different base types)
      sound/usb/mixer_quirks.c:512:38:    expected unsigned short [unsigned] [usertype] index
      sound/usb/mixer_quirks.c:512:38:    got restricted __le16 [usertype] <noident>
      sound/usb/mixer_quirks.c:543:35: warning: incorrect type in argument 5 (different base types)
      sound/usb/mixer_quirks.c:543:35:    expected unsigned short [unsigned] [usertype] value
      sound/usb/mixer_quirks.c:543:35:    got restricted __le16 [usertype] <noident>
      sound/usb/mixer_quirks.c:543:56: warning: incorrect type in argument 6 (different base types)
      sound/usb/mixer_quirks.c:543:56:    expected unsigned short [unsigned] [usertype] index
      sound/usb/mixer_quirks.c:543:56:    got restricted __le16 [usertype] <noident>
      sound/usb/quirks.c:502:35: warning: incorrect type in argument 5 (different base types)
      sound/usb/quirks.c:502:35:    expected unsigned short [unsigned] [usertype] value
      sound/usb/quirks.c:502:35:    got restricted __le16 [usertype] <noident>
      Signed-off-by: NEldad Zack <eldad@fogrefinery.com>
      Acked-by: NDaniel Mack <zonque@gmail.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      889d6684
  11. 04 4月, 2013 11 次提交
  12. 03 4月, 2013 1 次提交
    • T
      ALSA: usb: Work around CM6631 sample rate change bug · 690a863f
      Torstein Hegge 提交于
      The C-Media CM6631 USB receiver doesn't respond to changes in sample rate
      while the interface is active. The same behavior is observed in other UAC2
      hardware like the VIA VT1731.
      
      Reset the interface after setting the sampling frequency on sample rate
      changes, to ensure that the sample rate set by snd_usb_init_sample_rate() is
      used. Otherwise, the device will try to use the sample rate of the previous
      stream, causing distorted sound on sample rate changes.
      
      The reset is performed for all UAC2 devices, as it should not affect a
      standards compliant device, but it is only necessary for C-Media CM6631,
      VIA VT1731 and possibly others.
      
      Failure to read sample rate from the device is not handled as an error in
      set_sample_rate_v2(), as (permanent or intermittent) failure to read sample
      rate isn't essential for a successful sample rate set.
      Signed-off-by: NTorstein Hegge <hegge@resisty.net>
      Acked-by: NClemens Ladisch <clemens@ladisch.de>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      690a863f
  13. 20 3月, 2013 3 次提交
  14. 18 3月, 2013 5 次提交
  15. 12 3月, 2013 1 次提交
  16. 07 3月, 2013 1 次提交