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?
>
> Here are the final documentation and a very basic implementation, note
> that to compile it needs dbus 1.3 (@Marcel: What about making it a
> hard dependency?), other remarks:
lets do it the same way we do within oFono for HFP.
#ifndef DBUS_TYPE_UNIX_FD
#define DBUS_TYPE_UNIX_FD -1
#endif
if (media.enabled == TRUE) {
if (DBUS_TYPE_UNIX_FD < 0)
error("missing fd support");
else
register_driver...
}
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
