Return-Path: Message-ID: <41B849BC.5060002@suche.org> From: "suche.org" MIME-Version: 1.0 To: bluez-devel@lists.sourceforge.net References: <41B81ACB.1080807@xmission.com> <1102589835.9988.114.camel@pegasus> <41B83BA8.5010001@suche.org> <1102594031.9988.171.camel@pegasus> In-Reply-To: <1102594031.9988.171.camel@pegasus> Content-Type: text/html; charset=ISO-8859-15 Subject: [Bluez-devel] Re2: starting btsco-in-libalsa Sender: bluez-devel-admin@lists.sourceforge.net Errors-To: bluez-devel-admin@lists.sourceforge.net Reply-To: bluez-devel@lists.sourceforge.net List-Unsubscribe: , List-Id: BlueZ development List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 09 Dec 2004 13:49:00 +0100 
	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.
 =20
      
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.
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.
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.
b) There is an gerneral interface dsp/audio/mixer wich become crippled 

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.

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=A0 --- HTTP --- tcp=A0=A0=A0=A0=A0=A0=A0=A0=A0 ---=A0=A0=A0=A0 ip= --- arp --- 802.3 =A0 =A0 =A0=A0 =A0=A0=A0 --- kable
KPhone ---=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 dsp/audio ---=A0=A0=A0=A0= sco/rfcomm=A0 --- bluethooth --- on air

btsco is in the level of sco/rfcomm.
This could be compared with the routing engine that decide=A0 on wich device an packet went.
There sco is the tcp/udp channel and rfcomm the icmp.

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.

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.

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