Re: [Bluez-devel] AVDTP socket?

Marcel Holtmann
2004-11-19T22:04:06Z

Hi Brad,

> I added rcplay.c to cvs and made you a developer on bluetooth-alsa so
> you can tweak things if you see fit.

thanks. I will do that.

> The bluetake sometimes works and sometimes doesn't when using a2play.
> The same stream will work a couple of times and then it produces loud
> white noise. There is probably something still not quite right.
>
> I disabled this section in a2dp.c
>
> memset(buf, 0, 12);
> buf[0] = 0x80;
> buf[2] = seq_num >> 8;
> buf[3] = seq_num & 0xff;
> buf[12] = 0x0ff;
> buf[13] = 0x0ff;
> memcpy(buf + 14, &sbc_info, sizeof(sbc_info));
> size = read(fd, buf + 14 + sizeof(sbc_info), mtu - sizeof(sbc_info) -
> 14);
> write(streamfd, buf, size + 14 + sizeof(sbc_info));
> seq_num++;
>
> but it didn't help or hurt. I couldn't see why sbc_info was being
> written to the stream since I thought it was just a file header. Does
> your headset work with a2play as it is in cvs now?

Yes, perfect. I tried it with an MP3 that I convert to a wave file and
used the sbc_encoder.exe to create the SBC file. It also works fine with
the rcplay tool.

I think that GCT (the company that build the chips and wrote the
software for both headphone types) added their own SBC media packet
format. I read the A2DP specification again and as far as I understand
it, we must read the SBC frame header from the first frame. Set the
AVDTP configuration according to that header and then send the SBC frame
with the SBC media packet header (with or without fragmenting). And then
proceed with the other SBC frames in that file.

I found nothing about 0xff 0xff and even playing with content protection
and multiplexing bits and bytes, nothing resulted in these two bytes.

What we need is an easy way to calculate the frame size from the frame
header without decoding the frame data itself. And also scanning for the
sync byte is not really an option. If we get this working, we need to
check if these headphones also support real A2DP media packets.

Regards