search for: eastsit

Hi, I've been struggling for almost a week now, but I can't get the following setup to work. At home I have class A network: 10.0.0.0/16 with a masquerading gateway 10.0.0.1 running tinc. At work (http://www.eastsite.nl) we have a 192.168.0.0/24 network. The gateway is called 'ed' I've set up tinc on 'gateway' and everything is working fine from 'gateway', but none of the machines on my local network can access the remote network. Here's what I've got: [root@gateway ea...

Hi all, The decoder is down 30% execution time, identical bit output. Didn't get the mdct yet; 1024 point mdct is a bit much to brute-force, and I'm not going to hand-unroll the whole thing either (the machine- unrolled version produced a 1.5M executable; understandably, it wasn't very fast. Still waiting for processors with 1.5M L1 code caches ;-) Slowest parts now are: -- mdct --

So, it turns out (and another implementation actually explicitly mentions it) that LSP->LPC computation using the FIR algorithm is very sensitive to noise (iterative algorithm) and really really requires doubles [we're not kidding]. This was complicating things for folks pursuing fixed point implementations, and also was a potential source for bugs if FP optimizations got out of hand. This

I saw some mail go by a bit ago about doubles-vs-floats, but I seem to have lost it. I'm interested in rewriting the mdct code using Altivec on MacOS X. Altivec doesn't support doubles, though -- the only floating point vector type is single precision floats. Vorbis currently has doubles everywhere -- is this really necessary? Doubles are supposedly faster than floats in the PPC

Hi all, I'm busy doing optimizations for vorbis. Don't have time for it, but still doing it :-) Some suggestions: there are some double function names: forward/inverse pack/unpack look/free_look/free_info and maybe more. If they were renamed to time0_forward etc. profiling would be a lot easier. Oh, and add -fno-inline to $PROFILE in the Makefiles (or configure). Most expensive

Hello, I was wondering if it is possible to change the huffman stuff? A different mapping maybe, or maybe it is not too late to change? Decoding is much more efficient if: -- the huffman tree is left-aligned (i.e., longer codes more to the left) -- and we get the bits msb, not lsb Oh, and I need some clarification about the lsp: the purpose of the lsp is to find a low-bitcount approximation of

Well, here you are. 24k; sorry if I'm not supposed to put this size things in your mailbox, didn't know where else to put it. And you all are subscribed to vorbis-dev, after all. I'm not that good at breaking patches apart, so it's one big patch. Sorry. Overview: configure.in make profiling easier & more useful decoder-example.c (#if 0'ed) dither output;