Re: [Bluez-devel] audio problems with a2play

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

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

Moin,

Am Tue, 23 Nov 2004 07:20:12 -0700 schrieb Brad Midgley:

> I changed how the sbc_info values are translated into sbc_elements and
> I think we're getting the right values now:

Yupp, looks correct to me. So does the new hcidumps's job of decoding
it.

> 	s_config.sbc_elements.channel_mode = 8 >> sbc_info.channel_mode;

Heh, that's a clever way of doing this. 


I also saw that you were modifying the way a2play packs its frame though
that still doesn't look right to me. Maybe we should talk about our
interpretation of the specs in this case.

The way I see this we should have a media packet header from AVDTP p. 45
and a media payload from A2DP p. 23. The media packet header should be
12 octets in length (as we don't use any CSRC). I think a2play does
these right, except for the timestamp (I'll come to that in a second).

Next thing should be media payload header from A2DP which is 1 octet in
length and correct, too.

Then there should be an SBC frame as per A2DP p. 53 just like my code
produces them. That should start with 0x9C which I can't see anywhere in
the a2play output.

Now I saw Marcel tried adding a timestamp (which I did, too, without
any effects, sadly). The way I read section 4.3.3.1 of A2DP would be
that there should be an imaginary clock counting at the sampling
frequency of the SBC frames and whose value should then be put into the
timestamp field. Or, simply put: Count the samples sent so far. 

I've modified the CVS to my beliefs. Please correct me if you think I'm
wrong.

-- 
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 --]