create an alsa state file that routes system audio to bluetooth

[bmidgley@…]

Currently there is no way to route audio from a voip client for example to a
bluetooth headset. There is only a gsmbluetooth.state for using the gsm audio
with bluetooth.

[stefan@…]

​http://svn.openmoko.org/trunk/oe/packages/alsa/files/

Shows our currently deployed alsa state files. Besides the missing system -> bt
profile there are some more file in the DM2 dir of the P1 developer phones.

The loopback profiles don't make to much sense, but the play_wav_* could be
added to our standard alsa profile deploy. I'll add the files to this bug.

[stefan@…]

loopback_earphone.state

[stefan@…]

loopback_receiver.state

[stefan@…]

loopback_receiver_MIC2.state

[stefan@…]

loopback_speaker.state

[stefan@…]

play_wav_earphone.state

[stefan@…]

play_wav_receiver.state

[stefan@…]

play_wav_speaker.state

[laforge@…]

adding graeme and marcel (maybe they can coordinate on providing the
asound.state for bluetooth headset audio)

[graeme@…]

I either misunderstand this bug or I think you are looking at the wrong path for
audio. There is no reason to send audio via codec from CPU->codec->bluetooth.
CPU->bluetooth works and uses less power.

[graeme@…]

btsco in OE BTW

[marcel@…]

For the Bluetooth headset support we never route the SCO audio data to userspace
at all. They go from the Bluetooth chip's PCM directly to the GSM module or in
some cases to the microphone/speaker.

[graeme@…]

Does this mean that you are requiring that all bluetooth audio goes via the
codec or that it is just not a case that is handled yet. The setup of the codec
is quite complex and we will have to power up quite a few parts of it. I would
have thought sending audio via USB (which is already powered) to bluetooth would
be economic solution power wise.

[graeme@…]

Have double and triple checked the datasheet and the wm8753 cannot do full
duplex audio in this fashion. It was designed for the BT->digital->analog->GSM
path, allowing the applications CPU to sleep.

[marcel@…]

Going through the HCI interface of the Bluetooth USB driver consumes probably
even more power. The SCO frames are using USB ISOC URBs for transmission. These
produce a big overhead. This would mean that the USB bus would have to really
busy. For the headset use case for example the number of control, interrupt and
bulk URBs is very small.

The other thing is latency since we have to do a lot copy to get the audio data
from one daemon into the other one. For the desktop we might be okay with that,
but the small Neo1973 device it is a bad idea.

So yes, the audio (SCO frames) from the Bluetooth chip should go directly into
the codec via the chip's PCM interface and then routed according to the codec
settings.

[bmidgley@…]

the wm8753 cannot do full duplex audio in this fashion

Is there a different codec that we should suggest FIC use in the future to cover
this case?

In order to switch the chip from pcm to hci audio, it has to be reset. This
means all connections are lost so it can't be done transparently.

[laforge@…]

just an update to the slightly off-topic thread into which this bug entry has
developed: We've started a discussion with Wolfson now on what the restrictions
actually are, and which codec to use for GTA02 and later models.

[bmidgley@…]

Graeme, is it possible to make a .state file that routes system audio *out* to
the bluetooth headset? We could at least use this for custom ring tones to the
headset.

For audio input, using the built-in mic would be nice so we at least have an
option to use a voip app. Maybe cranking up the mic gain would make it usable
this way.

[graeme@…]

CPU -> BT audio mapping.

[john_lee@…]

Willie, could you please check this ?

[andy]

Chip can't do what is requested any better than it is doing it.