[CELT-dev] BYTES_PER_CHAR

[Mike Hooper]

Jean-Marc,

I am using the TI 55X platform and am having similar problems to Riccardo.
Could you please clarify the statement "use the lower half"? Are you
suggesting that we pack our 16 bit characters into two 8 bit nibbles before
passing "in[]" to "celt_encode"?

Also, if we define "channels=2" (ie stereo), what is the format of the data
in "in[]" (ie the un-encoded frame passed to celt_encode)? Is it interleaved
[16-bit PCM Left Chan][16-bit PCM Right Chan]? Or is frame_size samples of
Left channel followed by frame_size samples of Right channel?

Thx
MikeH

-----Original Message-----
From: celt-dev-bounces at xiph.org [mailto:celt-dev-bounces at xiph.org] On Behalf
Of Jean-Marc Valin
Sent: Tuesday, July 20, 2010 7:09 AM
To: celt-dev at xiph.org; Riccardo Micci
Subject: Re: [CELT-dev] BYTES_PER_CHAR

Hi,

I assume your platform is a TI C5x, in which case, CELT definitely works 
on those. When it comes to the 16-bit chars, what I think you need to do 
is just use the lower half. CELT will consider the chars as bytes, so 
it'll only read/write to/from the lowest 8 bits. Once you take that into 
account, you should be fine. Other than that, I occasionally introduce 
code that doesn't work when ints are 16-bits, but those are usually 
minor. Then only reason they end up in the code is that I have no way to 
actually test that CELT works with ints are 16-bits.

Cheers,

	Jean-Marc

On 10-07-20 06:57 AM, Riccardo Micci wrote:
>
> Hello,
> I'm porting CELT 0.7.1 to an embedded platform and unfortunately (at
> least for me) CHAR is defined as 16 bits. I now got the vocoder
> compiling but when i compare the encoded output with a windows build,
> they don't match.
> Among the other problems i think that the char definition is one of the
> biggest players. I've seen in arch.h the following definitions:
> /* 2 on TI C5x DSP */
> #define BYTES_PER_CHAR 2
> #define BITS_PER_CHAR 16
> #define LOG2_BITS_PER_CHAR 4
> That makes me think the code is in someway ready to work on these kind
> of platforms. I don't see the above definition used anywhere in the code
> though. Does anybody know if CELT could work on platform with 16 bits
> char or if any attempt has been already tried?
>
> Thanks!
>
> Regards
> Riccardo
> ------------------------------------------------------------------------
>
> Riccardo Micci
> Senior DSP Engineer, Wireless Group
>
> *Cambridge Consultants*
> Science Park, Milton Road
> Cambridge, CB4 0DW, England
> Switchboard: +44 (0)1223 420024
> Direct dial: +44 (0)1223 392402
> Mobile: +44 (0)
> Fax: +44 (0)1223 423373
> riccardo.micci at cambridgeconsultants.com
> <mailto:riccardo.micci at cambridgeconsultants.com>
> www.CambridgeConsultants.com <http://www.cambridgeconsultants.com/>
>
>
>
>
>
> ------------------------------------------------------------------------
>
>
> This email is from Cambridge Consultants Limited, Science Park, Milton
> Road, Cambridge CB4 0DW with registered number 1036298 England. It may
> contain confidential information. It is intended for the addressee only
> and may not be copied or disclosed to any third party without our
> permission. If you are not the intended recipient please contact the
> sender as soon as possible and delete the material from any computer. If
> this email has been sent as a personal message to the addressee, the
> sender is not acting in his/her capacity as an employee or officer of
> Cambridge Consultants Limited and no liability is accepted for the
> content of any such email. Outgoing email may be monitored for the
> purpose of ensuring compliance with our email policy and relevant laws.
>
>
>
>
> _______________________________________________
> celt-dev mailing list
> celt-dev at xiph.org
> http://lists.xiph.org/mailman/listinfo/celt-dev
_______________________________________________
celt-dev mailing list
celt-dev at xiph.org
http://lists.xiph.org/mailman/listinfo/celt-dev