1. 15 Dec, 2015 4 commits
  2. 14 Dec, 2015 2 commits
    • Anssi Hannula's avatar
      ALSA: usb-audio: Add sample rate inquiry quirk for AudioQuest DragonFly · 12a6116e
      Anssi Hannula authored
      Avoid getting sample rate on AudioQuest DragonFly as it is unsupported
      and causes noisy "cannot get freq at ep 0x1" messages when playback
      Signed-off-by: default avatarAnssi Hannula <anssi.hannula@iki.fi>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
    • Anssi Hannula's avatar
      ALSA: usb-audio: Add a more accurate volume quirk for AudioQuest DragonFly · 42e3121d
      Anssi Hannula authored
      AudioQuest DragonFly DAC reports a volume control range of 0..50
      (0x0000..0x0032) which in USB Audio means a range of 0 .. 0.2dB, which
      is obviously incorrect and would cause software using the dB information
      in e.g. volume sliders to have a massive volume difference in 100..102%
      Commit 2d1cb7f6 ("ALSA: usb-audio: add dB range mapping for some
      devices") added a dB range mapping for it with range 0..50 dB.
      However, the actual volume mapping seems to be neither linear volume nor
      linear dB scale, but instead quite close to the cubic mapping e.g.
      alsamixer uses, with a range of approx. -53...0 dB.
      Replace the previous quirk with a custom dB mapping based on some basic
      output measurements, using a 10-item range TLV (which will still fit in
      alsa-lib MAX_TLV_RANGE_SIZE).
      Tested on AudioQuest DragonFly HW v1.2. The quirk is only applied if the
      range is 0..50, so if this gets fixed/changed in later HW revisions it
      will no longer be applied.
      v2: incorporated Takashi Iwai's suggestion for the quirk application
      Signed-off-by: default avatarAnssi Hannula <anssi.hannula@iki.fi>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
  3. 09 Dec, 2015 2 commits
  4. 07 Dec, 2015 3 commits
  5. 04 Dec, 2015 1 commit
    • Takashi Iwai's avatar
      ALSA: rme96: Fix unexpected volume reset after rate changes · a74a8216
      Takashi Iwai authored
      rme96 driver needs to reset DAC depending on the sample rate, and this
      results in resetting to the max volume suddenly.  It's because of the
      missing call of snd_rme96_apply_dac_volume().
      However, calling this function right after the DAC reset still may not
      work, and we need some delay before this call.  Since the DAC reset
      and the procedure after that are performed in the spinlock, we delay
      the DAC volume restore at the end after the spinlock.
      Reported-and-tested-by: default avatarSylvain LABOISNE <maeda1@free.fr>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
  6. 30 Nov, 2015 2 commits
  7. 27 Nov, 2015 1 commit
    • Takashi Iwai's avatar
      ALSA: hda - Skip ELD notification during system suspend · 8ae743e8
      Takashi Iwai authored
      The recent addition of ELD notifier for Intel HDMI/DP codec may lead
      the bad codec connection found as kernel messages like below:
       Suspending console(s) (use no_console_suspend to debug)
       hdmi_present_sense: snd_hda_codec_hdmi hdaudioC0D2: HDMI status: Codec=2 Pin=6 Presence_Detect=1 ELD_Valid=1
       snd_hda_intel 0000:00:1f.3: spurious response 0x0:0x2, last cmd=0x206f2e08
       snd_hda_intel 0000:00:1f.3: spurious response 0x0:0x2, last cmd=0x206f2e08
        snd_hda_codec_hdmi hdaudioC0D2: HDMI: ELD buf size is 0, force 128
        snd_hda_intel 0000:00:1f.3: azx_get_response timeout, switching to polling mode: last cmd=0x206f2f00
       snd_hda_intel 0000:00:1f.3: No response from codec, disabling MSI: last cmd=0x206f2f00
       snd_hda_intel 0000:00:1f.3: azx_get_response timeout, switching to single_cmd mode: last cmd=0x206f2f00
       azx_single_wait_for_response: 42 callbacks suppressed
      This seems appearing when the sound driver went to suspend before i915
      driver.  Then i915 driver disables HDMI/DP audio bit and calls the
      registered notifier, and the HDA codec tries to handle it as a
      hot(un)plug.  But since the driver is already in the suspended state,
      it fails miserably.
      As this is a sort of spurious wakeup, it can be ignored safely, as
      long as it's delivered during the system suspend.  OTOH, if a
      notification comes during the runtime suspend, the situation is
      different: we need to wake up.  But during the system suspend, such a
      notification can't be the reason for a wakeup.
      This patch addresses it by a simple check of the current sound card
      status.  The skipped notification doesn't matter because the HDA
      driver will check the plugged status forcibly at the resume in
      Then, why the card status, not a runtime PM status or else?  The HDA
      controller driver is supposed to set the card status to D3 at the
      system suspend but not at the runtime suspend.  So we can see it as a
      flag that is set only for the system suspend.  Admittedly, it's a bit
      ugly, but it should work well for now.
      Reported-and-tested-by: default avatar"Zhang, Xiong Y" <xiong.y.zhang@intel.com>
      Fixes: 25adc137 ('ALSA: hda - Wake the codec up on pin/ELD notify events')
      Cc: <stable@vger.kernel.org> # v4.3+
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
  8. 25 Nov, 2015 5 commits
  9. 24 Nov, 2015 1 commit
  10. 23 Nov, 2015 3 commits
  11. 20 Nov, 2015 3 commits
  12. 19 Nov, 2015 6 commits
  13. 18 Nov, 2015 2 commits
  14. 17 Nov, 2015 1 commit
  15. 16 Nov, 2015 4 commits