similar to: Endianness

I see the following in arch.h #elif defined (TI_C6X_ASM) #include "fixed_c6x.h" But there does not seem to be a header file by that name in the 1.1.2 distribution. dave

I did find it using my browser search. I am not sure where the "Git" is. It looks like many of the macros that use the TI intrinsics are commented-out. #if 0 +#include "dsplib.h" + +#undef MAX16 +#define MAX16(a,b) _max(a,b) ... Once my development has commenced (still in the study phase). I will be trying it. dave -----Original Message----- From: Jean-Marc Valin

Hi All, Need Help ! I am interested testing opus codec encoding decoding qaulity. for this have complied opus code codec from souce. After compiling i got opus_demo app. for Encoding i followed below steps: 1) Reference file used music_orig.wav (http://www.opus-codec.org/examples/samples/music_orig.wav) Number of samples : 4358219 (90.8 s) 2015-04-13 10:40:07 UTC Sampling

Hi, I have found differences in quality between opus_demo and opusenc/opusdec. I used for both applications the same raw pcm file,16 bit,48khz,litle endian. i use libopus 1.1-beta and opus-tools-0.1.7. The command for opus_demo is: opus_demo audio 48000 1 64000 -cvbr -framesize 10 in.pcm out.pcm For opusenc/dec: opusenc --raw --raw-chan 1 bitrate 64 -cvbr --framesize 10 in.pcm in.opus

Hello! I encoded a voice file (48kHz) with opusbin\opusenc.exe with the standard settings and decoded it. The output was amazing. I could not hear any loss at all. Then i encoded the same file with opus_demo.exe and standard settings and then decoded it. The output had a sizzling noise, even when I used full bandwidth. I think I have played around with any of the settings in opus_demo.exe,

Hi, I have downloaded the latest stable version *1.0.2 opus audio codec* from the following link: http://www.opus-codec.org/downloads/ *Details of OS & CPU:* OS : Microsoft Windows XP CPU : intel core 2 Duo cpu I am using Microsoft visual C++ 2010 Express to build the codec (opus.vcxproj available in the package downloaded). I am able to build it & could generate the application

Hi, I'm recently trying to investigate ppc_fp128 related problem. Here is a minimal C++ test case that seems wrongly compiled: long double id(long double a) { return a; } bool f(long double x) { return id(__builtin_fabsl(x)) >= 0; } int main() { if (f(-123.l)) { return 0; } return 1; } The program compiled with command: clang++ -static -target powerpc64le-linux-gnu bad.cc

Hey folks, If I've got some code that I can compile using clang, that depends on a certain endianness, can I generate bitcode that will have the code operate correctly, even if run on machines of the the opposite endianness? If not, what're we talking about in specific work that'd be needed? Thanks, - Lally

On Fri, 10 Apr 2015 12:19:16 +0200 Greg Kurz <gkurz at linux.vnet.ibm.com> wrote: > This patch brings cross-endian support to vhost when used to implement > legacy virtio devices. Since it is a relatively rare situation, the > feature availability is controlled by a kernel config option (not set > by default). > > The vq->is_le boolean field is added to cache the

On Fri, 10 Apr 2015 12:19:16 +0200 Greg Kurz <gkurz at linux.vnet.ibm.com> wrote: > This patch brings cross-endian support to vhost when used to implement > legacy virtio devices. Since it is a relatively rare situation, the > feature availability is controlled by a kernel config option (not set > by default). > > The vq->is_le boolean field is added to cache the

On Mon, Nov 30, 2015 at 7:24 PM Gao, Yunzhong < yunzhong_gao at playstation.sony.com> wrote: > According to > http://refspecs.linuxfoundation.org/ELF/ppc64/PPC-elf64abi.html, > "The high-order double-precision value (the one that comes first in > storage) must have the larger magnitude." > > So the order of the two doubles in your fp128 is not affected by the

On Wed, Feb 10, 2016 at 01:11:34PM +0100, Greg Kurz wrote: > On Wed, 10 Feb 2016 13:21:22 +0200 > "Michael S. Tsirkin" <mst at redhat.com> wrote: > > > On Wed, Jan 13, 2016 at 06:09:41PM +0100, Greg Kurz wrote: > > > The default use case for vhost is when the host and the vring have the > > > same endianness (default native endianness). But there

On Wed, Feb 10, 2016 at 01:11:34PM +0100, Greg Kurz wrote: > On Wed, 10 Feb 2016 13:21:22 +0200 > "Michael S. Tsirkin" <mst at redhat.com> wrote: > > > On Wed, Jan 13, 2016 at 06:09:41PM +0100, Greg Kurz wrote: > > > The default use case for vhost is when the host and the vring have the > > > same endianness (default native endianness). But there

On Wed, Jan 13, 2016 at 06:09:41PM +0100, Greg Kurz wrote: > The default use case for vhost is when the host and the vring have the > same endianness (default native endianness). But there are cases where > they differ and vhost should byteswap when accessing the vring: > - the host is big endian and the vring comes from a virtio 1.0 device > which is always little endian > -

On Wed, Jan 13, 2016 at 06:09:41PM +0100, Greg Kurz wrote: > The default use case for vhost is when the host and the vring have the > same endianness (default native endianness). But there are cases where > they differ and vhost should byteswap when accessing the vring: > - the host is big endian and the vring comes from a virtio 1.0 device > which is always little endian > -

I am new to LLVM and I am interested in using LLVM for an application that I plan to develop on Solaris. I want to execute the generaed code on different machines (both little endian and big endian). In my application endianess is important. How does LLVM deal with Endian issues? Does LLVM take care of byte swapping? Thanks __________________________________ Do you Yahoo!? Yahoo! Mail

List, A recent discussion over on XiphWiki is trying to decide if OggPCM should support only little-endianness or the usual combo of big and little. It started with the following statement by an user (Qqq): "Portable players are usually ARM, which is usually little-endian. The Macintosh is now little-endian. Obviously the PC is little-endian. Clearly there is a winner. It's long past

Hello, I'd like to implement the gnu attribute "scalar_storage_order" to mark structs with non-native endianness. My rational is working on network protocols over little endian architecture (for instance: RiscV). An old bug is open on this issue here: https://bugs.llvm.org/show_bug.cgi?id=35293 I'd like to discuss the possible ways to implement this. The GCC implementation is

From googling around, it seems that the ogg bitpacker has defined endianness, but I can't find anywhere that says which order it's in. Any help? The endianness of the 24 bit field in the OggPCM header should be specified. I was going to edit the wiki to specify it as network byte order, then realized that you may have standardized on something else in theora/vorbis already.

On Fri, Apr 10, 2015 at 12:19:16PM +0200, Greg Kurz wrote: > This patch brings cross-endian support to vhost when used to implement > legacy virtio devices. Since it is a relatively rare situation, the > feature availability is controlled by a kernel config option (not set > by default). > > The vq->is_le boolean field is added to cache the endianness to be > used for ring