similar to: FIX vs FLP switch?

Jean-Mark, Tim, Could either of you expound on the following comment in cwrs.c? /*If _k==0, the following do-while loop will overflow the buffer.*/ ---------------------------------------------------------------- ...because the following do-loop does overflow the buffer when k=126 k=2; do _u[k]=(k<<1)-1; while(++k<len); Thanks, MikeH -------------- next

The opus code default compiles on -o2 optimization level. I would like to change it to -o3. I have tried doing the changes in makefile.unix . The change is not getting reflected. I am building the code in Code composer studio for TI processor C6000. Could anybody help me with this -------------- next part -------------- An HTML attachment was scrubbed... URL:

I am having trouble understanding the stack allocation scheme when using a C55xx device. From what I can tell, the GLOBAL_STACK_SIZE is set in arch.h to 100,000 bytes (when using FIXED_POINT), which is then used in the ALLOC_STACK macro found in stack_alloc.h. This macro seems to say, if global_stack==0, then call celt_alloc_scratch, found in os_support.h, which in turn attempts to allocate (using

Hello All: I've recently had to provision some RHEL and CentOS VMWare instances. There was no network connectivity so I had to use a kickstart floppy and DVD iso rather than installing from our repository. To create the floppy I used the following: As root: dd if=/dev/zero of=floppy.flp bs=1k count=360 mkfs.vfat floppy.flp mount -o loop floppy.flp /mnt/floppy cp base_kickstart.ks

Tony, How is this going? Have you been able to get CELT to run on a TI55xx? I am very interested in the % utilization of the hardware and whether multiple instance of CELT on the same DSP are feasible. I look forward to your findings. MikeH -------------- next part -------------- An HTML attachment was scrubbed... URL:

Jean-Marc, It appears that since testcelt reads a WAVE file from disck and passes the data directly to celt_encode, so that celt_encode's "in" buffer must be expecting little-endian formatted packets. Is this correct? Is there endiness switch somewhere? Thx MikeH -------------- next part -------------- An HTML attachment was scrubbed... URL:

"frame_size = PCM audio in signed 16-bit format (native endian). There must be exactly frame_size samples per channel." Sorry for such a simple request, but could you please clarify the definition of frame_size when using stereo audio channels? When you say "frame_size samples" does this mean that, if my frame_size is defined as 128, there are 64 left samples and 64 right

Gents, "CELT now supports a larger dynamic range, suitable for encoding 24-bit audio (float version only)." I realize this was way back in V6, but is it still true? Thx, MikeH -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.xiph.org/pipermail/opus/attachments/20111010/d38482b5/attachment-0002.htm

I am trying to get CELT running on a TI 5515 and am having trouble creating a heap large enough to accommodate all of the dynamically created variables. In fact, I would much prefer to have all variables created statically. Could someone give me a short tutorial on what I need to do the create all of the requisite variable statically? Thx, MikeH -------------- next part -------------- An

In order to determine the optimum heap size requirements for my embedded C55xx design, I have used the following to get the encoder and decoder memory requirements: size = opus_encoder_get_size(config.channels); enc = malloc(size); error = opus_encoder_init(enc, config.Fs, config.channels, config.application); size = opus_decoder_get_size(config.channels);

Tim, et al, I have run into several problems with V0.8.0. I will address them seperately. 1. My compiler is complaining about the following code in celt.c which seems to define metric first as celt_word32, then as celt_word16. Am I mis-interpreting something? ?? VARDECL(celt_word32, metric); ?? ALLOC(metric, len, celt_word16); Thx MikeH -------------- next part -------------- An HTML attachment

As promised, here's a re-send of all my Aarch64 patches, following comments by John Ridges. Note that they actually affect more than just Aarch64 -- other than the ones specifically guarded by AARCH64_NEON defines, the Neon intrinsics all also apply on armv7; and the OPUS_FAST_INT64 patches apply on any 64-bit machine. The patches should largely be independent and independently useful, other

Following Tim's comments, here are my reworked patches for the Neon intrinsic function patches of of my Aarch64 patchset, i.e. replacing patches 5-8 of the v2 series. Patches 1-4 and 9-18 of the old series still apply unmodified. The one new (as opposed to changed) patch is the first one in this series, to add named constants for the ARM architecture variants. There are also some minor code

This sequence of patches provides arm64 support for Opus. Tested on iOS, Android, and Ubuntu 14.04. The patch sequence was written on top of Viswanath Puttagunta's Ne10 patches, but all but the second ("Reorganize pitch_arm.h") should, I think, apply independently of it. It does depends on my previous intrinsics configury reorganization, however. Comments welcome. With this and

Here are my aarch64 patches rebased to the current tip of Opus master. They're largely the same as my previous patch set, with the addition of the final one (the Neon fixed-point implementation of xcorr_kernel). This replaces Viswanath's Neon fixed-point celt_pitch_xcorr, since xcorr_kernel is used in celt_fir and celt_iir as well. These have been tested for correctness under qemu

Gents, In Version 8.1, QCONST16 is defined as follows in arch.h within the FLOATING_POINT section: #define QCONST16(x,bits) (x) However, in both celt.c and quant_bands.c, QCONST16 is referenced without a conditional FLOATING_POINT define. So when I compile as FIXED_POINT I get an "undefined identifier" for QCONST16. Am I doing something wrong? Thx, MikeH

hi there. I'm trying to boot several OSes floppy images from a cdrom via memdisk. Actually, Linux and FreeBSD boots fine, but, while i'm using the same method, I couldn't get into booting netbsd nor openbsd. The boot process seems to hang up, in those two cases, when the second stage native bootloader try to load the kernel (i'm not absolutely sure about this). The native first

Hi all, I'm sending patch "Optimize silk_warped_autocorrelation_FIX() for ARM NEON" in an separate email. It is based on Tim’s aarch64v8 branch https://git.xiph.org/?p=users/tterribe/opus.git;a=shortlog;h=refs/heads/aarch64v8 Thanks for your comments. Linfeng

Due to a build problem. It has been fixed and updated in-place on freefall.cdrom.com and ftp.freebsd.org. Sorry for any inconvenience caused! Jordan

Gents, My TI C55xx complier is complaining about (in opus_encoder.c, opus_encode()): st->silk_mode.payloadSize_ms = 1000 * frame_size / st->Fs; where .payloadSize_ms is opus_int, frame_size is an int, and Fs is a long. Should one of these be cast differently? Thx, MikeH -------------- next part -------------- An HTML attachment was scrubbed... URL: