public inbox for linux-bluetooth@vger.kernel.org
 help / color / mirror / Atom feed
From: Marcel Holtmann <marcel@holtmann.org>
To: BlueZ Mailing List <bluez-devel@lists.sourceforge.net>
Subject: Re: [Bluez-devel] Re: starting btsco-in-libalsa
Date: Thu, 09 Dec 2004 14:10:33 +0100	[thread overview]
Message-ID: <1102597833.9988.207.camel@pegasus> (raw)
In-Reply-To: <41B849BC.5060002@suche.org>

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

  reply	other threads:[~2004-12-09 13:10 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-12-09  9:28 [Bluez-devel] starting btsco-in-libalsa Brad Midgley
2004-12-09 10:57 ` Marcel Holtmann
2004-12-09 11:48   ` [Bluez-devel] " suche.org
2004-12-09 12:07     ` Marcel Holtmann
2004-12-09 12:49       ` [Bluez-devel] Re2: " suche.org
2004-12-09 13:10         ` Marcel Holtmann [this message]
2004-12-09 17:31     ` [Bluez-devel] " Brad Midgley

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1102597833.9988.207.camel@pegasus \
    --to=marcel@holtmann.org \
    --cc=bluez-devel@lists.sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox