Skip to content
  1. Aug 04, 2010
  3. Aug 02, 2010
  5. Jul 29, 2010
  7. Jul 28, 2010
  9. Jul 27, 2010
  11. Jul 26, 2010
  13. Jul 21, 2010
  15. Jul 20, 2010
  17. Jul 19, 2010
  19. Jul 16, 2010
  21. Jul 15, 2010
  23. Jul 14, 2010
  25. Jul 13, 2010
  27. Jul 12, 2010
  29. Jul 09, 2010
  31. Jul 08, 2010
  33. Jul 06, 2010
  35. Jul 05, 2010
  37. Jun 28, 2010
    • 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 <michael.goeke@icachip.de>
Signed-off-by: default avatarDave Dillow <dave@thedillows.org>
Signed-off-by: default avatarJaroslav Kysela <perex@perex.cz>
      08b45098
    • 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
synchronized.

Reported-by: default avatarHans Schou <linux@schou.dk>
Signed-off-by: default avatarDave Dillow <dave@thedillows.org>
Signed-off-by: default avatarJaroslav Kysela <perex@perex.cz>
      3a3d5fd1
    • 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 <dave@thedillows.org>
Signed-off-by: default avatarJaroslav Kysela <perex@perex.cz>
      5daeba34