[pulseaudio-discuss] Summary of the PulseAudio/Bluetooth discussions at the BlueZ meeting in Helsinki

[Colin Guthrie]

Lennart Poettering wrote:
> The latter, m-bt-device, then connects to the BlueZ audio service via one
> BlueZ specific well known unix socket, configures a connection to the
> BT device, gets a BT socket fd passed in via the unix socket and then
> hands this over to its RT thread. The code for this would actually be
> very similar to module-esd-sink which we ship already. m-esd-s is a
> sink for PA that hands data to an existing EsounD server. It's basic
> structure is very similar: we first configure the ESD connection from
> the main thread via exchanging a few simple packets and then hand the
> actual communication socket to the RT thread for the actual work. The
> big difference in logic is mostly that the BT module needs to encode
> the audio data to SBC/SCO first, while the ESD module just spits raw
> PCM to the TCP stream. And then, the timing needs to be implemented
> differently. 

This sounds quite similar to the RAOP stuff too in that unlike ESD on 
which it is based, it has to do the stupid encryption stuff before 
spitting it out. If there is a kind of standard structure defined for 
doing this encoding I'll try to keep the raop sink in fitting with that.

> Eventually the btaudio unix socket should also be used to pass the key
> events from the bt head set. I'd need to add a simple subsystem to
> pass them on to the application then. Those keypresses would then be
> passed to the application inline via the audio API. On one hand I see
> that it would be good send the key events inline to make clear to
> which audio device they belong. OTOH I have a bad feeling about this
> because I don't want to add yet another key event subsystem, in
> addtion to XIE, the linux input stuff and even HAL. We need to think
> about this a bit more. (It is interesting to note, that having the
> sound server forward "pause" and "resume" request to applications is
> on the todo list anyway, to allow policy modules to request music
> playback stopping on imcoming phone calls and suchlike. So doing the
> full "audio key" set of keypresses would be a simple extension of
> that.)

Again interesting to me. I've not looked into it fully as I've not 
really learnt all that much about the airtunes device's capabilities 
other than just implementing the audio output support. But I think I saw 
an IR sensor in the thing and presume that it can pass play/pause events 
to the client (I'm sure I've seen a relevant option in iTunes prefs 
too). Whatever subsystem is created here for BT, I can presumably 
implement for RAOP too too. Neato!

Col