All of lore.kernel.org
 help / color / mirror / Atom feed
* [Bluez-devel] sco links
@ 2004-03-03 14:18 Simon Vogl
  2004-03-03 15:11 ` James Courtier-Dutton
  0 siblings, 1 reply; 5+ messages in thread
From: Simon Vogl @ 2004-03-03 14:18 UTC (permalink / raw)
  To: BlueZ Mailing List

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: vogl@soft.uni-linz.ac.at,  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
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [Bluez-devel] sco links
  2004-03-03 14:18 [Bluez-devel] sco links Simon Vogl
@ 2004-03-03 15:11 ` James Courtier-Dutton
  2004-03-03 16:17   ` Fred Schättgen
  0 siblings, 1 reply; 5+ messages in thread
From: James Courtier-Dutton @ 2004-03-03 15:11 UTC (permalink / raw)
  To: Simon Vogl; +Cc: BlueZ Mailing List

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
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [Bluez-devel] sco links
  2004-03-03 15:11 ` James Courtier-Dutton
@ 2004-03-03 16:17   ` Fred Schättgen
  2004-03-03 16:32     ` Simon Vogl
  2004-03-03 16:53     ` Fred Schättgen
  0 siblings, 2 replies; 5+ messages in thread
From: Fred Schättgen @ 2004-03-03 16:17 UTC (permalink / raw)
  To: bluez-devel; +Cc: Simon Vogl, James Courtier-Dutton

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
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [Bluez-devel] sco links
  2004-03-03 16:17   ` Fred Schättgen
@ 2004-03-03 16:32     ` Simon Vogl
  2004-03-03 16:53     ` Fred Schättgen
  1 sibling, 0 replies; 5+ messages in thread
From: Simon Vogl @ 2004-03-03 16:32 UTC (permalink / raw)
  To: Fred Schättgen; +Cc: bluez-devel, James Courtier-Dutton

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: vogl@soft.uni-linz.ac.at,  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
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [Bluez-devel] sco links
  2004-03-03 16:17   ` Fred Schättgen
  2004-03-03 16:32     ` Simon Vogl
@ 2004-03-03 16:53     ` Fred Schättgen
  1 sibling, 0 replies; 5+ messages in thread
From: Fred Schättgen @ 2004-03-03 16:53 UTC (permalink / raw)
  To: bluez-devel; +Cc: Simon Vogl, James Courtier-Dutton

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
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2004-03-03 16:53 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-03-03 14:18 [Bluez-devel] sco links Simon Vogl
2004-03-03 15:11 ` James Courtier-Dutton
2004-03-03 16:17   ` Fred Schättgen
2004-03-03 16:32     ` Simon Vogl
2004-03-03 16:53     ` Fred Schättgen

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.