Hello Mikel,
On 05/07/2012 16:21, Mikel Astiz wrote:
<snip>
+Interaction with the audio component (i.e. PulseAudio) will be done through the
+MediaTransport object (passed to telephony agent during NewConnection call).
This is where the interesting part begins: how exactly are you
planning to do this?
Perhaps I'm missing something but I see no relation between Media
transport and telephony agent in your patchset. It seems this part of
the documentation is inconsistent with the code.
The Bluez MediaTransport will act as central point for messages related
to audio.
e.g. for volume management, PulseAudio or oFono will call SetProperty
method of MediaTransport which will send a property changed signal.
This behavior is implemented through existing MediaTransport signals and
patch 8.
I don't understand your original motivation to do this, but from my
point of view, something similar would actually be interesting to
propagate call-states (HFP) from oFono to PulseAudio. This information
can later be useful for audio routing policies in PulseAudio.
IMO, component implementing audio routing policy should listen oFono
state changes directly.
On call, it may have to stop current audio playback then route audio:
- from telephony chipset to speaker if there is no HFP connection
- or from telephony chipset to bluetooth device if a HFP endpoint exists
I do not think this needs to pass through BlueZ.
That being said, I'm not sure if the Telephony API is the proper way
to address this.
Regards
Fred
--
Frederic Danis Open Source Technology Center
frederic.danis@xxxxxxxxx Intel Corporation
--
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
