Hello ,
I have query for HFP in bluez.
As we know in Desktop PC , SCORouting is default routed to HCI and I
used to get sco data on HCI.
But is there anyway to route it to my desktop PCM.
I can't use audio.conf file(available at /etc/bluetooth) as in my PC
dbus is having some problem.
Apart from that is their any option so that it could be changed to PCM
either by doing any tweak to bluez user space or kernal space?
Any help is welcome.
rgds
Koustuv
Hi Suraj,
On Thu, Jun 30, 2011, Sumangala, Suraj wrote:
> Sometime ago we had a situation where we were testing a BT chip that
> did NOT support SCO over HCI and supported only SCO over PCM.
>
> The problem was whenever SCO connection was made; my host (Ubuntu)
> sent 2 or 3 SCO packets over HCI to the controller. The controller
> could not handle these packets as it meant as only a SCO over PCM
> device and crashed.
>
> So we had to drop the SCO packets in the HCI transport driver
> explicitly. So, when we say in the configuration file that SCO is
> over PCM should the stack make sure that no SCO packets are sent over
> HCI?
The user space part of BlueZ isn't actually responsible for sending any
data over SCO at all. Instead this is the job of the audio subsystem
(PulseAudio, GStreamer, ALSA, etc). If you have special hardware that
only supports SCO over PCM you need to tell your audio subsystem about
that. E.g. in PulseAudio there are parameters for giving an ALSA device
to use for reading/writing the audio instead of using the SCO socket
given by BlueZ. I.e. for a system where you have a dedicated PCM line to
the controller you implement a kernel ALSA driver which abstracts this
line to user space and then give the ALSA device exposed by that driver
to PulseAudio (or whatever audio susbystem you might have).
Johan
Hi Johan
Sometime ago we had a situation where we were testing a BT chip that did NOT support SCO over HCI and supported only SCO over PCM.
The problem was whenever SCO connection was made; my host (Ubuntu) sent 2 or 3 SCO packets over HCI to the controller.
The controller could not handle these packets as it meant as only a SCO over PCM device and crashed.
So we had to drop the SCO packets in the HCI transport driver explicitly.
So, when we say in the configuration file that SCO is over PCM should the stack make sure that no SCO packets are sent over HCI?
Note: This was observed long time before, not sure if it is relevant now.
Regards
Suraj
Hi Koustuv,
On Mon, Jun 27, 2011, Koustuv Ghosh wrote:
> I have query for HFP in bluez.
> As we know in Desktop PC , SCORouting is default routed to HCI and I
> used to get sco data on HCI.
> But is there anyway to route it to my desktop PCM.
>
> I can't use audio.conf file(available at /etc/bluetooth) as in my PC
> dbus is having some problem.
> Apart from that is their any option so that it could be changed to PCM
> either by doing any tweak to bluez user space or kernal space?
PCM routing requires a special hardware line to be connected to your
Bluetooth controller. Typically this is only found on embedded systems
and your desktop PC (most likely) doesn't have it. The audio.conf
setting is only there to document the underlying hardware state and
doesn't actually change anything as such. The only thing that the
setting impacts is the possibility to call Headset.Play() and once that
method is gone (it's already marked as deprecated) the setting will also
be removed from audio.conf.
Johan
Hi Kai,
First of all, please don't top-post on this mailing list. Secondly,
sorry about the delayed response, I seem to have missed this email
initially.
On Fri, Jul 01, 2011, kchai1 wrote:
> About the Headset.Play() function you mentioned, what is the main
> purpose?
It used to be used for SCO connection creation.
> If it was marked as deprecated, what is the replaced solution?
>
> Could you give me some information?
You should be using the Media API (doc/media-api.txt) which is what any
audio subsystem (like PulseAudio) has to use anyway in order to access
Bluetooth audio streams. Having a separate Play method is just confusing
since it doesn't give any guarantees that someone will actually take
care of the SCO link and send/receive audio over it.
Johan
Hi Johan,
About the Headset.Play() function you mentioned, what is the main
purpose?
If it was marked as deprecated, what is the replaced solution?
Could you give me some information?
Kai
On Thu, 2011-06-30 at 14:38 +0300, Johan Hedberg wrote:
> Hi Suraj,
>
> On Thu, Jun 30, 2011, Sumangala, Suraj wrote:
> > Sometime ago we had a situation where we were testing a BT chip that
> > did NOT support SCO over HCI and supported only SCO over PCM.
> >
> > The problem was whenever SCO connection was made; my host (Ubuntu)
> > sent 2 or 3 SCO packets over HCI to the controller. The controller
> > could not handle these packets as it meant as only a SCO over PCM
> > device and crashed.
> >
> > So we had to drop the SCO packets in the HCI transport driver
> > explicitly. So, when we say in the configuration file that SCO is
> > over PCM should the stack make sure that no SCO packets are sent over
> > HCI?
>
> The user space part of BlueZ isn't actually responsible for sending any
> data over SCO at all. Instead this is the job of the audio subsystem
> (PulseAudio, GStreamer, ALSA, etc). If you have special hardware that
> only supports SCO over PCM you need to tell your audio subsystem about
> that. E.g. in PulseAudio there are parameters for giving an ALSA device
> to use for reading/writing the audio instead of using the SCO socket
> given by BlueZ. I.e. for a system where you have a dedicated PCM line to
> the controller you implement a kernel ALSA driver which abstracts this
> line to user space and then give the ALSA device exposed by that driver
> to PulseAudio (or whatever audio susbystem you might have).
>
> Johan
> --
> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html