Hi Luiz, > The idea is to complete replace the existing audio IPC with DBus. > Johan and I discussed this a few times in the past and today we > finally archive something, so here are some design choices so far: > > 1. Codec capabilities and configuration are blobs (array of bytes or > 'ay'), so there is no attempt to format codec structures into dbus > structures, this make it easier for both end points as well as > bluetoothd and also enables proprietary codecs. (suggested by Marcel > in the last BlueZ meeting) > > 2. The spec is not a2dp specific. So it should be possible to register > end points for HFP and VDP. if you really wanna achieve that, then I would prefer not to use StreamEndPoint as interface. So first of all it should be StreamEndpoint. While SEP takes the P into account, the word "endpoint" in itself is proper enough. And if this should support HFP, then the term Stream is kinda tricky. We could just allow that, but I prefer not to mix streaming with headset functionality. So what about just using the "Endpoint" as a generic agent type interface. Or "MediaEndpoint" if you need to tie it to the media interface? Regards Marcel -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html