Skip to content

L
linux
Switch branch/tag
  1. 09 Jul, 2020 5 commits
    • Mark Hills's avatar
      ALSA: echoaudio: Address bugs in the interrupt handling · a0b224b9
      Mark Hills authored 
      Distorted audio appears occasionally, affecting either playback or
capture and requiring the affected substream to be closed by all
applications and re-opened.

The best way I have found to reproduce the bug is to use dmix in
combination with Chromium, which opens the audio device multiple times
in threads. Anecdotally, the problems appear to have increased with
faster CPUs. I ruled out 32-bit counter wrapping; it often happens
much earlier.

Since applying this patch I have not had problems, where previously
they would occur several times a day.

The patch targets the following issues:

* Check for progress using the counter from the hardware, not after it
  has been truncated to the buffer.

  This is a clean way to address a possible bug where if a whole
  ringbuffer advances between interrupts, it goes unnoticed.

* Move last_period state from chip to pipe

  This more logically belongs as part of pipe, and code is reasier to
  read if it is "counter position last time a period elapsed".

  Now the code has no references to period count. A period is just
  when the regular counter crosses a threshold. This increases
  readability and reduces scope for bugs.

* Treat period notification and buffer advance independently:

  This helps to clarify what is the responsibility of the interrupt
  handler, and what is pcm_pointer().

  Removing shared state between these operations means race conditions
  are fixed without introducing locks. Synchronisation is only around
  the read of pipe->dma_counter. There may be cache line contention
  around "struct audiopipe" but I did not have cause to profile this.

Pay attention to be robust where dma_counter wrapping is not a
multiple of period_size or buffer_size.

This is a revised patch based on feedback from Takashi and Giuliano.
Signed-off-by: default avatarMark Hills <mark@xwax.org>
Link: https://lore.kernel.org/r/20200708101848.3457-5-mark@xwax.orgSigned-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      a0b224b9
    • Mark Hills's avatar
      ALSA: echoaudio: Prevent some noise on unloading the module · f688a0df
      Mark Hills authored 
      These are valid conditions in normal circumstances, so do not "warn" but
make them for debugging.
Signed-off-by: default avatarMark Hills <mark@xwax.org>
Link: https://lore.kernel.org/r/20200708101848.3457-4-mark@xwax.orgSigned-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      f688a0df
    • Mark Hills's avatar
      ALSA: echoaudio: Prevent races in calls to set_audio_format() · 6c331254
      Mark Hills authored 
      The function uses chip->comm_page which needs locking against
other use at the same time.
Signed-off-by: default avatarMark Hills <mark@xwax.org>
Link: https://lore.kernel.org/r/20200708101848.3457-3-mark@xwax.orgSigned-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      6c331254
    • Mark Hills's avatar
      ALSA: echoaudio: Race conditions around "opencount" · 027c7002
      Mark Hills authored 
      Use of atomics does not make these statements robust:

       atomic_inc(&chip->opencount);
       if (atomic_read(&chip->opencount) > 1 && chip->rate_set)
               chip->can_set_rate=0;

and

       if (atomic_read(&chip->opencount)) {
               if (chip->opencount) {
                       changed = -EAGAIN;
               } else {
                       changed = set_digital_mode(chip, dmode);

It would be necessary to atomically increment or decrement the value
and use the returned result. And yet we still need to prevent other
threads making use of "can_set_rate" while we set it.

However in all but one case the atomic is misleading as they are already
running with "mode_mutex" held.

Decisions are made on mode setting are often intrinsically connected
to "opencount" because some operations are not permitted unless
there is sole ownership.

So instead simplify this, and use "mode_mutex" as a lock for all reference
counting and mode setting.
Signed-off-by: default avatarMark Hills <mark@xwax.org>
Link: https://lore.kernel.org/r/20200708101848.3457-2-mark@xwax.orgSigned-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      027c7002
    • Mark Hills's avatar
      ALSA: echoaudio: Remove redundant check · db091b0e
      Mark Hills authored 
      This check is always false, as it's not the responsibilty of the
device-specific code to make this check. It is already checked
in snd_echo_digital_mode_put.

I do not have a Mona interface to test this change.

This patch is in preparation for follow-up patch to modify the
behavior of "opencount".
Signed-off-by: default avatarMark Hills <mark@xwax.org>
Link: https://lore.kernel.org/r/20200708101848.3457-1-mark@xwax.orgSigned-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      db091b0e
  3. 08 Jul, 2020 1 commit
  5. 07 Jul, 2020 28 commits
  7. 30 Jun, 2020 1 commit
  9. 25 Jun, 2020 1 commit
  11. 19 Jun, 2020 2 commits
    • Takashi Iwai's avatar
      Merge branch 'topic/hda-micmute-led' into for-next · c7440acc
      Takashi Iwai authored 
      This is a patch set inspired by the recent patch Kai-Heng posted about
the HD-audio mic-mute LED control.  Currently HD-audio driver deals
with the mute and mic-mute LED in several different ways: primarily
with the direct callback of vmaster hook and capture sync hook, while
another with the LED class device binding.  The latter has been used
for binding with the platform device LEDs like Thinkpad, Dell,
Huawei.  And, yet, recently we added our own LED classdev for the
mic-mute LED on some HP systems although they are controlled directly
with the callback; it's exposed, however, for the DMIC that is
governed by a different ASoC driver.

This patch set is an attempt to sort out and make them consistent:
namely,
* All LEDs are now controlled via LED class device
* The generic driver provides helper functions to easily build up the
  LED class dev and the relevant mixer controls
* Conversion of the existing framework and clean ups

The patches are lightly tested in my side with a couple of machines
and also through hda-emu tests.  Some devices receive new kcontrols
for the mute LED behavior (that have been missing so far), but
anything else look good though my tests.

Link: https://lore.kernel.org/r/20200618110842.27238-1-tiwai@suse.deSigned-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      c7440acc
    • Takashi Iwai's avatar
      ALSA: hda: Enable sync-write operation as default for all controllers · f34a4c9d
      Takashi Iwai authored 
      In the end we already enabled the sync-write mode for most of HD-audio
controllers including Intel, and it's no big merit to keep the async
write mode for the rest.  Let's make it as default and drop the
superfluous AZX_DCAPS_SYNC_WRITE bit flag.

Also, avoid to set the allow_bus_reset flag, which is a quite unstable
and hackish behavior that was needed only for some early platforms
(decades ago).  The straight fallback to the single cmd mode is more
robust.

Link: https://lore.kernel.org/r/20200618144051.7415-1-tiwai@suse.deSigned-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      f34a4c9d
  13. 18 Jun, 2020 2 commits
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7