1. 23 Apr, 2023 3 commits
  2. 22 Apr, 2023 15 commits
  3. 21 Apr, 2023 4 commits
  4. 19 Apr, 2023 2 commits
  5. 18 Apr, 2023 1 commit
  6. 11 Apr, 2023 1 commit
  7. 08 Apr, 2023 1 commit
    • Oswald Buddenhagen's avatar
      ALSA: pcm: fix wait_time calculations · 3ed2b549
      Oswald Buddenhagen authored
      ... in wait_for_avail() and snd_pcm_drain().
      
      t was calculated in seconds, so it would be pretty much always zero, to
      be subsequently de-facto ignored due to being max(t, 10)'d. And then it
      (i.e., 10) would be treated as secs, which doesn't seem right.
      
      However, fixing it to properly calculate msecs would potentially cause
      timeouts when using twice the period size for the default timeout (which
      seems reasonable to me), so instead use the buffer size plus 10 percent
      to be on the safe side ... but that still seems insufficient, presumably
      because the hardware typically needs a moment to fire up. To compensate
      for this, we up the minimal timeout to 100ms, which is still two orders
      of magnitude less than the bogus minimum.
      
      substream->wait_time was also misinterpreted as jiffies, despite being
      documented as being in msecs. Only the soc/sof driver sets it - to 500,
      which looks very much like msecs were intended.
      
      Speaking of which, shouldn't snd_pcm_drain() also use substream->
      wait_time?
      
      As a drive-by, make the debug messages on timeout less confusing.
      Signed-off-by: default avatarOswald Buddenhagen <oswald.buddenhagen@gmx.de>
      Link: https://lore.kernel.org/r/20230405201219.2197774-1-oswald.buddenhagen@gmx.deSigned-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      3ed2b549
  8. 06 Apr, 2023 3 commits
  9. 30 Mar, 2023 1 commit
  10. 29 Mar, 2023 8 commits
  11. 24 Mar, 2023 1 commit