[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