Hi all!
First of all: thank you very much for your work and your help!
As suggested i installed a vanilla 2.6.9 kernel with mh4-patches, and
also updated bluez-libs and bluez-utils to the current version 2.11.
And, success: with yesterdays cvs version i have a2dp audio working
with my BT420! BTW: As sox plays only a very few of my mp3's i use
mpg123 for decoding:
mpg123 -s test.mp3 |sox -t raw -r 44100 -s -w -c 2 - -r 44100 -s -w
-t au - |sbc/sbcenc - | ./a2play 00:08:F4:30:03:71
But: i cannot get the normal voice headset to work.
The aplay command starts but then i do not hear anything, nor does
aplay finish:
aplay -D plughw:Headset test.wav
Playing WAVE 'test.wav' : Signed 16 bit Little Endian, Rate 22050 Hz,
Mono
In the system log i get the following entries:
Dec 1 08:32:08 linux kernel: snd-bt-sco: playback_trigger 0
Dec 1 08:32:08 linux kernel: snd-bt-sco: setting playback to NULL
Dec 1 08:32:09 linux kernel: snd-bt-sco: playback_open
Dec 1 08:32:09 linux kernel: snd-bt-sco: prepare ok bps: 16000 size:
8000 count: 2000
Dec 1 08:32:09 linux kernel: snd-bt-sco: playback_trigger 1
Dec 1 08:32:09 linux kernel: snd-bt-sco: setting playback to bspcm
Looks alright, doesn't it?
Do you have an idea what could be wrong? I checked the mixer settings
via alsamixer, which are fine too (BTW: what is this
"loopback"-switch?).
Thanks for any suggestions!
Sebastian
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Bluetooth wrote:
| Brad Midgley wrote:
|
|> We can continue to maintain a daemon that does not support these
|> features and works well for embeded systems. What applications will
|> you use the headset with and how will they start/stop/detect connections?
|
|
| Currently kphone sjphone, kphone vor example try to open the dsp device
| on inbound or outbond connection if we can signal btsco that dsp is open
| this would be sufficent or not ?
There are several reasons why a Headset can be "connected" to the DSP
(that is, open the SCO channel).
We discussed those earlier (I think on the old mailing list - is there
an archive?), and it pretty much boiles down to:
1. user presses button on the headset. Headset sends some RFCOMM stuff
to the server, and that one should open the SCO channel
2. the server opens the SCO channel
to indicate a ring on the headset there's also an RFCOMM signal that
should, following the BT specs, used to signalize the user "incoming
call" so that the user can connect the headphone and take the call by
pressing the button.
In fact I think a phone software must be able to use some "general"
interface to connect to the btsco daemon to signal "incoming call" and
recieve a "take call". That's what I'd expect of a real good phone
application supporting a headset - it should work excatly like my phone
connected to the headset.
But of course, there are many ways a headset could be used, so I think
we also need an "auto connect" mode that opens the sco connection when
the dsp is opened - like you described. Like the "auto-pickup" function
of a cellphone when in car mode or headset connected...
So the user must be able to select what his headset should do:
a) idle until user presses connect button, than connect
b) connect when audio interface is opened
(b) has some problems because there's a connection delay, and some
programs might open/close devices often, so maybe we need a disconnect
timeout (when device is disconnected, keep SCO running in case it
immediatly re-connects)
Just my thoughts...
|> the kernel needs changes in bluez.
|>
|> Marcel explained it once: "To get more than one SCO channel working
|> the hci_usb driver must be fixed to dynamicaly change the alternate
|> settting."
|>
|> again, I don't know SCO well enough to understand this, but it sounds
|> fundamental.
|>
|> the btsco in the kernel also needs to be changed to allow for multiple
|> simultaneous audio streams.
|
|
| Hm sounds bad :-(
Well it depends. What sounded more badly was his note about "the whole
hci_usb is a mess and should be rewritten".
The problem with hci_usb and sco is that you need to select the correct
"alternate setting" depending on the bitrate that is needed for *all*
sco channels together. So i.e. three 16 bit sco connections lead to the
48bit endpoint (just gussing, but it's something alike).
So the endpoint depends on the number of channels and of course on the
bitrate (there are several codecs that only use 8bit).
How the endpoint could be set is sorted out in a "rough style", but
there are several issues when it comes to interupts and not-yet-send
data in the USB urb's that I don't know how to fix right now. We have a
notify that tells the hci_usb about new made connections, and a counter
for sco connections. But are unable to simply change the alternate
settings as long as there are unsent USB packages, and we are unsure
where to safely switch the setting.
I'd have to dig deeply into it and I don't have the time right now. I
hope I'll have some more soon, but... *sigh*
Please don't focus only on your use case for btsco but remember that
there are very different topics that have to be addressed here. If you
are looking at embedded devices and trying to reduce dependencies than
we should think about one full-featured *and* one light-weight program
to solve our problems the best way for different platforms and needs.
And have a look what the BT specs say about how the headsets should
operate (audio connection stuff)
regards,
~ Lars
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFBrlmrQWC6DTWkDAoRAmL3AJ9+GYhlERvP1kejG2RN01qePkcmMwCgrqz+
mK8aBQ/E3oW8uoZhJNSzQhI=
=dweH
-----END PGP SIGNATURE-----
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Brad Midgley wrote:
> Thomas
>
>> Currently there is no support for multiple headset because of missing
>> arguments. It was an open question how it should be done.
>
>
> to actually answer the question, this looks best:
>
> - ./btsco2 <mac1> -1 <mac2> 1 <mac3> 2
> Where -1 in the Channel Parameter stand for Autodetec
>
> because I'm not sure the autodetect will always work. Can we use '0'
> instead of '-1' for autodetect though? -1 looks like a flag.
Hm than better 'a' because i think that even 0 is an valid channel.
> If we combine the a2dp and sco support, then we need to use
> alsa-lib/aserver because it requires userspace audio processing.
>
> If you want a voip application to work seamlessly with the headset, to
> make the headset ring on an incoming call for example, we need some
> kind of signaling like dbus.
>
> We can continue to maintain a daemon that does not support these
> features and works well for embeded systems. What applications will
> you use the headset with and how will they start/stop/detect connections?
Currently kphone sjphone, kphone vor example try to open the dsp device
on inbound or outbond connection if we can signal btsco that dsp is open
this would be sufficent or not ?
> the kernel needs changes in bluez.
>
> Marcel explained it once: "To get more than one SCO channel working
> the hci_usb driver must be fixed to dynamicaly change the alternate
> settting."
>
> again, I don't know SCO well enough to understand this, but it sounds
> fundamental.
>
> the btsco in the kernel also needs to be changed to allow for multiple
> simultaneous audio streams.
Hm sounds bad :-(
Cu Thomas
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Thomas
> Currently there is no support for multiple headset because of missing
> arguments. It was an open question how it should be done.
to actually answer the question, this looks best:
- ./btsco2 <mac1> -1 <mac2> 1 <mac3> 2
Where -1 in the Channel Parameter stand for Autodetec
because I'm not sure the autodetect will always work. Can we use '0'
instead of '-1' for autodetect though? -1 looks like a flag.
> This would make it to what it is an small deamon with no dependecies out
> of the kernel. This is ideal for embeded system.
If we combine the a2dp and sco support, then we need to use
alsa-lib/aserver because it requires userspace audio processing.
If you want a voip application to work seamlessly with the headset, to
make the headset ring on an incoming call for example, we need some kind
of signaling like dbus.
We can continue to maintain a daemon that does not support these
features and works well for embeded systems. What applications will you
use the headset with and how will they start/stop/detect connections?
>>> c) Is there any Plan to allow th BT-SCO Sound driver in kernel Space
>>> to handle mor than one bluetooth as sound device.
>>> Nice would be an option to tell the driver how many sound device he
>>> sould allocate.
> If there is an support i will build it in.
the kernel needs changes in bluez.
Marcel explained it once: "To get more than one SCO channel working the
hci_usb driver must be fixed to dynamicaly change the alternate settting."
again, I don't know SCO well enough to understand this, but it sounds
fundamental.
the btsco in the kernel also needs to be changed to allow for multiple
simultaneous audio streams.
brad
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Brad Midgley wrote:
> Thomas
>
>> a) How should btsco2 Handle Multiple Headset in the Parameter ?
>> - ./btsco2 <mac1> <mac2> <mac3>
>> - ./btsco2 <mac1> -1 <mac2> 1 <mac3> 2
>> Where -1 in the Channel Parameter stand for Autodetec
>
>
> the argument list is fine, but this is showing how we need to improve
> things. btsco needs to be split into three parts:
>
> * connection processor: keep saved state about what headsets are
> paired, available, connected, alsa device mappings, etc. We should get
> it to add a new headset while it's running via dbus events. (We will
> have to get it to talk to dbus for connect/disconnect events and
> control anyway)
Currently there is no support for multiple headset because of missing
arguments. It was an open question how it should be done.
I do not realy like the idee of d-bus for this task. From my point of
view btsco should be an smal daemon that run with low resources.
This special mean that he should not require an extream set of librarys
for tasks that can be done faster simpler and easer to read without the
libs.
1. ALSA till i used btsco i never needed to install libasound to get the
sound running under linux.
2. The configure script link without check against libptread wich is
aktuall not used on asound on my system
3. The btsco can be writen with less lines and less memory usage without
asound/pthread
4. Even the bluetooth stuff is not realy needed but leas overloaded in
my eyes.
This would make it to what it is an small deamon with no dependecies out
of the kernel. This is ideal for embeded system.
> * audio processor: the audio processing part of btsco will need to be
> separated out and put into alsa-lib.
There is no audio processor in the btsco daemon.
>
> * gui for telling the connection processor to
> discover/add/delete/connect/disconnect to a service on a headset
>
>> c) Is there any Plan to allow th BT-SCO Sound driver in kernel Space
>> to handle mor than one bluetooth as sound device.
>> Nice would be an option to tell the driver how many sound device he
>> sould allocate.
>
>
> it's been talked about. I don't exactly understand the problem so I
> pasted the discussion into the sourceforge bug item.
If there is an support i will build it in.
Cu Thomas
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Thomas
> a) How should btsco2 Handle Multiple Headset in the Parameter ?
> - ./btsco2 <mac1> <mac2> <mac3>
> - ./btsco2 <mac1> -1 <mac2> 1 <mac3> 2
> Where -1 in the Channel Parameter stand for Autodetec
the argument list is fine, but this is showing how we need to improve
things. btsco needs to be split into three parts:
* connection processor: keep saved state about what headsets are paired,
available, connected, alsa device mappings, etc. We should get it to add
a new headset while it's running via dbus events. (We will have to get
it to talk to dbus for connect/disconnect events and control anyway)
* audio processor: the audio processing part of btsco will need to be
separated out and put into alsa-lib.
* gui for telling the connection processor to
discover/add/delete/connect/disconnect to a service on a headset
> c) Is there any Plan to allow th BT-SCO Sound driver in kernel Space to
> handle mor than one bluetooth as sound device.
> Nice would be an option to tell the driver how many sound device he
> sould allocate.
it's been talked about. I don't exactly understand the problem so I
pasted the discussion into the sourceforge bug item.
> Fixed Problems from btsco:
> 1) If headset is not available on start the server try to connect it
> every 3 seconds
> Open:
> 1) Detect if headset disconnects and close sco/rfcomm socket and tell
> the kernel space
> 2) An rfcomm listener for inbound connections where headset initiate the
> connection.
fine.
brad
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Okay, well, shame on me...:
The A2DP playback worked right out of the box, so i did not notice
that you have to press the connect button on the headphone to
establish a voice connection... 8-()
Maybe we could add a note to the documentation...
Anyway, now it all is working fantastic, i can listen to music
streaming right from my notebook, and chat via Skype with my headset.
Thanks a lot for your help and your work!
It's amazing, i think i do not need my telephone anymore... ;-)
Sebastian
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi,
i have some Questions:
a) How should btsco2 Handle Multiple Headset in the Parameter ?
- ./btsco2 <mac1> <mac2> <mac3>
- ./btsco2 <mac1> -1 <mac2> 1 <mac3> 2
Where -1 in the Channel Parameter stand for Autodetec
b) How tell the User what BT Device to use for the headset(s)
c) Is there any Plan to allow th BT-SCO Sound driver in kernel Space to
handle mor than one bluetooth as sound device.
Nice would be an option to tell the driver how many sound device he
sould allocate.
Fixed Problems from btsco:
1) If headset is not available on start the server try to connect it
every 3 seconds
Open:
1) Detect if headset disconnects and close sco/rfcomm socket and tell
the kernel space
2) An rfcomm listener for inbound connections where headset initiate the
connection.
I think Open.1 i can fix.
Cu Thomas
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Thomas,
> > this looks a way better. I am going to check it in as btsco2.c
> >
> Uhps the S must be came in when is saved the source :-(
your version is now in the CVS as btsco2.c and I already fixed a bunch
of coding style mistakes that were still present (especially the missing
static declarations). There are still some more things that are not nice
and you should read the kernel coding style paper from Greg.
Regards
Marcel
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Thomas,
> i hope this time it is better c style.
this looks a way better. I am going to check it in as btsco2.c
However I got these with my first compilation run:
btsco2.c: In function `main':
btsco2.c:501: error: `S' undeclared (first use in this function)
btsco2.c:501: error: (Each undeclared identifier is reported only once
btsco2.c:501: error: for each function it appears in.)
btsco2.c:501: error: parse error before "if"
btsco2.c:481: warning: unused variable `rlen'
And btw we use unified diffs.
> Why libm, libdl and libpthread are linked ?
Needed by the ALSA library.
Regards
Marcel
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Index: btsco.c
===================================================================
RCS file: /cvsroot/bluetooth-alsa/btsco/btsco.c,v
retrieving revision 1.11
diff -r1.11 btsco.c
66,68d65
< #define NOT_CONNECTED 0
< #define CONNECTED 1
<
77c74
< {
---
> {
104c101
< }
---
> }
108c105
< {
---
> {
153c150
< }
---
> }
156c153
< {
---
> {
164c161
< }
---
> }
167c164
< {
---
> {
174c171
< }
---
> }
214d210
<
217a214
> int if_type;
221c218
< if (dev < 0)
---
> if (dev < 0)
231,232c228,229
< if (snd_hwdep_info_get_iface(hwdep_info) ==
< SNDRV_HWDEP_IFACE_BT_SCO) {
---
> if_type = snd_hwdep_info_get_iface(hwdep_info);
> if (if_type == SNDRV_HWDEP_IFACE_BT_SCO || if_type==12) {
301,313c298
< int main(int argc, char *argv[])
< {
< int dev;
< int card;
<
< struct sigaction sa;
<
< fd_set rfds;
< //struct timeval timeout;
< unsigned char buf[2048];
< //int sel, rlen, wlen;
< int rlen, wlen;
<
---
> struct s_headset {
317,337c302,303
<
< //char *filename;
< //mode_t filemode;
< //int mode = 0;
< int dd;
< int rd; // rfcomm handle
< int sd; //sco handle
< uint16_t sco_handle, sco_mtu, vs;
< char line[100];
< int volumes[2], last_volumes[2];
< int opdone;
<
< // sco_mode is our running mode. 0 => not connect, 1 => connected
< // see NOT_CONNECTED,CONNECTED :)
< int sco_mode;
<
< struct pollfd pfds[10];
< int nfds;
<
< int i, err;
<
---
> int rfcomm_fd;
> int sco_fd;
339,343c305,331
< char hwdep_name[16];
<
< /* detect the audio device */
< if (find_hwdep_device(&card, &dev)) {
< error("Can't find device. Bail");
---
> int volumes[2];
> int last_volumes[2];
> struct s_headset *next;
> };
>
> struct s_headset b_headset;
> struct s_headset *first = NULL;
>
> int headset_button(struct s_headset *headset)
> {
> uint16_t sco_handle, sco_mtu;
>
> if (headset == NULL)
> return 0;
> if (headset->sco_fd != -1) {
> /* close bt_sco audio handle */
> bt_sco_set_fd(headset->handle, -1);
> /* disconnect SCO stream */
> close(headset->sco_fd);
> headset->sco_fd = -1;
> fprintf(stderr, "disconnected SCO channel\n");
> return 1;
> }
> fprintf(stderr, "opened hwdep\n");
> /* connect sco stream */
> if ((headset->sco_fd = sco_connect(&headset->local, &headset->bdaddr, &sco_handle, &sco_mtu)) < 0) {
> perror ("Can't connect SCO audio channel\n");
345a334,361
> fprintf(stderr, "connected SCO channel\n");
> // write(rd, "RING\r\n", 6);
> printf ("Setting sco fd\n");
> bt_sco_set_fd (headset->handle, headset->sco_fd);
> printf ("Done setting sco fd\n");
> return 1;
> }
>
> struct s_headset *headset_new (void)
> {
> struct s_headset *headset;
> headset = malloc (sizeof(struct s_headset));
> if (headset == NULL)
> return NULL;
> headset->sco_fd = -1;
> headset->rfcomm_fd = -1;
> headset->handle = NULL;
> headset->last_volumes[0] = 0;
> headset->last_volumes[1] = 0;
> headset->next = first;
> first = headset;
> return headset;
> }
>
> int headset_volume_fromcard (struct s_headset *headset)
> {
> int len;
> char line[100];
347c363,392
< printf("Device is %d:%d\n", card, dev);
---
> len = snd_hwdep_read(headset->handle, headset->volumes, sizeof(headset->volumes));
> if (len != sizeof(headset->volumes))
> return 0;
> printf ("volume speaker: %d mic: %d\n", headset->volumes[0], headset->volumes[1]);
> if (headset->volumes[0] != headset->last_volumes[0]) {
> sprintf(line, "+VGS=%d\r", headset->volumes[0]);
> write(headset->rfcomm_fd, line, strlen(line));
> headset->last_volumes[0] = headset->last_volumes[0];
> }
> if (headset->volumes[1] != headset->last_volumes[1]) {
> sprintf(line, "+VGM=%d\r", headset->volumes[1]);
> write(headset->rfcomm_fd, line, strlen(line));
> headset->last_volumes[1] = headset->last_volumes[1];
> }
> return 1;
> }
>
> int headset_speaker (struct s_headset *headset)
> {
> fprintf(stderr, "Sending up speaker change %d\n", headset->volumes[0]);
> snd_hwdep_write(headset->handle, headset->volumes, sizeof (headset->volumes));
> return 1;
> }
>
> int headset_micro (struct s_headset *headset)
> {
> fprintf(stderr, "Sending up microphone change %d\n", headset->volumes[1]);
> snd_hwdep_write(headset->handle, headset->volumes, sizeof (headset->volumes));
> return 1;
> }
349c394,417
< sprintf(hwdep_name, "hw:%i,%i", card, dev);
---
> int headset_from_bt (struct s_headset *headset)
> {
> unsigned char buf[2048];
> int rlen;
> int opdone;
>
> opdone = 0;
> rlen = read(headset->rfcomm_fd, buf, sizeof(buf) - 1);
> if (rlen <= 0)
> return 0;
> buf [rlen] = 0;
> fprintf(stderr, "recieved %s\n", buf);
> if (strstr(buf, "AT+BVRA=" )) opdone = headset_button(headset);
> else if (strstr(buf, "AT+CKPD=200")) opdone = headset_button(headset);
> else if (strstr(buf, "AT+CHUP" )) opdone = headset_button(headset);
> else if (strstr(buf, "AT+CIND=?" )) opdone = headset_button(headset);
> else if (sscanf (buf, "AT+VGS=%d", &headset->volumes[0]) == 1) opdone = headset_speaker (headset);
> else if (sscanf (buf, "AT+VGM=%d", &headset->volumes[1]) == 1) opdone = headset_micro (headset);
> if (opdone == 1)
> /* tell them we recieved */
> write(headset->rfcomm_fd, "\r\nOK\r\n", 6);
> else write(headset->rfcomm_fd, "\r\nERROR\r\n", 9);
> return 1;
> }
351,354c419,425
< /* open hwdep on audio device */
< if ((err = snd_hwdep_open(&handle, hwdep_name, O_RDWR)) < 0) {
< error("btsco open (%i-%i): %s\n", card, dev, snd_strerror(err));
< return -1;
---
> void headset_destroy(struct s_headset *headset)
> {
> if (headset == NULL)
> return;
> if (headset->sco_fd != -1) {
> bt_sco_set_fd(headset->handle, -1);
> close(headset->sco_fd);
357,361c428,436
< if (argc > 3) {
< printf("Clearing fd\n");
< bt_sco_set_fd(handle, 1);
< return 1;
< }
---
> sleep(1);
> if (headset->rfcomm_fd != -1)
> close(headset->rfcomm_fd);
> if (headset->handle != NULL)
> snd_hwdep_close(headset->handle);
> headset->sco_fd = -1;
> headset->rfcomm_fd = -1;
> headset->handle = NULL;
> }
363,376c438,447
< /* find bdaddr */
< switch (argc) {
< case 2:
< str2ba(argv[1], &bdaddr);
< channel = detect_channel(&bdaddr);
< break;
< case 3:
< str2ba(argv[1], &bdaddr);
< channel = atoi(argv[2]);
< break;
< default:
< usage();
< exit(-1);
< }
---
> void cleanup(void)
> {
> struct s_headset *akt_headset;
> akt_headset = first;
> while (akt_headset != NULL) {
> struct s_headset *next = akt_headset->next;
> headset_destroy(akt_headset);
> akt_headset = next;
> }
> }
377a449,452
> int check_bt_voice(int dev)
> {
> int dd;
> uint16_t vs;
379,380c454
< hci_devba(0, &local);
< dd = hci_open_dev(0);
---
> dd = hci_open_dev(dev);
397a472,532
> return 0;
> }
>
> int main(int argc, char *argv[])
> {
> int dev;
> int card;
> struct sigaction sa;
>
> int rlen;
> int bt_dev = 0;
>
> struct pollfd pfds[16];
>
> int err;
>
> char hwdep_name[16];
> struct s_headset *akt_headset;
>
> atexit(cleanup);
>
> /* detect the audio device */
> if (find_hwdep_device(&card, &dev)) {
> error("Can't find device. Bail");
> return 1;
> }
> printf("Device is %d:%d\n", card, dev);
> sprintf(hwdep_name, "hw:%i,%i", card, dev);S
>
> if (check_bt_voice(bt_dev))
> return -1;
>
>
> /* find bdaddr */
> switch (argc) {
> case 2:
> akt_headset = headset_new();
> hci_devba(bt_dev, &akt_headset->local);
> str2ba(argv[1], &akt_headset->bdaddr);
> akt_headset->channel = detect_channel(&akt_headset->bdaddr);
> /* open hwdep on audio device */
> if ((err = snd_hwdep_open(&akt_headset->handle, hwdep_name, O_RDWR)) < 0) {
> error("btsco open (%i-%i): %s\n", card, dev, snd_strerror(err));
> return -1;
> }
> break;
> case 3:
> akt_headset = headset_new();
> hci_devba(bt_dev, &akt_headset->local);
> str2ba(argv[1], &akt_headset->bdaddr);
> akt_headset->channel = atoi(argv[2]);
> /* open hwdep on audio device */
> if ((err = snd_hwdep_open(&akt_headset->handle, hwdep_name, O_RDWR)) < 0) {
> error("btsco open (%i-%i): %s\n", card, dev, snd_strerror(err));
> return -1;
> }
> break;
> default:
> usage();
> exit(-1);
> }
410,435d544
< /* connect rfcomm control channel */
< if ((rd = rfcomm_connect(&local, &bdaddr, channel)) < 0) {
< perror("Can't connect RFCOMM channel");
< return -1;
< }
<
< fprintf(stderr, "RFCOMM channel %i connected\n", channel);
<
< i = 0;
<
< /* set up data polling description */
< nfds = 0;
<
< /* polling data from rfcomm */
< pfds[nfds].fd = rd;
< pfds[nfds++].events = POLLIN;
<
< // polling data from command line - unused now
< // pfds[nfds].fd = 0;
< // pfds[nfds++].events = POLLIN;
<
< /* polling data from hwdep interface */
< nfds += snd_hwdep_poll_descriptors(handle, &pfds[nfds], 1);
<
< last_volumes[0] = last_volumes[1] = 0;
<
437,438d545
< sco_mode = NOT_CONNECTED;
< sd = -1;
439a547,572
> short revents;
> int nfds;
> nfds = 0;
> /* set up data polling description */
> for (akt_headset = first; akt_headset != NULL; akt_headset = akt_headset->next) {
> if (akt_headset->rfcomm_fd == -1)
> {
> /* connect rfcomm control channel */
> if ((akt_headset->rfcomm_fd = rfcomm_connect(
> &akt_headset->local,
> &akt_headset->bdaddr,
> akt_headset->channel)) < 0)
> fprintf(stderr, "Can't connect RFCOMM channel");
> else fprintf(stderr, "RFCOMM channel %i connected\n", akt_headset->channel);
> }
> if (akt_headset->rfcomm_fd != -1)
> {
> pfds[nfds].fd = akt_headset->rfcomm_fd;
> pfds[nfds++].events = POLLIN;
> }
> if (akt_headset->handle != NULL)
> {
> /* polling data from hwdep interface */
> nfds += snd_hwdep_poll_descriptors(akt_headset->handle, &pfds[nfds], 1);
> }
> }
441,444c574,579
< opdone = 0;
<
< if (poll(pfds, nfds, 1000) > 0) {
< short revents;
---
> if (nfds == 0) {
> sleep(3);
> continue;
> }
> if (poll(pfds, nfds, 1000) <= 0)
> continue;
446,472c581,586
< /*printf("inner loop\n"); */
< /* Volume polling (sound card) */
< if (!snd_hwdep_poll_descriptors_revents
< (handle, &pfds[nfds - 1], 1, &revents)
< && revents & POLLIN) {
< int len;
<
< len =
< snd_hwdep_read(handle, volumes,
< sizeof(volumes));
< if (len == sizeof(volumes)) {
< printf
< ("speaker volume: %d mic volume: %d\n",
< volumes[0], volumes[1]);
< if (volumes[0] != last_volumes[0]) {
< sprintf(line, "+VGS=%d\r",
< volumes[0]);
< write(rd, line, strlen(line));
< }
< if (volumes[1] != last_volumes[1]) {
< sprintf(line, "+VGM=%d\r",
< volumes[1]);
< write(rd, line, strlen(line));
< }
< memcpy(last_volumes, volumes,
< sizeof(volumes));
< opdone = 1;
---
> for (akt_headset = first; akt_headset != NULL; akt_headset = akt_headset->next) {
> int j;
> for (j=0; j<nfds; j++) {
> if (pfds[j].fd == akt_headset->rfcomm_fd) {
> if (pfds[j].revents & POLLIN) headset_from_bt (akt_headset);
> continue;
474,548c588,599
< }
< // control transmission events for volume and channel control
< if (pfds[0].revents & POLLIN) {
< memset(buf, 0, sizeof(buf));
< rlen = read(rd, buf, sizeof(buf) - 1);
< if (rlen > 0) {
< fprintf(stderr, "recieved %s\n", buf);
< /* tell them we recieved */
< wlen = write(rd, "\r\nOK\r\n", 6);
<
< if (strstr(buf, "AT+BVRA=")
< || strstr(buf, "AT+CKPD=200")
< || strstr(buf, "AT+CHUP")
< || strstr(buf, "AT+CIND=?")) {
< /* mini state machine: handle connect/disconnect */
< switch (sco_mode) {
< case NOT_CONNECTED:
< fprintf(stderr,
< "opened hwdep\n");
< /* connect sco stream */
< if ((sd =
< sco_connect(&local,
< &bdaddr,
< &sco_handle,
< &sco_mtu))
< < 0) {
<
< perror
< ("Can't connect SCO audio channel\n");
< } else {
< fprintf(stderr,
< "connected SCO channel\n");
< // write(rd, "RING\r\n", 6);
< printf
< ("Setting sco fd\n");
< bt_sco_set_fd
< (handle,
< sd);
<
< printf
< ("Done setting sco fd\n");
< sco_mode =
< CONNECTED;
< }
<
< opdone = 1;
< break;
< case CONNECTED:
< /* close bt_sco audio handle */
< bt_sco_set_fd(handle,
< -1);
< /* disconnect SCO stream */
< close(sd);
< fprintf(stderr,
< "disconnected SCO channel\n");
<
< sco_mode =
< NOT_CONNECTED;
<
< opdone = 1;
< break;
< }
< }
<
< if (sscanf
< (buf, "AT+VGS=%d",
< &volumes[0]) == 1) {
< fprintf(stderr,
< "Sending up speaker change %d\n",
< volumes[0]);
< snd_hwdep_write(handle,
< volumes,
< sizeof
< (volumes));
< opdone = 1;
---
> #ifdef TEST
> if (pfds[j].fd == akt_headset->sco_fd) {
> /* Just for testing; handled by kernel driver */
> fd_set rfds;
> if (0 && FD_ISSET(akt_headset->sco_fd, &rfds)) {
> int i;
> unsigned char buf[2048];
> memset(buf, 0, sizeof(buf));
> rlen = read(akt_headset->sco_fd, buf, sizeof(buf));
> write(akt_headset->sco_fd, buf, rlen);
> i++;
> if (i % 15 == 0) printf("rlen: %d\n", rlen);
550,576c601
< if (sscanf
< (buf, "AT+VGM=%d",
< &volumes[1]) == 1) {
< fprintf(stderr,
< "Sending up microphone change %d\n",
< volumes[1]);
< snd_hwdep_write(handle,
< volumes,
< sizeof
< (volumes));
< opdone = 1;
<
< }
< }
< }
<
< /* Just for testing; handled by kernel driver */
<
< if (0 && FD_ISSET(sd, &rfds)) {
< memset(buf, 0, sizeof(buf));
< rlen = read(sd, buf, sizeof(buf));
< write(sd, buf, rlen);
<
< i++;
<
< if (i % 15 == 0) {
< printf("rlen: %d\n", rlen);
---
> continue;
577a603,606
> #endif
> /* Volume polling (sound card) */
> if (!snd_hwdep_poll_descriptors_revents (akt_headset->handle, &pfds[j], 1, &revents) && revents & POLLIN)
> headset_volume_fromcard (akt_headset);
580,581d608
< if (!opdone)
< sleep(1);
583,595d609
<
< if (sco_mode == CONNECTED) {
< close(sd);
<
< bt_sco_set_fd(handle, -1);
<
< }
<
< sleep(1);
< close(rd);
<
< snd_hwdep_close(handle);
<
Hi Sebastian,
> On Wednesday, 1. December 2004 10:43, Marcel Holtmann wrote:
> > > Generally it should work with kernel 2.6.9, right?
> >
> > yes, and last time I tested this, it worked for me.
>
> Hmm, is there anything i can do to get more information about the
> problem? Any debug switch?
actually I have no idea, because I haven't written any line of code for
this. However take a look at what hcidump reports.
Regards
Marcel
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Marcel,
On Wednesday, 1. December 2004 10:43, Marcel Holtmann wrote:
> > Generally it should work with kernel 2.6.9, right?
>
> yes, and last time I tested this, it worked for me.
Hmm, is there anything i can do to get more information about the
problem? Any debug switch?
Thanks!
Sebastian
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Sebastian,
> > this should work. Do you enabled CONFIG_BT_HCIUSB_SCO in your
> > kernel?
>
> cat /proc/config.gz |gunzip -|grep CONFIG_BT_HCIUSB_SCO
> CONFIG_BT_HCIUSB_SCO=y
>
> Yes, it's enabled. Hmm, tricky thing...
> Generally it should work with kernel 2.6.9, right?
yes, and last time I tested this, it worked for me.
Regards
Marcel
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
On Wednesday, 1. December 2004 09:31, Marcel Holtmann wrote:
> this should work. Do you enabled CONFIG_BT_HCIUSB_SCO in your
> kernel?
cat /proc/config.gz |gunzip -|grep CONFIG_BT_HCIUSB_SCO
CONFIG_BT_HCIUSB_SCO=y
Yes, it's enabled. Hmm, tricky thing...
Generally it should work with kernel 2.6.9, right?
Sebastian
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Sebastian,
> "hciconfig hci0 revision" gives me:
>
> hci0: Type: USB
> BD Address: 00:0F:B3:17:3E:D0 ACL MTU: 192:8 SCO MTU: 64:8
> HCI 18.2
> Chip version: BlueCore02
> Max key size: 128 bit
> SCO mapping: HCI
this should work. Do you enabled CONFIG_BT_HCIUSB_SCO in your kernel?
Regards
Marcel
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Marcel,
On Wednesday, 1. December 2004 08:54, Marcel Holtmann wrote:
> there is no need to put sox in between:
>
> mpg123 --au - test.mp3 | sbc/sbcenc - | ./a2play 00:08:F4:30:03:71
Ahhh, even easier... ;-)
"hciconfig hci0 revision" gives me:
hci0: Type: USB
BD Address: 00:0F:B3:17:3E:D0 ACL MTU: 192:8 SCO MTU: 64:8
HCI 18.2
Chip version: BlueCore02
Max key size: 128 bit
SCO mapping: HCI
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Sebastian,
> And, success: with yesterdays cvs version i have a2dp audio working
> with my BT420! BTW: As sox plays only a very few of my mp3's i use
> mpg123 for decoding:
> mpg123 -s test.mp3 |sox -t raw -r 44100 -s -w -c 2 - -r 44100 -s -w
> -t au - |sbc/sbcenc - | ./a2play 00:08:F4:30:03:71
there is no need to put sox in between:
mpg123 --au - test.mp3 | sbc/sbcenc - | ./a2play 00:08:F4:30:03:71
> But: i cannot get the normal voice headset to work.
> The aplay command starts but then i do not hear anything, nor does
> aplay finish:
> aplay -D plughw:Headset test.wav
> Playing WAVE 'test.wav' : Signed 16 bit Little Endian, Rate 22050 Hz,
> Mono
>
> In the system log i get the following entries:
>
> Dec 1 08:32:08 linux kernel: snd-bt-sco: playback_trigger 0
> Dec 1 08:32:08 linux kernel: snd-bt-sco: setting playback to NULL
> Dec 1 08:32:09 linux kernel: snd-bt-sco: playback_open
> Dec 1 08:32:09 linux kernel: snd-bt-sco: prepare ok bps: 16000 size:
> 8000 count: 2000
> Dec 1 08:32:09 linux kernel: snd-bt-sco: playback_trigger 1
> Dec 1 08:32:09 linux kernel: snd-bt-sco: setting playback to bspcm
>
> Looks alright, doesn't it?
What does "hciconfig hci0 revision" say?
Regards
Marcel
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel