Date: Sat, 18 Sep 2010 09:49:25 +0100 (BST) From: Iain Hibbert <plunky@rya-online.net> To: Maksim Yevmenkin <maksim.yevmenkin@gmail.com> Cc: freebsd-bluetooth@freebsd.org Subject: Re: A2DP ? Message-ID: <1284799765.805051.828.nullmailer@galant.ukfsn.org> In-Reply-To: <AANLkTim8JWDfvRnbLXuGXWMM-WqrvJJ_r1sVOFNZxXbV@mail.gmail.com> References: <4C876C14.2030300@FreeBSD.org> <AANLkTi=HKrAckHUvL9ehWvWq5NhB40QkfNABSfNQ5Xet@mail.gmail.com> <AANLkTinpGP%2BKjQo5BB0mpPhpk0g5dB1ntLPmcTkbG-0n@mail.gmail.com> <1284715128.901194.134.nullmailer@galant.ukfsn.org> <AANLkTim8JWDfvRnbLXuGXWMM-WqrvJJ_r1sVOFNZxXbV@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 17 Sep 2010, Maksim Yevmenkin wrote:
> On Fri, Sep 17, 2010 at 2:18 AM, Iain Hibbert <plunky@rya-online.net> wrote:
> > The SCO sockets are not required, since A2DP uses RFCOMM to transport data
> > that I recall
>
> on later, i believe its l2cap actually :) on former, i agree, the exact quote
Oops yes, seems that both AVCTP and AVDTP are plain L2CAP according to the
SDP records on my phone:
ServiceRecordHandle: 0x00010001
ServiceClassIDList:
A/V Remote Control Target
ProtocolDescriptorList:
L2CAP (PSM 0x0017)
AVCTP (v1.0)
BluetoothProfileDescriptorList:
A/V Remote Control, v1.0
AttributeID 0x0100:
str8(34) "Audio Video Remote Control Profile"
SupportedFeatures:
Category 1
ServiceRecordHandle: 0x00010002
ServiceClassIDList:
Audio Source
ProtocolDescriptorList:
L2CAP (PSM 0x0019)
AVDTP (v1.0)
BluetoothProfileDescriptorList:
Advanced Audio Distribution, v1.0
AttributeID 0x0100:
str8(4) "A2DP"
I don't know if the AVDTP has any inbuilt flow control or if it relies
upon a perfect link or advanced L2CAP features (I was always impressed
with the RFCOMM credit based flow control)
> i doubt it. audio said to be encoded in SBC (mandatory) with optional
> support for MPEG-1,2 Audio, MPEG-2,4 AAC and ATRAC (whatever that is).
> so decoding is needed, imo.
Yes, my thought was that the daemon handles the Bluetooth connection and
decoding to 16-bit signed linear (or, however the audio device wants to
receive the raw data). This also conforms to the SBC algorithm licencing
which if I recall covers Bluetooth applications only.
> > available some other way. I have thought of doing something on NetBSD
> > using the pad(4) driver[*] which would enable a daemon to provide a system
> > standard audio interface (eg on /dev/audio2) that you can use with your
> > favourite music player but have been distracted by other things.
>
> yeah, i would do something like this too. no pad(4) on freebsd though :(
as I recall, Jared wrote pad(4) in a surprisingly short time and it
doesn't look very complex though I think FreeBSDs kernel audio API is
somewhat different.
Additionally there is the issue of feeding audio data through userland but
I think that even limited hardware devices (that are likely to be running
BSD as an OS) are significantly more capable than the general purpose
computers that were available 20 years ago and I'm not sure that its a
serious issue any longer. Even my 3yr old phone runs at 233Mhz and seems
to multitask in WM6 while playing music without skipping (much :)
iain
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1284799765.805051.828.nullmailer>