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@xxxxxxxx> Linux Sound Maintainer; ALSA Project; Red Hat, Inc. _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
