Hi,
2012/5/18 cee1 fykcee1@gmail.com:
2012/5/18 cee1 fykcee1@gmail.com:
在 2012年5月18日星期五，Clemens Ladisch 写道：
cee1 wrote:
We've found a way the can reproduce the problem more quickly on our product:
- do audio playback
- alsamixer, select 'Master', press 'm' and hold for a while.
Then release 'm', playback corrupts(sounds similar to http://dev.lemote.com/files/upload/software/PA-apc/corrupted_sound.ogg).
Is the output supposed to be playing or muted at this time?
Playing
Seems something to do with process_rewind(modules/alsa/alsa-sink.c), I tried commenting out snd_pcm_rewind block in process_rewind() and set out_frames=0 or out_frames=in_frames, the problem seems gone.
A bug in snd_pcm_rewind()/driver?
Some questions about rewind :-) 1. When rewind happens, it is possible to go into underrun, right? 2. The hardware doesn't know control->appl_ptr, it will go through a buffer size and then wrap back, go through the buffer again? 3. About substream->ops->pointer, in HDA, it was implemented by position buffer. Is it an atomic operation of update(by HDA controller) /read(by driver)? 4. [alsa-libs] snd_pcm_mmap_commit() -> snd_pcm_hw_mmap_commit(), which will forward pcm->appl.ptr(and wrap back if is bigger than pcm->boundary) and then pass the new appl.ptr to kernel through SNDRV_PCM_IOCTL_SYNC_PTR ioctl. In kernel side, it will assign pcm->appl.ptr to control->appl_ptr directly.
The question is in alsa-libs appl_ptr stays in [0, pcm->boundary), but in kernel side appl_ptr stays in [0, runtime->boundary), will it have problem if pcm->boundary != runtime->boundary? For example, sometimes kernel is 64bits but the userland is 32bits, then the width of 'long' in kernel will not be equal to width of 'long' in userland on some platform.