This project is mirrored from Pull mirroring updated .
  1. 19 Jul, 2010 2 commits
  2. 28 Jun, 2010 3 commits
    • David Dillow's avatar
      sis7019: increase reset delays · 08b45098
      David Dillow authored
      A few boards using this controller are reported to need a little extra
      time during their reset cycle.
      Reported-by: default avatarMichael Goeke <>
      Signed-off-by: default avatarDave Dillow <>
      Signed-off-by: default avatarJaroslav Kysela <>
    • David Dillow's avatar
      sis7019: fix capture issues with multiple periods per buffer · 3a3d5fd1
      David Dillow authored
      When using a timing voice to clock out periods during capture, the
      driver would slowly loose synchronization and never catch up, eventually
      reaching a point where it no longer generated interrupts. To avoid
      this situation, the virtual period clocking was changed to shorten the
      next timing period when our timing voice falls too far behind the
      capture voice. In addition, the first virtual period for the timing
      voice was slightly too short, causing the timing voice to initially be
      ahead of the capture voice.
      While tracking down this problem, I noticed that the expected sample
      offset was being incorrectly initialized, causing an overrun to be
      incorrectly reported when the timing voice happened to be perfectly
      Reported-by: default avatarHans Schou <>
      Signed-off-by: default avatarDave Dillow <>
      Signed-off-by: default avatarJaroslav Kysela <>
    • David Dillow's avatar
      ALSA: pcm_lib: avoid timing jitter in snd_pcm_read/write() · 5daeba34
      David Dillow authored
      When using poll() to wait for the next period -- or avail_min samples --
      one gets a consistent delay for each system call that is usually just a
      little short of the selected period time. However, When using
      snd_pcm_read/write(), one gets a jittery delay that alternates between
      less than a millisecond and approximately two period times. This is
      caused by snd_pcm_lib_{read,write}1() transferring any available samples
      to the user's buffer and adjusting the application pointer prior to
      sleeping to the end of the current period. When the next period
      interrupt occurs, there is then less than avail_min samples remaining to
      be transferred in the period, so we end up sleeping until a second
      period occurs.
      This is solved by using runtime->twake as the number of samples needed
      for a wakeup in addition to selecting the proper wait queue to wake in
      snd_pcm_update_state(). This requires twake to be non-zero when used
      by snd_pcm_lib_{read,write}1() even if avail_min is zero.
      Signed-off-by: default avatarDave Dillow <>
      Signed-off-by: default avatarJaroslav Kysela <>
  3. 02 Jun, 2010 1 commit
  4. 01 Jun, 2010 22 commits
  5. 31 May, 2010 7 commits
  6. 30 May, 2010 5 commits