Hi Luiz, > This introduces a new socket type BTPROTO_ISO which is used to transfer > ISO packets between userspace and kernel similarly to how BTPROTO_SCO > works. circling back to this now. What is the advantage of using a separate socket instead of the SCO socket type with a proper configured set of socket options. I mean at some we can just rename BTPROTO_SCO into BTPROTO_AUDIO since all the Synchronous and Isochronous naming in the spec is not really helpful. Even if in theory it can be used for other data, it has been in 20+ years only used for audio data. And actually it doesn’t need to be a socket at all. If we figure out a better interface for SCO/eSCO and ISO data when transported over HCI, I am ok with that as well. The fact that we open a SCO socket to establish the underlying transport, but then the data goes somewhere else is also weird to some degree. So I wonder if the audio control part might be better done over mgmt and if we get audio data to transport, we just hand back an fd via mgmt event. This is me just thinking out loud. If the separate ISO socket is in the end the best approach, we can also do it like that, but we should really evaluate the possible direction before we set this API in stone. Regards Marcel
