1. 19 Oct, 2015 3 commits
  2. 26 Aug, 2015 1 commit
    • Takashi Iwai's avatar
      ALSA: usb-audio: Avoid nested autoresume calls · 47ab1545
      Takashi Iwai authored
      After the recent fix of runtime PM for USB-audio driver, we got a
      lockdep warning like:
        [ INFO: possible recursive locking detected ]
        4.2.0-rc8+ #61 Not tainted
        pulseaudio/980 is trying to acquire lock:
         (&chip->shutdown_rwsem){.+.+.+}, at: [<ffffffffa0355dac>] snd_usb_autoresume+0x1d/0x52 [snd_usb_audio]
        but task is already holding lock:
         (&chip->shutdown_rwsem){.+.+.+}, at: [<ffffffffa0355dac>] snd_usb_autoresume+0x1d/0x52 [snd_usb_audio]
      This comes from snd_usb_autoresume() invoking down_read() and it's
      used in a nested way.  Although it's basically safe, per se (as these
      are read locks), it's better to reduce such spurious warnings.
      The read lock is needed to guarantee the execution of "shutdown"
      (cleanup at disconnection) task after all concurrent tasks are
      finished.  This can be implemented in another better way.
      Also, the current check of chip->in_pm isn't good enough for
      protecting the racy execution of multiple auto-resumes.
      This patch rewrites the logic of snd_usb_autoresume() & co; namely,
      - The recursive call of autopm is avoided by the new refcount,
        chip->active.  The chip->in_pm flag is removed accordingly.
      - Instead of rwsem, another refcount, chip->usage_count, is introduced
        for tracking the period to delay the shutdown procedure.  At
        the last clear of this refcount, wake_up() to the shutdown waiter is
      - The shutdown flag is replaced with shutdown atomic count; this is
        for reducing the lock.
      - Two new helpers are introduced to simplify the management of these
        refcounts; snd_usb_lock_shutdown() increases the usage_count, checks
        the shutdown state, and does autoresume.  snd_usb_unlock_shutdown()
        does the opposite.  Most of mixer and other codes just need this,
        and simply returns an error if it receives an error from lock.
      Fixes: 9003ebb1
       ('ALSA: usb-audio: Fix runtime PM unbalance')
      Reported-and-tested-by: default avatarAlexnader Kuleshov <kuleshovmail@gmail.com>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
  3. 16 Aug, 2015 2 commits
    • Pierre-Louis Bossart's avatar
      ALSA: usb: handle descriptor with SYNC_NONE illegal value · 395ae54b
      Pierre-Louis Bossart authored
      The M-Audio Transit exposes an interface with a SYNC_NONE attribute.
      This is not a valid value according to the USB audio classspec. However
      there is a sync endpoint associated to this record. Changing the logic to
      try to use this sync endpoint allows for seamless transitions between
      altset 2 and altset 3. If any errors happen, the behavior remains the same.
      $ more /proc/asound/card1/stream0
      M-Audio Transit USB at usb-0000:00:14.0-2, full speed : USB Audio
        Status: Stop
        Interface 1
          Altset 1
          Format: S24_3LE
          Channels: 2
          Endpoint: 3 OUT (ADAPTIVE)
          Rates: 48001 - 96000 (continuous)
        Interface 1
          Altset 2
          Format: S24_3LE
          Channels: 2
          Endpoint: 3 OUT (NONE)
          Rates: 8000 - 48000 (continuous)
        Interface 1
          Altset 3
          Format: S16_LE
          Channels: 2
          Endpoint: 3 OUT (ASYNC)
          Rates: 8000 - 48000 (continuous)
      Signed-off-by: default avatarPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
    • Pierre-Louis Bossart's avatar
      ALSA: usb: fix corrupted pointers due to interface setting change · 63018447
      Pierre-Louis Bossart authored
      When a transition occurs between alternate settings that do not use the
      same synchronization method, the substream pointers were not reset.
      This prevents audio from being played during the second transition.
      Identified and tested with M-Audio Transit device
      (0763:2006 Midiman M-Audio Transit)
      Details of the issue:
      First playback to adaptive endpoint:
      $ aplay -Dhw:1,0 ~/24_96.wav
      Playing WAVE '/home/plb/24_96.wav' : Signed 24 bit Little Endian in 3bytes,
      Rate 96000 Hz, Stereo
      [ 3169.297556] usb 1-2: setting usb interface 1:1
      [ 3169.297568] usb 1-2: Creating new playback data endpoint #3
      [ 3169.298563] usb 1-2: Setting params for ep #3 (type 0, 3 urbs), ret=0
      [ 3169.298574] usb 1-2: Starting data EP @ffff880035fc8000
      first playback to asynchronous endpoint:
      $ aplay -Dhw:1,0 ~/16_48.wav
      Playing WAVE '/home/plb/16_48.wav' : Signed 16 bit Little Endian,
      Rate 48000 Hz, Stereo
      [ 3204.520251] usb 1-2: setting usb interface 1:3
      [ 3204.520264] usb 1-2: Creating new playback data endpoint #3
      [ 3204.520272] usb 1-2: Creating new capture sync endpoint #83
      [ 3204.521162] usb 1-2: Setting params for ep #3 (type 0, 4 urbs), ret=0
      [ 3204.521177] usb 1-2: Setting params for ep #83 (type 1, 4 urbs), ret=0
      [ 3204.521182] usb 1-2: Starting data EP @ffff880035fce000
      [ 3204.521204] usb 1-2: Starting sync EP @ffff8800bd616000
      second playback to adaptive endpoint: no audio and error on terminal:
      $ aplay -Dhw:1,0 ~/24_96.wav
      Playing WAVE '/home/plb/24_96.wav' : Signed 24 bit Little Endian in 3bytes,
      Rate 96000 Hz, Stereo
      aplay: pcm_write:1939: write error: Input/output error
      [ 3239.483589] usb 1-2: setting usb interface 1:1
      [ 3239.483601] usb 1-2: Re-using EP 3 in iface 1,1 @ffff880035fc8000
      [ 3239.484590] usb 1-2: Setting params for ep #3 (type 0, 4 urbs), ret=0
      [ 3239.484606] usb 1-2: Setting params for ep #83 (type 1, 4 urbs), ret=0
      This last line shows that a sync endpoint is used when it shouldn't.
      The sync endpoint is no longer valid and the pointers are corrupted
      Signed-off-by: default avatarPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
  4. 09 Feb, 2015 1 commit
  5. 28 Nov, 2014 1 commit
  6. 02 May, 2014 1 commit
    • Sander Eikelenboom's avatar
      ALSA: usb-audio: Prevent printk ratelimiting from spamming kernel log while DEBUG not defined · b7a77235
      Sander Eikelenboom authored
      This (widely used) construction:
      Causes the ratelimiting to spam the kernel log with the "callbacks suppressed"
      message below, even while the dev_dbg it is supposed to rate limit wouldn't
      print anything because DEBUG is not defined for this device.
      [  533.803964] retire_playback_urb: 852 callbacks suppressed
      [  538.807930] retire_playback_urb: 852 callbacks suppressed
      [  543.811897] retire_playback_urb: 852 callbacks suppressed
      [  548.815745] retire_playback_urb: 852 callbacks suppressed
      [  553.819826] retire_playback_urb: 852 callbacks suppressed
      So use dev_dbg_ratelimited() instead of this construction.
      Signed-off-by: default avatarSander Eikelenboom <linux@eikelenboom.it>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
  7. 09 Apr, 2014 1 commit
  8. 26 Feb, 2014 1 commit
    • Takashi Iwai's avatar
      ALSA: usb-audio: Use standard printk helpers · 0ba41d91
      Takashi Iwai authored
      Convert with dev_err() and co from snd_printk(), etc.
      As there are too deep indirections (e.g. ep->chip->dev->dev),
      a few new local macros, usb_audio_err() & co, are introduced.
      Also, the device numbers in some messages are dropped, as they are
      shown in the prefix automatically.
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
  9. 07 Oct, 2013 3 commits
  10. 26 Sep, 2013 1 commit
    • Alan Stern's avatar
      ALSA: improve buffer size computations for USB PCM audio · 976b6c06
      Alan Stern authored
      This patch changes the way URBs are allocated and their sizes are
      determined for PCM playback in the snd-usb-audio driver.  Currently
      the driver allocates too few URBs for endpoints that don't use
      implicit sync, making underruns more likely to occur.  This may be a
      holdover from before I/O delays could be measured accurately; in any
      case, it is no longer necessary.
      The patch allocates as many URBs as possible, subject to four
      	The total number of URBs for the endpoint is not allowed to
      	exceed MAX_URBS (which the patch increases from 8 to 12).
      	The total number of packets per URB is not allowed to exceed
      	MAX_PACKS (or MAX_PACKS_HS for high-speed devices), which is
      	decreased from 20 to 6.
      	The total duration of queued data is not allowed to exceed
      	MAX_QUEUE, which is decreased from 24 ms to 18 ms.
      	The total number of ALSA frames in the output queue is not
      	allowed to exceed the ALSA buffer size.
      The last requirement is the hardest to implement.  Currently the
      number of URBs needed to fill a buffer cannot be determined in
      advance, because a buffer contains a fixed number of frames whereas
      the number of frames in an URB varies to match shifts in the device's
      clock rate.  To solve this problem, the patch changes the logic for
      deciding how many packets an URB should contain.  Rather than using as
      many as possible without exceeding an ALSA period boundary, now the
      driver uses only as many packets as needed to transfer a predetermined
      number of frames.  As a result, unless the device's clock has an
      exceedingly variable rate, the number of URBs making up each period
      (and hence each buffer) will remain constant.
      The overall effect of the patch is that playback works better in
      low-latency settings.  The user can still specify values for
      frames/period and periods/buffer that exceed the capabilities of the
      hardware, of course.  But for values that are within those
      capabilities, the performance will be improved.  For example, testing
      shows that a high-speed device can handle 32 frames/period and 3
      periods/buffer at 48 KHz, whereas the current driver starts to get
      glitchy at 64 frames/period and 2 periods/buffer.
      A side effect of these changes is that the "nrpacks" module parameter
      is no longer used.  The patch removes it.
      Signed-off-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      CC: Clemens Ladisch <clemens@ladisch.de>
      Tested-by: default avatarDaniel Mack <zonque@gmail.com>
      Tested-by: default avatarEldad Zack <eldad@fogrefinery.com>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
  11. 06 Aug, 2013 8 commits
  12. 27 Jun, 2013 2 commits
  13. 29 Apr, 2013 1 commit
  14. 18 Apr, 2013 3 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>
    • 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
      Signed-off-by: default avatarDaniel Mack <zonque@gmail.com>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
    • 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>
  15. 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
      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>
  16. 10 Apr, 2013 1 commit
  17. 04 Apr, 2013 2 commits
  18. 18 Mar, 2013 1 commit
  19. 11 Feb, 2013 1 commit
  20. 25 Jan, 2013 1 commit
    • Takashi Iwai's avatar
      ALSA: Make snd_printd() and snd_printdd() inline · 86b27237
      Takashi Iwai authored
      Because currently snd_printd() and snd_printdd() macros are expanded
      to empty when CONFIG_SND_DEBUG=n, a compile warning like below
      appears sometimes, and we had to covert it by ugly ifdefs:
        sound/pci/hda/patch_sigmatel.c: In function ‘stac92hd71bxx_fixup_hp’:
        sound/pci/hda/patch_sigmatel.c:2434:24: warning: unused variable ‘spec’ [-Wunused-variable]
      For "fixing" these issues better, this patch replaces snd_printd() and
      snd_printdd() definitions with empty inline functions instead of
      macros.  This should have the same effect but shut up warnings like
      But since we had already put ifdefs, changing to inline functions
      would trigger compile errors.  So, such ifdefs is removed in this
      In addition, snd_pci_quirk name field is defined only when
      CONFIG_SND_DEBUG_VERBOSE is set, and the reference to it in
      snd_printdd() argument triggers the build errors, too.  For avoiding
      these errors, introduce a new macro snd_pci_quirk_name() that is
      defined no matter how the debug option is set.
      Reported-by: default avatarStratos Karafotis <stratosk@semaphore.gr>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
  21. 11 Jan, 2013 1 commit
  22. 24 Dec, 2012 1 commit
  23. 04 Dec, 2012 1 commit
    • Eldad Zack's avatar
      ALSA: usb-audio: sync ep init fix for audioformat mismatch · 0d9741c0
      Eldad Zack authored
      Commit 947d2996
       , "ALSA: snd-usb:
      properly initialize the sync endpoint", while correcting the
      initialization of the sync endpoint when opening just the data
      endpoint, prevents devices that has a sync endpoint, with a channel
      number different than that of the data endpoint, from functioning.
      Due to a different channel and period bytes count, attempting to
      initialize the sync endpoint will fail at the usb host driver.
      For example, when using xhci:
       cannot submit urb 0, error -90: internal error
      With this patch, if a sync endpoint has multiple audioformats, a
      matching audioformat is preferred. An audioformat must be found
      with at least one channel and support the requested sample rate
      and PCM format, otherwise the stream will not be opened.
      If the number of channels differ between the selected audioformat
      and the requested format, adjust the period bytes count accordingly.
      It is safe to perform the calculation on the basis of the channel
      count, since the requested PCM audio format and the rate must be
      supported by the selected audioformat.
      Cc: Jeffrey Barish <jeff_barish@earthlink.net>
      Cc: Daniel Mack <zonque@gmail.com>
      Signed-off-by: default avatarEldad Zack <eldad@fogrefinery.com>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
  24. 29 Nov, 2012 1 commit