forked from Minki/linux
3a3d5fd125
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: Hans Schou <linux@schou.dk> Signed-off-by: Dave Dillow <dave@thedillows.org> Signed-off-by: Jaroslav Kysela <perex@perex.cz> |
||
|---|---|---|
| .. | ||
| aoa | ||
| arm | ||
| atmel | ||
| core | ||
| drivers | ||
| i2c | ||
| isa | ||
| mips | ||
| oss | ||
| parisc | ||
| pci | ||
| pcmcia | ||
| ppc | ||
| sh | ||
| soc | ||
| sparc | ||
| spi | ||
| synth | ||
| usb | ||
| ac97_bus.c | ||
| Kconfig | ||
| last.c | ||
| Makefile | ||
| sound_core.c | ||
| sound_firmware.c | ||