1. 09 6月, 2015 1 次提交
  2. 19 5月, 2015 2 次提交
  3. 28 4月, 2015 1 次提交
  4. 22 3月, 2015 1 次提交
  5. 21 3月, 2015 1 次提交
  6. 21 2月, 2015 1 次提交
    • P
      ALSA: core: selection of audio_tstamp type and accuracy reports · 229d0430
      Pierre-Louis Bossart 提交于
      Audio timestamps can be extracted from sample counters, wall clocks,
      PHC clocks (Ethernet AVB), on-demand synchronized snapshots. This
      patch provides the ability to report timestamping capabilities, select
      timestamp types and retrieve timestamp accuracy, if supported.
      Details can be found in Documentations/sound/alsa/timestamping.txt
      
      This functionality is introduced by reclaiming the reserved_aligned
      field introduced by commit9c7066ae
      in snd_pcm_status to provide userspace with selection/query capabilities.
      Additional driver_tstamp and audio_tstamp_accuracy fields are also added.
      
      snd_pcm_mmap_status remains a read-only structure with only
      the audio timestamp value accessible from user space. The selection
      of audio timestamp type is done through snd_pcm_status only
      
      This commit does not impact ABI and does not impact the default
      behavior. By default audio timestamp is aligned with hw_pointer and
      reports the DMA position. Backwards compatibility is handled by using
      the HDAudio wall clock for playback and the hw_ptr for all other
      cases.
      
      For timestamp selection a new STATUS_EXT ioctl is introduced with
      read/write parameters. Alsa-lib will be modified to make use of
      STATUS_EXT.
      Signed-off-by: NPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      229d0430
  7. 10 12月, 2014 1 次提交
  8. 04 11月, 2014 2 次提交
    • T
      ALSA: pcm: Add xrun_injection proc entry · 2b30d411
      Takashi Iwai 提交于
      This patch adds a new proc entry for PCM substreams to inject an
      XRUN.  When a PCM substream is running and any value is written to its
      xrun_injection proc file, the driver triggers XRUN.  This is a useful
      feature for debugging XRUN and error handling code paths.
      
      Note that this entry is enabled only when CONFIG_SND_PCM_XRUN_DEBUG is
      set.
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      2b30d411
    • T
      ALSA: pcm: Replace PCM hwptr tracking with tracepoints · f5914908
      Takashi Iwai 提交于
      ALSA PCM core has a mechanism tracking the PCM hwptr updates for
      analyzing XRUNs.  But its log is limited (up to 10) and its log output
      is a kernel message, which is hard to handle.
      
      In this patch, the hwptr logging is moved to the tracing
      infrastructure instead of its own.  Not only the hwptr updates but
      also XRUN and hwptr errors are recorded on the trace log, so that user
      can see such events at the exact timing.
      
      The new "snd_pcm" entry will appear in the tracing events:
        # ls -F /sys/kernel/debug/tracing/events/snd_pcm
        enable  filter  hw_ptr_error/  hwptr/  xrun/
      
      The hwptr is for the regular hwptr update events.  An event trace
      looks like:
      
        aplay-26187 [004] d..3  4012.834761: hwptr: pcmC0D0p/sub0: POS: pos=488, old=0, base=0, period=1024, buf=16384
      
      "POS" shows the hwptr update by the explicit position update call and
      "IRQ" means the hwptr update by the interrupt,
      i.e. snd_pcm_period_elapsed() call.  The "pos" is the passed
      ring-buffer offset by the caller, "old" is the previous hwptr, "base"
      is the hwptr base position, "period" and "buf" are period- and
      buffer-size of the target PCM substream.
      (Note that the hwptr position displayed here isn't the ring-buffer
       offset.  It increments up to the PCM position boundary.)
      
      The XRUN event appears similarly, but without "pos" field.
      The hwptr error events appear with the PCM identifier and its reason
      string, such as "Lost interrupt?".
      
      The XRUN and hwptr error reports on kernel message are still left, can
      be turned on/off via xrun_debug proc like before.  But the bit 3, 4, 5
      and 6 bits of xrun_debug proc are dropped by this patch.  Also, along
      with the change, the message strings have been reformatted to be a bit
      more consistent.
      
      Last but not least, the hwptr reporting is enabled only when
      CONFIG_SND_PCM_XRUN_DEBUG is set.
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      f5914908
  9. 20 10月, 2014 1 次提交
  10. 04 8月, 2014 1 次提交
  11. 15 7月, 2014 1 次提交
  12. 25 6月, 2014 1 次提交
    • T
      ALSA: hda - Adjust speaker HPF and add LED support for HP Spectre 13 · 8b3dfdaf
      Takashi Iwai 提交于
      HP Spectre 13 has the IDT 92HD95 codec, and BIOS seems to set the
      default high-pass filter in some "safer" range, which results in the
      very soft tone from the built-in speakers in contrast to Windows.
      Also, the mute LED control is missing, since 92HD95 codec still has no
      HP-specific fixups for GPIO setups.
      
      This patch adds these missing features: the HPF is adjusted by the
      vendor-specific verb, and the LED is set up from a DMI string (but
      with the default polarity = 0 assumption due to the incomplete BIOS on
      the given machine).
      
      Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=74841
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      8b3dfdaf
  13. 05 5月, 2014 1 次提交
  14. 28 2月, 2014 1 次提交
  15. 08 1月, 2014 1 次提交
  16. 29 10月, 2013 1 次提交
  17. 11 10月, 2013 1 次提交
  18. 27 9月, 2013 1 次提交
  19. 23 9月, 2013 5 次提交
  20. 27 8月, 2013 1 次提交
  21. 20 8月, 2013 1 次提交
  22. 29 7月, 2013 2 次提交
    • T
      ALSA: hda - Fix invalid multi-io creation on VAIO-Z laptops · da96fb5b
      Takashi Iwai 提交于
      VAIO-Z laptops need to use the specific DAC for the speaker output
      by some unknown reason although the codec itself supports the flexible
      connection.  So we implemented a workaround by a new flag,
      no_primary_hp, for assigning the speaker pin first.
      
      This worked until 3.8 kernel, but it got broken because the driver
      learned for a better multi-io pin mapping, and not it can assign two
      mic pins for multi-io.  Since the multi-io requires to be the primary
      output, the hp and two mic pins are assigned in prior to the speaker
      in the end.
      
      Although the machine has two mic pins, one of them is used as a noise-
      canceling headphone, thus it's no real retaskable mic jack.  Thus, at
      best, we can disable the multi-io assignment and make the parser
      behavior back to the state before the multi-io.
      
      This patch adds again a new flag, no_multi_io, to indicate that the
      device has no multi-io capability, and set it in the fixup for
      VAIO-Z.  The no_multi_io flag itself can be used generically, added
      via a helper line, too.
      Reported-by: NTormen <my.nl.abos@gmail.com>
      Reported-by: NAdam Williamson <awilliam@redhat.com>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      da96fb5b
    • T
      ALSA: hda - Remove analog mic pin override from STAC9228 dell-bios quirk · eefb8be4
      Takashi Iwai 提交于
      The current fixup for dell-bios model with STAC9228 codec contains the
      override of pin 0x0c for analog mic.  But this is actually just adding
      a bogus pin and confuses the parser.  Better to remove it for the
      auto-mic switching.
      
      Meanwhile, for a possible regression, keep the old configuration as
      model=dell-bios-amic, so that people can test it again quickly.
      
      Tested on Dell 1420n laptop.
      Reported-and-tested-by: NEric Shattow <lucent@gmail.com>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      eefb8be4
  23. 25 7月, 2013 1 次提交
  24. 17 6月, 2013 2 次提交
  25. 04 4月, 2013 1 次提交
    • T
      Revert "ALSA: hda - Allow power_save_controller option override DCAPS" · 8fc24426
      Takashi Iwai 提交于
      This reverts commit 6ab31741.
      
      The commit [6ab31741: ALSA: hda - Allow power_save_controller option
      override DCAPS] changed the behavior of power_save_controller so that
      it can override the driver capability.  This assumed that this option
      is rarely changed dynamically unlike power_save option.  Too naive.
      
      It turned out that the user-space power-management tool tries to set
      power_save_controller option to 1 together with power_save option
      without knowing what's actually doing.  This enabled forcibly the
      runtime PM of the controller,  which is known to be broken om many
      chips thus disabled as default.
      
      So, the only sane fix is to revert this commit again.  It was intended
      to ease debugging/testing for runtime PM enablement, but obviously we
      need another way for it.
      
      Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=56171Reported-and-tested-by: NNikita Tsukanov <keks9n@gmail.com>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      8fc24426
  26. 17 3月, 2013 1 次提交
  27. 08 3月, 2013 2 次提交
  28. 14 2月, 2013 1 次提交
  29. 12 2月, 2013 1 次提交
  30. 29 1月, 2013 1 次提交
  31. 09 1月, 2013 1 次提交