-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
there's a kernel patch in snd-bt-sco, and it would be great if someone
could explain what it does:
*****
- --- linux-2.6.4-orig/drivers/bluetooth/hci_usb.c 2004-03-11
02:55:44.000000000 +0000
+++ linux-2.6.4/drivers/bluetooth/hci_usb.c 2004-03-13
23:52:27.000000000 +0000
@@ -851,7 +851,12 @@
~ #ifdef CONFIG_BT_HCIUSB_SCO
~ case USB_ENDPOINT_XFER_ISOC:
- - if (ep->desc.wMaxPacketSize < size || a > 2)
+ /* Use only the 9 byte
+ "One voice channel with 8 bit encoding"
+ endpoint until there is support for changing
+ the endpoint dynamically. See
+ Bluetooth 1.1 Part H:2, section 2.1 */
+ if (ep->desc.wMaxPacketSize != 9)
~ break;
~ size = ep->desc.wMaxPacketSize;
****
Also, it would be interesting to know if this patch for kernel 2.6.4 is
still nessesary for newer kernels (2.6.6 to be specific), because I want
to "port" snd-bt-sco to alsa 1.0.4 and kernel 2.6.6.
thanks in advance,
~ Lars
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFAqebKQWC6DTWkDAoRAsATAJ43Iinhsajz11AA15HWB8jgnXhVXQCfUMkU
nAKI5G5kkz+1dLD9A/+SgPo=
=7SjZ
-----END PGP SIGNATURE-----
-------------------------------------------------------
This SF.Net email is sponsored by: SourceForge.net Broadband
Sign-up now for SourceForge Broadband and get the fastest
6.0/768 connection for only $19.95/mo for the first 3 months!
http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Lars,
> um, sorry - what's an alternate setting? I mean, what exactly is "set" here?
this has nothing to do with ALSA or BlueZ. It is a USB specific
definition of having alternate settings for an interface. Look at
/proc/bus/usb/devices for your USB Bluetooth dongle.
Regards
Marcel
-------------------------------------------------------
This SF.Net email is sponsored by: SourceForge.net Broadband
Sign-up now for SourceForge Broadband and get the fastest
6.0/768 connection for only $19.95/mo for the first 3 months!
http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click
_______________________________________________
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 already looked up the voice number stuff in the core docs, and was
|>able to find out that 0x0140 is ideal right now (MU_LAW encoded). Works
|>here, already.
|
|
| for this you must use alternate setting 1, because it is 8 bit.
|
um, sorry - what's an alternate setting? I mean, what exactly is "set" here?
I have a working setup with
hciconfig hci0 voice 0x0140
the above kernel patch and the default snd-bt-sco driver stuff (of
course alsa codec information has changed from PCM to MU_LAW)
so I don't exactly know that this alternate setting means :)
Or is it a setting that makes the 8bit-modes possible without using that
kernel patch?
sorry, but I'm a bit new to Bluez :)
~ Lars
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFAqhGqQWC6DTWkDAoRAruDAJ4+ovPkHM6M7YvCI2nh6T82RcXy+QCfV8xf
Cc+MRgtEf1rE96S3NHmcV/g=
=mc1o
-----END PGP SIGNATURE-----
-------------------------------------------------------
This SF.Net email is sponsored by: SourceForge.net Broadband
Sign-up now for SourceForge Broadband and get the fastest
6.0/768 connection for only $19.95/mo for the first 3 months!
http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Lars,
> just wanted to mention that one single SCO connection at a time is
> sufficent right now, IMO; I don't think that most people will need more
> than one (open) connection for audio right now. Of course, if the core
> definition says there must be more than one, we have to implement it.
the difference is 8-bit, 16-bit and the number of SCO connections.
> Or is SCO used for anything else but audio?
With Bluetooth 1.2 and eSCO it will be possible to use it for data
transmission. We have to adapt full eSCO support at some time.
Regards
Marcel
-------------------------------------------------------
This SF.Net email is sponsored by: SourceForge.net Broadband
Sign-up now for SourceForge Broadband and get the fastest
6.0/768 connection for only $19.95/mo for the first 3 months!
http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Lars,
> I already looked up the voice number stuff in the core docs, and was
> able to find out that 0x0140 is ideal right now (MU_LAW encoded). Works
> here, already.
for this you must use alternate setting 1, because it is 8 bit.
> Hm, is there any chance to get this implemented "the proper" way, so all
> audio codecs (8bit 8kHz and 16bit 8kHz) can be used with hci_usb?
You can make use of the notify() callback and adjust the alternate
setting as needed. Maybe you have to unlink and re-submit the ISOC
URB's, but the best way is to start the ISOC URB's only when a SCO
connection is created.
Regards
Marcel
-------------------------------------------------------
This SF.Net email is sponsored by: SourceForge.net Broadband
Sign-up now for SourceForge Broadband and get the fastest
6.0/768 connection for only $19.95/mo for the first 3 months!
http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
just wanted to mention that one single SCO connection at a time is
sufficent right now, IMO; I don't think that most people will need more
than one (open) connection for audio right now. Of course, if the core
definition says there must be more than one, we have to implement it.
Or is SCO used for anything else but audio?
cu,
~ Lars
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFAqfT0QWC6DTWkDAoRAk1hAJ9jKGqBmKGaffY4wJfy+d0T9phZ4ACgoaaL
GL7p+eYbE7YPM4kgocamyqU=
=IiOx
-----END PGP SIGNATURE-----
-------------------------------------------------------
This SF.Net email is sponsored by: SourceForge.net Broadband
Sign-up now for SourceForge Broadband and get the fastest
6.0/768 connection for only $19.95/mo for the first 3 months!
http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
| There are different voice encodings over the isochronous USB channel
| that is used for the SCO connection. Which encoding is used is selected
| by running 'hciconfig hci0 voice <somenumber>', where <somenumber> is,
| for example, 0x0040 for one 8 bit 8000Hz stream and 0x0060 for one 16
| bit 8000Hz stream.
|
| Depending on how many SCO channels are open and what format is used,
| different isoc USB frames are used by the bluetooth device. The
| possibilities are enumerated in the documentation that is referenced in
| that comment.
|
I already looked up the voice number stuff in the core docs, and was
able to find out that 0x0140 is ideal right now (MU_LAW encoded). Works
here, already.
Hm, is there any chance to get this implemented "the proper" way, so all
audio codecs (8bit 8kHz and 16bit 8kHz) can be used with hci_usb?
I changed from PCM to MU_LAW because of the better quality, but of
course PCM/16bit would sound best. If - and only if - the sound data is
not already in PCM/8bit or MU_LAW.
I'd like to enhance the driver that it can handle all those three audio
modes (should not be that complicated; PCM/8 and MU_LAW are the same,
anyway, because they only use a different encoding, but same buffer
sizes, and 16 bit should simply use a double-size buffer ( or transmit
1/2 of the data)).
So, what has to be done to the hci_usb?
thanks,
~ Lars
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFAqe5QQWC6DTWkDAoRAueiAKCKzNV8FlhsIh6FcBnupj3N2o70eQCfYZCa
jvLzfRN71qitW4l8oXJNRA4=
=EgiL
-----END PGP SIGNATURE-----
-------------------------------------------------------
This SF.Net email is sponsored by: SourceForge.net Broadband
Sign-up now for SourceForge Broadband and get the fastest
6.0/768 connection for only $19.95/mo for the first 3 months!
http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
On 18 May 2004, at 11:34, Lars Grunewaldt wrote:
> there's a kernel patch in snd-bt-sco, and it would be great if someone
> could explain what it does:
>
> *****
> - --- linux-2.6.4-orig/drivers/bluetooth/hci_usb.c 2004-03-11
> 02:55:44.000000000 +0000
> +++ linux-2.6.4/drivers/bluetooth/hci_usb.c 2004-03-13
> 23:52:27.000000000 +0000
> @@ -851,7 +851,12 @@
>
> ~ #ifdef CONFIG_BT_HCIUSB_SCO
> ~ case USB_ENDPOINT_XFER_ISOC:
> - - if (ep->desc.wMaxPacketSize < size || a > 2)
> + /* Use only the 9 byte
> + "One voice channel with 8 bit encoding"
> + endpoint until there is support for changing
> + the endpoint dynamically. See
> + Bluetooth 1.1 Part H:2, section 2.1 */
> + if (ep->desc.wMaxPacketSize != 9)
> ~ break;
> ~ size = ep->desc.wMaxPacketSize;
> ****
There are different voice encodings over the isochronous USB channel
that is used for the SCO connection. Which encoding is used is selected
by running 'hciconfig hci0 voice <somenumber>', where <somenumber> is,
for example, 0x0040 for one 8 bit 8000Hz stream and 0x0060 for one 16
bit 8000Hz stream.
Depending on how many SCO channels are open and what format is used,
different isoc USB frames are used by the bluetooth device. The
possibilities are enumerated in the documentation that is referenced in
that comment.
What it boils down to is that for one 8000Hz 8 bit channel, the USB
packets are 9 bytes each. That check ensures that the appropriate
endpoint is selected. Otherwise, the wrong endpoint probably gets
chosen and the audio doesn't work at all or it sounds very bad.
The isoc streams ideally would be dynamically selected as required,
depending on the type and number of SCO connections. Since there wasn't
infrastructure in place when I wrote that patch, I hard-coded that
choice to coincide with that required by the alsa driver.
Hope that sheds some light on the matter!
-------------------------------------------------------
This SF.Net email is sponsored by: SourceForge.net Broadband
Sign-up now for SourceForge Broadband and get the fastest
6.0/768 connection for only $19.95/mo for the first 3 months!
http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Lars,
> there's a kernel patch in snd-bt-sco, and it would be great if someone
> could explain what it does:
>
> *****
> - --- linux-2.6.4-orig/drivers/bluetooth/hci_usb.c 2004-03-11
> 02:55:44.000000000 +0000
> +++ linux-2.6.4/drivers/bluetooth/hci_usb.c 2004-03-13
> 23:52:27.000000000 +0000
> @@ -851,7 +851,12 @@
>
> ~ #ifdef CONFIG_BT_HCIUSB_SCO
> ~ case USB_ENDPOINT_XFER_ISOC:
> - - if (ep->desc.wMaxPacketSize < size || a > 2)
> + /* Use only the 9 byte
> + "One voice channel with 8 bit encoding"
> + endpoint until there is support for changing
> + the endpoint dynamically. See
> + Bluetooth 1.1 Part H:2, section 2.1 */
> + if (ep->desc.wMaxPacketSize != 9)
> ~ break;
> ~ size = ep->desc.wMaxPacketSize;
> ****
according to the current voice setting (0x0060 by default) and the
number of SCO link the Bluetooth USB driver has to adjust the alternate
setting for the ISOC interface. Currently we don't support this dynamic
adjustment in hci_usb and so I have choosen to use alternate setting 2
as default value in the latest versions of 2.4 and 2.6 kernels. This
means that the voice setting must be 0x0060 and there can be only one
SCO link at the same time. For more information look at the Bluetooth
core specification.
> Also, it would be interesting to know if this patch for kernel 2.6.4 is
> still nessesary for newer kernels (2.6.6 to be specific), because I want
> to "port" snd-bt-sco to alsa 1.0.4 and kernel 2.6.6.
Don't use this patch and accept the default voice setting of 0x0060.
Regards
Marcel
-------------------------------------------------------
This SF.Net email is sponsored by: SourceForge.net Broadband
Sign-up now for SourceForge Broadband and get the fastest
6.0/768 connection for only $19.95/mo for the first 3 months!
http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Lars,
> you could as well say "an elephant won't fit into a mousewhole until it
> get's a dynamic interface". Of course mulaw and alaw differ from pcm/16
> bit only because they are 8bit/sample. so what. Would not work if it
> would be 7 or 9 bit, either. Also it's not likely that the bit count
> will change sooner or later :)
that is not the point here. The H:2 alternate setting for ISOC interface
only differs between 8bit or 16bit and the number of SCO connections.
> Suggestions are welcome. If anyone has an idea how to improve this
> "alternate setting" handling, i.e. make it possible for an
> application/driver to set the setting in runtime without rewriting the
> whole code, that would be a great thing.
Only the hci_usb driver has to take care of it and the needed notify()
framework from the BlueZ core is already in place.
Regards
Marcel
-------------------------------------------------------
This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND
_______________________________________________
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,
|
|
|>won't be a problem. I know what to do because I changed them before,
|>from S8 to MULAW_8 :)
|>
|>My only problem/wish is that I'd like to support all three audio
|>encodings, but I understand this is impossible right now.
|
|
| only because mulaw and alaw are 8bit.
you could as well say "an elephant won't fit into a mousewhole until it
get's a dynamic interface". Of course mulaw and alaw differ from pcm/16
bit only because they are 8bit/sample. so what. Would not work if it
would be 7 or 9 bit, either. Also it's not likely that the bit count
will change sooner or later :)
I'll have a look at the documentation and I'll try to figure out how to
improve the alsa/sco integration, but I'm very busy right now and I
don't know how fast I can come up with anything.
Suggestions are welcome. If anyone has an idea how to improve this
"alternate setting" handling, i.e. make it possible for an
application/driver to set the setting in runtime without rewriting the
whole code, that would be a great thing.
cu & thanks for listening :)
~ Lars
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFA0fomQWC6DTWkDAoRAn5tAJ9k0E1H5I8vNZxvV8sENsMPYp90YgCgiZzM
3wDmQBpZMUmQshpVsGJSMIk=
=MK9u
-----END PGP SIGNATURE-----
-------------------------------------------------------
This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Lars,
> won't be a problem. I know what to do because I changed them before,
> from S8 to MULAW_8 :)
>
> My only problem/wish is that I'd like to support all three audio
> encodings, but I understand this is impossible right now.
only because mulaw and alaw are 8bit.
> What exactly are the influences of the "alternate setting"? Does this
> only change SCO/Audio behaviour, or is the whole bluez stack affected by
> this (if hci_usb is used, of course). I just want to understand the
> pros/cons of 8bit/16bit setting.
Look at the Bluetooth specification of H:2. This is USB specific and it
is because of the ISOC transfers that are used for the SCO packets.
> There's one more (alsa-related) issue I have with the alsa driver. The
> problem is that, if there's no open sco channel, the audio application
> accessing the interface is stalled because the buffer is never read. It
> would be better if the data could be "dumped" or something.
>
> Is this possible in an easy way, or do I have to look for audio
> sync/timing and stuff instead of just writing the data to /dev/null and
> tell the app "go for the next buffer".
This is a complete other topic and as I said many times before the SCO
driver must be written to be better integrated into the BlueZ core and
the ALSA sound system.
Regards
Marcel
-------------------------------------------------------
This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Jonathan Paisley wrote:
| On 17 Jun 2004, at 1:24, Marcel Holtmann wrote:
|
|>> To make my headset work for now (need my "phone") I used that bad kernel
|>> patch again, but I'll try to do everything to avoid that in the release.
|>> I just have to understand what's going on...
|>
|>
|> I don't see your problem. Simply use 16bit PCM in the ALSA code.
|
|
| This should work fine. Reconfigure the sound format descriptors in the
| ALSA driver to describe 16 bit audio instead of 8 bit.
won't be a problem. I know what to do because I changed them before,
from S8 to MULAW_8 :)
My only problem/wish is that I'd like to support all three audio
encodings, but I understand this is impossible right now.
What exactly are the influences of the "alternate setting"? Does this
only change SCO/Audio behaviour, or is the whole bluez stack affected by
this (if hci_usb is used, of course). I just want to understand the
pros/cons of 8bit/16bit setting.
[listOT]
There's one more (alsa-related) issue I have with the alsa driver. The
problem is that, if there's no open sco channel, the audio application
accessing the interface is stalled because the buffer is never read. It
would be better if the data could be "dumped" or something.
Is this possible in an easy way, or do I have to look for audio
sync/timing and stuff instead of just writing the data to /dev/null and
tell the app "go for the next buffer".
[/listOT]
thanks,
~ Lars
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFA0Z4TQWC6DTWkDAoRAusPAKCaEozsMCgE38q4Ki+wHBcVoYu/RwCgjbPn
6NmfwP1Qxbvgrg3tMkPQdtg=
=AMrl
-----END PGP SIGNATURE-----
-------------------------------------------------------
This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
On 17 Jun 2004, at 1:24, Marcel Holtmann wrote:
> Hi Lars,
>
>> Now I'm lost again. Is there an audio transcoding somewhere in the SCO
>> layer, so that I could simply send PCM_S16 and the SCO layer
>> transcodes
>> the audio if the headset does not support this? I mean there must be a
>> reason why the original snd-bt-sco developer hardcoded the 8bit format
>> instead of using 16 bit.
>
> the reason was me, because my first SCO test was with a 3Com PCMCIA
> card
> and 8bit is less data than 16bit ;)
When I wrote the ALSA driver initially I fairly arbitrarily chose 8-bit
rather than 16-bit sound format.
>> To make my headset work for now (need my "phone") I used that bad
>> kernel
>> patch again, but I'll try to do everything to avoid that in the
>> release.
>> I just have to understand what's going on...
>
> I don't see your problem. Simply use 16bit PCM in the ALSA code.
This should work fine. Reconfigure the sound format descriptors in the
ALSA driver to describe 16 bit audio instead of 8 bit.
Hi Lars,
> Now I'm lost again. Is there an audio transcoding somewhere in the SCO
> layer, so that I could simply send PCM_S16 and the SCO layer transcodes
> the audio if the headset does not support this? I mean there must be a
> reason why the original snd-bt-sco developer hardcoded the 8bit format
> instead of using 16 bit.
the reason was me, because my first SCO test was with a 3Com PCMCIA card
and 8bit is less data than 16bit ;)
> What about audio quality during transcoding? MULAW sounds much better
> than PCM_S8.
Default air coding is CVSD with 16bit PCM input coding.
> Sorry that I don't fully understand this bluetooth stuff, I'm trying my
> best here. :(
>
> I hope I dont make anyone angry or something...
Don't worry, but you should dig through the mailing list archives. You
will find some detailed explanations for SCO.
> sorry, misunderstanding. I'll make a new version of snd-bt-sco that
> builds with alsa-1.0.5a. Nothing for bluez.
Feel free to do so.
> I'd like to help you out with this dynamic alternate setting adjustment,
> but I think I don't know enough usb and/or bluetooth mojo to do anything
> usefull.
Maybe someone should rewrite the hci_usb driver from scratch. There are
more issues with it :(
> To make my headset work for now (need my "phone") I used that bad kernel
> patch again, but I'll try to do everything to avoid that in the release.
> I just have to understand what's going on...
I don't see your problem. Simply use 16bit PCM in the ALSA code.
Regards
Marcel
-------------------------------------------------------
This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Marcel Holtmann wrote:
|>If you could just supply a short code snippet that shows how to handle
|>this stuff. Right now it does not look very wise to reduce support to
|>audio 0x0060, because it seems that not many headsets support that audio
|>encoding.
|
|
| This has nothing to do with the headset, because we are talking about
| the input coding and not the air coding.
Now I'm lost again. Is there an audio transcoding somewhere in the SCO
layer, so that I could simply send PCM_S16 and the SCO layer transcodes
the audio if the headset does not support this? I mean there must be a
reason why the original snd-bt-sco developer hardcoded the 8bit format
instead of using 16 bit.
What about audio quality during transcoding? MULAW sounds much better
than PCM_S8.
I have just a hard time with "accept 0x0060 because - ."
Sorry that I don't fully understand this bluetooth stuff, I'm trying my
best here. :(
I hope I dont make anyone angry or something...
|
|
|>As soon as this works again, I'll put a new patch together and make it
|>available.
|
|
| What kind of patch? We need dynamic alternate setting adjustment for the
| hci_usb driver. Nothing else.
sorry, misunderstanding. I'll make a new version of snd-bt-sco that
builds with alsa-1.0.5a. Nothing for bluez.
I'd like to help you out with this dynamic alternate setting adjustment,
but I think I don't know enough usb and/or bluetooth mojo to do anything
usefull.
To make my headset work for now (need my "phone") I used that bad kernel
patch again, but I'll try to do everything to avoid that in the release.
I just have to understand what's going on...
cu,
~ Lars
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFA0N/+QWC6DTWkDAoRArSUAJ4p4tJgUHZNgynBUdmQVyyGLR53lwCdGAe/
KLuMLz+uvuTKLaIO1yB8s9E=
=ZqlF
-----END PGP SIGNATURE-----
-------------------------------------------------------
This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Lars,
> I hope you can remember the issue we had a few weeks ago about
> snd-bt-sco/bt-headset stuff.
>
> I'm right now moving it from alsa 1.0.3 to 1.0.5a and kernel 2.6.7, and
> I want to get rid of this patch (as it seems you all don't like it).
>
> But I still don't understand, and can't find out, what I have to do to
> set the dubious "alternate" setting of the hci_usb you spoke of. I'm
> totally lost here, and I hope you can help me out easily :)
>
> I understand what it does, but I don't have *any* clue right now what I
> have to do to set the usb alternate setting.
the alternate setting is right for one SCO channel and a voice setting
of 0x0060.
> - - parameter to hci_usb on module load or some other CL stuff?
> - - changing something in the btsco userspace daemon that handles the
> rfcomm/sco-stuff?
>
> If you could just supply a short code snippet that shows how to handle
> this stuff. Right now it does not look very wise to reduce support to
> audio 0x0060, because it seems that not many headsets support that audio
> encoding.
This has nothing to do with the headset, because we are talking about
the input coding and not the air coding.
> As soon as this works again, I'll put a new patch together and make it
> available.
What kind of patch? We need dynamic alternate setting adjustment for the
hci_usb driver. Nothing else.
Regards
Marcel
-------------------------------------------------------
This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi again,
I hope you can remember the issue we had a few weeks ago about
snd-bt-sco/bt-headset stuff.
I'm right now moving it from alsa 1.0.3 to 1.0.5a and kernel 2.6.7, and
I want to get rid of this patch (as it seems you all don't like it).
But I still don't understand, and can't find out, what I have to do to
set the dubious "alternate" setting of the hci_usb you spoke of. I'm
totally lost here, and I hope you can help me out easily :)
I understand what it does, but I don't have *any* clue right now what I
have to do to set the usb alternate setting.
- - parameter to hci_usb on module load or some other CL stuff?
- - changing something in the btsco userspace daemon that handles the
rfcomm/sco-stuff?
If you could just supply a short code snippet that shows how to handle
this stuff. Right now it does not look very wise to reduce support to
audio 0x0060, because it seems that not many headsets support that audio
encoding.
As soon as this works again, I'll put a new patch together and make it
available.
thanks for helping out,
~ Lars
Marcel Holtmann wrote:
| Hi Lars,
|
|
|>um, sorry - what's an alternate setting? I mean, what exactly is "set"
here?
|
|
| this has nothing to do with ALSA or BlueZ. It is a USB specific
| definition of having alternate settings for an interface. Look at
| /proc/bus/usb/devices for your USB Bluetooth dongle.
|
| Regards
|
| Marcel
|
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFA0M5wQWC6DTWkDAoRAlK5AJ94SZEYK4UTgem1AwCFWBpaCCQ9OwCfZjUu
wM24Y3tNEwcKkL6UO24qQgY=
=MKIj
-----END PGP SIGNATURE-----
-------------------------------------------------------
This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel