hi,
can anyone help me with my sco link? in about 50% of cases, the audio dat=
a
has an offset of one byte, resulting in terrible noise. I think I saw a
flag in a packet header somewhere that indicates the number of bytes to s=
kip
until the audio data starts -- I looked through the bt specs several time=
s now
but can't find it again. Anyone has a clue for this?
Simon
--=20
_______________________________________________________________________
Dr. Simon Vogl
Institut f=C3=BCr Pervasive Computing, Johannes Kepler Universit=C3=A4t L=
inz
Altenberger Stra=C3=9Fe 69, A-4040 Linz, Austria
Tel: +43 732 2468-8517, Fax: +43 732 2468-8426
mailto: [email protected], http://www.soft.uni-linz.ac.at/
-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
On Wednesday 03 March 2004 17:17, Fred Sch=E4ttgen wrote:
> I have also noticed that problem. When I just tried with hstest, 2 out of=
5
> tries were noise, the rest was perfect.
> I don't think is has anything to do with interrupts, because the the
> problem lasts for the whole duration of the connection or it doesn't appe=
ar
> at all. Also could I work around that problem somewhat in an own
> application by guessing the byte order of the 16-bit audio samples. So I
> also think that there is something wrong with some offset.
>
> Btw. I'm currently running 2.4.24, so maybe this has been fixed in 2.4.25.
> When comparing the ouput of scotest with that of hcidump, it looks like it
> is not the same every time... with scotest and hcidump running on the same
> machine, shouldn't the SCO data that's displayed by hcidump be exactly the
> same as the output of hstest?
I've noticed two things when comparing the hcidumps and the output of hstes=
t:
The first packet that is received (as displayed by hcidump) has got a=20
different handle than the following packets - most certainly the one of the=
=20
previous SCO connection. This first packet doesn't appear in the output of=
=20
hstest, so it seems that BlueZ is ignoring that packet, which seems to be=20
perfectly right.
The following packets then seem in fact to be shifted by one byte:
1078328725.638104 > SCO data: handle 0x003d dlen 48 <--- different handl=
e!
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00=20
00 00 00 00 00 00 00 00 00 00 00 FF FF 00 00 00 00 00 00 FF=20
FF FF FF 00 00 FF FF FF=20
1078328725.638106 > SCO data: handle 0x003a dlen 48
FF FF FF 00 00 FF FF FF FF FF FF 00 00 FF FF FF FF 00 00 00=20
00 FF FF FF FF 00 00 FF FF FF FF FF FF 00 00 FF FF FF FF FF=20
FF 00 00 FF FF FF FF 00=20
1078328725.648104 > SCO data: handle 0x003a dlen 48
00 00 00 FF FF FF FF 00 00 FF FF FF FF FF FF 00 00 FF FF FF=20
FF FF FF 00 00 FF FF FF FF 00 00 00 00 FF FF FF FF 00 00 FF=20
FF FF FF FF FF 00 00 FF=20
It seems to be the same as the data received by hstest, except for the firs=
t=20
packet, which seems to be discarded because of the different handle. So thi=
s=20
is certainly a problem with the Bluetooth dongle. Or is there still a chanc=
e=20
for BlueZ to get it wrong?
Mine is a Conceptronic.. uhm.. CBT100U(?).
$ sudo hciconfig hci0 version
hci0: Type: USB
BD Address: 00:10:60:A4:AC:15 ACL MTU: 192:8 SCO MTU: 64:8
HCI Ver: 1.1 (0x1) HCI Rev: 0x20d LMP Ver: 1.1 (0x1) LMP Subver: 0x=
20d
Manufacturer: Cambridge Silicon Radio (10)
$ sudo hciconfig hci0 revision
hci0: Type: USB
BD Address: 00:10:60:A4:AC:15 ACL MTU: 192:8 SCO MTU: 64:8
HCI 16.4
Chip version: BlueCore02
Max key size: 56 bit
SCO mapping: HCI
greetings
=46red
-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Fred Sch?ttgen wrote:
>On Wednesday 03 March 2004 16:11, James Courtier-Dutton wrote:
>
>
>>Simon Vogl wrote:
>>
>>
>>>hi,
>>>can anyone help me with my sco link? in about 50% of cases, the audio
>>>data has an offset of one byte, resulting in terrible noise. I think I
>>>saw a flag in a packet header somewhere that indicates the number of
>>>bytes to skip
>>>until the audio data starts -- I looked through the bt specs several
>>>times now
>>>but can't find it again. Anyone has a clue for this?
>>>Simon
>>>
>>>
>>The terrible noise will be lost interrupts
>>
>>
>
>I have also noticed that problem. When I just tried with hstest, 2 out of 5
>tries were noise, the rest was perfect.
>I don't think is has anything to do with interrupts, because the the problem
>lasts for the whole duration of the connection or it doesn't appear at all.
>Also could I work around that problem somewhat in an own application by
>guessing the byte order of the 16-bit audio samples. So I also think that
>there is something wrong with some offset.
>
>
>
I think too that it corresponds to an alignment problem, as the noise
energy corresponds what I would
expect as the audio signal
Simon
--
_______________________________________________________________________
Dr. Simon Vogl
Institut f?r Pervasive Computing, Johannes Kepler Universit?t Linz
Altenberger Stra?e 69, A-4040 Linz, Austria
Tel: +43 732 2468-8517, Fax: +43 732 2468-8426
mailto: [email protected], http://www.soft.uni-linz.ac.at/
-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
On Wednesday 03 March 2004 16:11, James Courtier-Dutton wrote:
> Simon Vogl wrote:
> > hi,
> > can anyone help me with my sco link? in about 50% of cases, the audio
> > data has an offset of one byte, resulting in terrible noise. I think I
> > saw a flag in a packet header somewhere that indicates the number of
> > bytes to skip
> > until the audio data starts -- I looked through the bt specs several
> > times now
> > but can't find it again. Anyone has a clue for this?
> > Simon
>
> The terrible noise will be lost interrupts
I have also noticed that problem. When I just tried with hstest, 2 out of 5
tries were noise, the rest was perfect.
I don't think is has anything to do with interrupts, because the the problem
lasts for the whole duration of the connection or it doesn't appear at all.
Also could I work around that problem somewhat in an own application by
guessing the byte order of the 16-bit audio samples. So I also think that
there is something wrong with some offset.
Btw. I'm currently running 2.4.24, so maybe this has been fixed in 2.4.25.
When comparing the ouput of scotest with that of hcidump, it looks like it is
not the same every time... with scotest and hcidump running on the same
machine, shouldn't the SCO data that's displayed by hcidump be exactly the
same as the output of hstest?
greetings
Fred
-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Simon Vogl wrote:
> hi,
> can anyone help me with my sco link? in about 50% of cases, the audio data
> has an offset of one byte, resulting in terrible noise. I think I saw a
> flag in a packet header somewhere that indicates the number of bytes to
> skip
> until the audio data starts -- I looked through the bt specs several
> times now
> but can't find it again. Anyone has a clue for this?
> Simon
>
The terrible noise will be lost interrupts
Cheers
James
-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel