Hi, 2012/5/18 cee1 <fykcee1 at gmail.com>: > 2012/5/18 cee1 <fykcee1 at gmail.com>: >> ? 2012?5?18?????Clemens Ladisch ??? >> >>> cee1 wrote: >>> > We've found a way the can reproduce the problem more quickly on our >>> > product: >>> > 1. do audio playback >>> > 2. 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. -- Regards, - cee1
