Guys,
I put some junk in the btsco cvs:
alsa-lib.patch
bt/
if you apply alsa-lib.patch and put bt inside alsa-lib/src/pcm then the
idea is that you can build a userspace alsa driver.
currently it doesn't even compile... it's just based on the jack plugin
and not yet reworked for bluetooth.
anyway, this is my next project. it depends on a couple of things in
other parts of the project:
it would be nice if 'make install' inside sbc/ would install the sbc
includes and library (static libs would be ok)
the avdtp library is just a skeleton right now... should I just ignore
it for now and hardcode what is currently in a2play?
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
Thomas,
> i think this goes to the wrong direction.
> 1. Even if there exist alsa library for many programms it is sufficent
> to use /dev/dsp and /dev/audio.
> This mean that the soundcard driver should work independent of the alsa
> library.
...
> So what are the grounds for moving btsco to the lib inseat of moving it
> to the module ?
I think Marcel explained sufficiently that this is how we can get
handsfree and a2dp profiles working properly in the audio driver.
When we get the libalsa stuff going, there will be overlap in function
with the current kernel module and daemon, but we can keep the kernel
module in our project. As with everything open source, it'll be
maintained by people who care about it.
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
Hi Thomas,
> > this is too short thinking. There are parts that don't belong inside the
> > kernel. And SBC encoding and decoding is one of them.
> >
> OK that is an point that i can understand. But the btsco daemon does
> not handly any conversion.
> He is only responsible for managing the "hardware" Meaning 2 points:
> - handle the hardware connection rfcomm / sco
> - pipe the volume information betwen the mixer and the headset.
> He does not do any conversion and also he only interact between kernel
> modules as an linking glue.
the SCO is PCM and so there is no problem to have this inside the
kernel, but headset profile means AT commands over RFCOMM. I am not
going to put an AT parser inside the kernel.
> > Bluetooth is not only hardware. What you see is a dongle, but on top
> > there is a complete stack. We interface with L2CAP and this is a
> > software layer.
> >
> Hm here came L2CAP in ? Currently i see that there is an rfcomm
> connection for controll
> and an SCO connection there the audio data is transmitted.
And RFCOMM is on top of L2CAP. Even if you don't have to worry about
L2CAP, it is there.
> btsco connect to rfcomm and connect/disconnect sco with sound module
> and send mixer infos.
> there i do not se the point there whe deamon handle L2CAP. And i think
> the discussion is there to
> move this part.
> I think an good comparision would be the Network to Bluetooth sound
> Mozilla --- HTTP --- tcp --- ip --- arp --- 802.3
> --- kable
> KPhone --- dsp/audio --- sco/rfcomm --- bluethooth
> --- on air
>
> btsco is in the level of sco/rfcomm.
> This could be compared with the routing engine that decide on wich
> device an packet went.
> There sco is the tcp/udp channel and rfcomm the icmp.
This is not compareable. TCP/IP is more protocol specific and the
Bluetooth stack is more profile/application specific.
> The situation is similiar in antoher point the basic routing is done
> in the kernel so that tcp stack is usable.
> And external routing deamon is used for higher layer routing wich
> interact with the internal routing.
I don't get the point what static routing versus dynamic routing has to
do with it.
> For bluetooth headset this would mean basic function is done in the
> kernel (connection handling, volume controll).
> data conversion and spezial sound protocol in userspace.
If we talk about the headset/handsfree support and if it would only be
SCO specific I would agree, but the volume control is realized using AT
commands. You don't want an AT parser inside the 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 Thomas,
> > nice start. Actually I tried this by myself some time ago, but haven't
> > got any further than a skeleton. The main problem I see at the moment is
> > that we have to develop this inside the ALSA lib source and that is bad.
> > The reason for this is "pcm_local.h" and its definitions that are not
> > installed system wide. I don't think that SND_PCM_TYPE_BLUETOOTH is
> > needed, but I can be wrong of course. The other thing is that this stuff
> > should belong to the pcm/ext/ directory. My skeleton is attached and I
> > used these extra lines in ~/.asoundrc
> >
> > pcm.aiptek {
> > type a2dp
> > bdaddr "00:0B:xx:xx:xx:xx"
> > }
> >
> > Assuming that /usr/lib/alsa-lib/libasound_module_pcm_a2dp.so exists this
> > works as it should. So we have PCM at the input side of this plugin and
> > we send SBC over AVDTP to our headphone.
> >
>
> i think this goes to the wrong direction.
> 1. Even if there exist alsa library for many programms it is sufficent
> to use /dev/dsp and /dev/audio.
> This mean that the soundcard driver should work independent of the
> alsa library.
this is too short thinking. There are parts that don't belong inside the
kernel. And SBC encoding and decoding is one of them.
> For me looks this very similar to the old pwc driver problem.
> a) An kernel module that create an hook for interact with an non
> kernel module
No it is not. We don't design crappy binary interfaces to the kernel.
Everything is open and the socket interface is a well known "hook" into
the kernel side of a network stack.
> b) There is an gerneral interface dsp/audio/mixer wich become crippled
> without the alsa lib
> So why not be conesquent and put btsco int the snd-bt-sco module ?
> Like other hardware the module is tooled via command line or IOCTL
> wich bt-device it should handle.
Bluetooth is not only hardware. What you see is a dongle, but on top
there is a complete stack. We interface with L2CAP and this is a
software layer.
> Than the we have and "single" module wich is responsable for handling
> bluetooth sound.
See the point above. There will never be a "single" module solution.
> Currently it look more like an skeleton for me that grab data from SCO
> and tell BTSCO how to configure the hardware.
It is this way actually, because the sound volume (mixer settings) are
done via AT commands over RFCOMM. There is no way to do this inside the
kernel.
> So what are the grounds for moving btsco to the lib inseat of moving
> it to the module ?
The support for a Bluetooth protocol can be implemented as a kernel
module or in userspace depending on its needs. A Bluetooth profile is
like an application is this is userspace. So decide by yourself what is
the protocol and what is the profile.
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 Brad,
> I put some junk in the btsco cvs:
>
> alsa-lib.patch
> bt/
>
> if you apply alsa-lib.patch and put bt inside alsa-lib/src/pcm then the
> idea is that you can build a userspace alsa driver.
>
> currently it doesn't even compile... it's just based on the jack plugin
> and not yet reworked for bluetooth.
nice start. Actually I tried this by myself some time ago, but haven't
got any further than a skeleton. The main problem I see at the moment is
that we have to develop this inside the ALSA lib source and that is bad.
The reason for this is "pcm_local.h" and its definitions that are not
installed system wide. I don't think that SND_PCM_TYPE_BLUETOOTH is
needed, but I can be wrong of course. The other thing is that this stuff
should belong to the pcm/ext/ directory. My skeleton is attached and I
used these extra lines in ~/.asoundrc
pcm.aiptek {
type a2dp
bdaddr "00:0B:xx:xx:xx:xx"
}
Assuming that /usr/lib/alsa-lib/libasound_module_pcm_a2dp.so exists this
works as it should. So we have PCM at the input side of this plugin and
we send SBC over AVDTP to our headphone.
> anyway, this is my next project. it depends on a couple of things in
> other parts of the project:
Actually I think this is the way we should go. Using a2play is great,
but this will open it up to any tool that can play music using the ALSA
library.
> it would be nice if 'make install' inside sbc/ would install the sbc
> includes and library (static libs would be ok)
This is the whole goal, but for now I think we should copy the source
and simply link it. My plan is to combine sbclib.c and sbc.c and include
sbc_internal.h into sbc.c then. Also sbc_tables.h is not really useful
as a separate include.
> the avdtp library is just a skeleton right now... should I just ignore
> it for now and hardcode what is currently in a2play?
It is more than a skeleton, but I haven't committed the other code and I
don't think that I will have much time to work on it. Ignore it for now,
because we can catch up with that later.
Regards
Marcel