[Bluez-devel] sco link help needed

[Bluez-devel] sco link help needed

[Simon Vogl]

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 initiali=
zation
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 connec=
tion...),
Simon

P.S. Is there a location for such tips anywhere? If not, I am willing to =
donate
space & a wiki on one of our institute servers....

--=20
_______________________________________________________________________
Dr. Simon Vogl
Institut f=C3=BCr Pervasive Computing, Johannes Kepler Universit=C3=A4t L=
inz
Altenberger Stra=C3=9Fe 69, A-4040 Linz, Austria

Tel: +43 732 2468-8517, Fax: +43 732 2468-8426
mailto: vogl@soft.uni-linz.ac.at,  http://www.soft.uni-linz.ac.at/








-------------------------------------------------------
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
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] sco link help needed

[Fred Schättgen]

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


-------------------------------------------------------
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
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] sco link help needed

[James Courtier-Dutton]

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
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] sco link help needed

[Marcel Holtmann]

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
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] sco link help needed

[James Courtier-Dutton]

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

Re: [Bluez-devel] sco link help needed

[Marcel Holtmann]

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
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] sco link help needed

[James Courtier-Dutton]

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

Re: [Bluez-devel] sco link help needed

[Marcel Holtmann]

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
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] sco link help needed

[James Courtier-Dutton]

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

Re: [Bluez-devel] sco link help needed

[Marcel Holtmann]

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
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] sco link help needed

[Mauro Tortonesi]

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                 mtortonesi@ing.unife.it
                                mauro@deepspace6.net
                                mauro@ferrara.linux.it
Deep Space 6 - IPv6 with Linux  http://www.deepspace6.net
Ferrara Linux User Group        http://www.ferrara.linux.it

Re: [Bluez-devel] sco link help needed

[Marcel Holtmann]

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 www.bluetooth.org and the
links to the mailing list archives are at 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
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] sco link help needed

[Mauro Tortonesi]

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 www.bluetooth.org and the
> links to the mailing list archives are at 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                 mtortonesi@ing.unife.it
                                mauro@deepspace6.net
                                mauro@ferrara.linux.it
Deep Space 6 - IPv6 with Linux  http://www.deepspace6.net
Ferrara Linux User Group        http://www.ferrara.linux.it

Re: [Bluez-devel] sco link help needed

[Marcel Holtmann]

Hi Mauro,

> > the Bluetooth specification can be found under www.bluetooth.org and the
> > links to the mailing list archives are at 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
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] sco link help needed

[Mauro Tortonesi]

On Wednesday 25 February 2004 15:23, Marcel Holtmann wrote:
> Hi Mauro,
>
> > > the Bluetooth specification can be found under www.bluetooth.org and
> > > the links to the mailing list archives are at 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                 mtortonesi@ing.unife.it
                                mauro@deepspace6.net
                                mauro@ferrara.linux.it
Deep Space 6 - IPv6 with Linux  http://www.deepspace6.net
Ferrara Linux User Group        http://www.ferrara.linux.it

Re: [Bluez-devel] sco link help needed

[Marcel Holtmann]

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
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] sco link help needed

[Mauro Tortonesi]

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                 mtortonesi@ing.unife.it
                                mauro@deepspace6.net
                                mauro@ferrara.linux.it
Deep Space 6 - IPv6 with Linux  http://www.deepspace6.net
Ferrara Linux User Group        http://www.ferrara.linux.it

Re: [Bluez-devel] sco link help needed

[Marcel Holtmann]

Hi Nils,

> > Is the PCM mapping of both dongles set to HCI? What kernel version do
> > you use?
> 
> And if it isn't?
> I searched the archive but could not find a way to change it.
> Or is this fixed in the firmware? This would be a pity...
> I have just got a Fujitsu-Siemens Lifebook with builtin Blueooth (CSR
> chipset BlueCore01b, HCI 12.3) which reports SCOmapping to PCM...

the SCO mapping is a PSKEY like everything else. It is the same as for
the host transport or the UART setttings. You can change it if you know
how. Actually I don't provide any source code that is capable of
changing PSKEY's.

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
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] sco link help needed

[Nils Faerber]

Am Mi, den 25.02.2004 schrieb Marcel Holtmann um 18:16:
> Hi Nils,
Hi!

> > > Is the PCM mapping of both dongles set to HCI? What kernel version do
> > > you use?
> > And if it isn't?
> > I searched the archive but could not find a way to change it.
> > Or is this fixed in the firmware? This would be a pity...
> > I have just got a Fujitsu-Siemens Lifebook with builtin Blueooth (CSR
> > chipset BlueCore01b, HCI 12.3) which reports SCOmapping to PCM...
> the SCO mapping is a PSKEY like everything else. It is the same as for
> the host transport or the UART setttings. You can change it if you know
> how. Actually I don't provide any source code that is capable of
> changing PSKEY's.

Oh well ;)
Many thanks for the info anyway...

> Regards
> Marcel
CU
  nils faerber

-- 
kernel concepts          Tel: +49-271-771091-12
Dreisbachstr. 24         Fax: +49-271-771091-19
D-57250 Netphen          D1 : +49-170-2729106
--

Re: [Bluez-devel] sco link help needed

[James Courtier-Dutton]

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

Re: [Bluez-devel] sco link help needed

[Dr. Simon Vogl]

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
> Bluez-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] sco link help needed

[Marcel Holtmann]

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
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] sco link help needed

[James Courtier-Dutton]

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
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

libs2 and utils2

[Aaron Klish]

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

[Bluez-devel] Re: libs2 and utils2

[Marcel Holtmann]

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
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] sco link help needed

[Fred Schättgen]

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

Re: [Bluez-devel] sco link help needed

[Marcel Holtmann]

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
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] sco link help needed

[Fred Schättgen]

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
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] sco link help needed

[Dr. Simon Vogl]

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
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel