Re: [Bluez-devel] Comments about the Logitech/HP stereo headphones

["Henryk Plötz" <henryk@ploetzli.ch>]

[-- Attachment #1: Type: text/plain, Size: 1894 bytes --]

Moin,

Am Sun, 24 Apr 2005 09:47:47 -0400 schrieb Guylhem Aznar:

> - for kernel integration, linus &co may not be interested in a
> kernel-side sbc decoder- they will certainly ask for a /dev/ entry
> taking the native format - in that case already encoded sbc. 

and

> Later on, like rfcomm manages rfcomm0 etc. entries, some a2dp tool
> could bind a2dp peripherals to /dev/a2dpN where SBC audio would be
> expected and streamed to the a2dp peripheral bound there.

My 0.02EUR: There is a problem here. Mayank turned up a very valid point
in his "a2play code not according to the specifications" posting: Having
the SBC encoding decoupled from the AVDTP negotiation is not a good
thing. One of the primary problems of the current pipe approach (and
expecting applications to stream SBC into a socket/device/whatever is
not different in this regard) is that the format of the SBC stream
(sample rate, channel mode, etc.) will have to depend on the
capabilities of the receiver, but there is no feedback to the encoder
about that.

Therefore the best implementation would be to put the actual encoding
into the same layer of code that does the negotiation, or at least put
the control over the encoder there. Otherwise you wouldn't have the
simple "open and write something into it" semantics most other devices
have, but would need to have something along the lines of "open the
device, offer it some audio formats, let it do the negotation, read back
the audio format that is to be used, encode the audio stream into that
format". 

And also coupling /dev/a2dpN tightly to SBC format would make it even
harder (or impossible) to support other audio formats as A2DP does.

-- 
Henryk Plötz
Grüße aus Berlin
~~~~~~~ Un-CDs, nein danke! http://www.heise.de/ct/cd-register/ ~~~~~~~
~ Help Microsoft fight software piracy: Give Linux to a friend today! ~

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]