[pulseaudio-discuss] [PATCH 0/2] Bluetooth A2DP Source module

[Lennart Poettering]

On Mon, 17.08.09 09:36, Zheng, Huan (huan.zheng at intel.com) wrote:

> Hi, Lennart
> I think it will be good if PA could have sink/source direct connection.
> 
> >One question though: what about support for HSP/HFP? Would it even
> >make sense to make PA behave like a headset to other devices?

> On some platforms, such as a vehicle platform which has a Pulseaudio
> inside, it may want to behave like a headset. It wants to capture
> from BT HSP source (data coming from a real phone) and play it to
> its local speaker (ALSA sink), and capture from ALSA source and play
> it to BT HSP sink (data goes to a real phone).
> 
> To achieve the above goal, direct sink/source connection is needed, and PA's ability to auto detect a phone of capability "audio gateway" may also needed. 
> 
> I actually tried to use PA as a headset role with a NOKIA phone before, 
> I wanted to make the below happen, but there's no direct sink/source connection, 
> Far end voice --> Phone HSP --> PA HSP SRC --> PA ALSA SINK
> PA ALSA SRC --> PA HSP SINK --> Phone HSP --> Far end
> So, what I actually achieved is:
> Far end voice --> Phone HSP --> PA HSP SRC --> Local file
> Local playback --> PA HSP SINK --> Phone HSP --> Far end
> And the above audio path works.

Hmm, does that mean you implemented the AT command interpreter for
this? Is that code available? Will this be avilable in Bluez?

> Conclusion is: Without direct sink/source connection, we may need a daemon which to do a fake sink/source connection. But if direct sink/source connection is implemented inside PA, it will be very useful. :)

Hmm, the HSP/HFP case might actually be a bit simpler than the A2DP
case. Because when we act as HSP/HFP headset we can freely choose the
timing, we have full control of it in contrast to A2DP where the
sender decides everything. So in this case I'd not make this available
as a sink and a source pair, but instead as two streams. That way we
simply use the clock of the underlying ALSA devices for
sending/recving the audio data. I think this would even be more
natural in this case, and not require direct sink/source connections.

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/           GnuPG 0x1A015CC4