2005-03-08 19:11:31

by soraberri

[permalink] [raw]
Subject: [Bluez-devel] btsco and alsa driver interaction



I have studied btsco.c code (the userspace code part), but I'm scared of
the kernel part. It's my first match with a kernel driver and it has won
the game... so, I would like to ask you just to figure out how the big
black box is behaving.

My impression is that in btsco daemon, once we get the descriptor for
the SOCK_STREAM socket we just need to hook it to the hwdep device, and
it seems that it is done this way -more or less-

sd=sco_connect( &local,
&bdaddr,
&sco_handle,
&sco_mtu));

bt_sco_set_fd(handle, sd);

where _handle_ represents the device. So I imagine that all what is
happening with the SCO channel is "carried" into the device. Is it right?


I also imagine that when we poll data from the hwdep interface, we are
not polling SCO data type (which I assume it is being drived
automatically); instead, we are polling for volume-control data type
which is enigmatically (for me) generated at the core of the driver. Is
it right?

The question is, 'when does the following condition evaluate TRUE ?

if (!snd_hwdep_poll_descriptors_revents(handle, &pfds[nfds - 1], 1,
revents) && revents & POLLIN) {

a) when we have used the write function some point before, like this:
snd_hwdep_write(handle, volumes, sizeof(volumes));

b) only when the driver is initialized at the begining

c) or, periodically at some interval defined in the driver code...

well, sorry if these answers are a bit obscure, they are just to give
you an idea of how poor is what I can imagine. I think what I wish to
know is 'when and why will the hwdep interface produce the events we are
listening for'?

Thanks a lot in advance

Luis Peiro



-------------------------------------------------------
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://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel


2005-03-10 08:26:04

by suche.org

[permalink] [raw]
Subject: Re: [Bluez-devel] Re: btsco and alsa driver interaction

soraberri wrote:

> Hi
>
> many thanks Brad! I didn't think in the mixer before... now I think I
> got it :O
> (by the way, I haven't forgotten about adding support in the audio
> gateway as you suggested one day, in order to let the headset intiate
> an audio connection. This would require the proper SDP record in the
> database with the proper RFCOMM channel number, and a RFCOMM socket
> listening in the application. I made some copy-paste for the first
> thing in sdptool code, but I haven't find the rigth place for the
> listening socket yet... I have much left to study I guess!)

Hi,

in btso2 the listen socket can be easyly integretet.
You aktivate hin in the main while loop. It should be no problem
since the programm is desinged to handle multiple connections.
But currently only supprt one since i do not know how to add an second
headset, and have none.

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://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

2005-03-09 09:17:15

by soraberri

[permalink] [raw]
Subject: [Bluez-devel] Re: btsco and alsa driver interaction

Hi

many thanks Brad! I didn't think in the mixer before... now I think I
got it :O
(by the way, I haven't forgotten about adding support in the audio
gateway as you suggested one day, in order to let the headset intiate an
audio connection. This would require the proper SDP record in the
database with the proper RFCOMM channel number, and a RFCOMM socket
listening in the application. I made some copy-paste for the first thing
in sdptool code, but I haven't find the rigth place for the listening
socket yet... I have much left to study I guess!)

best regards

Luis_Peiro



Brad Midgley wrote:
> Luis
>
> It's good to see your interest... I think you have the right ideas on
> how things work.
>
>> I also imagine that when we poll data from the hwdep interface, we are
>> not polling SCO data type (which I assume it is being drived
>> automatically); instead, we are polling for volume-control data type
>> which is enigmatically (for me) generated at the core of the driver.
>> Is it right?
>
>
> if the volume change is initiated through a generic mixer, then yes.
> Think of a mixer application running on your computer. Run any
> alsa-aware mixer and it will let you choose the alsa mixer device to be
> the headset.
>
>> The question is, 'when does the following condition evaluate TRUE ?
>>
>> if (!snd_hwdep_poll_descriptors_revents(handle, &pfds[nfds - 1], 1,
>> revents) && revents & POLLIN) {
>
>
> It evaluates true when there are volume-change events to be examined
> that were initiated through a soft mixer.
>
> 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://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click



-------------------------------------------------------
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://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

2005-03-09 02:04:25

by Brad Midgley

[permalink] [raw]
Subject: Re: [Bluez-devel] btsco and alsa driver interaction

Luis

It's good to see your interest... I think you have the right ideas on
how things work.

> I also imagine that when we poll data from the hwdep interface, we are
> not polling SCO data type (which I assume it is being drived
> automatically); instead, we are polling for volume-control data type
> which is enigmatically (for me) generated at the core of the driver. Is
> it right?

if the volume change is initiated through a generic mixer, then yes.
Think of a mixer application running on your computer. Run any
alsa-aware mixer and it will let you choose the alsa mixer device to be
the headset.

> The question is, 'when does the following condition evaluate TRUE ?
>
> if (!snd_hwdep_poll_descriptors_revents(handle, &pfds[nfds - 1], 1,
> revents) && revents & POLLIN) {

It evaluates true when there are volume-change events to be examined
that were initiated through a soft mixer.

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://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel