Re: [Bluez-devel] audio problems with a2play

Marcel Holtmann
2004-11-23T21:14:56Z

Hi Henryk,

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

so should it be and I got a trace from a friend with a prototype A2DP
device with a Zeevo ZV4002 and a Bluetooth stack from Impulsesoft. They
actually do it this way, but GCT puts in 0xff 0xff. I haven't find any
combination to make my Aiptek headphone understand the one byte media
payload header. The very ugly thing is that this headphone is actually
A2DP qualified.

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

This was only a quick and dirty hack to see how my headphone behaves if
I fill in that field. Actually it don't cares at all. I will check the
other A2DP trace again, because I saw that they filled in the timestamp
value and maybe the only count the SBC frames.

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

Didn't showed up so far.

Regards

Marcel