LinuxLists.cc - [Bluez-devel] sco link help needed

[permalink] [raw]

Subject: Re: [Bluez-devel] sco link help needed

On Wednesday 25 February 2004 16:37, Marcel Holtmann wrote:

> > > Is the PCM mapping of both dongles set to HCI?
> >
> > how can i find this out? from the SCO MTU value?
> >
> > [mauro@giskard mauro]$ /sbin/hciconfig hci0 revision
> > hci0: Type: USB
> > BD Address: 00:0A:3A:51:13:1C ACL MTU: 192:8 SCO MTU: 64:8
> > HCI 16.4
>
> No. Use "hciconfig hci0 revision" (as root). It must be set to HCI.

in fact, it is set to HCI.

--
Aequam memento rebus in arduis servare mentem...

Mauro Tortonesi [email protected]
[email protected]
[email protected]
Deep Space 6 - IPv6 with Linux http://www.deepspace6.net
Ferrara Linux User Group http://www.ferrara.linux.it

2004-02-25 15:37:32

[permalink] [raw]

Subject: Re: [Bluez-devel] sco link help needed

Hi Mauro,

> well, you knew just what to search. i have spent more than one hour searching
> for "sco" and "sco csr" on the sf.net archives (which, as you surely know,
> are not very fast, have thousands of messages and have a shameful uptime)
> without finding anything useful. if you had kindly told me "look for
> something like scotest" or "look for a message from steven singer" i could
> have find the mail you were referring to in a minute.

I use the Gmane archives, because they are much faster ;)

> > Is the PCM mapping of both dongles set to HCI?
>
> how can i find this out? from the SCO MTU value?
>
> [mauro@giskard mauro]$ /sbin/hciconfig hci0 revision
> hci0: Type: USB
> BD Address: 00:0A:3A:51:13:1C ACL MTU: 192:8 SCO MTU: 64:8
> HCI 16.4

No. Use "hciconfig hci0 revision" (as root). It must be set to HCI.

> > What kernel version do you use?
>
> 2.4.25pre7

This should work, but the 2.6 seems to have problems with USB ISOC
transfers.

Regards

Marcel

-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

2004-02-25 15:35:13

[permalink] [raw]

Subject: Re: [Bluez-devel] sco link help needed

On Wednesday 25 February 2004 15:23, Marcel Holtmann wrote:
> Hi Mauro,
>
> > > the Bluetooth specification can be found under http://www.bluetooth.org and
> > > the links to the mailing list archives are at http://www.bluez.org.
> >
> > really, i was asking about the link to the url in the archives where i
> > can find the "comments from the CSR guys about SCO"...
>
> is it so hard to search through the archives? I did the search for you,
> but don't expect me to do it again. This is one of them
>
> http://article.gmane.org/gmane.linux.bluez.user/502

well, you knew just what to search. i have spent more than one hour searching
for "sco" and "sco csr" on the sf.net archives (which, as you surely know,
are not very fast, have thousands of messages and have a shameful uptime)
without finding anything useful. if you had kindly told me "look for
something like scotest" or "look for a message from steven singer" i could
have find the mail you were referring to in a minute.

> > > You can send PCM audio over a SCO socket, but you can't expect that the
> > > PCM stream on the other side is byte by byte the same. It only sounds
> > > the same.
> >
> > i haven't tried, but i don't suppose that infinite series of zeros i get
> > on the receiver sounds just like art blakey's alamode. there is surely
> > something wrong in the transfer process. could it be the fact that my
> > hosts have an usb-uhci controller?
>
> Is the PCM mapping of both dongles set to HCI?

how can i find this out? from the SCO MTU value?

[mauro@giskard mauro]$ /sbin/hciconfig hci0 revision
hci0: Type: USB
BD Address: 00:0A:3A:51:13:1C ACL MTU: 192:8 SCO MTU: 64:8
HCI 16.4

> What kernel version do you use?

2.4.25pre7

--
Aequam memento rebus in arduis servare mentem...

Mauro Tortonesi [email protected]
[email protected]
[email protected]
Deep Space 6 - IPv6 with Linux http://www.deepspace6.net
Ferrara Linux User Group http://www.ferrara.linux.it

2004-02-25 15:09:38

[permalink] [raw]

Subject: Re: [Bluez-devel] sco link help needed

Hi Simon,

> Yes, there seems to be something utterly wrong, indeed - I spent four
> days debugging my apps (down
> to the hci_usb driver) until I found out that I do not get a byte of
> audio data with that acer bt stick (mind,
> though, that I get the connection set up all right, and that I cound
> send an audio stream). After a change
> to a newer Acer stick my apps first worked fine, but sometimes the sco
> connections don't get set up ...

the PCM mapping is important. For CSR chips it can be checked with
"hciconfig hci0 revision". It must be set to HCI.

Regards

Marcel

-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

2004-02-25 14:59:15

by Simon Vogl

[permalink] [raw]

Subject: Re: [Bluez-devel] sco link help needed

Yes, there seems to be something utterly wrong, indeed - I spent four
days debugging my apps (down
to the hci_usb driver) until I found out that I do not get a byte of
audio data with that acer bt stick (mind,
though, that I get the connection set up all right, and that I cound
send an audio stream). After a change
to a newer Acer stick my apps first worked fine, but sometimes the sco
connections don't get set up ...

Strange.
Simon

James Courtier-Dutton wrote:

> Mauro Tortonesi wrote:
>
>>>
>>> You can send PCM audio over a SCO socket, but you can't expect that the
>>> PCM stream on the other side is byte by byte the same. It only sounds
>>> the same.
>>
>>
>>
>> i haven't tried, but i don't suppose that infinite series of zeros i
>> get on the receiver sounds just like art blakey's alamode. there is
>> surely something wrong in the transfer process. could it be the fact
>> that my hosts have an usb-uhci controller?
>>
>
> If you are receiving only zeros at the far end, the problem is with
> the sco driver or the hci-usb driver or the uhci_hcd driver.
>
> I currently think the hci-usb driver is at fault, but I am doing
> research with the linux usb developers to discover how they think it
> should be done, and then I will look at the hci-usb driver and see if
> it is doing things correctly.
>
> With my system, the urbs are failing the submit_urb in the hci-usb
> driver on kernel 2.6.3, so the hci-usb driver must be doing something
> wrong as the new kernel usb code does more checks in order to catch
> badly behaved applications. I think they are taking the approach that
> if an application is behaving badly, make it fail completely, thus
> forcing the program writter to correct it. Seems like a good policy to
> me. It is better to have an application working 100% of the time or 0%
> of the time, rather than randomly working/not working.
>
> Cheers
> James
>
>
> -------------------------------------------------------
> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> Build and deploy apps & Web services for Linux with
> a free DVD software kit from IBM. Click Now!
> http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
> _______________________________________________
> Bluez-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/bluez-devel

2004-02-25 14:23:32

[permalink] [raw]

Subject: Re: [Bluez-devel] sco link help needed

Hi Mauro,

> > the Bluetooth specification can be found under http://www.bluetooth.org and the
> > links to the mailing list archives are at http://www.bluez.org.
>
> really, i was asking about the link to the url in the archives where i can
> find the "comments from the CSR guys about SCO"...

is it so hard to search through the archives? I did the search for you,
but don't expect me to do it again. This is one of them

http://article.gmane.org/gmane.linux.bluez.user/502

> > How often must I repeat this?
>
> sorry, i happen to be a bit dumb sometimes ;-) but it seems that many others
> are experiencing problems with SCO. perhaps you could start writing something
> like a SCO readme?

Let me use the statement from Steven Singer

Summary: SCO is suitable only for analogue signals

> > You can send PCM audio over a SCO socket, but you can't expect that the
> > PCM stream on the other side is byte by byte the same. It only sounds
> > the same.
>
> i haven't tried, but i don't suppose that infinite series of zeros i get on
> the receiver sounds just like art blakey's alamode. there is surely something
> wrong in the transfer process. could it be the fact that my hosts have an
> usb-uhci controller?

Is the PCM mapping of both dongles set to HCI? What kernel version do
you use?

Regards

Marcel

-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

2004-02-25 14:30:10

[permalink] [raw]

Subject: Re: [Bluez-devel] sco link help needed

Mauro Tortonesi wrote:
>>
>>You can send PCM audio over a SCO socket, but you can't expect that the
>>PCM stream on the other side is byte by byte the same. It only sounds
>>the same.
>
>
> i haven't tried, but i don't suppose that infinite series of zeros i get on
> the receiver sounds just like art blakey's alamode. there is surely something
> wrong in the transfer process. could it be the fact that my hosts have an
> usb-uhci controller?
>

If you are receiving only zeros at the far end, the problem is with the
sco driver or the hci-usb driver or the uhci_hcd driver.

I currently think the hci-usb driver is at fault, but I am doing
research with the linux usb developers to discover how they think it
should be done, and then I will look at the hci-usb driver and see if it
is doing things correctly.

With my system, the urbs are failing the submit_urb in the hci-usb
driver on kernel 2.6.3, so the hci-usb driver must be doing something
wrong as the new kernel usb code does more checks in order to catch
badly behaved applications. I think they are taking the approach that if
an application is behaving badly, make it fail completely, thus forcing
the program writter to correct it. Seems like a good policy to me. It is
better to have an application working 100% of the time or 0% of the
time, rather than randomly working/not working.

Cheers
James

2004-02-25 14:22:56

[permalink] [raw]

Subject: Re: [Bluez-devel] sco link help needed

Mauro Tortonesi wrote:
>
> i have been trying to transfer pcm data over a sco socket both using scotest
> and other similar apps of mine, but the actual data tranferred were only a
> bunch of random bytes, completely unrelated to the data sent. moreover, the
> behaviour of sco links is very unreliable. in my tests i have used several
> usb dongles with CSR chips (firmware versions ranging from HCI 15.3 to HCI
> 16.4) and kernel versions from 2.4.22 to 2.4.25-pre7.
>
> you have told us many times that there are strong limitations in what you can
> do with sco sockets, but i still can't understand what are these limitations.
> i have tried searching trough the archives but i couldn't find anything
> interesting about this.

The standard SCO link takes data from the user app. The CSR chip (any
bluetooth device in fact) will take that data and treat it as Audio PCM
samples. the CSR chip will then use a LOSSY codec called CVSD and
transmit those samples over the air. Due to interference, some of the
samples in the air get lost. At the receiving end, CVSD is converted
back into PCM audio. If any samples have been lost in the air, they are
replaced with duplicate of the previous sample.
Due to the lossy nature of the CVSD codec, the actual PCM values will be
different at the destination end as they were at the source end. But the
differences will be such that they are mostly unnoticeable to the human
ear. So, if you are wishing to transfer anything other than Sound across
a SCO link, change your mind. If you look at the video streaming
bluetooth profiles, you will see that they all use Bulk transfers.
Some CSR chips try to include a "Transparent" feature, which disables
the CVSD codec, and passes samples directly onto the air, but that also
has problems associated with it.

If your usb device can do Interrupt OUT, use that instead if you need
low latency output. Some USB dongles can do it, some cannot.

Cheers
James

-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

2004-02-25 14:04:47

[permalink] [raw]

Subject: Re: [Bluez-devel] sco link help needed

On Wednesday 25 February 2004 14:25, Marcel Holtmann wrote:
> Hi Mauro,
>
> > > Yes it have to. You should read the mailing list archive and search for
> > > comments from the CSR guys about SCO. And you can of course take the
> > > Bluetooth specification itself.
> >
> > could you please provide a url?
>
> the Bluetooth specification can be found under http://www.bluetooth.org and the
> links to the mailing list archives are at http://www.bluez.org.

really, i was asking about the link to the url in the archives where i can
find the "comments from the CSR guys about SCO"...

> > i have been trying to transfer pcm data over a sco socket both using
> > scotest and other similar apps of mine, but the actual data tranferred
> > were only a bunch of random bytes, completely unrelated to the data sent.
> > moreover, the behaviour of sco links is very unreliable. in my tests i
> > have used several usb dongles with CSR chips (firmware versions ranging
> > from HCI 15.3 to HCI 16.4) and kernel versions from 2.4.22 to
> > 2.4.25-pre7.
> >
> > you have told us many times that there are strong limitations in what you
> > can do with sco sockets, but i still can't understand what are these
> > limitations. i have tried searching trough the archives but i couldn't
> > find anything interesting about this.
>
> How often must I repeat this?

sorry, i happen to be a bit dumb sometimes ;-) but it seems that many others
are experiencing problems with SCO. perhaps you could start writing something
like a SCO readme?

> We are doing audio over SCO and no data
> transfer. Even with transparent SCO as air coding the results on both
> ends must not be the same.
>
> > > Again, I can't follow what you are trying to achieve. The current
> > > socket interface for SCO fits not perfect, because it is audio only
> > > data.
> >
> > does this mean that you simply can't perform pcm audio transfers between
> > two bluez hosts by using sco sockets just like scotest does? if so, what
> > is the purpose of scotest, then?
>
> You can send PCM audio over a SCO socket, but you can't expect that the
> PCM stream on the other side is byte by byte the same. It only sounds
> the same.

i haven't tried, but i don't suppose that infinite series of zeros i get on
the receiver sounds just like art blakey's alamode. there is surely something
wrong in the transfer process. could it be the fact that my hosts have an
usb-uhci controller?

--
Aequam memento rebus in arduis servare mentem...

Mauro Tortonesi [email protected]
[email protected]
[email protected]
Deep Space 6 - IPv6 with Linux http://www.deepspace6.net
Ferrara Linux User Group http://www.ferrara.linux.it

2004-02-25 13:25:46

[permalink] [raw]

Subject: Re: [Bluez-devel] sco link help needed

Hi Mauro,

> > Yes it have to. You should read the mailing list archive and search for
> > comments from the CSR guys about SCO. And you can of course take the
> > Bluetooth specification itself.
>
> could you please provide a url?

the Bluetooth specification can be found under http://www.bluetooth.org and the
links to the mailing list archives are at http://www.bluez.org.

> i have been trying to transfer pcm data over a sco socket both using scotest
> and other similar apps of mine, but the actual data tranferred were only a
> bunch of random bytes, completely unrelated to the data sent. moreover, the
> behaviour of sco links is very unreliable. in my tests i have used several
> usb dongles with CSR chips (firmware versions ranging from HCI 15.3 to HCI
> 16.4) and kernel versions from 2.4.22 to 2.4.25-pre7.
>
> you have told us many times that there are strong limitations in what you can
> do with sco sockets, but i still can't understand what are these limitations.
> i have tried searching trough the archives but i couldn't find anything
> interesting about this.

How often must I repeat this? We are doing audio over SCO and no data
transfer. Even with transparent SCO as air coding the results on both
ends must not be the same.

> > Again, I can't follow what you are trying to achieve. The current socket
> > interface for SCO fits not perfect, because it is audio only data.
>
> does this mean that you simply can't perform pcm audio transfers between two
> bluez hosts by using sco sockets just like scotest does? if so, what is the
> purpose of scotest, then?

You can send PCM audio over a SCO socket, but you can't expect that the
PCM stream on the other side is byte by byte the same. It only sounds
the same.

Regards

Marcel

-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

2004-02-25 12:59:00

[permalink] [raw]

Subject: Re: [Bluez-devel] sco link help needed

On Monday 23 February 2004 08:55, Marcel Holtmann wrote:

> > The bluetooth chip should not have to worry about dropping packets, the
> > application should just send the chip packets when the chip wants them.
>
> Yes it have to. You should read the mailing list archive and search for
> comments from the CSR guys about SCO. And you can of course take the
> Bluetooth specification itself.

hi marcel,

could you please provide a url?

i have been trying to transfer pcm data over a sco socket both using scotest
and other similar apps of mine, but the actual data tranferred were only a
bunch of random bytes, completely unrelated to the data sent. moreover, the
behaviour of sco links is very unreliable. in my tests i have used several
usb dongles with CSR chips (firmware versions ranging from HCI 15.3 to HCI
16.4) and kernel versions from 2.4.22 to 2.4.25-pre7.

you have told us many times that there are strong limitations in what you can
do with sco sockets, but i still can't understand what are these limitations.
i have tried searching trough the archives but i couldn't find anything
interesting about this.

> > I am only asking for changes to the SCO side of things due to it's real
> > time nature. Using network sockets for RFCOMM and bulk data transfers
> > that are not real time in nature is fine.
> >
> > Once we have proper real time SCO support, we can overlay the current
> > SCO file descriptor read/write model on top if you still need it.
>
> Again, I can't follow what you are trying to achieve. The current socket
> interface for SCO fits not perfect, because it is audio only data.

does this mean that you simply can't perform pcm audio transfers between two
bluez hosts by using sco sockets just like scotest does? if so, what is the
purpose of scotest, then?

--
Aequam memento rebus in arduis servare mentem...

Mauro Tortonesi [email protected]
[email protected]
[email protected]
Deep Space 6 - IPv6 with Linux http://www.deepspace6.net
Ferrara Linux User Group http://www.ferrara.linux.it

2004-02-23 17:19:10

[permalink] [raw]

Subject: [Bluez-devel] Re: libs2 and utils2

Hi Aaron,

> What are your plans for officially releasing the code in libs2 and utils2
> currently in CVS? Do you have a target date sometime in the future?

the libs2 should already been released, but it wasn't. The new code must
be tested on a big endian platform and I lost my Sun Ultra60.

The core part is finished and the HCI layer needs only a small number of
corrections. But the SDP client part is a full rewrite and need much
more testing.

> At what point will you stop supporting the current libraries and utilities?

As long as people send me patches for the current version I will apply
them. Actually I only want to put bugfixes into libs, but for utils I'll
accept new features.

Regards

Marcel

-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

2004-02-23 16:35:40

by Aaron Klish

[permalink] [raw]

Subject: libs2 and utils2

Hi Marcel,
What are your plans for officially releasing the code in libs2 and utils2
currently in CVS? Do you have a target date sometime in the future?
At what point will you stop supporting the current libraries and utilities?
Thanks for any info.

Aaron

------------
Aaron Klish
Bluetooth Software Engineer
Motorola PCS
PH# (217) 384-8598
FX# (217) 384-8550

[X] Motorola General Business Information
[ ] Motorola Internal Use Only
[ ] Motorola Confidential Proprietary

2004-02-23 07:55:38

[permalink] [raw]

Subject: Re: [Bluez-devel] sco link help needed

Hi James,

> What I am trying to say is that using read/write interfaces for realtime
> streams like SCO is just the wrong way to do it.
> I have looked at snd-bluez-sco-2003-09-15.tar.gz and from what I can
> understand from it, the snd-bluez-sco kernel driver is just using simple
> read/write commands to a file descriptor given to it from the userspace
> daemon "bluezsco".

I don't see a problem with a read/write interface, because what we get
from the Bluetooth chip is already PCM. I don't wann make it more
complex as needed if the hardware can do most of the stuff for us.

> This approach will get sound to and from the bluetooth headset.
> But SCO has the potential for so much more, so why are we restricting it?
> We must allow for applications like VoIP and DVD playback. These need
> control over latency and playback timing accuracy. The current "file
> descriptor read/write" approach does not allow for that.

Where do we restrict this?

> The bluetooth chip should not have to worry about dropping packets, the
> application should just send the chip packets when the chip wants them.

Yes it have to. You should read the mailing list archive and search for
comments from the CSR guys about SCO. And you can of course take the
Bluetooth specification itself.

> I am only asking for changes to the SCO side of things due to it's real
> time nature. Using network sockets for RFCOMM and bulk data transfers
> that are not real time in nature is fine.
>
> Once we have proper real time SCO support, we can overlay the current
> SCO file descriptor read/write model on top if you still need it.

Again, I can't follow what you are trying to achieve. The current socket
interface for SCO fits not perfect, because it is audio only data. But
with eSCO we also provide data transmission over SCO.

However I don't wanna continue a socket interface for SCO. What I wan't
is something like:

1. We need an SCO channel
2. Connect SCO channel
3. Attach SCO channel to an ALSA audio device
4. Find new audio device and use it
5. Use SCO controls for mixers settings etc.

Regards

Marcel

-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

2004-02-22 23:37:49

[permalink] [raw]

Subject: Re: [Bluez-devel] sco link help needed

Marcel Holtmann wrote:
> Hi James,
>
>
>>So you only want a basic read/write interface? No possibility for
>>specifying low latency and setting accurate playback timing?
>>What would happen if the user wanted to use bluetooth headphones, and
>>wanted sound to come out of the headphones, and the video from a DVD to
>>be displayed on the computer screen. We need some way to ensure the two
>>are in sync. A simple read/write interface cannot do that.
>>For playing a DVD, latency does not matter, what matters in accurate
>>playback timing.
>>For Voice over IP, low latency is what matters.
>>I cannot see how your simple read/write interface can handle these
>>options. The SCO interface should be able to handle all these.
>
>
> for incoming SCO data packets we can trust the timing of the Bluetooth
> chip. For outgoing SCO data from our side we should make sure that we
> don't send to much and overload the Bluetooth chip, but any good
> Bluetooth chip should be able to handle this and simply drop the
> unneeded packets.

What I am trying to say is that using read/write interfaces for realtime
streams like SCO is just the wrong way to do it.
I have looked at snd-bluez-sco-2003-09-15.tar.gz and from what I can
understand from it, the snd-bluez-sco kernel driver is just using simple
read/write commands to a file descriptor given to it from the userspace
daemon "bluezsco".

This approach will get sound to and from the bluetooth headset.
But SCO has the potential for so much more, so why are we restricting it?
We must allow for applications like VoIP and DVD playback. These need
control over latency and playback timing accuracy. The current "file
descriptor read/write" approach does not allow for that.

The bluetooth chip should not have to worry about dropping packets, the
application should just send the chip packets when the chip wants them.

I am only asking for changes to the SCO side of things due to it's real
time nature. Using network sockets for RFCOMM and bulk data transfers
that are not real time in nature is fine.

Once we have proper real time SCO support, we can overlay the current
SCO file descriptor read/write model on top if you still need it.

>
>
>>Ok, so you only want alsa to interface PCM (alsa's term for an audio
>>channel, where the audio samples go.) directly to a SCO channel.
>>So, what about an application that supports alsa now. How will it set
>>volume and mic levels on a bluetooth headset? Will the user have to add
>>special bluetooth support to their application?
>
>
> This is what I meant with SCO interface. A SCO kernel module must also
> present an ALSA mixer, but it sends and receives the settings to and
> from an userspace application. So if you receive the AT command for
> increasing the volume on the RFCOMM channel, you signal this to the SCO
> kernel module and this changes the mixer settings. We will see what is
> best solution here after the SCO to ALSA PCM mapping is working.

Ok, doing that with the mixer is not a problem for me. mixer settings
are not time critical, and simple two way IOCTLs for get/set volume etc.
will work fine with the current userspace approach.

>
> Regards
>
> Marcel
>
>
Cheers

James

2004-02-22 22:35:37

by Fred Schaettgen

[permalink] [raw]

Subject: Re: [Bluez-devel] sco link help needed

On Sunday 22 February 2004 23:00, Marcel Holtmann wrote:
> > The rfcomm stuff isn't performance critical at all, so there is need for
> > it to go into an alsa driver.
>
> the headset profile will never be in kernel space, because profiles are
> application specific. An ALSA Bluetooth driver should map between a SCO
> channel and an audio device, so that you can for example use XMMS or
> GnomeMeeting with your Bluetooth headset.
..
> You always have a control application on an ACL link before any SCO
> channel will be open.

Sure. I was just worried that with the alsa driver a userspace application
might loose control over how SCO connections are handled.
I don't want to be able to tell alsa that it should accept SCO connections on
its own, instead I still want to accept it myself without having to resort to
alsa functions and only optionally pass the socket (or whatever) to alsa to
create a new device. Maybe it's supposed to work like that anyway, it was
just not clear to me.

greetings
Fred

-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

2004-02-22 22:09:51

[permalink] [raw]

Subject: Re: [Bluez-devel] sco link help needed

Hi James,

> So you only want a basic read/write interface? No possibility for
> specifying low latency and setting accurate playback timing?
> What would happen if the user wanted to use bluetooth headphones, and
> wanted sound to come out of the headphones, and the video from a DVD to
> be displayed on the computer screen. We need some way to ensure the two
> are in sync. A simple read/write interface cannot do that.
> For playing a DVD, latency does not matter, what matters in accurate
> playback timing.
> For Voice over IP, low latency is what matters.
> I cannot see how your simple read/write interface can handle these
> options. The SCO interface should be able to handle all these.

for incoming SCO data packets we can trust the timing of the Bluetooth
chip. For outgoing SCO data from our side we should make sure that we
don't send to much and overload the Bluetooth chip, but any good
Bluetooth chip should be able to handle this and simply drop the
unneeded packets.

> Ok, so you only want alsa to interface PCM (alsa's term for an audio
> channel, where the audio samples go.) directly to a SCO channel.
> So, what about an application that supports alsa now. How will it set
> volume and mic levels on a bluetooth headset? Will the user have to add
> special bluetooth support to their application?

This is what I meant with SCO interface. A SCO kernel module must also
present an ALSA mixer, but it sends and receives the settings to and
from an userspace application. So if you receive the AT command for
increasing the volume on the RFCOMM channel, you signal this to the SCO
kernel module and this changes the mixer settings. We will see what is
best solution here after the SCO to ALSA PCM mapping is working.

Regards

Marcel

-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

2004-02-22 22:00:10

[permalink] [raw]

Subject: Re: [Bluez-devel] sco link help needed

Hi Fred,

> I don't understand why the whole headset profile has to be implemented as a
> part of an alsa driver. Everything can be done completely in user space
> already, completely independent from alsa. The only reason one might wish to
> have a special alsa driver is better responsiveness only, or what else did I
> miss?
> The rfcomm stuff isn't performance critical at all, so there is need for it to
> go into an alsa driver.

the headset profile will never be in kernel space, because profiles are
application specific. An ALSA Bluetooth driver should map between a SCO
channel and an audio device, so that you can for example use XMMS or
GnomeMeeting with your Bluetooth headset.

> I really don't like the idea that an alsa driver would decide if a sco
> connection is going to be accepted or not. This should all be up to the a
> regular userspace application. The alsa driver should not accept incoming
> connections itself.
> Instead their should be a way for the application to create or accept (or not
> accept) a SCO connection the usual way and - only if it wishes to - tell alsa
> to take care of that connection by creating a new alsa device for it.
> The only job the driver should do is to connect an existing sco socket to an
> alsa device and make sure that there are no cracks in the audio stream,
> nothing more.

You always have a control application on an ACL link before any SCO
channel will be open.

Regards

Marcel

-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

2004-02-22 22:04:15

[permalink] [raw]

Subject: Re: [Bluez-devel] sco link help needed

Marcel Holtmann wrote:
> Hi James,
>
>
>>A agree that we need a clearly defined interface for the bluetooth SCO.
>>For SCO connections the interface will HAVE to be a callback based
>>interface. SCO is all about realtime data, and we must ensure minimal
>>latency, so that requires a callback interface.
>>I.E. We set up the SCO connection, and get it to callback after every X
>>frames received. The same for sending, callback saying I need X samples now!
>
>
> we already had this discussion and there is no need for such a callback
> stuff. If there is too much data, we simply have to drop some samples.

So you only want a basic read/write interface? No possibility for
specifying low latency and setting accurate playback timing?
What would happen if the user wanted to use bluetooth headphones, and
wanted sound to come out of the headphones, and the video from a DVD to
be displayed on the computer screen. We need some way to ensure the two
are in sync. A simple read/write interface cannot do that.
For playing a DVD, latency does not matter, what matters in accurate
playback timing.
For Voice over IP, low latency is what matters.
I cannot see how your simple read/write interface can handle these
options. The SCO interface should be able to handle all these.

>
>
>>For alsa to work well with bluetooth, we will need some special handling
>>. The main use of alsa with bluetooth will be for headset communications
>>and therefore use the bluetooth headset profile.
>
>
> That is wrong. Also Handsfree, Cordless Telephony and Intercom needs a
> SCO to audio device mapping. With eSCO we will also have a data link and
> maybe more profiles in the future.

Ok, so you only want alsa to interface PCM (alsa's term for an audio
channel, where the audio samples go.) directly to a SCO channel.
So, what about an application that supports alsa now. How will it set
volume and mic levels on a bluetooth headset? Will the user have to add
special bluetooth support to their application?

Cheers
James

2004-02-22 21:54:53

by Fred Schaettgen

[permalink] [raw]

Subject: Re: [Bluez-devel] sco link help needed

On Sunday 22 February 2004 21:53, James Courtier-Dutton wrote:
> Marcel Holtmann wrote:
> > we don't need a kernel module that implements the headset profile as an
> > audio device. What we need is a generic SCO kernel module with a well
> > defined interface that is between the Bluetooth HCI SCO traffic and the
> > ALSA sound layer. This means that if a SCO connection is created the
> > driver must set up a new sound device, but the mixer stuff is profile
> > stuff and must be done by a userspace application.
...
> Summary: -
> 1) The alsa driver for bluetooth will be a kernel mode implementation of
> the bluetooth headset profile.

I don't understand why the whole headset profile has to be implemented as a
part of an alsa driver. Everything can be done completely in user space
already, completely independent from alsa. The only reason one might wish to
have a special alsa driver is better responsiveness only, or what else did I
miss?
The rfcomm stuff isn't performance critical at all, so there is need for it to
go into an alsa driver.

> 2) A userspace tool will be used to configure the bluetooth pairing and
> configure the alsa-bluez link.
>
> 3) We will need to be able to implement bluetooth profiles in kernel
> modules as well as user space applications.

I really don't like the idea that an alsa driver would decide if a sco
connection is going to be accepted or not. This should all be up to the a
regular userspace application. The alsa driver should not accept incoming
connections itself.
Instead their should be a way for the application to create or accept (or not
accept) a SCO connection the usual way and - only if it wishes to - tell alsa
to take care of that connection by creating a new alsa device for it.
The only job the driver should do is to connect an existing sco socket to an
alsa device and make sure that there are no cracks in the audio stream,
nothing more.

greetings
Fred

2004-02-22 21:30:47

[permalink] [raw]

Subject: Re: [Bluez-devel] sco link help needed

Hi James,

> A agree that we need a clearly defined interface for the bluetooth SCO.
> For SCO connections the interface will HAVE to be a callback based
> interface. SCO is all about realtime data, and we must ensure minimal
> latency, so that requires a callback interface.
> I.E. We set up the SCO connection, and get it to callback after every X
> frames received. The same for sending, callback saying I need X samples now!

we already had this discussion and there is no need for such a callback
stuff. If there is too much data, we simply have to drop some samples.

> For alsa to work well with bluetooth, we will need some special handling
> . The main use of alsa with bluetooth will be for headset communications
> and therefore use the bluetooth headset profile.

That is wrong. Also Handsfree, Cordless Telephony and Intercom needs a
SCO to audio device mapping. With eSCO we will also have a data link and
maybe more profiles in the future.

> 1) Pairing. Provide a method to pair a bluetooth headset, so that if the
> headset tried to open the connection. bluez will link to alsa only for
> that paired device. So, we will need to be able to register alsa as a
> pairing handler to bluez. Does the concept of a pairing handler even
> exist yet in bluez?

A headset will never set up the SCO channel. The AG does it.

> 2) There is currently no method in alsa, for alsa to tell the
> application "I am here now, listen to me!". So, if the headset initiates
> the connection, there is currently no way to use alsa to inform the
> application that the headset wishes to do such a thing. Maybe we could
> implement this with an alsa mixer element that is present all the time
> the pairing is present. And the application could poll the mixer
> element, and if the mixer element changed state, we would open the PCM
> to receive the audio. A sort of on/off hook indication.

See above. And the userspace application must set up the audio device.
Remember that we can't have a SCO link without an ACL link and this
means that we need a control application which knows in detail when to
create the audio device.

> 3) The headset profile consists of a RFCOMM connection for setting
> volume levels etc. and also a SCO connection for passing audio samples.
> The alsa driver will implement the headset profile when working with
> bluez. We might be able to expand that to the hands-free profile later.
> The RFCOMM will therefore interface with the alsa mixer. the SCO
> connection will interface with the alsa PCM.

No. The Bluetooth ALSA driver is not in any way related to a profile.

> 1) The alsa driver for bluetooth will be a kernel mode implementation of
> the bluetooth headset profile.

No profile implementation in the kernel. It is userspace stuff.

> 2) A userspace tool will be used to configure the bluetooth pairing and
> configure the alsa-bluez link.

This has nothing to do with it. Pairing is independent from an ALSA
driver.

> 3) We will need to be able to implement bluetooth profiles in kernel
> modules as well as user space applications.

No. Profiles are userspace stuff.

> 4) The bluez SCO interface should be changed to a callback interface.

I don't see any need for it.

Regards

Marcel

-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

2004-02-22 20:53:31

[permalink] [raw]

Subject: Re: [Bluez-devel] sco link help needed

Marcel Holtmann wrote:
> Hi James,
>
>
>>For those interested, I am planning to write an alsa driver for
>>bluetooth headsets.
>>The alsa driver module would load into kernel, but not present any sound
>>devices.
>>Once a pairing had been set up (a small tool will be used for the
>>pairing), the alsa driver module would then dynamically add a sound card
>>to the kernel device list, and this sound card would work just like any
>>other sound device in linux.
>>The alsa driver would handle both iso and rfcomm connections, iso for
>>the sound, rfcomm for mixer volume etc.
>
>
> we don't need a kernel module that implements the headset profile as an
> audio device. What we need is a generic SCO kernel module with a well
> defined interface that is between the Bluetooth HCI SCO traffic and the
> ALSA sound layer. This means that if a SCO connection is created the
> driver must set up a new sound device, but the mixer stuff is profile
> stuff and must be done by a userspace application.
>
> Regards
>
> Marcel
>
>

A agree that we need a clearly defined interface for the bluetooth SCO.
For SCO connections the interface will HAVE to be a callback based
interface. SCO is all about realtime data, and we must ensure minimal
latency, so that requires a callback interface.
I.E. We set up the SCO connection, and get it to callback after every X
frames received. The same for sending, callback saying I need X samples now!

It will be up to the layer above, what is does in each callback function.

The interface between bluetooth SCO and upper layers will have to be
able to work in both kernel and user space.
alsa has all it's low level drivers in kernal space.
The low level drivers provide the direct access to the hardware.
E.g. Output/input of samples, IRQ handling, Interface to mixer hardware.
The alsa driver can dynamically add and remove what is visable to the
user space. I.E. One plugs in a USB sound card, the card automatically
appears for use to the user.

For alsa to work well with bluetooth, we will need some special handling
. The main use of alsa with bluetooth will be for headset communications
and therefore use the bluetooth headset profile.
Problems to overcome: -
1) Pairing. Provide a method to pair a bluetooth headset, so that if the
headset tried to open the connection. bluez will link to alsa only for
that paired device. So, we will need to be able to register alsa as a
pairing handler to bluez. Does the concept of a pairing handler even
exist yet in bluez?
2) There is currently no method in alsa, for alsa to tell the
application "I am here now, listen to me!". So, if the headset initiates
the connection, there is currently no way to use alsa to inform the
application that the headset wishes to do such a thing. Maybe we could
implement this with an alsa mixer element that is present all the time
the pairing is present. And the application could poll the mixer
element, and if the mixer element changed state, we would open the PCM
to receive the audio. A sort of on/off hook indication.

3) The headset profile consists of a RFCOMM connection for setting
volume levels etc. and also a SCO connection for passing audio samples.
The alsa driver will implement the headset profile when working with
bluez. We might be able to expand that to the hands-free profile later.
The RFCOMM will therefore interface with the alsa mixer. the SCO
connection will interface with the alsa PCM.

Summary: -
1) The alsa driver for bluetooth will be a kernel mode implementation of
the bluetooth headset profile.

2) A userspace tool will be used to configure the bluetooth pairing and
configure the alsa-bluez link.

3) We will need to be able to implement bluetooth profiles in kernel
modules as well as user space applications.

4) The bluez SCO interface should be changed to a callback interface.

That is currently what I think would need to happen.
Any comments?

Cheers
James

2004-02-22 12:44:05

by Simon Vogl

[permalink] [raw]

Subject: Re: [Bluez-devel] sco link help needed

Hi James,
have you looked at what Jonathan Paisley implemented?
http://www.dcs.gla.ac.uk/~jp/snd-bluez-sco/
Cheers,
Simon

James Courtier-Dutton wrote:

> Fred Sch?ttgen wrote:
>
>> On Thursday 19 February 2004 15:36, Simon Vogl wrote:
>>
>>> Hi,
>>> I desparately need some help with audio links:
>>> I have written two small programs that use my pc to emulate a headset
>>> and a handsfree device. Both work quite nicely, the rfcomm-based
>>> initialization takes place, and I get an SCO connection, but
>>> mysteriously,
>>> I don't get a single byte of audio data (I don't see it with hcidump
>>> neither).
>>>
>>> my setup:
>>> * Acer usb bluetooth dongle
>>> * test phones used: p800 (headset), p6600/ngage/3650 (handsfree)
>>> with no
>>> luck... * kernel 2.4.23
>>> * bluez utils&lib from cvs
>>> * and yes, i did register hset profile via sdptool....
>>>
>>> I had the program running perfectly already with a T68i....
>>> Any help appreciated heavily (for example a traace of a successful
>>> connection...), Simon
>>
>>
>>
>> I wrote a small handsfree application as a part of the KDE Bluetooth
>> Framework. It basically worked, even though it had problems with an
>> ever increasing lag, which has probably nothing to do with bluez. But
>> at the moment it's broken and it's not very high priority, since my
>> microphone is also broken ;)
>> But you might take a look at it.. it's in kdeextragear-3:
>> http://webcvs.kde.org/cgi-bin/cvsweb.cgi/kdeextragear-3/kdebluetooth/handsfree/
>>
>> I'll try to fix it during the next days.
>>
>> Btw. I'm not sure if the sound doesn't work currently because of a
>> kernel problem. Maybe I should try with an older kernel.. It used to
>> work with 2.4.24 if I remember correctly.
>>
>> greetings
>> Fred
>>
> For those interested, I am planning to write an alsa driver for
> bluetooth headsets.
> The alsa driver module would load into kernel, but not present any
> sound devices.
> Once a pairing had been set up (a small tool will be used for the
> pairing), the alsa driver module would then dynamically add a sound
> card to the kernel device list, and this sound card would work just
> like any other sound device in linux.
> The alsa driver would handle both iso and rfcomm connections, iso for
> the sound, rfcomm for mixer volume etc.
>
> Is anyone else working on this, or shall I start alone?
>
> Cheers
> James

-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

2004-02-22 12:27:16

[permalink] [raw]

Subject: Re: [Bluez-devel] sco link help needed

Hi James,

> For those interested, I am planning to write an alsa driver for
> bluetooth headsets.
> The alsa driver module would load into kernel, but not present any sound
> devices.
> Once a pairing had been set up (a small tool will be used for the
> pairing), the alsa driver module would then dynamically add a sound card
> to the kernel device list, and this sound card would work just like any
> other sound device in linux.
> The alsa driver would handle both iso and rfcomm connections, iso for
> the sound, rfcomm for mixer volume etc.

we don't need a kernel module that implements the headset profile as an
audio device. What we need is a generic SCO kernel module with a well
defined interface that is between the Bluetooth HCI SCO traffic and the
ALSA sound layer. This means that if a SCO connection is created the
driver must set up a new sound device, but the mixer stuff is profile
stuff and must be done by a userspace application.

Regards

Marcel

-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

2004-02-21 14:37:31