[alsa-devel] [PATCH 3/3] ALSA: pcm: conditionally avoid mmap of control data

Takashi Sakamoto o-takashi at sakamocchi.jp
Tue May 16 08:24:39 CEST 2017


On May 16 2017 15:18, Takashi Iwai wrote:
> On Tue, 16 May 2017 07:57:30 +0200,
> Takashi Sakamoto wrote:
>>
>> On May 16 2017 14:46, Takashi Iwai wrote:
>>> In this case, the problem is that the mmap control allows the appl_ptr
>>> being changed silently without interaction with the driver.  If the
>>> driver requires some explicit action for changing the appl_ptr, it
>>> won't work.
>>
>> I think 'struct snd_pcm_ops.pointer' is available for this purpose, too.
>>
>> static snd_pcm_sframes_t snd_pcm_playback_rewind(...)
>> {
>>     ...
>>     hw_avail = snd_pcm_playback_hw_avail(runtime);
>>     (->struct snd_pcm_ops.pointer())
>>     ...
>>     (rewind PCM frames)
>>     ...
>> +   substream->ops->pointer(...);
>>     (->struct snd_pcm_ops.pointer())
>>     ...
>> }
>>
>> If drivers need to handle event to update the appl_ptr, it records
>> value of the appl_ptr, then compare it to current value to get the
>> updates.
>
> IIRC, the problem isn't about the forward / rewind but about the
> normal data transfer.  In mmap mode, we transfer data on the mmap
> buffer, and update appl_ptr via mmap control.  Both are done without
> notification to the driver (which is intentional for avoiding the
> context switching).
>
> So we want to disable this optimization and always notify to the
> driver.  Disabling mmap status/control is the straight hack as it
> falls back to ioctl and then the driver can know the change.

There's SNDRV_PCM_IOCTL_HW_SYNC command. In kernel land implementation, 
this command is handled with a call of 'struct snd_pcm_ops.pointer'.

In alsa-lib, this command is often executed in most cases to handle PCM 
frames.


Regards

Takashi Sakamoto


More information about the Alsa-devel mailing list