Re: [Bluez-devel] audio problems with a2play

Brad Midgley
2004-11-23T21:34:26Z

Henryk

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

good

>> s_config.sbc_elements.channel_mode = 8 >> sbc_info.channel_mode;
>
> Heh, that's a clever way of doing this.

I am willing to do something more conventional if this method breaks :)

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

yes, exactly. Marcel got it to work by tracing the (non-spec!) traffic
produced by using his headset's transmitter. We don't have the luxury of
capturing the traffic but we should try to follow the spec as well as we
can.

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

we just send one sbc frame then? I was assuming that but not sure.

Are you saying we should put 0x9c in the stream or it should be in the
stream already? The SBC-specific stuff is definitely where my
understanding ends.

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

I think what we have in CVS looks better but it doesn't sound better :(

Are you using the bluetake too?

Brad