Skip to content

L
linux
Switch branch/tag
  1. 29 Jul, 2010 2 commits
  3. 28 Jul, 2010 1 commit
  5. 27 Jul, 2010 1 commit
  7. 26 Jul, 2010 2 commits
  9. 21 Jul, 2010 1 commit
  11. 20 Jul, 2010 1 commit
  13. 19 Jul, 2010 5 commits
  15. 16 Jul, 2010 4 commits
  17. 15 Jul, 2010 1 commit
  19. 14 Jul, 2010 1 commit
  21. 12 Jul, 2010 3 commits
  23. 09 Jul, 2010 1 commit
  25. 08 Jul, 2010 1 commit
  27. 06 Jul, 2010 6 commits
  29. 05 Jul, 2010 2 commits
  31. 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 <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
  33. 24 Jun, 2010 1 commit
  35. 23 Jun, 2010 4 commits
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7