Voice setting for U-law and A-law.
Quoted 26 lines · --- Andreas Beck
Quoted 3 lines · Ivy
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.
Quoted 3 lines
Quoted 1 line
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 ?..
Quoted 7 lines
Quoted 2 lines
(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.
Quoted 5 lines
Quoted 3 lines
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.
Quoted 3 lines
CU, Andy
-ivy
Quoted 14 lines
Signature · 13 lines
-- = 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
Quoted 3 lines · Ivy
Quoted 2 lines
Quoted 1 line
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.
Quoted 6 lines
Quoted 4 lines
Quoted 3 lines
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.
Quoted 2 lines
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