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