search for: 80bit

...at. Q. should I try the patch mentioned below and forget about snoms doing 80 bit incription or should I persevere with making this work? thanks James ---snip--- Patch SRTP for 32bit SRTP have a cryptographic hash to check the integrity of the encrypted packets. It support two hash size: ? 32bit ? 80bit In order to properly fine tune SRTP for mobile networks and to have compatibility with PrivateGSM Enterprise we must use SRTP with hash at 32bit (HMAC_SHA1_32). Asterisk 1.8 by default does not announce in SDP both 32bit and 80bit, but only the 80bit version even if both are supported. This very sm...

...uses this, and import/exports it, will > also write the appropriate conversion OggStream plugin which will allow > applications which only support, say, 16bit audio, to work with it. Do you think the noise in your 16bit application will sound different between a conversion from a 96bit or 80bit audio file from the same analog source ? If the argument for keeping these fields freeform is to support 96bit audio, I'd say Erik is right that you shouldn't pick freeform fields. As a practical matter, I don't see a direct use case for a file/interchange format with a 540 dB dynamica...

...encoding with rc2 (rebuilt rpm with latest redhat 7.1 gcc errata) I got some extremely loud treble distortion sounds in the left channel (only). Please listen to the samples at low level to avoid hurting your ears. My guess is that the bug is related to the channel coupling mode used in 128bit and 80bit mode because that's the only modes that exposes this behaviour. A 6 second sample of the problem is available from http://noa.tm/britney-bug/ By the way, the documentation on http://www.vorbis.com/stereo.psp indicates that there is a way to select stereo mode with oggenc, but that don't s...

...13), !dbg !14 %x = alloca x86_fp80, align 16 !11 = !DILocalVariable(name: "x", scope: !4, file: !1, line: 2, type: !12) !12 = !DIBasicType(name: "long double", size: 128, align: 128, encoding: DW_ATE_float) !13 = !DIExpression() which happens because llvm knows that fp80s are 80bits, while clang declares them as 128bits in the debug info. We might have to special case this in the verifier, but before we do that, I wanted to ask about the following: Reading the DWARF standard, it seems like the following would be a valid description of an X86 80bit long double: DW_TAG_base_t...

Hi Neil, I admit that at this point I haven't considered the implications of the license MPFR is under, and at the moment I'm sticking my head in the sand until and unless we want to go down this path. My expectation is that we would use their exposed API - so we'd #include <mpfr.h> and use functions from there, linking against -lmpfr and -lgmp. I admit that this option would

...gt; given type. The data bit offset attribute is the offset in bits from the > beginning of the containing storage to the beginning of the value. Bits > that are part of the offset are padding. which made me think the representation I proposed in the original email might be correct (i.e. an 80bit value, but always stores as 16 bytes). As far as I see it, there's 3 questions here: 1) What's the right representation in DWARF? 2) If we think it should be the byte_size/bit_size combination, how do we describe this in IR, because right now, even though the size is in bits, will always...

...hysics pipeline is unstable and unless the compiler/platform guarantees 100% identical floating point results, the outcome will diverge. Do you think LLVM can be forced to produce identical floating point results? Even when using different optimization levels or even different CPUs? Some CPUs use 80bit FPU precision for intermediate results (on-chip in registers), while variables in-memory only use 32-bit or 64bit precision. In combination with cancellation and other re-ordering this can give slightly different results. >> If not, the code doesn't seem very useful to me. How could any...

...e offset in bits from the >> beginning of the containing storage to the beginning of the value. Bits >> that are part of the offset are padding. >> >> >> >> which made me think the representation I proposed in the original email >> might be correct (i.e. an 80bit value, but always stores as 16 bytes). >> >> >> >> As far as I see it, there's 3 questions here: >> >> >> >> 1) What's the right representation in DWARF? >> >> >> Unfortunately impossible/hard to answer. DWARF is fairly flexi...

...o you think LLVM can be forced to produce identical floating point > results? Even when using different optimization levels or even different > CPUs? Not right now, but the support can certainly be added. It really *should* be added. It will take a bit of work, however. > Some CPUs use 80bit FPU precision for intermediate results (on-chip in > registers), while variables in-memory only use 32-bit or 64bit precision. > In combination with cancellation and other re-ordering this can > give slightly different results. Yep, which is why good compilers have ways to control this....

Hi all, I'm trying to build R from subversion with MKL 10.0.2 on Ubuntu. I tried: ./configure --with-blas='-L/opt/intel/mkl/10.0.2.018/lib/em64t -lmkl -lguide' --with-lapack='/opt/intel/mkl/10.0.2.018/lib/em64t -lmkl -lmkl_lapack' --enable-R-shlib and got: R is now configured for x86_64-unknown-linux-gnu Source directory: . Installation directory: /usr/local

Hi all, I'm trying to build R from subversion with MKL 10.0.2 on Ubuntu. I tried: ./configure --with-blas='-L/opt/intel/mkl/10.0.2.018/lib/em64t -lmkl -lguide' --with-lapack='/opt/intel/mkl/10.0.2.018/lib/em64t -lmkl -lmkl_lapack' --enable-R-shlib and got: R is now configured for x86_64-unknown-linux-gnu Source directory: . Installation directory: /usr/local

On Mon, Nov 2, 2015 at 8:38 AM, Adrian Prantl via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Looking at the code in clang CGDebugInfo just passes through the width of > the type as it is described by the TypeInfo, which in turn is defined by > the Target. At the moment I do not understand why an x86_fp80 is reported > to be 128 bits wide. (Since it’s a type natively

Hi all, Siliva contacted me about this OggPCM proposal and asked me to join in. For those who don't know me, I am the main author and maintainer of libsndfile and therefore know quite a bit about how uncompressed audio is stored in sound files. However even I would not consider myself an expert; there are areas to do with channel assignments that I know I am ignorant of. I am also quite