[Bluez-devel] btsco and alsa driver interaction

[Bluez-devel] btsco and alsa driver interaction

[soraberri]

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
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

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

[Brad Midgley]

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
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

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

[soraberri]

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
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

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

[suche.org]

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
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel