-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hello there
A while ago I decided that I might want to take over the snd-bt-sco
project.
I had very little time in the last month due to personal reasons, but
I'm eager to give this project at least structure and manpower.
I have the feeling that there are some different people picking at the
code right now, but there is no teamwork here.
If there are people out there who are using snd-bt-sco or might want to
improve the program, please notice me.
I think this might be a good idea, maybe it's possible to set up a
sourceforge project together or something.
I alone can't do much right now, and there are some problems to address
(i.e. how to handle call pickup stuff). I'm pretty busy so I don't have
the time to get into the subject enough :(
thanks in advance,
~ Lars
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFBF6uZQWC6DTWkDAoRAnhcAKC6fQi746tDO8jD751GOpfhhCuiegCeMOIm
NjpCCxbpeAsMrHyhoNcWUjI=
=AxaF
-----END PGP SIGNATURE-----
-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. http://www.ostg.com
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Roderick,
> > > I can't find anything in this thread that reveals whether you're
> > > trying to send SCO traffic over USB or UART. The data handling
> > > for the two cases have subtle differences.
> >
> > As far as I'm aware, we're dealing with USB only.
> >
>
> I am researching BlueZ application in Embedded applcations.
>
> Having UART support would be useful for embedded processors that don't
> have USB host support. Please don't disregard it completely
don't worry about it, because my plan is to use the standard HCI of the
BlueZ core for SCO data. This means it will work with every driver we
have written so far. I don't think that playing special driver tricks
will help us in any way and unless somebody proves me otherwise I don't
wanna do it.
Regards
Marcel
-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
On Tue, 2004-08-10 at 16:31, Jonathan Paisley wrote:
>
> > I can't find anything in this thread that reveals whether you're
> > trying to send SCO traffic over USB or UART. The data handling
> > for the two cases have subtle differences.
>
> As far as I'm aware, we're dealing with USB only.
>
I am researching BlueZ application in Embedded applcations.
Having UART support would be useful for embedded processors that don't
have USB host support. Please don't disregard it completely
-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi James,
> > the point is in writing an ALSA driver and not changing the ALSA
> > subsystem. The SCO driver is part of the Bluetooth subsystem and so it
> > will go in by me. The ALSA subsystem provides an in-kernel API and that
> > can be used without any acknowledge of the ALSA maintainer.
>
> ALSA is very modularised. This separates the hardware specific driver
> stuff from the more general alsa kernel code. So, if you write your own
> ALSA driver hardware module, it will have to depend on other ALSA
> modules. The only ALSA API that is going to be stable is the user land
> alsa-lib, which talks to applications. Although the ALSA kernel API and
> ALSA low level hardware driver API has not changed in some time, the
> ALSA maintainer reserves the right to change it at any time without
> having to warn people, as alsa-lib hides all the changes from users.
> It is therefore a good idea to place any ALSA specific code in the ALSA
> tree, so that the ALSA maintainers keep it's kernel API up to date.
> This would then leave the BlueZ team to only have to worry about the
> ALSA to BlueZ API.
you don't get my point. The ALSA code in the kernel is the base and if I
want to use that API I don't have to ask anyone for inclusion. The ALSA
subsystem is part of the Linux kernel and so they must take of that
every component is working with their changes. This has nothing to do
with their CVS, because as I said, the kernel counts.
Regards
Marcel
-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Jonathan Paisley wrote:
> On 10 Aug 2004, at 16:51, James Courtier-Dutton wrote:
>> So, I suggest we might do better if we provide a number of different
>> ways to get sound to bluetooth devices, in order of preference.
>> 1) PCM as Carl suggests
>> 2) Bypass HCI stack and send SCO direct to USB devices. I don't think
>> one can do that for UART based devices. I don't know what is best for
>> PCI devices, as I have not looked at the PCI source code. I
>> concentrated on the USB source code when I tried before.
>> 3) Current HCI stack method. <- Last resort.
> Perhaps somebody with more bluetooth know-how can comment here, but:
>
> 1) I thought PCM was for connection from the bluetooth chip to some
> other hardware (e.g., a physical earpiece). That's not an option for
> getting audio to the computer unless the device in question has some
> funky other connection to the computer.
Correct. Our BT chips all have a PCM port which routes one
or more audio streams directly to external chips (usually audio codecs),
so the audio packets don't flow over HCI. (A SCO connection is
created, managed and destroyed over HCI, but the audio packets
run through the PCM port.) The PCM port connection is usually
used in dedicated audio devices: cell phones, headsets, etc.
Some of our chips include an audio codec, so they can directly drive
a microphone and earpiece. (The chips were designed to form the core
of a headset.) In this case, the SCO packets never leave the chip.
As far as I've seen, all BT chip manufacturers provide a PCM port.
The manufacturers' PCM ports are, inevitably, manufacturer-specific,
though they should all have a common core of functionality.
> 2) Isn't the SCO-over-USB standard defined in terms of the HCI
> protocol? How do you go about bypassing it?
I don't understand suggestion (2) above (HCI stack bypass). The
"standard" BT stack loses interest in SCO at HCI - it doesn't travel
through L2CAP, etc. One could conceive of routing an audio
sample stream to another device at, or just above, the host's USB
driver level. But this feels awfully like the "last resort"
option (3).
Carl
**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.
This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.
http://www.mimesweeper.com
**********************************************************************
-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
On 10 Aug 2004, at 16:51, James Courtier-Dutton wrote:
> So, I suggest we might do better if we provide a number of different=20=
> ways to get sound to bluetooth devices, in order of preference.
> 1) PCM as Carl suggests
> 2) Bypass HCI stack and send SCO direct to USB devices. I don't think=20=
> one can do that for UART based devices. I don't know what is best for=20=
> PCI devices, as I have not looked at the PCI source code. I=20
> concentrated on the USB source code when I tried before.
> 3) Current HCI stack method. <- Last resort.
=10Perhaps somebody with more bluetooth know-how can comment here, but:
1) I thought PCM was for connection from the bluetooth chip to some=20
other hardware (e.g., a physical earpiece). That's not an option for=20
getting audio to the computer unless the device in question has some=20
funky other connection to the computer.
2) Isn't the SCO-over-USB standard defined in terms of the HCI=20
protocol? How do you go about bypassing it?
-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Marcel Holtmann wrote:
>
> the point is in writing an ALSA driver and not changing the ALSA
> subsystem. The SCO driver is part of the Bluetooth subsystem and so it
> will go in by me. The ALSA subsystem provides an in-kernel API and that
> can be used without any acknowledge of the ALSA maintainer.
ALSA is very modularised. This separates the hardware specific driver
stuff from the more general alsa kernel code. So, if you write your own
ALSA driver hardware module, it will have to depend on other ALSA
modules. The only ALSA API that is going to be stable is the user land
alsa-lib, which talks to applications. Although the ALSA kernel API and
ALSA low level hardware driver API has not changed in some time, the
ALSA maintainer reserves the right to change it at any time without
having to warn people, as alsa-lib hides all the changes from users.
It is therefore a good idea to place any ALSA specific code in the ALSA
tree, so that the ALSA maintainers keep it's kernel API up to date.
This would then leave the BlueZ team to only have to worry about the
ALSA to BlueZ API.
>
>
>>I was just offering to help with the submission.
>
>
> Thanks, but going through the ALSA CVS won't give me any advantage. I
> hope that I can talk with Jaroslav about the Bluetooth issue at the
> Linux-Kongress next month.
He does actually answer emails as well. ;-)
>
> Regards
>
> Marcel
>
James
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Marcel Holtmann wrote:
| Hi Lars,
|
|>[STRUCTURE]
|>
|>so we get three parts, bluez kernel (BZ), user space daemon (USD) and
|>alsa driver (AD).
|
| actually only two parts are needed. The SCO kernel driver and a headset
| userspace daemon.
|
| The SCO module register the SCO socket and register for handling SCO
| packets with the BlueZ core. The SCO raw socket can be used for control
| other things. It can also register the ALSA device, because most stuff
| will be only moving data packets from the BlueZ core to ALSA and vice
| versa. So the SCO module will depend on the ALSA and BlueZ core.
|
| The other part is the userspace daemon that includes the SDP, RFCOMM, AT
| handling, ALSA setup etc.
hm, I can't say I agree. Maybe I'm just ignorant so I can't follow you here.
The advantage of splitting BZ kernel and alsa driver would be gaining
flexibility (i.e. people like me who can't use kernel alsa could stick
to alsa-driver...)
Of course I don't know that much about the internal processes, so if you
say it's a lot easier implemented like you propose, we should go for it.
I just find the idea strange to get an alsa sound device without loading
an alsa sound module - but after all the sco module will cover this, so
why not *shrug*.
|
|>[INTEROPERABILITY]
|>
|>There are two main sources that may demand things and that must be
|>supported:
|>1. the headset: if the user presses the button, an AT is send. This must
|>be caught by USD, that opens the SCO connection in the usual way. Now
|>some ioctl kernel mojo happens to make the SCO connection usable for
|>alsa programs (I'm not sure how it works, but is sounds easy)
|>
|>2. the AD itself: a program might open the audio channel, than the AD
|>must notice the USD (or BZ?) to ring the headset bell so the user
|>notices, or open the SCO channel directly, depending on configuration;
|>also we must be able to change volume and stuff.
|>
|>those two must be able to communicate in some way. The HS sends AT
|>commands that are handled by the USD, but how can the alsa driver i.e.
|>request an channel open? Or, from whom (USD or BZ?)
|
|
| If it is possible to poll the ALSA hwdep in some way this will be
| possible, but you must remeber that every kernel releated stuff will
| never be profile related. The kernel stuff is about protocol and all
| profile specific parts are done in userspace.
OK, so if we only have two parts, the BZ that handles alsa stuff two and
~ the user space daemon this is simplified because we only need to make
sure that USD and BZ can communicate (there won't be any AD any more ;)
One thing I don't get right now is this:
who of those two takes care of the alsa stuff, the user mode program or
the BZ code? I think of the functions like start/stop playback, get info
etc.pp. - the alsa driver functions. AFAIK an alsa driver must provide
this functions so that an application can use them. Where will they be
located?
|
|
|>Of course it's not that easy, but concerning the device existing problem
|>the device is reported by the alsa driver, and that one does not depend
|>on an existing RFCOMM connection or something
|
| Every SCO link depend on an existing ACL connection. In case of the
| headset and handsfree profiles these means no SCO link without the
| RFCOMM connection.
OK, I think we are not looking at the problem from the same site.
Of course there CAN'T be any SCO link. There can't be an RFCOMM link
either. But we *could* provide an interface that points into outer space
or something, so an application can read and write data to and from this
interface if no headset is present.
I don't know that much about simulating an audio socket (this is what
I'm talking about I think), and there will be some problems like timing
and stuff. But I think we have to do this anyway for two reasons:
a) I (yes, I :) want to be able to start gnomemeeting, noticing that my
headset is two stairs up. I want to fetch it, tell the userspace thingy
"look my headset <BTADDR>" and I don't want to tell my gnomemeeting that
it has to look again for audio interfaces. I think this would be a
feature and possible to achieve
b) again, just me: with the current solution the audio application locks
up if there is no open SCO socket available. Of course this is stupid,
and we'll have to address this if we want to have a solution for the "AG
requests connection [by opening alsa sound device for playback]". It's
not proper to lock the application until the user managed to activate
his headset by pressing that little button. Maybe he just wants to
cancel the call.
Sorry for picking at this, but it's important to me.
thanks for all people for your great interest, this looks really
promising :)
cu,
~ Lars
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFBGPGsQWC6DTWkDAoRAjU0AKCLZjNZ9uuwVgVxrYs26fmkgBJk4ACguIw2
qHR0pEXCGQ10rzgMQKmHbnE=
=r4OX
-----END PGP SIGNATURE-----
-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Carl Orsborn wrote:
> I know nothing of snd-bt-sco or alsa, so some of my comments
> below will doubtless expose my ignorance, but I know something
> of how CSR devices handle SCO traffic (or, at least, how
> they're *supposed* to handle SCO traffic).
>
> I can't find anything in this thread that reveals whether you're
> trying to send SCO traffic over USB or UART. The data handling
> for the two cases have subtle differences.
>
> Over USB, there's an isochronous connection - the bus provides
> capacity for 8 ksamples/second in each direction. If a CSR
> device somehow fails to receive SCO traffic from air it fills
> the embarrassing gap in the USB to-host flow with dummy
> data. Thus, the host continues to receive 8 ksamples/second.
>
> Over UART, the same compensation mechanism applies - the CSR
> device makes up data for any from-air gaps. This allows the
> host to match its tx sample rate to the connection's rx
> sample rate, and so removes the need for the host to maintain
> an accurate 8 kHz clock.
>
> The Bluetooth device has a pair of *small* ring buffers for each
> SCO connection - one for each direction. They are small to
> keep audio latency low; manufacturers of audio devices insist
> on low latency. Keeping latency low for audio traffic flowing
> over HCI (USB or UART) is hard. Most of our customers route
> SCO traffic over the Bluetooth device's separate audio interface
> (PCM port), bypassing the HCI transport.
>
> As I noted above, the USB/SCO path is isochronous. This means
> packets can be lost silently. If the path is carrying 16-bit
> samples (the normal case), and if a USB packet can hold an
> odd number of bytes, this can lead to a 1 byte offset in
> the audio stream. This sounds ghastly. We fixed this in the
> Bluetooth device's firmware ages ago - spotting the loss of
> sync by looking for SCO packet headers. However, many host
> USB device drivers can still suffer this problem.
>
> Much of this is discussed in CSR's "HCI Implementation" document,
> bcore-me-026, though this is normally only made available to
> CSR's (direct) customers.
>
> Regards,
>
> Carl
>
Carl seems to hint that sending SCO packets over HCI is hard achieve low
latency.
So this seems to support my assertions all this time, that sending HCI
SCO packets with the other HCI packets as we current do is going to fail.
So, I suggest we might do better if we provide a number of different
ways to get sound to bluetooth devices, in order of preference.
1) PCM as Carl suggests
2) Bypass HCI stack and send SCO direct to USB devices. I don't think
one can do that for UART based devices. I don't know what is best for
PCI devices, as I have not looked at the PCI source code. I concentrated
on the USB source code when I tried before.
3) Current HCI stack method. <- Last resort.
Cheers
James
-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Carl,
Thanks for adding your info to the discussion - much appreciated.
On Tue, 10 Aug 2004 3:26pm +0100, Carl Orsborn wrote:
> I can't find anything in this thread that reveals whether you're
> trying to send SCO traffic over USB or UART. The data handling
> for the two cases have subtle differences.
As far as I'm aware, we're dealing with USB only.
> Over USB, there's an isochronous connection - the bus provides
> capacity for 8 ksamples/second in each direction. If a CSR
> device somehow fails to receive SCO traffic from air it fills
> the embarrassing gap in the USB to-host flow with dummy
> data. Thus, the host continues to receive 8 ksamples/second.
>
> Over UART, the same compensation mechanism applies - the CSR
> device makes up data for any from-air gaps. This allows the
> host to match its tx sample rate to the connection's rx
> sample rate, and so removes the need for the host to maintain
> an accurate 8 kHz clock.
>
> As I noted above, the USB/SCO path is isochronous. This means
> packets can be lost silently. If the path is carrying 16-bit
Does this mean that it is sufficient to clock the outgoing data (with a
packet or two of buffering) according to the data received on the SCO
connection over USB? I suppose any dropouts due to the isochronous nature
of the (incoming) link will complicate this...
This is what the current (hack of a) driver does at the moment, minus the
extra buffering. Since the buffering is missing, there are dropouts which
I assume are being caused by data not being provided in time.
-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi James,
> I thought that if you wished to submit a BlueZ ALSA driver, you would be
> submitting it to the person mentioned in this record.
> SOUND
> P: Jaroslav Kysela
> M: [email protected]
> L: [email protected]
> S: Maintained
>
> I did not know that you could bypass that person to get a SOUND related
> item into the kernel.
the point is in writing an ALSA driver and not changing the ALSA
subsystem. The SCO driver is part of the Bluetooth subsystem and so it
will go in by me. The ALSA subsystem provides an in-kernel API and that
can be used without any acknowledge of the ALSA maintainer.
> I was just offering to help with the submission.
Thanks, but going through the ALSA CVS won't give me any advantage. I
hope that I can talk with Jaroslav about the Bluetooth issue at the
Linux-Kongress next month.
Regards
Marcel
-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Marcel Holtmann wrote:
> Hi James,
>
>
>>I can get modules added to the alsa cvs. I would think that newly
>>developed modules should go into cvs first, and then backported to older
>>kernel versions. After all, the only way to get snd-bt-sco into the
>>linux kernel proper, is via the alsa cvs.
>>There are various staging steps in the alsa cvs, before a module in the
>>alsa cvs gets into the linux kernel proper.
>
>
> why should this be? ALSA is part of the Linux 2.6 kernel and so I would
> submit a BlueZ ALSA driver for kernel inclusion only. I don't care about
> the ALSA CVS, because the ALSA CVS must track the kernel and not vice
> versa.
>
>
>>Of course the snd-bt-sco module will just be a bit of shim code between
>>alsa and blues. With the major work done in a user space bluetooth profile.
>>
>>One advantage of alsa, is that once a module is in the alsa cvs, it will
>>will always function correctly on all kernel versions, so back porting
>>is not an issue with alsa.
>
>
> Maybe I have to repeat it, but I don't care about the ALSA CVS and any
> older kernel versions. The current mainline kernel is the only base.
>
> Regards
>
> Marcel
>
>
I thought that if you wished to submit a BlueZ ALSA driver, you would be
submitting it to the person mentioned in this record.
SOUND
P: Jaroslav Kysela
M: [email protected]
L: [email protected]
S: Maintained
I did not know that you could bypass that person to get a SOUND related
item into the kernel.
I was just offering to help with the submission.
James
Hi Lars,
> Please, let me try it again:
ok, lets start over ;)
> [STRUCTURE]
>
> so we get three parts, bluez kernel (BZ), user space daemon (USD) and
> alsa driver (AD).
>
> kernel/bluez kernel stuff (BZ):
> This part resides in the kernel. It already does. It handles what
> happens to the devices, i.e. converts the SCO device into an alsa device
> node on request. It builds (not requests!) the connections for RFCOMM
> and SCO (of course, that is what it does now too).
>
> user space daemon (USD):
> requests headset RFCOMM connect (from the user, like "bthsd --connect
> <BTADDR>" or something alike, just an example) and handles the AT
> commands. This is what our btsco program does right now, but I'd like to
> have a real daemon here that is once started and then runs totally in
> the background. Most AT handling that is needed is already implemented.
>
> alsa driver (AD):
> the alsa-specific stuff, like reporting to alsa applications what
> channels exist, what audio props they have and so on
actually only two parts are needed. The SCO kernel driver and a headset
userspace daemon.
The SCO module register the SCO socket and register for handling SCO
packets with the BlueZ core. The SCO raw socket can be used for control
other things. It can also register the ALSA device, because most stuff
will be only moving data packets from the BlueZ core to ALSA and vice
versa. So the SCO module will depend on the ALSA and BlueZ core.
The other part is the userspace daemon that includes the SDP, RFCOMM, AT
handling, ALSA setup etc.
> [INTEROPERABILITY]
>
> There are two main sources that may demand things and that must be
> supported:
> 1. the headset: if the user presses the button, an AT is send. This must
> be caught by USD, that opens the SCO connection in the usual way. Now
> some ioctl kernel mojo happens to make the SCO connection usable for
> alsa programs (I'm not sure how it works, but is sounds easy)
>
> 2. the AD itself: a program might open the audio channel, than the AD
> must notice the USD (or BZ?) to ring the headset bell so the user
> notices, or open the SCO channel directly, depending on configuration;
> also we must be able to change volume and stuff.
>
> those two must be able to communicate in some way. The HS sends AT
> commands that are handled by the USD, but how can the alsa driver i.e.
> request an channel open? Or, from whom (USD or BZ?)
If it is possible to poll the ALSA hwdep in some way this will be
possible, but you must remeber that every kernel releated stuff will
never be profile related. The kernel stuff is about protocol and all
profile specific parts are done in userspace.
> Of course it's not that easy, but concerning the device existing problem
> the device is reported by the alsa driver, and that one does not depend
> on an existing RFCOMM connection or something, so it should be possible
> to load the "snd-bt-sco" alsa module (like it is now) so the program
> thinks that the driver exists. Audio data should be taken from /dev/null
> or something alike to make sure the application does not break when
> trying to access the dummy device.
Every SCO link depend on an existing ACL connection. In case of the
headset and handsfree profiles these means no SCO link without the
RFCOMM connection.
Regards
Marcel
-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Carl,
thanks for this additional information.
> Much of this is discussed in CSR's "HCI Implementation" document,
> bcore-me-026, though this is normally only made available to
> CSR's (direct) customers.
If this moves forward and we get a little group of people that are
looking at the ALSA driver and how we must extend the hci_usb driver and
maybe the BlueZ core, can we make this document available to them?
I also suggest to everyone who will work on this, that he buys himself a
D-Link DBT-120 (Rev. B2 or B3, but not B4) dongle and update it with the
Apple firmware to HCI 18.1 to get a newer firmware.
Regards
Marcel
-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Now from the alsa point of view.
Marcel Holtmann wrote:
> Hi Lars,
>
>
>>| Lets connect the SCO channel throught the socket interface and then tell
>>| the kernel via an IOCTL to change this into an ALSA device. We do the
>>| same for RFCOMM where we convert a socket into a TTY.
>>|
>>| Most of the snd-bt-sco source will be useless, because it handles the in
>>| kernel socket programming and you don't need that inside the SCO module.
>>
>>yes, of course, the basic connection handling will change. But we alsa
>>has some registration issues like, what encodings are supported, volume
>>change hooks and stuff.
>>
>>I think we'll get the following [correct me if I'm wrong]:
>>
>>BlueZ stuff:
>>- - connection handling (should this be solved like in the hidd daemon?)
>
>
> the connection handling is the AT based stuff of the headset or
> handsfree profile and that can be done in a headset/handsfree profile
> daemon. The hidd is different, because it has to move the L2CAP sockets
> into the kernel space. We don't need this here.
>
>
>>- - listening for incoming audio connection requests from the headset
>>(button press)
>
>
> It is part of the connection handling, because button press is an AT
> event on the RFCOMM channel.
Agreed, not anything alsa can do about it either. If a connection comes
from the headset, there is no way to channel this information via alsa
up to the application, so the application has to have a separate control
channel for these messages. E.g. ON/OFF Hook. But theoretically Volume
Up/down could be passed, and ON/OFF hook could be passed as a hidden
mixer control, but for other Bluetooth profiles, where dialed digits are
passed, there would be not method to pass those through alsa, so, in my
view, it is better not to use alsa for any of the RFCOMM messages, and
provice a separate messages link to the application for those.
>
>
>>- - listening for server audio connection requests from alsa
>
>
> This is also connection handling stuff. In this case you must wait for
> an incoming SCO connection (HS case). For the AG case you are in charge
> to create the SCO link.
So, you are suggesting that an app, opening an alsa pcm device should
automatically link up the RFCOMM channel etc, and be able to send sound
to a headset. That is unworkable for a number of different reasons. One
being that the app that opens the alsa pcm device should also be
controlling the RFCOMM channel separately, for reasons I gave above.
>
>
>>- - opening SCO connection, creating an alsa compatible device
>
>
> The same. Creating the ALSA device is only an IOCTL away. You should
> take a look at the source code of the rfcomm program to see how this is
> done for RFCOMM TTY devices.
The creation of an alsa device name should be linked to which bluetooth
device it is talking to. For example, once a pairing is set up, the user
application can always talk to the same alsa device name to send sound
to the headset, for every call to that headset. I.E. link alsa device
name to pairing, and not create a new one for each RFCOMM connection.
E.g. All SCO connectionns to headset A be called ./pcm0p/sub0 &
./pcm0c/sub0.
All SCO connections to headset B be called ./pcm1p/sub0 & ./pcm1c/sub0.
It is possible for an user space application to specifically use pcm0 or
pcm1, so that information could be passed from bluez to tell the
application which device to use for this call.
>
>
>>Alsa stuff:
>>- -provide alsa information like supported audio encodings
>
>
> the current settings of the SCO links are stored as voice_setting in the
> hci_dev structure.
alsa provides detailed ways for hardware to inform alsa which formats
the hardware can do. This information can be reset each time the alsa
pcm device is opened. alsa-lib will then automatically do format
conversion between the user application and what the hardware can do.
So, if a blues interface fixes all SCO connections to format X, but then
the format changes, alsa will sense that the next time a pcm device is
opened.
>
>
>>- -notice the BlueZ module if some program looks for a connection
>
>
> If you mean with that when someone opens the DSP device we should create
> the connection, then this will fail. The RFCOMM channel must be created
> first and this is part of the connection handling from userspace. The
> kernel can't do anything here.
Agreed, some of the reasons for this are explained above.
>
>
>>It would be great if a device (headset) could be connected somehow
>>(tool) manually like hidd --connect <BTADDR>; in this case, an RFCOMM
>>connection will be build.
>>
>>The bluez module than notices the alsa module that there spawned a new
>>device, telling alsa module what codecs to propagate (this should be
>>possible because something similar works for usb audio stuff with
>>hotplugging).
>
>
> The general workflow should be something like this:
>
> - create RFCOMM channel and start AT handling
> - create SCO socket if needed
> - issue ioctl to make SCO socket an ALSA device
Could the SCO socket be open and closed when the alsa pcm device is
opened and closed? Of course the SCO socket will fail to open, unless
the user space application has previously set up the RFCOMM channel.
The alsa api process goes:
open, set params, prepare, start...pass sound samples...stop, close.
It would be nice if SCO packets only happened at the "start" point, the
ceased at the "stop" point.
>
> At this point the SCO packets would go from the HCI device to the ALSA
> layer without userspace intervention and the userspace program has only
> to take care of the AT handling.
>
>
>>I see some problems when an application opens and closes the audio
>>channel rapidly (gnomemeeting does this when playing the ring sound);
>>maybe we could implement something like a release timeout before the SCO
>>connection is truely terminated.
>>
>>My mein issue with the current implementation is that if no SCO
>>connection is open, the audio device is simply blocked. Bad habit; it
>>must look transparent for the application, whether there is a BT headset
>>connected to the stack or not, the device should be available (I think).
>>Most programs check device state on startup, and the headset might not
>>be connected at that time by the user.
That is difficult, so you want to setup a link to the headset, start
playing sound, the headset goes out of range and the RFCOMM link times
out. But later the headset comes into range, and you want the headset
to start playing sound again, and during this time, the application can
happily keep sending samples to the alsa pcm device?
As Marcel says...not easy.
>
>
> This is not as easy as you think. Lets discuss this later.
>
> Regards
>
> Marcel
>
Hi Jonathan,
> > If you mean with that when someone opens the DSP device we should create
> > the connection, then this will fail. The RFCOMM channel must be created
> > first and this is part of the connection handling from userspace. The
> > kernel can't do anything here.
>
> A user space daemon can, however, keep a file descriptor open on the ALSA
> device's hwdep interface. The kernel driver could notify the daemon when
> an app opens the device, at which point the daemon can take a policy
> decision about attempting to connect to some default headset device (which
> eventually results in binding the SCO socket to the device).
>
> > The general workflow should be something like this:
> >
> > - create RFCOMM channel and start AT handling
> > - create SCO socket if needed
> > - issue ioctl to make SCO socket an ALSA device
>
> I think that the creation of ALSA devices and binding of SCO socket to an
> ALSA device should be separate operations. That way, an ALSA device can
> exist with no attached headset. Using the technique described above, that
> device can be demand-connected to a particular SCO socket.
if this works we may can implement something like "rfcomm bind ...". The
creation of the ALSA device can be handled through a SCO raw socket like
we did it for RFCOMM.
Regards
Marcel
-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi James,
> I can get modules added to the alsa cvs. I would think that newly
> developed modules should go into cvs first, and then backported to older
> kernel versions. After all, the only way to get snd-bt-sco into the
> linux kernel proper, is via the alsa cvs.
> There are various staging steps in the alsa cvs, before a module in the
> alsa cvs gets into the linux kernel proper.
why should this be? ALSA is part of the Linux 2.6 kernel and so I would
submit a BlueZ ALSA driver for kernel inclusion only. I don't care about
the ALSA CVS, because the ALSA CVS must track the kernel and not vice
versa.
> Of course the snd-bt-sco module will just be a bit of shim code between
> alsa and blues. With the major work done in a user space bluetooth profile.
>
> One advantage of alsa, is that once a module is in the alsa cvs, it will
> will always function correctly on all kernel versions, so back porting
> is not an issue with alsa.
Maybe I have to repeat it, but I don't care about the ALSA CVS and any
older kernel versions. The current mainline kernel is the only base.
Regards
Marcel
-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Marcel Holtmann wrote:
| Hi Lars,
|>BlueZ stuff:
|>- - connection handling (should this be solved like in the hidd daemon?)
|
|
| the connection handling is the AT based stuff of the headset or
| handsfree profile and that can be done in a headset/handsfree profile
| daemon. The hidd is different, because it has to move the L2CAP sockets
| into the kernel space. We don't need this here.
Well, I just ment from the user perspective, and it really looks nearly
identically to me. Of course what happens in the kernel is TOTALLY
different!
I agree with most other stuff you wrote, it was the same that I meant.
|>Alsa stuff:
|>- -provide alsa information like supported audio encodings
|
| the current settings of the SCO links are stored as voice_setting in the
| hci_dev structure.
|
Great. Not usable until the alsa module has read it from hci_dev and
reformatted it, so that an alsa application can make use of this
information. Yes? :)
|>- -notice the BlueZ module if some program looks for a connection
|
| If you mean with that when someone opens the DSP device we should create
| the connection, then this will fail. The RFCOMM channel must be created
| first and this is part of the connection handling from userspace. The
| kernel can't do anything here.
Uh, now this gets complicated. We should try to speak in the same terms.
I'm pretty sure it's my fault, but I'm a bit new to this stuff.
|>It would be great if a device (headset) could be connected somehow
|>(tool) manually like hidd --connect <BTADDR>; in this case, an RFCOMM
|>connection will be build.
|>
|>The bluez module than notices the alsa module that there spawned a new
|>device, telling alsa module what codecs to propagate (this should be
|>possible because something similar works for usb audio stuff with
|>hotplugging).
|
|
| The general workflow should be something like this:
|
| - create RFCOMM channel and start AT handling
| - create SCO socket if needed
| - issue ioctl to make SCO socket an ALSA device
|
| At this point the SCO packets would go from the HCI device to the ALSA
| layer without userspace intervention and the userspace program has only
| to take care of the AT handling.
Yes, that is what I meant, of course. But we should line out who (which
code/program) does what, because this is the main reason for
misunderstanding right now.
Please, let me try it again:
[STRUCTURE]
so we get three parts, bluez kernel (BZ), user space daemon (USD) and
alsa driver (AD).
kernel/bluez kernel stuff (BZ):
This part resides in the kernel. It already does. It handles what
happens to the devices, i.e. converts the SCO device into an alsa device
node on request. It builds (not requests!) the connections for RFCOMM
and SCO (of course, that is what it does now too).
user space daemon (USD):
requests headset RFCOMM connect (from the user, like "bthsd --connect
<BTADDR>" or something alike, just an example) and handles the AT
commands. This is what our btsco program does right now, but I'd like to
have a real daemon here that is once started and then runs totally in
the background. Most AT handling that is needed is already implemented.
alsa driver (AD):
the alsa-specific stuff, like reporting to alsa applications what
channels exist, what audio props they have and so on
[INTEROPERABILITY]
There are two main sources that may demand things and that must be
supported:
1. the headset: if the user presses the button, an AT is send. This must
be caught by USD, that opens the SCO connection in the usual way. Now
some ioctl kernel mojo happens to make the SCO connection usable for
alsa programs (I'm not sure how it works, but is sounds easy)
2. the AD itself: a program might open the audio channel, than the AD
must notice the USD (or BZ?) to ring the headset bell so the user
notices, or open the SCO channel directly, depending on configuration;
also we must be able to change volume and stuff.
those two must be able to communicate in some way. The HS sends AT
commands that are handled by the USD, but how can the alsa driver i.e.
request an channel open? Or, from whom (USD or BZ?)
|>I see some problems when an application opens and closes the audio
|>channel rapidly (gnomemeeting does this when playing the ring sound);
|>maybe we could implement something like a release timeout before the SCO
|>connection is truely terminated.
|>
|>My main issue with the current implementation is that if no SCO
|>connection is open, the audio device is simply blocked. Bad habit; it
|>must look transparent for the application, whether there is a BT headset
|>connected to the stack or not, the device should be available (I think).
|>Most programs check device state on startup, and the headset might not
|>be connected at that time by the user.
|
|
| This is not as easy as you think. Lets discuss this later.
Of course it's not that easy, but concerning the device existing problem
the device is reported by the alsa driver, and that one does not depend
on an existing RFCOMM connection or something, so it should be possible
to load the "snd-bt-sco" alsa module (like it is now) so the program
thinks that the driver exists. Audio data should be taken from /dev/null
or something alike to make sure the application does not break when
trying to access the dummy device.
Of course this should not be our first concern, but I think it's a good
idea to think of such things before beginning development...
cu,
~ Lars
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFBGNnsQWC6DTWkDAoRAvENAJ9bst1uL+oDjFXM/V9ioCzzcklgCgCffTVQ
8FDDQp18ZuM3j3w/KTHvdps=
=gqoc
-----END PGP SIGNATURE-----
-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Marcel,
On Tue, 10 Aug 2004 4:36pm +0200, Marcel Holtmann wrote:
>>> The general workflow should be something like this:
>>>
>>> - create RFCOMM channel and start AT handling
>>> - create SCO socket if needed
>>> - issue ioctl to make SCO socket an ALSA device
>>
>> I think that the creation of ALSA devices and binding of SCO socket to an
>> ALSA device should be separate operations. That way, an ALSA device can
>> exist with no attached headset. Using the technique described above, that
>> device can be demand-connected to a particular SCO socket.
>
> if this works we may can implement something like "rfcomm bind ...". The
> creation of the ALSA device can be handled through a SCO raw socket like
> we did it for RFCOMM.
Sounds ideal. Now we need to find somebody with enough time to implement
it! :)
I know nothing of snd-bt-sco or alsa, so some of my comments
below will doubtless expose my ignorance, but I know something
of how CSR devices handle SCO traffic (or, at least, how
they're *supposed* to handle SCO traffic).
I can't find anything in this thread that reveals whether you're
trying to send SCO traffic over USB or UART. The data handling
for the two cases have subtle differences.
Over USB, there's an isochronous connection - the bus provides
capacity for 8 ksamples/second in each direction. If a CSR
device somehow fails to receive SCO traffic from air it fills
the embarrassing gap in the USB to-host flow with dummy
data. Thus, the host continues to receive 8 ksamples/second.
Over UART, the same compensation mechanism applies - the CSR
device makes up data for any from-air gaps. This allows the
host to match its tx sample rate to the connection's rx
sample rate, and so removes the need for the host to maintain
an accurate 8 kHz clock.
The Bluetooth device has a pair of *small* ring buffers for each
SCO connection - one for each direction. They are small to
keep audio latency low; manufacturers of audio devices insist
on low latency. Keeping latency low for audio traffic flowing
over HCI (USB or UART) is hard. Most of our customers route
SCO traffic over the Bluetooth device's separate audio interface
(PCM port), bypassing the HCI transport.
As I noted above, the USB/SCO path is isochronous. This means
packets can be lost silently. If the path is carrying 16-bit
samples (the normal case), and if a USB packet can hold an
odd number of bytes, this can lead to a 1 byte offset in
the audio stream. This sounds ghastly. We fixed this in the
Bluetooth device's firmware ages ago - spotting the loss of
sync by looking for SCO packet headers. However, many host
USB device drivers can still suffer this problem.
Much of this is discussed in CSR's "HCI Implementation" document,
bcore-me-026, though this is normally only made available to
CSR's (direct) customers.
Regards,
Carl
Jonathan Paisley wrote:
> On Tue, 10 Aug 2004 1:53pm +0100, James Courtier-Dutton wrote:
>
>> 4) SCO then waits until SCO has finished (2), and only then takes X
>> samples from the ring buffer, creates a SCO packet, and sends it to
>> the hardware...then repeats.
>> 5) Add a SCO api call, so that the higher level module can find out
>> how much of the SCO packet has been output, and thus return accurate
>> hardware pointer values.
>
>
> Is this additional api call necessary? Suppose packets are about 24
> bytes (that's what I remember them to be). So the suggestion is to have
> two of these in flight at a time. Given 8000 Hz sampling rate (equating
> to 8000 or 16000 bytes per second if using 8bit or 16bit PCM,
> respectively), those 24 bytes correspond to between 1.5 and 3ms.
>
> In summary: isn't it sufficient to just keep track of what packets have
> been sent? This gives 3ms accuracy.
>
> Thanks.
**********************************************************************
The information transmitted is intended only for the person or
entity to which it is addressed and may contain confidential
and/or privileged material.
Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by
persons or entities other than the intended recipient is
prohibited.
If you received this in error, please contact the sender and
delete the material from any computer.
**********************************************************************
-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Marcel Holtmann wrote:
> Hi James,
>
>
>>>I prefer the ALSA integration would be written from scratch, because the
>>>original driver was written for a 2.4 kernel and we must concentrate on
>>>the 2.6 series. The ALSA subsytem will be cleaned up in the next kernel
>>>releases and the magic casting stuff they do is still wrong.
>>
>>The latest alsa cvs fixes the magic casting stuff.
>
>
> as I said, I don't care about what is in the ALSA CVS or their external
> drivers. The main focus is the ALSA subsystem in the mainline kernel.
>
> So everone who will work on this have this in mind and start with the
> latest 2.6 kernel. If the ALSA stuff in their CVS is newer, then ping
> them to merge it mainline.
>
> Regards
>
> Marcel
>
I can get modules added to the alsa cvs. I would think that newly
developed modules should go into cvs first, and then backported to older
kernel versions. After all, the only way to get snd-bt-sco into the
linux kernel proper, is via the alsa cvs.
There are various staging steps in the alsa cvs, before a module in the
alsa cvs gets into the linux kernel proper.
Of course the snd-bt-sco module will just be a bit of shim code between
alsa and blues. With the major work done in a user space bluetooth profile.
One advantage of alsa, is that once a module is in the alsa cvs, it will
will always function correctly on all kernel versions, so back porting
is not an issue with alsa.
James
Lars Grunewaldt wrote:
> Jonathan Paisley wrote:
>
> | I haven't been keeping track of ALSA development recently. It sounds
> | like you're saying that the API is going to be changing enough that
> | simple modifications to the existing ALSA-interfacing code in snd-bt-sco
> | will not be enough to keep it up to date. Does this mean it would be
> | worth putting a hold on development of a properly-bluez-integrated
> | driver until the ALSA subsystem has stabilised?
The ALSA kernel driver subsystem has not changed at all(or maybe very
minor bits), so the old snd-bt-sco will probably still work. What has
changed is the obvious stuff, like what is needed to convert any kernel
2.4.x module to 2.6.x.
>
> possibly, I don't know that their status is either. snd-bt-sco compiles
> nice with kernel 2.6.7 (well nice... at least it does (Niko)) and also
> with alsa-driver-1.0.5a (myself)...
>
> I'll try to take the time to read through the alsa dev information to
> find out what's going on there, but Marcel will be much more in touch
> with the kernel-related stuff.
>
> At least I managed to get and look into the headset profile, that
> already helped much to clear things up :)
>
> cu,
> ~ Lars
I have developed other alsa-kernel drivers, so I can help on alsa kernel
specific questions, although I don't currently have any time to write
and bluetooth/sco code.
-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi James,
> > I prefer the ALSA integration would be written from scratch, because the
> > original driver was written for a 2.4 kernel and we must concentrate on
> > the 2.6 series. The ALSA subsytem will be cleaned up in the next kernel
> > releases and the magic casting stuff they do is still wrong.
>
> The latest alsa cvs fixes the magic casting stuff.
as I said, I don't care about what is in the ALSA CVS or their external
drivers. The main focus is the ALSA subsystem in the mainline kernel.
So everone who will work on this have this in mind and start with the
latest 2.6 kernel. If the ALSA stuff in their CVS is newer, then ping
them to merge it mainline.
Regards
Marcel
-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Lars,
> | Lets connect the SCO channel throught the socket interface and then tell
> | the kernel via an IOCTL to change this into an ALSA device. We do the
> | same for RFCOMM where we convert a socket into a TTY.
> |
> | Most of the snd-bt-sco source will be useless, because it handles the in
> | kernel socket programming and you don't need that inside the SCO module.
>
> yes, of course, the basic connection handling will change. But we alsa
> has some registration issues like, what encodings are supported, volume
> change hooks and stuff.
>
> I think we'll get the following [correct me if I'm wrong]:
>
> BlueZ stuff:
> - - connection handling (should this be solved like in the hidd daemon?)
the connection handling is the AT based stuff of the headset or
handsfree profile and that can be done in a headset/handsfree profile
daemon. The hidd is different, because it has to move the L2CAP sockets
into the kernel space. We don't need this here.
> - - listening for incoming audio connection requests from the headset
> (button press)
It is part of the connection handling, because button press is an AT
event on the RFCOMM channel.
> - - listening for server audio connection requests from alsa
This is also connection handling stuff. In this case you must wait for
an incoming SCO connection (HS case). For the AG case you are in charge
to create the SCO link.
> - - opening SCO connection, creating an alsa compatible device
The same. Creating the ALSA device is only an IOCTL away. You should
take a look at the source code of the rfcomm program to see how this is
done for RFCOMM TTY devices.
> Alsa stuff:
> - -provide alsa information like supported audio encodings
the current settings of the SCO links are stored as voice_setting in the
hci_dev structure.
> - -notice the BlueZ module if some program looks for a connection
If you mean with that when someone opens the DSP device we should create
the connection, then this will fail. The RFCOMM channel must be created
first and this is part of the connection handling from userspace. The
kernel can't do anything here.
> It would be great if a device (headset) could be connected somehow
> (tool) manually like hidd --connect <BTADDR>; in this case, an RFCOMM
> connection will be build.
>
> The bluez module than notices the alsa module that there spawned a new
> device, telling alsa module what codecs to propagate (this should be
> possible because something similar works for usb audio stuff with
> hotplugging).
The general workflow should be something like this:
- create RFCOMM channel and start AT handling
- create SCO socket if needed
- issue ioctl to make SCO socket an ALSA device
At this point the SCO packets would go from the HCI device to the ALSA
layer without userspace intervention and the userspace program has only
to take care of the AT handling.
> I see some problems when an application opens and closes the audio
> channel rapidly (gnomemeeting does this when playing the ring sound);
> maybe we could implement something like a release timeout before the SCO
> connection is truely terminated.
>
> My mein issue with the current implementation is that if no SCO
> connection is open, the audio device is simply blocked. Bad habit; it
> must look transparent for the application, whether there is a BT headset
> connected to the stack or not, the device should be available (I think).
> Most programs check device state on startup, and the headset might not
> be connected at that time by the user.
This is not as easy as you think. Lets discuss this later.
Regards
Marcel
-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
On Tue, 10 Aug 2004 3:45pm +0200, Marcel Holtmann wrote:
>> - -notice the BlueZ module if some program looks for a connection
>
> If you mean with that when someone opens the DSP device we should create
> the connection, then this will fail. The RFCOMM channel must be created
> first and this is part of the connection handling from userspace. The
> kernel can't do anything here.
A user space daemon can, however, keep a file descriptor open on the ALSA
device's hwdep interface. The kernel driver could notify the daemon when
an app opens the device, at which point the daemon can take a policy
decision about attempting to connect to some default headset device (which
eventually results in binding the SCO socket to the device).
> The general workflow should be something like this:
>
> - create RFCOMM channel and start AT handling
> - create SCO socket if needed
> - issue ioctl to make SCO socket an ALSA device
I think that the creation of ALSA devices and binding of SCO socket to an
ALSA device should be separate operations. That way, an ALSA device can
exist with no attached headset. Using the technique described above, that
device can be demand-connected to a particular SCO socket.
Marcel Holtmann wrote:
>
>
> I prefer the ALSA integration would be written from scratch, because the
> original driver was written for a 2.4 kernel and we must concentrate on
> the 2.6 series. The ALSA subsytem will be cleaned up in the next kernel
> releases and the magic casting stuff they do is still wrong.
>
> Regards
>
> Marcel
>
>
The latest alsa cvs fixes the magic casting stuff.
Hi Lars,
> | do it as you like, but remember that I hate cross-postings accross
> | mailing lists.
>
> me too. Much. It's useless. I'm pretty sure that the more you are
> involved, the more development issues will be discussed on bluez-devel.
>
> I just feel the need to drag some people into this because for one thing
> development is not really going forward, but I think there are many
> people picking an the problems. That's not good, because I think only
> cooperation brings good results.
>
> I hope we can find a proper and nice solution soon, because I'm using
> the headset already in day-to-day phone calling, and the faster it gets
> stable, the less annoyed will be the people I'm talking to.
go ahead and don't forget to add me to that mailing list.
Regards
Marcel
-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
On Tue, 10 Aug 2004 1:53pm +0100, James Courtier-Dutton wrote:
> 4) SCO then waits until SCO has finished (2), and only then takes X samples
> from the ring buffer, creates a SCO packet, and sends it to the
> hardware...then repeats.
> 5) Add a SCO api call, so that the higher level module can find out how much
> of the SCO packet has been output, and thus return accurate hardware pointer
> values.
Is this additional api call necessary? Suppose packets are about 24 bytes
(that's what I remember them to be). So the suggestion is to have two of
these in flight at a time. Given 8000 Hz sampling rate (equating to 8000
or 16000 bytes per second if using 8bit or 16bit PCM, respectively), those
24 bytes correspond to between 1.5 and 3ms.
In summary: isn't it sufficient to just keep track of what packets have
been sent? This gives 3ms accuracy.
Thanks.
Hi Jonathan,
> > the point is that dropping packets and generating zero packets is
> > already part of the Bluetooth chip. This means we will get a correct
> > stream from the hardware and we must only make sure that we deliver our
> > packets in time as long as the hardware is able to buffer it.
>
> Agreed. The problem I've seen is due to the driver not providing packets
> in time to the SCO layer. As such, the hardware doesn't get a chance to
> buffer.
there is also a flow control for SCO packets if my memory don't play
tricks with me. However I think that we should not worry about this too
much at the moment. If we ran into problems then we can think about how
we can fix them.
> > I prefer the ALSA integration would be written from scratch, because the
> > original driver was written for a 2.4 kernel and we must concentrate on
> > the 2.6 series. The ALSA subsytem will be cleaned up in the next kernel
> > releases and the magic casting stuff they do is still wrong.
>
> I haven't been keeping track of ALSA development recently. It sounds like
> you're saying that the API is going to be changing enough that simple
> modifications to the existing ALSA-interfacing code in snd-bt-sco will not
> be enough to keep it up to date. Does this mean it would be worth putting
> a hold on development of a properly-bluez-integrated driver until the ALSA
> subsystem has stabilised?
I don't know how much of the API will be really changed, but actually
some parts can be done much easier. My point is that I get a clean
driver in the end. The focus is the ALSA of a recent 2.6.8 kernel or
later and nothing before. If we must change something in the ALSA
library or tools only for adding another driver, this is a sign that
something has designed in a wrong way.
Regards
Marcel
-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Jonathan Paisley wrote:
| I haven't been keeping track of ALSA development recently. It sounds
| like you're saying that the API is going to be changing enough that
| simple modifications to the existing ALSA-interfacing code in snd-bt-sco
| will not be enough to keep it up to date. Does this mean it would be
| worth putting a hold on development of a properly-bluez-integrated
| driver until the ALSA subsystem has stabilised?
possibly, I don't know that their status is either. snd-bt-sco compiles
nice with kernel 2.6.7 (well nice... at least it does (Niko)) and also
with alsa-driver-1.0.5a (myself)...
I'll try to take the time to read through the alsa dev information to
find out what's going on there, but Marcel will be much more in touch
with the kernel-related stuff.
At least I managed to get and look into the headset profile, that
already helped much to clear things up :)
cu,
~ Lars
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFBGMv9QWC6DTWkDAoRAlCXAJwMq2qXbuqm2+zKqN2MSGKvb73mjgCbB7zw
8TqZ9t4iMRlrOk7oWiJ5QOo=
=aO9i
-----END PGP SIGNATURE-----
-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Marcel Holtmann wrote:
|>As far as the existing snd-bt-sco source goes, I think there's a
|>significant amount of code that can be saved. Most of the code is dealing
|>with the ALSA integration, management of the mixer and pcm interfaces
etc.
|>The kernel thread that does the socket programming can be ripped out
|>(along with the ioctl handlers that set it up) and replaced with
|>timer-driven code which talks directly to the SCO module.
|
|
| I prefer the ALSA integration would be written from scratch, because the
| original driver was written for a 2.4 kernel and we must concentrate on
| the 2.6 series. The ALSA subsytem will be cleaned up in the next kernel
| releases and the magic casting stuff they do is still wrong.
Hm, OK if someone has the time to do this. I might have, if I do some
work on this as my final work for my study. Maybe I'll have to talk
about this with some professors. But I think it's not crazy enough to
make me happy with it ;)
Anyway, we'll get this. It's not like an alsa module is that hard to
write, even from scratch.
cu,
~ Lars
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFBGMsmQWC6DTWkDAoRArdpAKDG9djRipQay4i1/PRWBBiqFVZnZwCfeFGi
CoKHPJLgWaZRP62jgqFlu3g=
=wXN3
-----END PGP SIGNATURE-----
-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Marcel Holtmann wrote:
| Hi Lars,
|
|
|>| I actually prefer that you discuss this on the bluez-devel mailing list,
|>| because you may need to change BlueZ core parts and most of this will be
|>| kernel related stuff and this should belong here.
|>
|>I know, and I voted for that too. But I also feel that we need to
|>discuss some lineup questions first that might me just fuzz for the
|>BlueZ list, so I think it's good to start seperatly.
|>
|>We'll post and discuss BlueZ-specific stuff on the bluez-devel list, and
|>propably the other one will die sooner or later. But for now I think
|>it's a good way to make up our minds first.
|
|
| do it as you like, but remember that I hate cross-postings accross
| mailing lists.
me too. Much. It's useless. I'm pretty sure that the more you are
involved, the more development issues will be discussed on bluez-devel.
I just feel the need to drag some people into this because for one thing
development is not really going forward, but I think there are many
people picking an the problems. That's not good, because I think only
cooperation brings good results.
I hope we can find a proper and nice solution soon, because I'm using
the headset already in day-to-day phone calling, and the faster it gets
stable, the less annoyed will be the people I'm talking to.
regards,
~ Lars
YAY, CANT HEAR ME AGAIN? SORRY, MY HEADSET IS MESSED UP AGAIN BECAUSE IT
DROPPED ONE BYTE... ;)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFBGMleQWC6DTWkDAoRAq0iAKC7cClewBhf1tyOaGngcbjXoMvC1QCfUXNY
AfUFeOse8WDNSsZvVjblnio=
=1RlX
-----END PGP SIGNATURE-----
-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Jonathan,
> > and the snd-bt-sco driver uses socket programming from within a kernel
> > thread. If we remove that and include it directly into the SCO driver I
> > think we have all what we need ;)
>
> I'll chime in here to say that I agree with this too! (as the original
> author of the snd-bt-sco hack).
>
> I'd also mention that I didn't find latency to be a problem, but I know
> that there are issues resulting from lack of buffering that cause audio
> dropouts for the listener. This lack of buffering, however, is a result of
> the design of the driver and not a fundamental limitation in bluez.
the point is that dropping packets and generating zero packets is
already part of the Bluetooth chip. This means we will get a correct
stream from the hardware and we must only make sure that we deliver our
packets in time as long as the hardware is able to buffer it.
> > Lets connect the SCO channel throught the socket interface and then tell
> > the kernel via an IOCTL to change this into an ALSA device. We do the
> > same for RFCOMM where we convert a socket into a TTY.
> >
> > Most of the snd-bt-sco source will be useless, because it handles the in
> > kernel socket programming and you don't need that inside the SCO module.
>
> Again, this sounds like a reasonable way to do things. I'd imagine that
> the ALSA device will have to hang around in the absence of an active SCO
> connection in order that programs using the device can keep it open while
> a headset comes and goes. Therefore it'd be necessary to have a mechanism
> to dynamically create ALSA devices, and another for binding active SCO
> sockets to those devices.
>
> As far as the existing snd-bt-sco source goes, I think there's a
> significant amount of code that can be saved. Most of the code is dealing
> with the ALSA integration, management of the mixer and pcm interfaces etc.
> The kernel thread that does the socket programming can be ripped out
> (along with the ioctl handlers that set it up) and replaced with
> timer-driven code which talks directly to the SCO module.
I prefer the ALSA integration would be written from scratch, because the
original driver was written for a 2.4 kernel and we must concentrate on
the 2.6 series. The ALSA subsytem will be cleaned up in the next kernel
releases and the magic casting stuff they do is still wrong.
Regards
Marcel
-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
On Tue, 10 Aug 2004 3:11pm +0200, Marcel Holtmann wrote:
>> I'd also mention that I didn't find latency to be a problem, but I know
>> that there are issues resulting from lack of buffering that cause audio
>> dropouts for the listener. This lack of buffering, however, is a result of
>> the design of the driver and not a fundamental limitation in bluez.
>
> the point is that dropping packets and generating zero packets is
> already part of the Bluetooth chip. This means we will get a correct
> stream from the hardware and we must only make sure that we deliver our
> packets in time as long as the hardware is able to buffer it.
Agreed. The problem I've seen is due to the driver not providing packets
in time to the SCO layer. As such, the hardware doesn't get a chance to
buffer.
>> As far as the existing snd-bt-sco source goes, I think there's a
>> significant amount of code that can be saved. Most of the code is dealing
>> with the ALSA integration, management of the mixer and pcm interfaces etc.
>> The kernel thread that does the socket programming can be ripped out
>> (along with the ioctl handlers that set it up) and replaced with
>> timer-driven code which talks directly to the SCO module.
>
> I prefer the ALSA integration would be written from scratch, because the
> original driver was written for a 2.4 kernel and we must concentrate on
> the 2.6 series. The ALSA subsytem will be cleaned up in the next kernel
> releases and the magic casting stuff they do is still wrong.
I haven't been keeping track of ALSA development recently. It sounds like
you're saying that the API is going to be changing enough that simple
modifications to the existing ALSA-interfacing code in snd-bt-sco will not
be enough to keep it up to date. Does this mean it would be worth putting
a hold on development of a properly-bluez-integrated driver until the ALSA
subsystem has stabilised?
Hi Lars,
> | I actually prefer that you discuss this on the bluez-devel mailing list,
> | because you may need to change BlueZ core parts and most of this will be
> | kernel related stuff and this should belong here.
>
> I know, and I voted for that too. But I also feel that we need to
> discuss some lineup questions first that might me just fuzz for the
> BlueZ list, so I think it's good to start seperatly.
>
> We'll post and discuss BlueZ-specific stuff on the bluez-devel list, and
> propably the other one will die sooner or later. But for now I think
> it's a good way to make up our minds first.
do it as you like, but remember that I hate cross-postings accross
mailing lists.
Regards
Marcel
-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Marcel Holtmann wrote:
|>Marcel, what exactly do you mean by "implementing an alsa interface"?
|>Should there be an interface [like SCO] that is than accessed by an
|>additional alsa driver?
|>
|>Maybe it would be possible to use some of the snd-bt-sco code here,
|>because only the userspace daemon that "wraps" the sound sockets
|>together must be "integrated" (well, it's functionality) into BlueZ,
|>while the snd-bt-sco alsa driver could remain nearly the same, just
|>accessing the BlueZ/alsa interface instead of BlueZ/SCO?
|
|
| Lets connect the SCO channel throught the socket interface and then tell
| the kernel via an IOCTL to change this into an ALSA device. We do the
| same for RFCOMM where we convert a socket into a TTY.
|
| Most of the snd-bt-sco source will be useless, because it handles the in
| kernel socket programming and you don't need that inside the SCO module.
yes, of course, the basic connection handling will change. But we alsa
has some registration issues like, what encodings are supported, volume
change hooks and stuff.
I think we'll get the following [correct me if I'm wrong]:
BlueZ stuff:
- - connection handling (should this be solved like in the hidd daemon?)
- - listening for incoming audio connection requests from the headset
(button press)
- - listening for server audio connection requests from alsa
- - opening SCO connection, creating an alsa compatible device
Alsa stuff:
- -provide alsa information like supported audio encodings
- -notice the BlueZ module if some program looks for a connection
It would be great if a device (headset) could be connected somehow
(tool) manually like hidd --connect <BTADDR>; in this case, an RFCOMM
connection will be build.
The bluez module than notices the alsa module that there spawned a new
device, telling alsa module what codecs to propagate (this should be
possible because something similar works for usb audio stuff with
hotplugging).
two cases (as they are also described in the Headset Profile):
1. AG connects to HS (like, some program opened our audio device) - ring
the bell so that the user knows there sould be a connection initiated by
pressing the button
2. auto-connect: AG connects to HS, simply build the SCO channel. this
should be an option. Don't wait for user button press (might be
interesting for programs that play a ring sound via audio on the headset)
3. HS connects to AG: build a SCO connection.
4. we should have some (simple) way to tell the audio/bluez interface to
"ring", so that a program like gnomemeeting could be enhanced to use the
bt-internal ring tone for connection request instead of playing a true
audio sound
I see some problems when an application opens and closes the audio
channel rapidly (gnomemeeting does this when playing the ring sound);
maybe we could implement something like a release timeout before the SCO
connection is truely terminated.
My mein issue with the current implementation is that if no SCO
connection is open, the audio device is simply blocked. Bad habit; it
must look transparent for the application, whether there is a BT headset
connected to the stack or not, the device should be available (I think).
Most programs check device state on startup, and the headset might not
be connected at that time by the user.
just my 2 cents :)
- - Lars
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFBGMX8QWC6DTWkDAoRAoJDAKCKU8X5/ksEJjEXohjZ3U68P8TaIwCeIgB9
MMsXRaxv6JRFVnUiRDu+5a4=
=/w2t
-----END PGP SIGNATURE-----
-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
On Tue, 10 Aug 2004 2:14pm +0200, Marcel Holtmann wrote:
>> | Actually you think that we need it, but I am still not sure that this is
>> | really needed in case of the concept of the SCO packet from the HCI and
>> | the SCO handling that is done on link manager/chip level. However you
>> | can still convince me with real code.
>>
>> I have to agree with Marcel here. I've been using snd-bt-sco for a while
>> now with my HBH-35 Sony Ericsson Headset, and it works pretty well. Of
>> course I don't know much about how audio is processed here, but the
>> snd-bt-sco layer simply connects the sco socket to the alsa audio
>> socket. There's not much stuff about full duplex or low latency done,
>> I'm pretty sure I'd have noticed.
>
> and the snd-bt-sco driver uses socket programming from within a kernel
> thread. If we remove that and include it directly into the SCO driver I
> think we have all what we need ;)
I'll chime in here to say that I agree with this too! (as the original
author of the snd-bt-sco hack).
I'd also mention that I didn't find latency to be a problem, but I know
that there are issues resulting from lack of buffering that cause audio
dropouts for the listener. This lack of buffering, however, is a result of
the design of the driver and not a fundamental limitation in bluez.
>> Maybe it would be possible to use some of the snd-bt-sco code here,
>> because only the userspace daemon that "wraps" the sound sockets
>> together must be "integrated" (well, it's functionality) into BlueZ,
>> while the snd-bt-sco alsa driver could remain nearly the same, just
>> accessing the BlueZ/alsa interface instead of BlueZ/SCO?
>
> Lets connect the SCO channel throught the socket interface and then tell
> the kernel via an IOCTL to change this into an ALSA device. We do the
> same for RFCOMM where we convert a socket into a TTY.
>
> Most of the snd-bt-sco source will be useless, because it handles the in
> kernel socket programming and you don't need that inside the SCO module.
Again, this sounds like a reasonable way to do things. I'd imagine that
the ALSA device will have to hang around in the absence of an active SCO
connection in order that programs using the device can keep it open while
a headset comes and goes. Therefore it'd be necessary to have a mechanism
to dynamically create ALSA devices, and another for binding active SCO
sockets to those devices.
As far as the existing snd-bt-sco source goes, I think there's a
significant amount of code that can be saved. Most of the code is dealing
with the ALSA integration, management of the mixer and pcm interfaces etc.
The kernel thread that does the socket programming can be ripped out
(along with the ioctl handlers that set it up) and replaced with
timer-driven code which talks directly to the SCO module.
I don't know if this will help, but I will itemise the requirements that
and alsa driver will need:
1) A ring buffer, that is then broken up into 2 or more chunks called
periods. The userland application will set the buffer_size and period_size.
2) An interrupt or callback routine is called as each period reaches the
headset speakers, same for capture from headset mic.
3) A hardware pointer value, that can be read at any time, and returns
the current sample being played by the speakers, or as close as possible
to it.
4) Latency between samples leaving the ring buffer and being played to
the speakers should be as small as possible. This should be less than
10ms. Optimum low latency is achieved using 2 periods per buffer.
5) The rate at which samples leave the ring buffer should be constant,
and ideally under hardware control.
My suggestion for the SCO channel, is to use a fixed number, normally 2,
of SCO packets in a loop.
1) User app fills buffer.
2) SCO takes X samples from ring buffer, creates a SCO packet, and sends
it to the hardware.
3) SCO takes X more samples from the ring buffer, creates another SCO
packet, and sends it to the hardware.
4) SCO then waits until SCO has finished (2), and only then takes X
samples from the ring buffer, creates a SCO packet, and sends it to the
hardware...then repeats.
5) Add a SCO api call, so that the higher level module can find out how
much of the SCO packet has been output, and thus return accurate
hardware pointer values.
In this way there are only ever 2 SCO packets in the pipeline.
It fixes the latency, and we always have an accurate idea of which
sample is currently being played.
Summary: Limit the size of the SCO packet buffer to 2 packets, or some
fixed even value.
Cheers
James
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Marcel Holtmann wrote:
| Hi Lars,
|>for those who are interested in further development of former snd-bt-sco
|>and now bluetooth-alsa connection (project name not ready ;) we made a
|>mailing list to exchange early thoughts.
|
|
| I actually prefer that you discuss this on the bluez-devel mailing list,
| because you may need to change BlueZ core parts and most of this will be
| kernel related stuff and this should belong here.
I know, and I voted for that too. But I also feel that we need to
discuss some lineup questions first that might me just fuzz for the
BlueZ list, so I think it's good to start seperatly.
We'll post and discuss BlueZ-specific stuff on the bluez-devel list, and
propably the other one will die sooner or later. But for now I think
it's a good way to make up our minds first.
CU,
~ Lars
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFBGMIpQWC6DTWkDAoRAsOIAJwL+eKvuybhnt3VvX8P9Rw7bLnwrwCgmDaS
1jvapZrjdAMuEzg8TcbNfZo=
=j9II
-----END PGP SIGNATURE-----
-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Lars,
> | Actually you think that we need it, but I am still not sure that this is
> | really needed in case of the concept of the SCO packet from the HCI and
> | the SCO handling that is done on link manager/chip level. However you
> | can still convince me with real code.
>
> I have to agree with Marcel here. I've been using snd-bt-sco for a while
> now with my HBH-35 Sony Ericsson Headset, and it works pretty well. Of
> course I don't know much about how audio is processed here, but the
> snd-bt-sco layer simply connects the sco socket to the alsa audio
> socket. There's not much stuff about full duplex or low latency done,
> I'm pretty sure I'd have noticed.
and the snd-bt-sco driver uses socket programming from within a kernel
thread. If we remove that and include it directly into the SCO driver I
think we have all what we need ;)
> Marcel, what exactly do you mean by "implementing an alsa interface"?
> Should there be an interface [like SCO] that is than accessed by an
> additional alsa driver?
>
> Maybe it would be possible to use some of the snd-bt-sco code here,
> because only the userspace daemon that "wraps" the sound sockets
> together must be "integrated" (well, it's functionality) into BlueZ,
> while the snd-bt-sco alsa driver could remain nearly the same, just
> accessing the BlueZ/alsa interface instead of BlueZ/SCO?
Lets connect the SCO channel throught the socket interface and then tell
the kernel via an IOCTL to change this into an ALSA device. We do the
same for RFCOMM where we convert a socket into a TTY.
Most of the snd-bt-sco source will be useless, because it handles the in
kernel socket programming and you don't need that inside the SCO module.
Regards
Marcel
-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Lars,
> for those who are interested in further development of former snd-bt-sco
> and now bluetooth-alsa connection (project name not ready ;) we made a
> mailing list to exchange early thoughts.
I actually prefer that you discuss this on the bluez-devel mailing list,
because you may need to change BlueZ core parts and most of this will be
kernel related stuff and this should belong here.
> If anyone wants to participate, here's the address (I think joining is
> only possible by manual entry, just drop a mail to the list)
>
> [email protected]
If you still want a separate list, then subscribe me.
Regards
Marcel
-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
for those who are interested in further development of former snd-bt-sco
and now bluetooth-alsa connection (project name not ready ;) we made a
mailing list to exchange early thoughts.
If anyone wants to participate, here's the address (I think joining is
only possible by manual entry, just drop a mail to the list)
[email protected]
regards,
~ Lars
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFBGLX+QWC6DTWkDAoRAt3EAKCZ8owLo2JYZStQjkaKnIlCU57oOgCfbRQq
DFQcaX9BI75yde7OXBYE42o=
=xvN0
-----END PGP SIGNATURE-----
-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Marcel Holtmann wrote:
|>To summarise, we need low latency, full duplex, and to provide that, we
|>need to accurately be able to determine and control the buffer sizes.
|>The current bluetooth stack has no api to help us in this regard, and
|>therefore will not work very well.
|
|
| Actually you think that we need it, but I am still not sure that this is
| really needed in case of the concept of the SCO packet from the HCI and
| the SCO handling that is done on link manager/chip level. However you
| can still convince me with real code.
I have to agree with Marcel here. I've been using snd-bt-sco for a while
now with my HBH-35 Sony Ericsson Headset, and it works pretty well. Of
course I don't know much about how audio is processed here, but the
snd-bt-sco layer simply connects the sco socket to the alsa audio
socket. There's not much stuff about full duplex or low latency done,
I'm pretty sure I'd have noticed.
Of course this is useless if you want to do, say, proper audio handling
in a way ProTools would do it, but for VoIP and Gateway phone I never
had much of a problem.
If audio latency could be reduced (I'd estimate it at about 250ms-400ms
for input->output loopback) it would be a nice enhancement, but I won't
state that "this can't be done with current Bluez".
I'm just not really sure where to start now ;)
Marcel, what exactly do you mean by "implementing an alsa interface"?
Should there be an interface [like SCO] that is than accessed by an
additional alsa driver?
Maybe it would be possible to use some of the snd-bt-sco code here,
because only the userspace daemon that "wraps" the sound sockets
together must be "integrated" (well, it's functionality) into BlueZ,
while the snd-bt-sco alsa driver could remain nearly the same, just
accessing the BlueZ/alsa interface instead of BlueZ/SCO?
cu,
~ Lars
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFBGA5kQWC6DTWkDAoRAv1rAKCiObAKyOieEGVYQXaXUL/miJoRhQCePGgG
ccqZc1X2B3oRPW+WvLrSD6c=
=pgzQ
-----END PGP SIGNATURE-----
-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi James,
> > I think the SCO driver should provide two interfaces. The first one we
> > know already is a socket interface to the SCO packets and the second
> > should handle the SCO packets directly over into an ALSA interface. May
> > you would like to switch between these two via an IOCTL, like we did it
> > for the RFCOMM layer.
>
> I looked at doing ALSA -> SCO interface a long time ago, but gave up due
> to what I considered limitations with the current bluetooth stack.
you never sent any patches for changing this. Start writing code and
send it in for review.
> To summarise, we need low latency, full duplex, and to provide that, we
> need to accurately be able to determine and control the buffer sizes.
> The current bluetooth stack has no api to help us in this regard, and
> therefore will not work very well.
Actually you think that we need it, but I am still not sure that this is
really needed in case of the concept of the SCO packet from the HCI and
the SCO handling that is done on link manager/chip level. However you
can still convince me with real code.
Regards
Marcel
-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Marcel Holtmann wrote:
> Hi Lars,
>
>
>>| And as I said before, the best way is to extend the current SCO kernel
>>| module with an ALSA interface, because the basic idea of snd-bt-sco is
>>| wrong.
>>
>>I think you are absolutly right, but can you explain a bit more what you
>>have in mind? No code fragments or stuff, just how you think this might
>>be structured and integrated best. I think you are the person who knows
>>most about this topic.
>
>
> I think the SCO driver should provide two interfaces. The first one we
> know already is a socket interface to the SCO packets and the second
> should handle the SCO packets directly over into an ALSA interface. May
> you would like to switch between these two via an IOCTL, like we did it
> for the RFCOMM layer.
>
> Regards
>
> Marcel
>
I looked at doing ALSA -> SCO interface a long time ago, but gave up due
to what I considered limitations with the current bluetooth stack.
To summarise, we need low latency, full duplex, and to provide that, we
need to accurately be able to determine and control the buffer sizes.
The current bluetooth stack has no api to help us in this regard, and
therefore will not work very well.
James
Hi Lars,
> | And as I said before, the best way is to extend the current SCO kernel
> | module with an ALSA interface, because the basic idea of snd-bt-sco is
> | wrong.
>
> I think you are absolutly right, but can you explain a bit more what you
> have in mind? No code fragments or stuff, just how you think this might
> be structured and integrated best. I think you are the person who knows
> most about this topic.
I think the SCO driver should provide two interfaces. The first one we
know already is a socket interface to the SCO packets and the second
should handle the SCO packets directly over into an ALSA interface. May
you would like to switch between these two via an IOCTL, like we did it
for the RFCOMM layer.
Regards
Marcel
-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. http://www.ostg.com
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Marcel Holtmann wrote:
| Hi Lars,
|
|
|>A while ago I decided that I might want to take over the snd-bt-sco
|>project.
|
| you can use this mailing list and you can also post patches here.
|
| And as I said before, the best way is to extend the current SCO kernel
| module with an ALSA interface, because the basic idea of snd-bt-sco is
| wrong.
I think you are absolutly right, but can you explain a bit more what you
have in mind? No code fragments or stuff, just how you think this might
be structured and integrated best. I think you are the person who knows
most about this topic.
thanks,
~ Lars
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFBF7CYQWC6DTWkDAoRAqvUAKCjj1RzXu+OHjGa8rpw39r09ldRhwCguZd8
ys/yzAvmczrpsrUd5LzqDMg=
=ui6U
-----END PGP SIGNATURE-----
-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. http://www.ostg.com
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Lars,
> A while ago I decided that I might want to take over the snd-bt-sco
> project.
>
> I had very little time in the last month due to personal reasons, but
> I'm eager to give this project at least structure and manpower.
>
> I have the feeling that there are some different people picking at the
> code right now, but there is no teamwork here.
>
> If there are people out there who are using snd-bt-sco or might want to
> improve the program, please notice me.
>
> I think this might be a good idea, maybe it's possible to set up a
> sourceforge project together or something.
>
> I alone can't do much right now, and there are some problems to address
> (i.e. how to handle call pickup stuff). I'm pretty busy so I don't have
> the time to get into the subject enough :(
you can use this mailing list and you can also post patches here.
And as I said before, the best way is to extend the current SCO kernel
module with an ALSA interface, because the basic idea of snd-bt-sco is
wrong.
Regards
Marcel
-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. http://www.ostg.com
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel