Guys
The iPhono stopped producing recognizable sound using a2play a few days
ago... but even the most successful transfers with a2play have been
mixed with static.
I'm convinced we need a media payload header. Page 23 of the A2DP spec
shows how the media payload header should look.
I tried changing a2play to send media_payload_header instead of
sbc_frame_header and I got "quiet" noise when I did that. I tried
various frame counts with no luck.
I need to get a better idea of what is going on...
* which frame exactly is a2play's calc_frame_length measuring? Is it the
same "sbc frame" that they're talking about in a2dp p.24?
* how did you decide to put 2 0xff bytes in the CSRC section of the
media packet header? Why isn't this CSRC a multiple of 4 bytes like the
spec suggests on avdtp p. 46?
* what is the CSRC? (spec says "The CSRC list identifies the
contributing sources for the payload contained in this packet")
Brad
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Thomas,
> here is an optimized version of btsco.c it es rewriten for Linux only.
> Is does not need libbluetooth or libasound.
> It is event driven but currently use fixed MAC
>
> Any idea's are welcomed.
I finally looked at this. You've put some time into it I can see. If you
look at the bug list at our sourceforge page, you'll see we actually
want stronger ties to alsa libs (possibly using their userspace driver).
Working toward multiple headsets is good but if the struct is global
it's a missed opportunity.
I can understand the approach Linus takes to patches. He likes
incremental patches that solve a single well-defined problem. It's
easier to look for correctness.
You should choose one of the many problems with what we've got, discuss
it here, and take a shortest-distance approach to solving it.
The unconventional stuff like "{{{" and "if(-1 == ioctl(...))" work fine
but distract the reader from what the code is doing. After all, this
stuff has to be read by people, not just the compiler.
Brad
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Thomas,
> For the current version the size is to large but i thought of extending
> the source to allow multiple Headsets.
> Than it does not grow much since it already use an record and no static
> variables.
actually your record is global. And here again are again some comments
about coding. Defines and constants are in upper case, but not variable
names. So SND is the wrong name. This is C and not C++ or Jave and so
sSound is also a wrong. Use only lower case names and separate them with
a underscore.
> >Don't use {{{ and include some newlines. Actually follow the kernel
> >coding style.
> >
> >
> The {{{ i use for folding marks they can be replaced with { same as with
> }}} and }.
Really bad coding style.
> >Why do you rewrite the function from libbluetooth and libasound. Simply
> >use them, because these are shared library and they are loaded anyway.
> >
> >
> 1. What function of libbluetooth ? The only bluetooth function in wich
> would be useable is geting
> the local mac and the remove channel and string2adress conversion. wich
> is in no relation to the
> size the binary would grow.
The first thing is that these function are for easy handling of address
conversion and so use them. What you do is totally ugly. And what about
the size? How do you link the library? It is a dynamic library.
> With the same ground you could ask why i
> rewrite the asound part.
> Here the ground is even more interesting.
> 1. I save many file open / close
> 2. It run faster
> 3. If the sound device support async io or even only signaling if there
> are new mixer data it can be done without
> poll.
I don't know enough about the ALSA part, but actually your way is not
portable enough. The ALSA people may change interals, but they will keep
the API and so this is the way to go. If you think the ALSA library is
doing something wrong, then get in touch with them and clean it up.
> The ground i rewrite the original was so that i can use these code more
> easy to add it so other programms like kphone
> and use the button with switch sco on/off for accepting phone calls.
You can write whatever code you want and use it, but from a maintainer
perspective I will never add such code. And I don't see any problems
with linking some extra libraries.
Regards
Marcel
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
>the source code size of this version is amazing, but the coding style is
>crap. Sorry to say that.
>
>
For the current version the size is to large but i thought of extending
the source to allow multiple Headsets.
Than it does not grow much since it already use an record and no static
variables.
>Don't use {{{ and include some newlines. Actually follow the kernel
>coding style.
>
>
The {{{ i use for folding marks they can be replaced with { same as with
}}} and }.
>Why do you rewrite the function from libbluetooth and libasound. Simply
>use them, because these are shared library and they are loaded anyway.
>
>
1. What function of libbluetooth ? The only bluetooth function in wich
would be useable is geting
the local mac and the remove channel and string2adress conversion. wich
is in no relation to the
size the binary would grow. With the same ground you could ask why i
rewrite the asound part.
Here the ground is even more interesting.
1. I save many file open / close
2. It run faster
3. If the sound device support async io or even only signaling if there
are new mixer data it can be done without
poll.
The ground i rewrite the original was so that i can use these code more
easy to add it so other programms like kphone
and use the button with switch sco on/off for accepting phone calls.
Cu Thomas
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Thomas,
> here is an optimized version of btsco.c it es rewriten for Linux only.
> Is does not need libbluetooth or libasound.
> It is event driven but currently use fixed MAC
the source code size of this version is amazing, but the coding style is
crap. Sorry to say that.
Don't use {{{ and include some newlines. Actually follow the kernel
coding style.
Why do you rewrite the function from libbluetooth and libasound. Simply
use them, because these are shared library and they are loaded anyway.
Regards
Marcel
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi,
here is an optimized version of btsco.c it es rewriten for Linux only.
Is does not need libbluetooth or libasound.
It is event driven but currently use fixed MAC
Any idea's are welcomed.
Compile:
gcc test.c -o test
Cu Thomas
Henryk,
I am working right now on assembling a packet with more frames using
what is in cvs.
Brad
Henryk Pl?tz wrote:
> Moin,
>
> Am Tue, 23 Nov 2004 14:34:26 -0700 schrieb Brad Midgley:
>
>
>>we just send one sbc frame then? I was assuming that but not sure.
>
>
> Yes, for the beginning.
>
>
>>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.
>
>
> It's already there. The format of an SBC frame is defined in the A2DP
> spec p. 53. They all start with a fixed length header of four bytes
> (that's what struct sbc_frame_header is) and then some more data (the
> length of which is calculated by calc_frame_len). We must send the whole
> frame (that is header plus data).
>
>
>>I think what we have in CVS looks better but it doesn't sound better
>>:(
>
>
> Hmm, I made it behaving to the specs (I think) (and yes, this time I
> actually made sure I committed it) and don't hear anything now.
>
>
>>Are you using the bluetake too?
>
>
> Yes.
>
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Guys!
Try out a2play.c! It's playing to my bluetake properly now, at least for
most streams... (woohoo)
stream 5, 9 don't do anything, 7 is noise. 8 plays too fast.
the rest sound great.
What did it was putting frames up to the mtu length in every packet.
Maybe the certification doesn't test short packets of only one frame.
Brad
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Brad,
> If I'm understanding right, the payload should include the sbc_info
> header. I thought all along that was just for the purpose of storing the
> sbc in a file, but it sounds like the headset needs it.
I also don't see any reason why we need to store a SBC configuration and
then submit the same values with every frame. However without the header
it is impossible to get the SBC frame size.
> Is this closer? It doesn't sound right yet, but maybe we really do need
> to load up the packet to be closer to the mtu in order for the headset
> to be happy.
Do you mean you get some working sound with the specification conform
payload?
Regards
Marcel
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Moin,
Am Wed, 24 Nov 2004 06:09:11 +0100 schrieb Marcel Holtmann:
> I also don't see any reason why we need to store a SBC configuration
> and then submit the same values with every frame. However without the
> header it is impossible to get the SBC frame size.
Because we're allowed to change the bitpool value, I guess. The current
value can then always be read from the header. And of course to ease
resynchronization.
--
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! ~
Hi Henryk,
> Hmm, I made it behaving to the specs (I think) (and yes, this time I
> actually made sure I committed it) and don't hear anything now.
I think that all GCT based devices (1310:0100) will never behave like in
the specification defined.
Basically these two 0xff 0xff bytes mean nothing, but some values harm
and others don't. At the moment I am using these values:
buf[12] = 0x80 >> sbc_info.sampling_frequency
| 0x08 >> sbc_info.channel_mode;
buf[13] = 0x80 >> sbc_info.blocks
| 0x08 >> sbc_info.subbands
| 0x01 << sbc_info.allocation_method;
Regards
Marcel
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Henryk,
> > 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.
>
> Would you mind sharing theses traces with us? I'd really look at what
> other people do for this.
I actually don't know if this is possible, because it is a prototype
device. However I tried to export the trace into a text file, but my
viewer only shows the first 254 bytes of a L2CAP packet.
In what values are you interested. The AVDTP signalling channel looks
the same as we and the GCT devices do it. This device only selects other
settings for the SBC stream (0x22 0x16 0x33 0x33). Also the L2CAP MTU
for the AVDTP media channel is bigger (678 bytes) and thus it puts 5 SBC
frames into one L2CAP packet.
Regards
Marcel
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Moin,
Am Tue, 23 Nov 2004 14:34:26 -0700 schrieb Brad Midgley:
> we just send one sbc frame then? I was assuming that but not sure.
Yes, for the beginning.
> 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.
It's already there. The format of an SBC frame is defined in the A2DP
spec p. 53. They all start with a fixed length header of four bytes
(that's what struct sbc_frame_header is) and then some more data (the
length of which is calculated by calc_frame_len). We must send the whole
frame (that is header plus data).
> I think what we have in CVS looks better but it doesn't sound better
> :(
Hmm, I made it behaving to the specs (I think) (and yes, this time I
actually made sure I committed it) and don't hear anything now.
> Are you using the bluetake too?
Yes.
--
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! ~
Moin,
Am Tue, 23 Nov 2004 22:14:56 +0100 schrieb Marcel Holtmann:
> 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.
Would you mind sharing theses traces with us? I'd really look at what
other people do for this.
--
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! ~
Guys,
If I'm understanding right, the payload should include the sbc_info
header. I thought all along that was just for the purpose of storing the
sbc in a file, but it sounds like the headset needs it.
Is this closer? It doesn't sound right yet, but maybe we really do need
to load up the packet to be closer to the mtu in order for the headset
to be happy.
memcpy(buf + sizeof(packet_header), &payload_header,
sizeof(payload_header));
- size = read(fd, buf + sizeof(packet_header) +
sizeof(payload_header), frame_len);
+ memcpy(buf + sizeof(packet_header) +
sizeof(payload_header), &sbc_info, sizeof(sbc_info));
+ size = read(fd, buf + sizeof(packet_header) +
sizeof(payload_header) + sizeof(sbc_info), frame_len);
seq_num++;
if (size != frame_len) {
terminate = 1;
} else {
- write(streamfd, buf, size +
sizeof(packet_header) + sizeof(payload_header));
+ write(streamfd, buf, size +
sizeof(packet_header) + sizeof(payload_header) + sizeof(sbc_info));
}
Brad
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Brad,
> > 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.
we should follow the specification, but I also like to get my Aiptek
phone working without the sender device. So we already need the first
workaround/quirk for the not finished A2DP support ;)
The only good thing is that GCT puts in a device id SDP record with the
id value of 1310:0100 (from the USB vendor ist). I tried to look this up
at http://www.linux-usb.org/usb.ids if 1310 is assigned to GCT, but haven't
found anything so far.
So what we must do is read the device id SDP record (PNP Information,
service class 0x1200) and check for the product and vendor ids and if
they match set a flag to use their specific media payload header.
> > 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.
With the GCT stuff you can break the frame at any point you like. For me
this looks like the RFCOMM stream. However my device doesn't work if the
frame size is too short, so we should put as much frames into the L2CAP
payload as the MTU allows.
>>From the other trace of the Impulsesoft stack I saw that they put 5 SBC
frames into one AVDTP media packet. They use 0x22 0x16 0x33 0x33 for the
media specific settings of the SBC, while my Aiptek headphone sets them
to 0x22 0x46 0x02 0xfa.
> 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.
No, this must come from the SBC encoder.
Regards
Marcel
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
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
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
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
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Moin,
Am Tue, 23 Nov 2004 10:34:55 +0100 schrieb Marcel Holtmann:
> may you check the hcidump from CVS again if it is now correct? If yes,
> then I will release another version.
Yup, looks right to me.
--
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! ~
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! ~
Henryk,
>>Are these backwards then?
>
> Most of them are, with the notable exception of the allocation_method.
I changed how the sbc_info values are translated into sbc_elements and I
think we're getting the right values now:
s_config.sbc_elements.channel_mode = 8 >> sbc_info.channel_mode;
s_config.sbc_elements.frequency = 8 >> sbc_info.sampling_frequency;
s_config.sbc_elements.allocation_method =
1 << sbc_info.allocation_method;
s_config.sbc_elements.subbands = 2 >> sbc_info.subbands;
s_config.sbc_elements.block_length = 8 >> sbc_info.blocks;
Brad
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Henryk,
> > I don't know the "real" mapping between the indexed settings in the
> > sbc file format and the bitmapped settings/capabilities we use with
> > the a2dp protocol.
>
> It's on page 20 of the A2DP spec where it says, for example, that the
> first byte of the codec specific information elements for SBC encodes
> the sampling frequency in the upper half of the byte and the channel
> mode in the lower half. The first byte that a2play sends for
> sbc_test_01.sbc (which is 48 kHz mono) is 0x81, so bits 7 (0x80) and 0
> (0x01) are set. Bit 7 set means 16 kHz (section 4.3.2.1), bit 0 set
> means joint stereo (section 4.3.2.2). The correct value for this byte
> would be 0x18 (bits 4 and 3 set).
>
> Similarly the second byte (currently 0x86) should be 0x1a (bits 4, 3 and
> 1 set).
may you check the hcidump from CVS again if it is now correct? If yes,
then I will release another version.
Regards
Marcel
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Moin,
Am Mon, 22 Nov 2004 20:49:05 -0700 schrieb Brad Midgley:
> Are you saying the problem is in a2play or in hcidump?
Both are doing the same wrong thing.
> I don't know the "real" mapping between the indexed settings in the
> sbc file format and the bitmapped settings/capabilities we use with
> the a2dp protocol.
It's on page 20 of the A2DP spec where it says, for example, that the
first byte of the codec specific information elements for SBC encodes
the sampling frequency in the upper half of the byte and the channel
mode in the lower half. The first byte that a2play sends for
sbc_test_01.sbc (which is 48 kHz mono) is 0x81, so bits 7 (0x80) and 0
(0x01) are set. Bit 7 set means 16 kHz (section 4.3.2.1), bit 0 set
means joint stereo (section 4.3.2.2). The correct value for this byte
would be 0x18 (bits 4 and 3 set).
Similarly the second byte (currently 0x86) should be 0x1a (bits 4, 3 and
1 set).
> Are these backwards then?
Most of them are, with the notable exception of the allocation_method.
--
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! ~
Hi Brad,
> Are you saying the problem is in a2play or in hcidump?
actually I don't know. I will ask a friend to do some traces with the
CATC software. The hcidump from CVS should decode the settings like you
encode them, but I am not sure if this is correct. If yes, then my
Aiptek sender is sending strange settings, but it also don't fill in the
correct media payload headers. At the moment I am only using the rcplay
program for testing the sound on my headphone.
Regards
Marcel
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Henryk,
Are you saying the problem is in a2play or in hcidump?
I don't know the "real" mapping between the indexed settings in the sbc
file format and the bitmapped settings/capabilities we use with the a2dp
protocol.
Are these backwards then?
s_config.sbc_elements.channel_mode = 1 << sbc_info.channel_mode;
s_config.sbc_elements.frequency = 1 << sbc_info.sampling_frequency;
s_config.sbc_elements.allocation_method =
1 << sbc_info.allocation_method;
s_config.sbc_elements.subbands = 1 << sbc_info.subbands;
s_config.sbc_elements.block_length = 1 << sbc_info.blocks;
Brad
Henryk Pl?tz wrote:
> Moin,
>
> Hmm, If I'm not mistaken a2play has even other problems. I tried to play
> sbc_test_01.sbc (for a start) through it while doing hcidump -x (the
> old hcidump, that is). When doing the set configuration hcidump said
>
> < ACL data: handle 0x002b flags 0x02 dlen 18
> L2CAP(d): cid 0x40 len 14 [psm 25]
> AVDTP(s): Set config cmd: transaction 0
> 04 04 01 00 07 06 00 00 81 86 02 FA
>
> which decodes as
> ACP SEID = 1 (OK)
> INT SEID = 1 (OK)
> Media transport capability (OK)
> Media Codec capability
> Audio (OK)
> SBC (OK)
> Sampling frequency = 16kHz (should be 48)
> Channel mode = Joint stereo (should be mono)
> Block length = 4 (should be 16)
> Subbands = 8 (should be 4)
> Allocation method = SNR (OK)
> Bitspool = 2 to 250 (OK)
>
> As you can see the only correct parameter (apart from the hardwired
> ones) is the allocation method. All others seem to be kind of bit
> reversed. As a side note: The new hcidump AVDTP parser has the same
> problem.
>
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Moin,
Hmm, If I'm not mistaken a2play has even other problems. I tried to play
sbc_test_01.sbc (for a start) through it while doing hcidump -x (the
old hcidump, that is). When doing the set configuration hcidump said
< ACL data: handle 0x002b flags 0x02 dlen 18
L2CAP(d): cid 0x40 len 14 [psm 25]
AVDTP(s): Set config cmd: transaction 0
04 04 01 00 07 06 00 00 81 86 02 FA
which decodes as
ACP SEID = 1 (OK)
INT SEID = 1 (OK)
Media transport capability (OK)
Media Codec capability
Audio (OK)
SBC (OK)
Sampling frequency = 16kHz (should be 48)
Channel mode = Joint stereo (should be mono)
Block length = 4 (should be 16)
Subbands = 8 (should be 4)
Allocation method = SNR (OK)
Bitspool = 2 to 250 (OK)
As you can see the only correct parameter (apart from the hardwired
ones) is the allocation method. All others seem to be kind of bit
reversed. As a side note: The new hcidump AVDTP parser has the same
problem.
--
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! ~
hey
> * how did you decide to put 2 0xff bytes in the CSRC section of the
> media packet header? Why isn't this CSRC a multiple of 4 bytes like the
> spec suggests on avdtp p. 46?
>
> * what is the CSRC? (spec says "The CSRC list identifies the
> contributing sources for the payload contained in this packet")
csrc wasn't the right thing to look into... the csrc count (cc) is 0, so
if I'm reading this right, the two 0xff values are actually bleeding
into the payload header and the first byte of the payload.
brad
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Brad,
> The iPhono stopped producing recognizable sound using a2play a few days
> ago... but even the most successful transfers with a2play have been
> mixed with static.
last time I tested it, it worked quite well.
> I'm convinced we need a media payload header. Page 23 of the A2DP spec
> shows how the media payload header should look.
>
> I tried changing a2play to send media_payload_header instead of
> sbc_frame_header and I got "quiet" noise when I did that. I tried
> various frame counts with no luck.
>
> I need to get a better idea of what is going on...
>
> * which frame exactly is a2play's calc_frame_length measuring? Is it the
> same "sbc frame" that they're talking about in a2dp p.24?
It is the SBC frame length without the 4 byte SBC header.
> * how did you decide to put 2 0xff bytes in the CSRC section of the
> media packet header? Why isn't this CSRC a multiple of 4 bytes like the
> spec suggests on avdtp p. 46?
>
> * what is the CSRC? (spec says "The CSRC list identifies the
> contributing sources for the payload contained in this packet")
Actually I already tried to follow the AVDTP and A2DP specification, but
with no luck. My Aiptek headphone doesn't want to play nicely and I have
no clue how they got this thing qualified by the Bluetooth SIG.
>>From my testing I saw that my headphone only cares about the CC value of
the AVDTP media header. All other values are not used.
The 0xff 0xff in front of the SBC header are not part of the AVDTP media
header. It is already the media channel payload. This follows non of any
specification I know of. And I only know that values, because I sniffed
a connection between the sender device and the headphone with a protocol
analyzer.
Regards
Marcel
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel