[alsa-devel] [PATCH 0/2] ALSA: pcm: implement the anonymous dup v3
Jaroslav Kysela
perex at perex.cz
Fri Feb 1 17:28:44 CET 2019
Dne 1.2.2019 v 16:31 Phil Burk napsal(a):
> Thank you all for sorting this out. It seems like we are moving in a
> really good direction.
>
>> I agree. We can have just two modes for the beginning:
>> a) full one (useful for testing)
>> b) buffer only (allow just sound data mmap)
>
> The full one is would also be used by the HAL for querying the DSP position.
>
>> if we should use different names (like anon_inode:snd-pcm and
> anon_inode:snd-pcm-buffer)
>
> That would be helpful.
>
> I have attached a revised requirements doc. The original doc was more of
> a HowTo for OEMs to create the "anon_inode:dmabuf" FD.. This clarifies
> the requirements and allows for the use of "anon_inode:snd-pcm*". It
> should match what we have arrived at by discussion. Let me know if it
> makes sense.
It looks fine, but the HAL will use probably the standard sound device
open (/dev/snd/), doesn't? So:
fd1 - /dev/snd/pcm (HAL) - standard sound device inode (no restrictions)
fd2 - anon_inode:snd-pcm-buffer (for the EXCLUSIVE access)
With modes, I talked about the anonymous dup ioctl parameter. If there's
another resource manager above HAL, the situation might be:
fd1 - /dev/snd/pcm (resource manager) - standard sound device inode
fd2 - anon_inode:snd-pcm (access to the full pcm sound API using the
anonymous inode)
fd3 - anon_inode:snd-pcm-buffer (for the EXCLUSIVE access)
Perhaps you have different layers in Android.
Thanks,
Jaroslav
--
Jaroslav Kysela <perex at perex.cz>
Linux Sound Maintainer; ALSA Project; Red Hat, Inc.
More information about the Alsa-devel
mailing list