--- Andreas Beck <[email protected]> wrote:
> Ivy <[email protected]> wrote:
>
> > xxxxxx01xxxxxxxx Input Coding: u-law
> > xxxxxxxx01xxxxxx Input Data Format: 2"s complement
> > ( what is the advantage of 2's complement that 1's com ?).
>
> Actually I don't think this makes sense for ulaw/alaw, as AFAIK these
> are always 8 bit, as they were designed for telephony channels (ISDN)
> that operate at 64kbit, thus giving 8kSamples/s at 8 bit.
>
> The alaw/ulaw encoding gives a somewhat logarithmic scale which gives
> better dynamic range at the expense of small details the human ear
> doesn't recognize well anyway.
>
> For linear, the difference is in the coding of negative numbers.
> 1s complement will code negative numbers as their positive equivalent
> XOR 0xffff (i.e. a word with all-one bits). This is a rater uncommon
> coding scheme. It has the odditiy of having a +0 (0x0000) and a
> -0 (0xffff). 2s complement will add 1 after the above step, which
> has the advantage of simple handling of arithmetic operations with
> common ALUs designed for unsigned numbers. It just works - only thing
> you have to adjust is handling of overflow flags.
> Another advantage is a slightly increased range of values (-32768 to
> 32767 at 16 bit as compared to -32767 to 32767 at 1s complement)
> at the expense of an asymmetric value range.
>
> > xxxxxxxxxx1xxxxx Input Sample Size: 16 bit (Can i use 8 bit ?)
>
> IMHO you should, if you want alaw/ulaw.
You meant to use 16 Bit or 8 bit ?..
>
> > (what does it mean "ONly FOR Linear PCM in Documentation ?).
>
> I suppose these bits get ignored for formats other than linear PCM, as
> ulaw/alaw are inherently 8 bits.
>
> > xxxxxxxxxxx010xx # of bits padding at MSB: 2 (if i use 16 Bit,
> > 2bit's of MSB is needed for padding, coz only 14bits are enough
> > for u-law)
>
> AFAIK 8 bits are enough - could you explain?
U-LAW takes 14bits of linear PCM data as input and generates 8 bit compressed data. Am i correct ?.. Please correct me if i m wrong !!.. Thatswhy i assume that it needs 16 bits for INPUT Sample size and 2 bit offset in MSB position.
>
>
> CU, Andy
-ivy
>
> --
> = Andreas Beck | Email : <[email protected]> =
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by:
> Tame your development challenges with Apache's Geronimo App Server.
> Download it for free - -and be entered to win a 42" plasma tv or your very
> own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
> _______________________________________________
> Bluez-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/bluez-devel
__________________________
Free 3000MB email. Stops spam 100%. No banner ads. No popup ads. http://www.cashette.com
-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server.
Download it for free - -and be entered to win a 42" plasma tv or your very
own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Ivy <[email protected]> wrote:
> > > xxxxxxxxxx1xxxxx Input Sample Size: 16 bit (Can i use 8 bit ?)
> > IMHO you should, if you want alaw/ulaw.
> You meant to use 16 Bit or 8 bit ?..
8 bit.
> > > xxxxxxxxxxx010xx # of bits padding at MSB: 2 (if i use 16 Bit,
> > > 2bit's of MSB is needed for padding, coz only 14bits are enough
> > > for u-law)
> > AFAIK 8 bits are enough - could you explain?
> U-LAW takes 14bits of linear PCM data as input and generates 8 bit
> compressed data. Am i correct ?
Yes. That is correct.
> Thatswhy i assume that it needs 16 bits for INPUT Sample size and
> 2 bit offset in MSB position.
No - I suppose this is a misunderstanding about "input".
The SCM link via bluetooth uses its own encoding anyway (see the
comment about on air coding at the end of the list).
INPUT means what you feed in/get out at the driver side.
That is, if you choose alaw, you already feed alaw data.
Otherwise you could just use linear anyway. There would be no use in
converting to alaw first and then again to the air coding format.
Basically you will want to use alaw/ulaw, if you want to feed the
received data directly into a device that wants this data format anyway,
saving unnecessary conversions.
CU, ANdy
-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server.
Download it for free - -and be entered to win a 42" plasma tv or your very
own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel