search for: armv6j

...I am about to give up... Since I plan to use this on an embedded device (building dropbear is *NOT* an option!), I've excluded as many openssh configure options as I can but, ultimately, failed. This is my setup: export LDFLAGS=' -pie -z relro -z now' export CFLAGS='-O2 -g -march=armv6j -mtune=arm1136jf-s -mthumb-interwork -mno-thumb -Os -fpic' export CXXFLAGS='-O2 -g -march=armv6j -mtune=arm1136jf-s -mthumb-interwork -mno-thumb' export FFLAGS='-O2 -g -march=armv6j -mtune=arm1136jf-s -mthumb-interwork -mno-thumb' ./configure \ --host=armv6l-redhat-linux-gnueab...

...DT/TripleTest.cpp (working copy) @@ -851,6 +851,10 @@ EXPECT_EQ("arm1136jf-s", Triple.getARMCPUForArch()); } { + llvm::Triple Triple("armv6l-unknown-eabi"); + EXPECT_EQ("arm1136jf-s", Triple.getARMCPUForArch()); + } + { llvm::Triple Triple("armv6j-unknown-eabi"); EXPECT_EQ("arm1136jf-s", Triple.getARMCPUForArch()); } I looked into the tests (and unit tests), and found that perhaps the most appropriate test to add is in the determination of the cpu type from the architecture version. I verified that ARM1136 is the ba...

...never used up so should not make a difference. I compiled the three final versions of each major release of libopus so that was 0.9.14, 1.0.3 & 1.1. These were all compiled natively on the machine using the current repo version of gcc 4.6.3 and with these optimisation flags: -O2 -pipe -march=armv6j -mtune=arm1176jzf-s -mfpu=vfp -mfloat-abi=hard These were compiled with floating point enabled. I will look at the fixed point version separately later. I used a clip of speech from a librevox recording which was resampled from 44.1khz to 48khz within audacity. The clip is 2 minutes long. I wrot...

...never used up so should not make a difference. I compiled the three final versions of each major release of libopus so that was 0.9.14, 1.0.3 & 1.1. These were all compiled natively on the machine using the current repo version of gcc 4.6.3 and with these optimisation flags: -O2 -pipe -march=armv6j -mtune=arm1176jzf-s -mfpu=vfp -mfloat-abi=hard These were compiled with floating point enabled. I will look at the fixed point version separately later. I used a clip of speech from a librevox recording which was resampled from 44.1khz to 48khz within audacity. The clip is 2 minutes long. I wrot...

...> I compiled the three final versions of each major release of libopus so >> that was 0.9.14, 1.0.3 & 1.1. These were all compiled natively on the >> machine using the current repo version of gcc 4.6.3 and with these >> optimisation flags: >> >> -O2 -pipe -march=armv6j -mtune=arm1176jzf-s -mfpu=vfp -mfloat-abi=hard >> >> >> These were compiled with floating point enabled. I will look at the fixed >> point version separately later. >> >> I used a clip of speech from a librevox recording which was resampled from >> 44.1khz...

Christian, I will give 64kbit/s a try and post the figures. My own project is voice only and requires low bitrate so was hoping that it was just the way I was compiling and not an actual regression in speed for SILK. The raspberry PI is quite a cheap and handy reference platform though the ARM side is fairly underpowered but has a great GPU. It also has no audio in which is a pain for playing

...a difference. > > I compiled the three final versions of each major release of libopus so > that was 0.9.14, 1.0.3 & 1.1. These were all compiled natively on the > machine using the current repo version of gcc 4.6.3 and with these > optimisation flags: > > -O2 -pipe -march=armv6j -mtune=arm1176jzf-s -mfpu=vfp -mfloat-abi=hard > > > These were compiled with floating point enabled. I will look at the fixed > point version separately later. > > I used a clip of speech from a librevox recording which was resampled from > 44.1khz to 48khz within audacity. Th...

...; I have compiled myself the previous version of libopus to find out if it >> was a regression or something I was doing wrong in compiling. It looks like >> it has got slower since 0.9.14. I have recompiled everything with these >> CFLAGS natively on the Pi: "-O2 -pipe -march=armv6j -mtune=arm1176jzf-s >> -mfpu=vfp -mfloat-abi=hard". These seem to be the recommended settings. I >> had assumed that opusenc would not be taking that much CPU but having >> re-compiled I have made up some of the loss but not all. >> >> >> >> So on the...

...difference. > > I compiled the three final versions of each major release of libopus so > that was 0.9.14, 1.0.3 & 1.1. These were all compiled natively on the > machine using the current repo version of gcc 4.6.3 and with these > optimisation flags: > > -O2 -pipe -march=armv6j -mtune=arm1176jzf-s -mfpu=vfp -mfloat-abi=hard > > > These were compiled with floating point enabled. I will look at the fixed > point version separately later. > > I used a clip of speech from a librevox recording which was resampled from > 44.1khz to 48khz within audacity....

...s of each major release of > libopus so > that was 0.9.14, 1.0.3 & 1.1. These were all compiled natively > on the > machine using the current repo version of gcc 4.6.3 and with these > optimisation flags: > > -O2 -pipe -march=armv6j -mtune=arm1176jzf-s -mfpu=vfp > -mfloat-abi=hard > > > These were compiled with floating point enabled. I will look at > the fixed > point version separately later. > > I used a clip of speech from a librevox recording which was &gt...

> You assume triples make sense. That's the first mistake everyone does > when thinking about triples. :) I know they don't make sense in many corner cases, but I think discarding logic where it *does* exist is a mistake. > AFAIK, "ARMv7B" is only used by HighBank, which is no more. But that, > too, was "ARMv7A big endian". I believe it's what any