* SCORouting to PCM in Desktop
@ 2011-06-27 18:21 Koustuv Ghosh
2011-06-30 9:28 ` Johan Hedberg
0 siblings, 1 reply; 6+ messages in thread
From: Koustuv Ghosh @ 2011-06-27 18:21 UTC (permalink / raw)
To: linux-bluetooth
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: SCORouting to PCM in Desktop
2011-06-27 18:21 SCORouting to PCM in Desktop Koustuv Ghosh
@ 2011-06-30 9:28 ` Johan Hedberg
2011-06-30 10:07 ` Sumangala, Suraj
0 siblings, 1 reply; 6+ messages in thread
From: Johan Hedberg @ 2011-06-30 9:28 UTC (permalink / raw)
To: Koustuv Ghosh; +Cc: linux-bluetooth
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* RE: SCORouting to PCM in Desktop
2011-06-30 9:28 ` Johan Hedberg
@ 2011-06-30 10:07 ` Sumangala, Suraj
2011-06-30 11:38 ` Johan Hedberg
0 siblings, 1 reply; 6+ messages in thread
From: Sumangala, Suraj @ 2011-06-30 10:07 UTC (permalink / raw)
To: Johan Hedberg, Koustuv Ghosh; +Cc: linux-bluetooth@vger.kernel.org
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: SCORouting to PCM in Desktop
2011-06-30 10:07 ` Sumangala, Suraj
@ 2011-06-30 11:38 ` Johan Hedberg
2011-07-01 8:50 ` kchai1
0 siblings, 1 reply; 6+ messages in thread
From: Johan Hedberg @ 2011-06-30 11:38 UTC (permalink / raw)
To: Sumangala, Suraj; +Cc: Koustuv Ghosh, linux-bluetooth@vger.kernel.org
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: SCORouting to PCM in Desktop
2011-06-30 11:38 ` Johan Hedberg
@ 2011-07-01 8:50 ` kchai1
2011-07-09 15:23 ` Johan Hedberg
0 siblings, 1 reply; 6+ messages in thread
From: kchai1 @ 2011-07-01 8:50 UTC (permalink / raw)
To: Johan Hedberg
Cc: Sumangala, Suraj, Koustuv Ghosh, linux-bluetooth@vger.kernel.org
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 majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: SCORouting to PCM in Desktop
2011-07-01 8:50 ` kchai1
@ 2011-07-09 15:23 ` Johan Hedberg
0 siblings, 0 replies; 6+ messages in thread
From: Johan Hedberg @ 2011-07-09 15:23 UTC (permalink / raw)
To: kchai1; +Cc: Sumangala, Suraj, Koustuv Ghosh, linux-bluetooth@vger.kernel.org
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
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2011-07-09 15:23 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-06-27 18:21 SCORouting to PCM in Desktop Koustuv Ghosh
2011-06-30 9:28 ` Johan Hedberg
2011-06-30 10:07 ` Sumangala, Suraj
2011-06-30 11:38 ` Johan Hedberg
2011-07-01 8:50 ` kchai1
2011-07-09 15:23 ` Johan Hedberg
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).