[alsa-devel] Adjust volume may cause audio playback corruption

[cee1]

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