As SCO over bluetooth is only really suitable for audio sound data, I
see no real problem with alsa being the only interface in linux to send
data over a bluetooth SCO connection. (only the actually sco data, not
the bluetooth profile control)
Does anyone see a problem with that?
If people think we should also make it easy to add an OSS driver, and
also a network socket driver, we could maybe work out some devision
between the SCO specifics and the ALSA specifics. But for a first
attempt, we should keep the SCO and ALSA driver tightly matched.
Therefore maybe making the bluetooth sco and alsa-sco module being the
same module, with an ioctl interface so that a user space application
can handle the creation of bluetooth profile SCO pairing.
For example, if using a Headset profile, the alsa PCM and alsa MIXER
device would only appear if the userspace application had already set up
the RFCOMM connections. The userspace application would also have to
have set up the bluetooth specific details for the SCO connection, so
that when alsa opens the PCM, it has enough information to open a SCO
connection.
I have looked at this for the alsa->sco->bluetooth->hci_usb drivers.
The alsa driver has to be able to do the following: -
1) open - this should check that all bluetooth connections are up that
need to be up in order for SCO data to pass. It could do this via
interaction with the userspace bluetooth profile.
2) close - close everything neatly.
3) hw_params - allocate buffers etc. for the pcm audio as well as the
hw_params config. Can be called multiple times, so re-alloc of buffers
should be allowed for. hw_params are things like sample rate, number of
channels, PCM format. Obviously there are limits on what these values
can take when using bluetooth. 16bit PCM, 8bit PCM, 8bit A-law, 8bit
u-Law. Start by also limiting it to 1 PCM channel. I.E. Mono and not stereo.
4) pcm_prepare - actually set the hw_params. e.g. do the equivalent of
hciconfig hci0 voice XX, where XX depends on the hw_params.
Also selecting usb alt profiles.
The only difference between hw_params and pcm_prepare is that
pcm_prepare is called for xrun recovery.
5) trigger - actually start/stop usb_urbs (e.g. call
usb_submit_urb/usb_unlink_urb now.)
6) pointer - get hw_usb_frame_pointer and modify the result to simulate
an audio ring buffer of the size configured in the hw_params.
When retrieving the pointer, one should also retrieve the valid range
that the pointer can have, so one can adjust for pointer wrap around.
For usb, this would be the usb_get_current_frame_number() for the
pointer, and dev->bus->iso_sched_frames for the range of values it can take.
7) period_time_elapsed - hci_usb should call this on each urb_complete
call. For our use, it seems sensible to make 1 urb == 1 alsa period.
If we can let the alsa bluetooth audio driver have access to the
hardware pointers (in this case the usb current frame pointers), we will
get a much more accurate idea of exactly which audio sample is currently
being played.
Also, letting alsa control period and buffer sizes, and getting that to
directly determine usb urb sizes, we would give complete control of
buffer sizes to the application, which is vital for low latency
applications like Voice over IP.
Summary: -
we need to provide up to the sco level, control of low level usb
interface isoc parameters. E.g. prepare, trigger, pointer,
period_time_elapsed, hw_params.
If people are happy with this proposal, I will start writing the alsa
driver, and also start adding to the bluetooth -> hci_usb driver api to
allow for it. The api will only change for SCO data handling, as Bulk
and Int handling don't need such fine controls.
Cheers
James
-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Marcel Holtmann wrote:
> Hi James,
>
>>Some audio applications need this "pointer" feature, which is why alsa
>>provides it.
>>An example of this is playback of DVDs.
>>Video output needs to be kept closely in sync with the audio, and this
>>"pointer" and "trigger" feature allow the application to closely control
>>exactly when the sound plays. "trigger" handles the "start the sound
>>exactly now", and "pointer" provides feedback, saying that "sound sample
>>xyz is currently playing, so display video frame xyz now". "pointer"
>>also provides for "audio is playing 0.25 seconds ahead of video, adjust
>>it to match".
>>These are not hardware specific features, all sound hardware has these
>>features, including bluetooth audio, and we just need some way for
>>higher layers to get access to the values.
>>Another example is Voice over IP. If using a headset, one might want to
>>use it to make VoIP calls over the internet. One of the most important
>>issues with VoIP is latency. The lower the latency, the more natural the
>>conversation will be. Long latency produces conversations will long
>>breaks in between and possible delayed echos. It is a lot more difficult
>>to have a natually smooth conversation if the latency is high. These
>>"pointer" and "trigger" and "period_time_elapsed" functions allow for
>>applications to program minimum latancy that any particular hardware can
>>handle.
>
>
> You shouldn't think so much about it. Try to implement the ALSA driver
> without it and we see how it goes.
>
> Regards
>
> Marcel
>
So you want me to implement it in such a way that would add 10-20ms of
latency and have no audio/video syncronisation features?
We might as well stay with the current alsa over network sockets which
is what we have now.
Cheers
James
Hi James,
> alsa handles format conversion automatically, all we have to tell alsa
> is which formats we can do, and alsa does the rest. So, if alsa is not
> allowed to modify the hciconfig hci0 voice XX setting, it can just be
> told what it is via an IOCTL and then tell alsa to do conversions for
> any other formats.
we don't need an ioctl for that, because the current voice setting for a
HCI device is already present in the hci_dev structure.
> Some audio applications need this "pointer" feature, which is why alsa
> provides it.
> An example of this is playback of DVDs.
> Video output needs to be kept closely in sync with the audio, and this
> "pointer" and "trigger" feature allow the application to closely control
> exactly when the sound plays. "trigger" handles the "start the sound
> exactly now", and "pointer" provides feedback, saying that "sound sample
> xyz is currently playing, so display video frame xyz now". "pointer"
> also provides for "audio is playing 0.25 seconds ahead of video, adjust
> it to match".
> These are not hardware specific features, all sound hardware has these
> features, including bluetooth audio, and we just need some way for
> higher layers to get access to the values.
> Another example is Voice over IP. If using a headset, one might want to
> use it to make VoIP calls over the internet. One of the most important
> issues with VoIP is latency. The lower the latency, the more natural the
> conversation will be. Long latency produces conversations will long
> breaks in between and possible delayed echos. It is a lot more difficult
> to have a natually smooth conversation if the latency is high. These
> "pointer" and "trigger" and "period_time_elapsed" functions allow for
> applications to program minimum latancy that any particular hardware can
> handle.
You shouldn't think so much about it. Try to implement the ALSA driver
without it and we see how it goes.
Regards
Marcel
-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Marcel Holtmann wrote:
> Hi James,
>
>
>>This is something I need to be able to understand better.
>>What should actually be adjusting the voice setting? To me it seems
>>sensible that we should try to get the voice setting to match the alsa
>>PCM samples if we can.
>>Of course, another approach is getting the application to set the voice
>>setting, and then open the SCO link, and then force alsa to use whatever
>>voice setting the SCO link was set to. We would get the application to
>>inform alsa about this voice setting via an ioctl.
>
>
> we only need to know about the input coding. The ALSA driver maybe needs
> to convert the PCM samples to the input coding of the Bluetooth device.
alsa handles format conversion automatically, all we have to tell alsa
is which formats we can do, and alsa does the rest. So, if alsa is not
allowed to modify the hciconfig hci0 voice XX setting, it can just be
told what it is via an IOCTL and then tell alsa to do conversions for
any other formats.
>
>
>>The alsa-driver receives a trigger() api call from an alsa based
>>application. It would be nice to pass this trigger() function on down
>>the stack to whichever bluetooth hci driver we are using (hci_usb or
>>whatever else), and that hci driver handle it appropriately.
>>I just gave the usb_submit_urb() as an example of what the hci_usb.c
>>driver would do when it received the trigger() call.
>>For example. The SCO link is open, but no actual sound samples start
>>being sent or received from the CPU until the trigger() call.
>
>
> I don't see any need for it.
Some audio applications need this feature, which is why alsa provides it.
>
>
>>I was using the HCI USB driver as an example only.
>>The alsa-driver receives a pointer() from the alsa based application. we
>>need to pass a call to the HCI driver (hardware independently) which
>>would return the frame pointer. I don't think the concept of a
>>frame_pointer is USB specific. Any Bluetooth hardware driver will use a
>>frame_pointer.
>
>
> I don't get this either, because we don't need to interface with any
> hardware drivers.
Some audio applications need this "pointer" feature, which is why alsa
provides it.
An example of this is playback of DVDs.
Video output needs to be kept closely in sync with the audio, and this
"pointer" and "trigger" feature allow the application to closely control
exactly when the sound plays. "trigger" handles the "start the sound
exactly now", and "pointer" provides feedback, saying that "sound sample
xyz is currently playing, so display video frame xyz now". "pointer"
also provides for "audio is playing 0.25 seconds ahead of video, adjust
it to match".
These are not hardware specific features, all sound hardware has these
features, including bluetooth audio, and we just need some way for
higher layers to get access to the values.
Another example is Voice over IP. If using a headset, one might want to
use it to make VoIP calls over the internet. One of the most important
issues with VoIP is latency. The lower the latency, the more natural the
conversation will be. Long latency produces conversations will long
breaks in between and possible delayed echos. It is a lot more difficult
to have a natually smooth conversation if the latency is high. These
"pointer" and "trigger" and "period_time_elapsed" functions allow for
applications to program minimum latancy that any particular hardware can
handle.
>
>
>>Maybe I should look at the patch first, but ..
>
>
> You can find it in the mailing list archive.
>
>
>>I cannot see anywhere in the current HCI layer api where I can find out
>>which HCI SCO packet is currently(in realtime) being output. All I know
>>is that if I send an HCI SCO packet down the stack, it will get queued,
>>and at some point be output. That is not good enough.
>
>
> Why would you wanna know this? If you send too much data, the Bluetooth
> chip itself will drop the packets.
Hopefully my explanation above regarding DVDs will answer this.
>
> Regards
>
> Marcel
>
>
>
>
Cheers
James
Hi James,
> This is something I need to be able to understand better.
> What should actually be adjusting the voice setting? To me it seems
> sensible that we should try to get the voice setting to match the alsa
> PCM samples if we can.
> Of course, another approach is getting the application to set the voice
> setting, and then open the SCO link, and then force alsa to use whatever
> voice setting the SCO link was set to. We would get the application to
> inform alsa about this voice setting via an ioctl.
we only need to know about the input coding. The ALSA driver maybe needs
to convert the PCM samples to the input coding of the Bluetooth device.
> The alsa-driver receives a trigger() api call from an alsa based
> application. It would be nice to pass this trigger() function on down
> the stack to whichever bluetooth hci driver we are using (hci_usb or
> whatever else), and that hci driver handle it appropriately.
> I just gave the usb_submit_urb() as an example of what the hci_usb.c
> driver would do when it received the trigger() call.
> For example. The SCO link is open, but no actual sound samples start
> being sent or received from the CPU until the trigger() call.
I don't see any need for it.
> I was using the HCI USB driver as an example only.
> The alsa-driver receives a pointer() from the alsa based application. we
> need to pass a call to the HCI driver (hardware independently) which
> would return the frame pointer. I don't think the concept of a
> frame_pointer is USB specific. Any Bluetooth hardware driver will use a
> frame_pointer.
I don't get this either, because we don't need to interface with any
hardware drivers.
> Maybe I should look at the patch first, but ..
You can find it in the mailing list archive.
> I cannot see anywhere in the current HCI layer api where I can find out
> which HCI SCO packet is currently(in realtime) being output. All I know
> is that if I send an HCI SCO packet down the stack, it will get queued,
> and at some point be output. That is not good enough.
Why would you wanna know this? If you send too much data, the Bluetooth
chip itself will drop the packets.
Regards
Marcel
-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Marcel Holtmann wrote:
> Hi James,
>
>
>>As SCO over bluetooth is only really suitable for audio sound data, I
>>see no real problem with alsa being the only interface in linux to send
>>data over a bluetooth SCO connection. (only the actually sco data, not
>>the bluetooth profile control)
>>Does anyone see a problem with that?
>
>
> there are two interfaces with Bluetooth 1.2. SCO/eSCO audio and eSCO
> data. This means we need an ALSA interface and a socket interface.
Ok, I have not looked into eSCO yet.
>
>
>>If people think we should also make it easy to add an OSS driver, and
>>also a network socket driver, we could maybe work out some devision
>>between the SCO specifics and the ALSA specifics. But for a first
>>attempt, we should keep the SCO and ALSA driver tightly matched.
>
>
> We need the socket driver, but we don't need an OSS driver. But I see no
> problem with this, because the RFCOMM layer also includes socket and TTY
> support at the same time.
>
>
>>Therefore maybe making the bluetooth sco and alsa-sco module being the
>>same module, with an ioctl interface so that a user space application
>>can handle the creation of bluetooth profile SCO pairing.
>
>
> Yes. Only one kernel module called sco.
Agreed.
>
>
>>For example, if using a Headset profile, the alsa PCM and alsa MIXER
>>device would only appear if the userspace application had already set up
>>the RFCOMM connections. The userspace application would also have to
>>have set up the bluetooth specific details for the SCO connection, so
>>that when alsa opens the PCM, it has enough information to open a SCO
>>connection.
>
>
> ALSA don't open the SCO connection. This is part of the application that
> implements the profile. In the case of the headset profile, you must
> first have the RFCOMM connection and then the SCO link. No SCO link
> without an ACL link.
ALSA app calls snd_pcm_open(), but we will make this call fail if the
application that implements the profile is not yet ready for SCO audio data.
>
>
>>I have looked at this for the alsa->sco->bluetooth->hci_usb drivers.
>>The alsa driver has to be able to do the following: -
>>1) open - this should check that all bluetooth connections are up that
>>need to be up in order for SCO data to pass. It could do this via
>>interaction with the userspace bluetooth profile.
>
>
> If there is no SCO link -> failure.
Agreed.
>
>
>>2) close - close everything neatly.
>
>
> Of course, but the SCO link should be closed by the application.
I think I need to understand a bit more about what it actually set when
one opens a SCO connection. I thought all that happens is that a
connection number is decided on. If setting up a SCO connection also
fixes the voice setting, then I would like to allow alsa to have some
influence over this if possible.
>
>
>>3) hw_params - allocate buffers etc. for the pcm audio as well as the
>>hw_params config. Can be called multiple times, so re-alloc of buffers
>>should be allowed for. hw_params are things like sample rate, number of
>>channels, PCM format. Obviously there are limits on what these values
>>can take when using bluetooth. 16bit PCM, 8bit PCM, 8bit A-law, 8bit
>>u-Law. Start by also limiting it to 1 PCM channel. I.E. Mono and not stereo.
>
>
> The possible values depends on the voice setting.
This is something I need to be able to understand better.
What should actually be adjusting the voice setting? To me it seems
sensible that we should try to get the voice setting to match the alsa
PCM samples if we can.
Of course, another approach is getting the application to set the voice
setting, and then open the SCO link, and then force alsa to use whatever
voice setting the SCO link was set to. We would get the application to
inform alsa about this voice setting via an ioctl.
>
>
>>4) pcm_prepare - actually set the hw_params. e.g. do the equivalent of
>>hciconfig hci0 voice XX, where XX depends on the hw_params.
>>Also selecting usb alt profiles.
>>The only difference between hw_params and pcm_prepare is that
>>pcm_prepare is called for xrun recovery.
>
>
> I am not sure if we should allow the ALSA driver to change the voice
> settings. As I know it is not possible to change the voice setting of an
> already existing SCO link.
>
>
>>5) trigger - actually start/stop usb_urbs (e.g. call
>>usb_submit_urb/usb_unlink_urb now.)
>
>
> Not part of the ALSA driver. This is a problem of the HCI USB driver.
The alsa-driver receives a trigger() api call from an alsa based
application. It would be nice to pass this trigger() function on down
the stack to whichever bluetooth hci driver we are using (hci_usb or
whatever else), and that hci driver handle it appropriately.
I just gave the usb_submit_urb() as an example of what the hci_usb.c
driver would do when it received the trigger() call.
For example. The SCO link is open, but no actual sound samples start
being sent or received from the CPU until the trigger() call.
>
>
>>6) pointer - get hw_usb_frame_pointer and modify the result to simulate
>>an audio ring buffer of the size configured in the hw_params.
>>When retrieving the pointer, one should also retrieve the valid range
>>that the pointer can have, so one can adjust for pointer wrap around.
>>For usb, this would be the usb_get_current_frame_number() for the
>>pointer, and dev->bus->iso_sched_frames for the range of values it can take.
>
>
> The SCO interface is not driver specific. So no interaction we the HCI
> USB driver.
I was using the HCI USB driver as an example only.
The alsa-driver receives a pointer() from the alsa based application. we
need to pass a call to the HCI driver (hardware independently) which
would return the frame pointer. I don't think the concept of a
frame_pointer is USB specific. Any Bluetooth hardware driver will use a
frame_pointer.
>
>
>>7) period_time_elapsed - hci_usb should call this on each urb_complete
>>call. For our use, it seems sensible to make 1 urb == 1 alsa period.
>>
>>If we can let the alsa bluetooth audio driver have access to the
>>hardware pointers (in this case the usb current frame pointers), we will
>>get a much more accurate idea of exactly which audio sample is currently
>>being played.
>>
>>Also, letting alsa control period and buffer sizes, and getting that to
>>directly determine usb urb sizes, we would give complete control of
>>buffer sizes to the application, which is vital for low latency
>>applications like Voice over IP.
>
>
> No. ALSA <-> SCO is driver and hardware independent.
Again, I was only using USB as an example, the period_time_elapsed can
be called by any bluetooth hardware. E.g. In the interrupt handling routine.
>
>
>>Summary: -
>>we need to provide up to the sco level, control of low level usb
>>interface isoc parameters. E.g. prepare, trigger, pointer,
>>period_time_elapsed, hw_params.
>>
>>If people are happy with this proposal, I will start writing the alsa
>>driver, and also start adding to the bluetooth -> hci_usb driver api to
>>allow for it. The api will only change for SCO data handling, as Bulk
>>and Int handling don't need such fine controls.
>
>
> Let me repeat it. The upper interface to SCO is driver and hardware
> independent.
>
> We need to extend the HCI USB driver to support start/stop of ISOC URB's
> on demand and to select the right alternate settings. And this means to
> split the hash for number of ACL/SCO connections and send a notification
> to the driver if a new connection is created/released of if the voice
> settings are changed. We already talked about this stuff. I had already
> a patch for it, but the hash split was missing.
OK, I have not seen that patch yet.
>
> The ALSA <-> SCO driver should be written with the current API provided
> by the HCI layer. Check how the current SCO driver gets and sends its
> data packets. Start with this driver and don't worry so much about the
> USB specific part. Use voice setting 0x0060 as the only supported value
> at the moment.
Maybe I should look at the patch first, but ..
I cannot see anywhere in the current HCI layer api where I can find out
which HCI SCO packet is currently(in realtime) being output. All I know
is that if I send an HCI SCO packet down the stack, it will get queued,
and at some point be output. That is not good enough.
>
> Regards
>
> Marcel
>
>
>
>
Cheers
James
Hi James,
> As SCO over bluetooth is only really suitable for audio sound data, I
> see no real problem with alsa being the only interface in linux to send
> data over a bluetooth SCO connection. (only the actually sco data, not
> the bluetooth profile control)
> Does anyone see a problem with that?
there are two interfaces with Bluetooth 1.2. SCO/eSCO audio and eSCO
data. This means we need an ALSA interface and a socket interface.
> If people think we should also make it easy to add an OSS driver, and
> also a network socket driver, we could maybe work out some devision
> between the SCO specifics and the ALSA specifics. But for a first
> attempt, we should keep the SCO and ALSA driver tightly matched.
We need the socket driver, but we don't need an OSS driver. But I see no
problem with this, because the RFCOMM layer also includes socket and TTY
support at the same time.
> Therefore maybe making the bluetooth sco and alsa-sco module being the
> same module, with an ioctl interface so that a user space application
> can handle the creation of bluetooth profile SCO pairing.
Yes. Only one kernel module called sco.
> For example, if using a Headset profile, the alsa PCM and alsa MIXER
> device would only appear if the userspace application had already set up
> the RFCOMM connections. The userspace application would also have to
> have set up the bluetooth specific details for the SCO connection, so
> that when alsa opens the PCM, it has enough information to open a SCO
> connection.
ALSA don't open the SCO connection. This is part of the application that
implements the profile. In the case of the headset profile, you must
first have the RFCOMM connection and then the SCO link. No SCO link
without an ACL link.
> I have looked at this for the alsa->sco->bluetooth->hci_usb drivers.
> The alsa driver has to be able to do the following: -
> 1) open - this should check that all bluetooth connections are up that
> need to be up in order for SCO data to pass. It could do this via
> interaction with the userspace bluetooth profile.
If there is no SCO link -> failure.
> 2) close - close everything neatly.
Of course, but the SCO link should be closed by the application.
> 3) hw_params - allocate buffers etc. for the pcm audio as well as the
> hw_params config. Can be called multiple times, so re-alloc of buffers
> should be allowed for. hw_params are things like sample rate, number of
> channels, PCM format. Obviously there are limits on what these values
> can take when using bluetooth. 16bit PCM, 8bit PCM, 8bit A-law, 8bit
> u-Law. Start by also limiting it to 1 PCM channel. I.E. Mono and not stereo.
The possible values depends on the voice setting.
> 4) pcm_prepare - actually set the hw_params. e.g. do the equivalent of
> hciconfig hci0 voice XX, where XX depends on the hw_params.
> Also selecting usb alt profiles.
> The only difference between hw_params and pcm_prepare is that
> pcm_prepare is called for xrun recovery.
I am not sure if we should allow the ALSA driver to change the voice
settings. As I know it is not possible to change the voice setting of an
already existing SCO link.
> 5) trigger - actually start/stop usb_urbs (e.g. call
> usb_submit_urb/usb_unlink_urb now.)
Not part of the ALSA driver. This is a problem of the HCI USB driver.
> 6) pointer - get hw_usb_frame_pointer and modify the result to simulate
> an audio ring buffer of the size configured in the hw_params.
> When retrieving the pointer, one should also retrieve the valid range
> that the pointer can have, so one can adjust for pointer wrap around.
> For usb, this would be the usb_get_current_frame_number() for the
> pointer, and dev->bus->iso_sched_frames for the range of values it can take.
The SCO interface is not driver specific. So no interaction we the HCI
USB driver.
> 7) period_time_elapsed - hci_usb should call this on each urb_complete
> call. For our use, it seems sensible to make 1 urb == 1 alsa period.
>
> If we can let the alsa bluetooth audio driver have access to the
> hardware pointers (in this case the usb current frame pointers), we will
> get a much more accurate idea of exactly which audio sample is currently
> being played.
>
> Also, letting alsa control period and buffer sizes, and getting that to
> directly determine usb urb sizes, we would give complete control of
> buffer sizes to the application, which is vital for low latency
> applications like Voice over IP.
No. ALSA <-> SCO is driver and hardware independent.
> Summary: -
> we need to provide up to the sco level, control of low level usb
> interface isoc parameters. E.g. prepare, trigger, pointer,
> period_time_elapsed, hw_params.
>
> If people are happy with this proposal, I will start writing the alsa
> driver, and also start adding to the bluetooth -> hci_usb driver api to
> allow for it. The api will only change for SCO data handling, as Bulk
> and Int handling don't need such fine controls.
Let me repeat it. The upper interface to SCO is driver and hardware
independent.
We need to extend the HCI USB driver to support start/stop of ISOC URB's
on demand and to select the right alternate settings. And this means to
split the hash for number of ACL/SCO connections and send a notification
to the driver if a new connection is created/released of if the voice
settings are changed. We already talked about this stuff. I had already
a patch for it, but the hash split was missing.
The ALSA <-> SCO driver should be written with the current API provided
by the HCI layer. Check how the current SCO driver gets and sends its
data packets. Start with this driver and don't worry so much about the
USB specific part. Use voice setting 0x0060 as the only supported value
at the moment.
Regards
Marcel
-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Well, I am, as said, in the midst of development, but I but a short
description and the current state online at:
http://www.soft.uni-linz.ac.at/_wiki/tiki-index.php?page=ProjectBluezHandsfree
Have fun with it,
Simon
Marcel Holtmann wrote:
> Hi Simon,
>
>
>>I am have written two small programs that try to conform to the
>>headset/handsfree profile.
>>They are not finished yet, but I'd like to donate the source code :)
>>They are small, command-line
>>and use only alsa (with suboptimal quality at the moment). If anyone
>>wants to have a look
>>at the code, drop me a note.
>>Marcel, would you like to integrate them into the repository, or should
>>I start a separate project?
>
>
> show us the source code first and then let me decide.
>
> Regards
>
> Marcel
>
>
>
>
> -------------------------------------------------------
> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> Build and deploy apps & Web services for Linux with
> a free DVD software kit from IBM. Click Now!
> http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
> _______________________________________________
> Bluez-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/bluez-devel
--
_______________________________________________________________________
Dr. Simon Vogl
Institut f?r Pervasive Computing, Johannes Kepler Universit?t Linz
Altenberger Stra?e 69, A-4040 Linz, Austria
Tel: +43 732 2468-8517, Fax: +43 732 2468-8426
mailto: [email protected], http://www.soft.uni-linz.ac.at/
James,
I currently have two systems:=20
- my development host machine - an x86 PC, 2.4.20-6 Red Hat. There is
no patch available for this kernel, so I'm doing my work on the =
following:
- my target machine, an xScale single board computer, 2.4.19,=20
with several hardware specific patches. I did apply the 2.4.19.mh14 =
patch to this.
For both machines. I use an Anycomm USB BT dongle. I don't know what =
chipset is inside.
So I've got rfcomm, hci, SDP and sco.c on the target xScale machine.=20
The modules are loaded OK. I can "hcitool scan" and see the headset.
I've been running the following commands:
hcid
hciconfig hci0 voice 0x0040
sdpd
sdptool add --channel=3D7 HSET
hstest play file 00:02:72:41:2E:2F 7
<<< nothing seems to happen>>>>
Before I can connect, the headset must be paired. I put the headset=20
into pairing mode, then how do I get linux to initiate pairing with=20
the headset ?
I'm not sure what to do next. Any advice is appreciated.
Thanks,
Rich
-----Original Message-----
From: James Courtier-Dutton [mailto:[email protected]]
Sent: Monday, March 01, 2004 2:47 PM
To: Williams, Richard
Cc: BlueZ Mailing List
Subject: Re: [Bluez-devel] SCO. Some ideas.
Williams, Richard wrote:
> James,
>=20
> Thanks for the reply. But I am having trouble getting SCO to work on =
my
> platform. Can you point me to any documentation that explains how
> to get this to work ? I want to have a Sony-Ericsson BT headset to=20
> send/receive audio to/from my Linux box - 2.4.19.=20
>=20
> I do have BT working: rfcomm, SDP, Obex, but SCO is giving me more=20
> trouble.
>=20
> Thanks very much,
>=20
> Rich
>=20
Which type of bluetooth interface do you have on the PC?
I currently use a USB CSR based bluetooth device and a Sony-Ericsson=20
HBH-30 headset.
Cheers
James
-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Williams, Richard wrote:
> James,
>
> Thanks for the reply. But I am having trouble getting SCO to work on my
> platform. Can you point me to any documentation that explains how
> to get this to work ? I want to have a Sony-Ericsson BT headset to
> send/receive audio to/from my Linux box - 2.4.19.
>
> I do have BT working: rfcomm, SDP, Obex, but SCO is giving me more
> trouble.
>
> Thanks very much,
>
> Rich
>
Which type of bluetooth interface do you have on the PC?
I currently use a USB CSR based bluetooth device and a Sony-Ericsson
HBH-30 headset.
Cheers
James
-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Williams, Richard wrote:
> James,
>
> Thanks for the reply. But I am having trouble getting SCO to work on my
> platform. Can you point me to any documentation that explains how
> to get this to work ? I want to have a Sony-Ericsson BT headset to
> send/receive audio to/from my Linux box - 2.4.19.
>
> I do have BT working: rfcomm, SDP, Obex, but SCO is giving me more
> trouble.
>
> Thanks very much,
>
> Rich
>
So, you have applied this patch to the kernel ?
http://www.holtmann.org/linux/kernel/patch-2.4.19-mh14.gz
To test it use the hstest program in bluez-utils/test
Cheers
James
-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
James,
Thanks for the reply. But I am having trouble getting SCO to work on my
platform. Can you point me to any documentation that explains how
to get this to work ? I want to have a Sony-Ericsson BT headset to=20
send/receive audio to/from my Linux box - 2.4.19.=20
I do have BT working: rfcomm, SDP, Obex, but SCO is giving me more=20
trouble.
Thanks very much,
Rich
-----Original Message-----
From: James Courtier-Dutton [mailto:[email protected]]
Sent: Monday, March 01, 2004 12:39 PM
To: Williams, Richard
Cc: BlueZ Mailing List
Subject: Re: [Bluez-devel] SCO. Some ideas.
Williams, Richard wrote:
> Hi Guys,
>=20
> Your discussion is very relevant to me, since I'm building a small
> wearable computer system that will have several Bluetooth devices -=20
> among them will be a headset. I was planning to use standard rfcomm
> to send data among the other devices and use SCO for the interface=20
> from my computer to the BT headset.
>=20
> It sounds from your discussion that SCO is really not ready to be =
used.
> In my case, since I'm building an embedded system, I want simple
> and low power. For my system I'd really like a socket interface to =
SCO.
> If I MUST use a large audio package like ALSA, then I'll do that, but
> I really want something small and simple.
>=20
> Is there a bluez SCO that I can use ?=20
> Do you have any idea when a stable SCO package will be available ?
>=20
> I'm currently using linux-2.4.19 on an Intel Xscale processor.
>=20
> thank you very much,
>=20
> Regards,
>=20
> Rich
>=20
> Richard B. Williams
> Vitronics, Inc.
> 3 Corbett Way
> Eatontown, NJ 07724-2262
> 732-389-0244 x29
> [email protected]
>=20
SCO connections currently functions over the socket interface.
You can send sound to the headset, and receive sound from the headset=20
mics. The only problem is in the buffering. That support is there in=20
kernel 2.6.4, or 2.6.3 with patches, and also 2.4.x with other patches.
The problem in the buffering is the current lack of any feedback.
E.g. You output 0.1 second of samples. There is no feedback to tell you=20
that all the samples have been played, or if it is still in the middle=20
of playing.
So, lets take a possible real world setup.
One is playing an internet video stream. One has no way to keep audio in =
sync with video.
Summary: -
The current SCO support if fine, unless you need to keep the playback=20
audio in sync with anything.
Cheers
James
-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Williams, Richard wrote:
> Hi Guys,
>
> Your discussion is very relevant to me, since I'm building a small
> wearable computer system that will have several Bluetooth devices -
> among them will be a headset. I was planning to use standard rfcomm
> to send data among the other devices and use SCO for the interface
> from my computer to the BT headset.
>
> It sounds from your discussion that SCO is really not ready to be used.
> In my case, since I'm building an embedded system, I want simple
> and low power. For my system I'd really like a socket interface to SCO.
> If I MUST use a large audio package like ALSA, then I'll do that, but
> I really want something small and simple.
>
> Is there a bluez SCO that I can use ?
> Do you have any idea when a stable SCO package will be available ?
>
> I'm currently using linux-2.4.19 on an Intel Xscale processor.
>
> thank you very much,
>
> Regards,
>
> Rich
>
> Richard B. Williams
> Vitronics, Inc.
> 3 Corbett Way
> Eatontown, NJ 07724-2262
> 732-389-0244 x29
> [email protected]
>
SCO connections currently functions over the socket interface.
You can send sound to the headset, and receive sound from the headset
mics. The only problem is in the buffering. That support is there in
kernel 2.6.4, or 2.6.3 with patches, and also 2.4.x with other patches.
The problem in the buffering is the current lack of any feedback.
E.g. You output 0.1 second of samples. There is no feedback to tell you
that all the samples have been played, or if it is still in the middle
of playing.
So, lets take a possible real world setup.
One is playing an internet video stream. One has no way to keep audio in
sync with video.
Summary: -
The current SCO support if fine, unless you need to keep the playback
audio in sync with anything.
Cheers
James
-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Simon,
> I am have written two small programs that try to conform to the
> headset/handsfree profile.
> They are not finished yet, but I'd like to donate the source code :)
> They are small, command-line
> and use only alsa (with suboptimal quality at the moment). If anyone
> wants to have a look
> at the code, drop me a note.
> Marcel, would you like to integrate them into the repository, or should
> I start a separate project?
show us the source code first and then let me decide.
Regards
Marcel
-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
BTW,
I am have written two small programs that try to conform to the
headset/handsfree profile.
They are not finished yet, but I'd like to donate the source code :)
They are small, command-line
and use only alsa (with suboptimal quality at the moment). If anyone
wants to have a look
at the code, drop me a note.
Marcel, would you like to integrate them into the repository, or should
I start a separate project?
Simon
Williams, Richard wrote:
>Hi Guys,
>
>Your discussion is very relevant to me, since I'm building a small
>wearable computer system that will have several Bluetooth devices -
>among them will be a headset. I was planning to use standard rfcomm
>to send data among the other devices and use SCO for the interface
>from my computer to the BT headset.
>
>It sounds from your discussion that SCO is really not ready to be used.
>In my case, since I'm building an embedded system, I want simple
>and low power. For my system I'd really like a socket interface to SCO.
>If I MUST use a large audio package like ALSA, then I'll do that, but
>I really want something small and simple.
>
>Is there a bluez SCO that I can use ?
>Do you have any idea when a stable SCO package will be available ?
>
>I'm currently using linux-2.4.19 on an Intel Xscale processor.
>
>thank you very much,
>
>Regards,
>
>Rich
>
>Richard B. Williams
>Vitronics, Inc.
>3 Corbett Way
>Eatontown, NJ 07724-2262
>732-389-0244 x29
>[email protected]
>
>
>-----Original Message-----
>From: Marcel Holtmann [mailto:[email protected]]
>Sent: Monday, March 01, 2004 10:29 AM
>To: James Courtier-Dutton
>Cc: BlueZ Mailing List
>Subject: Re: [Bluez-devel] SCO. Some ideas.
>
>
>Hi James,
>
>
>
>>I have started to think of how we might better achieve our goal without
>>explicitly having trigger/pointer etc. api calls from the HCI to the SCO
>>layer.
>>The current bluez stack handles HCI SCO receiving ok for now. HCI SCO
>>packets can be lost, but that is not so much of a problem.
>>The current problem is the HCI SCO sending. i.e. CPU to Bluetooth air.
>>There is no rate limiting in the HCI SCO sending.
>>Options for rate limiting: -
>>1) For best sound quality, the rate limiting should be based on the HCI
>>hardware, and not any other source.
>>2) Only send hci sco when one receives an hci sco
>>This causes problems if received hci sco packets get dropped due to
>>missed irqs etc. So it is better to not link the TX rate limiting to any
>>RX packet rate.
>>3) Use the linux system time.
>>If the user changes the time, the linux system time get changed, so the
>>rate limiting will be messed up each time the linux system time is
>>changed. So, better not to use the linux system time.
>>
>>So, we really want to use (1) if we can.
>>How about?: -
>>
>>1) Each hci sco packet being send from the sco layer to the hci layer is
>>tagged with a sequence number.
>>We send the hci sco packet from sco layer to hci layer.
>>When the tx_complete for that hci sco packet happens, the packet is
>>returned to the sco layer being taged as complete and then the sco layer
>>refills it with new data and sends it down again. As we tagged the hci
>>sco packet with a sequence number, when it comes back we know which
>>packet was actually send. As it has a sequence number on it, we can
>>detect lost packets.
>>Because the completed packet is send back up to the sco layer, we are
>>able to remove one malloc/free from the process.
>>Currently we have sco layer doing alloc, hci layer doing free.
>>
>>2) Just use a limited sized queue.
>>sco layer fills the queue, but when the queue is full, it waits.
>>the hci layer empties the queue as and when it needs to.
>>Currently, I think we have a queue, but the size of the queue is not
>>controllable from the sco layer.
>>It might be better if the hci layer reads the first item in the queue,
>>schedules it for output. the hci layer only frees the item from the
>>queue when it reaches tx_complete.
>>The tx_complete state is reached when the bluetooth hardware calls the
>>interrupt handler.
>>
>>I think option (2) fits more closely with the current bluez design. All
>>I need is the answer to "How does one limit the queue size?".
>>
>>
>
>maybe you should look at hci_send_sco() and you can control everything
>by yourself that you wanna send down to the HCI layer and thus to the
>driver. Every connection has its own data queue (data_q).
>
>Regards
>
>Marcel
>
>
>
>
>-------------------------------------------------------
>SF.Net is sponsored by: Speed Start Your Linux Apps Now.
>Build and deploy apps & Web services for Linux with
>a free DVD software kit from IBM. Click Now!
>http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
>_______________________________________________
>Bluez-devel mailing list
>[email protected]
>https://lists.sourceforge.net/lists/listinfo/bluez-devel
>
>
>-------------------------------------------------------
>SF.Net is sponsored by: Speed Start Your Linux Apps Now.
>Build and deploy apps & Web services for Linux with
>a free DVD software kit from IBM. Click Now!
>http://ads.osdn.com/?ad_id56&alloc_id438&op=click
>_______________________________________________
>Bluez-devel mailing list
>[email protected]
>https://lists.sourceforge.net/lists/listinfo/bluez-devel
>
>
--
_______________________________________________________________________
Dr. Simon Vogl
Institut f?r Pervasive Computing, Johannes Kepler Universit?t Linz
Altenberger Stra?e 69, A-4040 Linz, Austria
Tel: +43 732 2468-8517, Fax: +43 732 2468-8426
mailto: [email protected], http://www.soft.uni-linz.ac.at/
Hi Guys,
Your discussion is very relevant to me, since I'm building a small
wearable computer system that will have several Bluetooth devices -=20
among them will be a headset. I was planning to use standard rfcomm
to send data among the other devices and use SCO for the interface=20
from my computer to the BT headset.
It sounds from your discussion that SCO is really not ready to be used.
In my case, since I'm building an embedded system, I want simple
and low power. For my system I'd really like a socket interface to SCO.
If I MUST use a large audio package like ALSA, then I'll do that, but
I really want something small and simple.
Is there a bluez SCO that I can use ?=20
Do you have any idea when a stable SCO package will be available ?
I'm currently using linux-2.4.19 on an Intel Xscale processor.
thank you very much,
Regards,
Rich
Richard B. Williams
Vitronics, Inc.
3 Corbett Way
Eatontown, NJ 07724-2262
732-389-0244 x29
[email protected]
-----Original Message-----
From: Marcel Holtmann [mailto:[email protected]]
Sent: Monday, March 01, 2004 10:29 AM
To: James Courtier-Dutton
Cc: BlueZ Mailing List
Subject: Re: [Bluez-devel] SCO. Some ideas.
Hi James,
> I have started to think of how we might better achieve our goal =
without=20
> explicitly having trigger/pointer etc. api calls from the HCI to the =
SCO=20
> layer.
> The current bluez stack handles HCI SCO receiving ok for now. HCI SCO=20
> packets can be lost, but that is not so much of a problem.
> The current problem is the HCI SCO sending. i.e. CPU to Bluetooth air.
> There is no rate limiting in the HCI SCO sending.
> Options for rate limiting: -
> 1) For best sound quality, the rate limiting should be based on the =
HCI=20
> hardware, and not any other source.
> 2) Only send hci sco when one receives an hci sco
> This causes problems if received hci sco packets get dropped due to=20
> missed irqs etc. So it is better to not link the TX rate limiting to =
any=20
> RX packet rate.
> 3) Use the linux system time.
> If the user changes the time, the linux system time get changed, so =
the=20
> rate limiting will be messed up each time the linux system time is=20
> changed. So, better not to use the linux system time.
>=20
> So, we really want to use (1) if we can.
> How about?: -
>=20
> 1) Each hci sco packet being send from the sco layer to the hci layer =
is=20
> tagged with a sequence number.
> We send the hci sco packet from sco layer to hci layer.
> When the tx_complete for that hci sco packet happens, the packet is=20
> returned to the sco layer being taged as complete and then the sco =
layer=20
> refills it with new data and sends it down again. As we tagged the hci =
> sco packet with a sequence number, when it comes back we know which=20
> packet was actually send. As it has a sequence number on it, we can=20
> detect lost packets.
> Because the completed packet is send back up to the sco layer, we are=20
> able to remove one malloc/free from the process.
> Currently we have sco layer doing alloc, hci layer doing free.
>=20
> 2) Just use a limited sized queue.
> sco layer fills the queue, but when the queue is full, it waits.
> the hci layer empties the queue as and when it needs to.
> Currently, I think we have a queue, but the size of the queue is not=20
> controllable from the sco layer.
> It might be better if the hci layer reads the first item in the queue, =
> schedules it for output. the hci layer only frees the item from the=20
> queue when it reaches tx_complete.
> The tx_complete state is reached when the bluetooth hardware calls the =
> interrupt handler.
>=20
> I think option (2) fits more closely with the current bluez design. =
All=20
> I need is the answer to "How does one limit the queue size?".
maybe you should look at hci_send_sco() and you can control everything
by yourself that you wanna send down to the HCI layer and thus to the
driver. Every connection has its own data queue (data_q).
Regards
Marcel
-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=3D1356&alloc_id=3D3438&op=3Dclick
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi James,
> I have started to think of how we might better achieve our goal without
> explicitly having trigger/pointer etc. api calls from the HCI to the SCO
> layer.
> The current bluez stack handles HCI SCO receiving ok for now. HCI SCO
> packets can be lost, but that is not so much of a problem.
> The current problem is the HCI SCO sending. i.e. CPU to Bluetooth air.
> There is no rate limiting in the HCI SCO sending.
> Options for rate limiting: -
> 1) For best sound quality, the rate limiting should be based on the HCI
> hardware, and not any other source.
> 2) Only send hci sco when one receives an hci sco
> This causes problems if received hci sco packets get dropped due to
> missed irqs etc. So it is better to not link the TX rate limiting to any
> RX packet rate.
> 3) Use the linux system time.
> If the user changes the time, the linux system time get changed, so the
> rate limiting will be messed up each time the linux system time is
> changed. So, better not to use the linux system time.
>
> So, we really want to use (1) if we can.
> How about?: -
>
> 1) Each hci sco packet being send from the sco layer to the hci layer is
> tagged with a sequence number.
> We send the hci sco packet from sco layer to hci layer.
> When the tx_complete for that hci sco packet happens, the packet is
> returned to the sco layer being taged as complete and then the sco layer
> refills it with new data and sends it down again. As we tagged the hci
> sco packet with a sequence number, when it comes back we know which
> packet was actually send. As it has a sequence number on it, we can
> detect lost packets.
> Because the completed packet is send back up to the sco layer, we are
> able to remove one malloc/free from the process.
> Currently we have sco layer doing alloc, hci layer doing free.
>
> 2) Just use a limited sized queue.
> sco layer fills the queue, but when the queue is full, it waits.
> the hci layer empties the queue as and when it needs to.
> Currently, I think we have a queue, but the size of the queue is not
> controllable from the sco layer.
> It might be better if the hci layer reads the first item in the queue,
> schedules it for output. the hci layer only frees the item from the
> queue when it reaches tx_complete.
> The tx_complete state is reached when the bluetooth hardware calls the
> interrupt handler.
>
> I think option (2) fits more closely with the current bluez design. All
> I need is the answer to "How does one limit the queue size?".
maybe you should look at hci_send_sco() and you can control everything
by yourself that you wanna send down to the HCI layer and thus to the
driver. Every connection has its own data queue (data_q).
Regards
Marcel
-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Marcel Holtmann wrote:
> Hi James,
>
>
>>So you want me to implement it in such a way that would add 10-20ms of
>>latency and have no audio/video syncronisation features?
>
>
> yes, do it.
>
>
>>We might as well stay with the current alsa over network sockets which
>>is what we have now.
>
>
> We will see what the latency really is if we go directly from the ALSA
> driver to the HCI SCO interface.
>
> Regards
>
> Marcel
>
>
I have started to think of how we might better achieve our goal without
explicitly having trigger/pointer etc. api calls from the HCI to the SCO
layer.
The current bluez stack handles HCI SCO receiving ok for now. HCI SCO
packets can be lost, but that is not so much of a problem.
The current problem is the HCI SCO sending. i.e. CPU to Bluetooth air.
There is no rate limiting in the HCI SCO sending.
Options for rate limiting: -
1) For best sound quality, the rate limiting should be based on the HCI
hardware, and not any other source.
2) Only send hci sco when one receives an hci sco
This causes problems if received hci sco packets get dropped due to
missed irqs etc. So it is better to not link the TX rate limiting to any
RX packet rate.
3) Use the linux system time.
If the user changes the time, the linux system time get changed, so the
rate limiting will be messed up each time the linux system time is
changed. So, better not to use the linux system time.
So, we really want to use (1) if we can.
How about?: -
1) Each hci sco packet being send from the sco layer to the hci layer is
tagged with a sequence number.
We send the hci sco packet from sco layer to hci layer.
When the tx_complete for that hci sco packet happens, the packet is
returned to the sco layer being taged as complete and then the sco layer
refills it with new data and sends it down again. As we tagged the hci
sco packet with a sequence number, when it comes back we know which
packet was actually send. As it has a sequence number on it, we can
detect lost packets.
Because the completed packet is send back up to the sco layer, we are
able to remove one malloc/free from the process.
Currently we have sco layer doing alloc, hci layer doing free.
2) Just use a limited sized queue.
sco layer fills the queue, but when the queue is full, it waits.
the hci layer empties the queue as and when it needs to.
Currently, I think we have a queue, but the size of the queue is not
controllable from the sco layer.
It might be better if the hci layer reads the first item in the queue,
schedules it for output. the hci layer only frees the item from the
queue when it reaches tx_complete.
The tx_complete state is reached when the bluetooth hardware calls the
interrupt handler.
I think option (2) fits more closely with the current bluez design. All
I need is the answer to "How does one limit the queue size?".
Any comments?
Cheers
James
Hi James,
> So you want me to implement it in such a way that would add 10-20ms of
> latency and have no audio/video syncronisation features?
yes, do it.
> We might as well stay with the current alsa over network sockets which
> is what we have now.
We will see what the latency really is if we go directly from the ALSA
driver to the HCI SCO interface.
Regards
Marcel
-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel