[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