similar to: patch for libspeex

Hi Jens, > There is already streaming support in the xmms-plugin. > The 0.6.0 version found at http://jzb.rapanden.dk/speex/ is hopelessly > outdated, but the nightly version should work. D'oh, should've looked at this before hand. Seems you've done more or less what I've done and taken the streaming code from the mpeg/vorbis plugins and meshed it in with yours. I

If such a thing happens, discussion of the RTP profile draft would be most welcome - please get responses back to the list! Ah, if I could only be there... but it's a terribly long way to fly to. Greg On Wed, 18 Dec 2002, Bernard Blackham wrote: > On Wed, Dec 18, 2002 at 04:55:49PM +1100, Conrad Parker wrote: > > for a good time read: > >

On Tue, Dec 17, 2002 at 11:55:21PM -0800, Greg Herlein wrote: > If such a thing happens, discussion of the RTP profile draft > would be most welcome - please get responses back to the > list! Now, if this were finalised before the conference then we could do a demo and use it for broadcasting the lectures streams around the world... What is currently the best way of doing this? I'm

On Sun, Dec 15, 2002 at 02:15:51PM -0500, Jean-Marc Valin wrote: > I thought that -O3 would inline those functions, but I'll have a closer > look... I'm not sure how C inlining works. Does the inlined function > need to be in a .h? I believe either the .h or the .c or both (both for consistency). It does seem an obvious optimisation for gcc to do though. Maybe because its in a

On Sat, Dec 14, 2002 at 06:04:08PM -0500, Jean-Marc Valin wrote: > Maybe not everything got re-compiled and some parts were left with -g or > something? With the files you sent, I get (on my PIII 1 GHz, with -O3): > speexenc --comp 3 --quality 3 sample.wav sample.spx > 0,65s user 0,00s system 100% cpu 0,647 total > > strange... I'm recompiling the lot, no debugging, -O3 (or

I have a patch for libspeex, which optimises some of the loops in vq_nbest and vq_nbest_sign that speeds up encoding - my results: test file: 10s wav file at 16000 Hz, mono encoding with wideband --quality 3, --comp 3 machine: PIII-900Mhz, 256MB RAM before: 2.78s after: 2.38s I'm still trying to grasp the code (I'm just a coder, no background in sound processing), and just optimised

On Sat, Dec 14, 2002 at 01:46:19AM -0500, Jean-Marc Valin wrote: > Thanks for the patch. I applied it and it give me up to 15% in speed. > Doesn't seem to change the results, which is a good thing (though you > originally forgot a "used=0" in vq_nbest_sign). I'll check a thing or > two and I'll apply to CVS. D'oh. My carelessness, sorry! :) > Strange...

On Wed, Dec 18, 2002 at 11:46:42PM +0800, Bernard Blackham wrote: > Hi Jens, > > > There is already streaming support in the xmms-plugin. > > The 0.6.0 version found at http://jzb.rapanden.dk/speex/ is hopelessly > > outdated, but the nightly version should work. > > D'oh, should've looked at this before hand. Seems you've done more > or less what

On Tue, Feb 18, 2003 at 09:06:16PM -0500, Jean-Marc Valin wrote: > BTW, when you have something working and stable, I could include it in > the main Speex distribution. Hmmm, define working and stable :) <braindump topic="speexcat"> It began as a merge between speexdec and speexenc from 1.0beta3, with the encoding/decoding removed, and simply piped in and out from ogg

On Tue, Feb 18, 2003 at 06:09:43PM -0500, Jean-Marc Valin wrote: > Le mar 18/02/2003 ? 17:38, John Hayes a ?crit : > > If I encode something in ultra-wideband, can I decode it in wideband by > > chopping off bytes in every frame? > > All you have to do is use the --force-wb switch with speexdec. It will > decode as if the file were wideband, ignoring the ultra-wideband

Hi all, I've done a bit of searching and haven't seen anybody else coming across this problem yet: I noticed that Dovecot uses the opposite flags for marking messages as deleted and draft to most other MUAs I've seen or used: With PINE, mutt and uw-imapd at least, messages are marked with X-Status 'D' for Deleted, and 'T' for drafT. Dovecot reverses this behaviour,

Hi, I did a bit of digging into the assertions from mbox-rewrite.c (hdr_parsed_size.physical_size == hdr_size). Every time it happens, hdr_size is 0, while hdr_parsed_size.physical_size is non-zero (presumably the correct value). Does this help track it down? I can't manage to get hold of an mbox that causes this though. Another infrequent assertion that's popped up: file

Le sam 14/12/2002 à 01:03, Bernard Blackham a écrit : > I have a patch for libspeex, which optimises some of the loops in > vq_nbest and vq_nbest_sign that speeds up encoding - my results: Thanks for the patch. I applied it and it give me up to 15% in speed. Doesn't seem to change the results, which is a good thing (though you originally forgot a "used=0" in vq_nbest_sign).

As the freeze for Debian sarge slowly approaches I want to make sure the Dovecot packages are in as good condition as possible. I see there have been a number of patches since 0.99.10. I have added the following patches: * segfault when user home directory is empty * Proper PAM service name * Make suid work on 2.6 kernels Any other patches thatI ought to add. Or better yet, will there be a

Hello Bernard, Friday, December 13, 2002, 7:22:54 AM, you wrote: Bernard> I've one small request - an option on speexenc that allows you to Bernard> specify a speex file to append to, allowing you to concatenate Bernard> streams without losing quality by decoding & encoding. Ideally, it Bernard> would: But you can `cat speex1.ogg speex2.ogg> unionspeex.og` and still have

If I encode something in ultra-wideband, can I decode it in wideband by chopping off bytes in every frame? John --- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.xiph.org/ogg/ To unsubscribe from this list, send a message to 'speex-dev-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed.

Hi, Speex is getting close to beta4, which I'd like to be feature-complete (or as close as possible). That's why I'd like to ask if anyone here has needs for a feature that hasn't been implemented yet. If so, please let me know. For those interested, here's what's going to be in beta4. First, the VBR code has been greatly improved and now works good with wideband too.

I'm trying to get speex to encode a bit faster, mainly by rewriting a few functions in SSE and translating the GCC __asm__ to VC __asm. There's 2 functions I'm targeting, first is vq_nbest which consumes 40% of the time at high complexity and split_cb_search_shape_sign. Which consumes just over 30%. I've split out two functions from: cb_search_precompute_energy - loop at the

> Now, if this were finalised before the conference then we could do > a demo and use it for broadcasting the lectures streams around the > world... What is currently the best way of doing this? The best demo right now is probably LinPhone (www.linphone.org). Simon is currently working (in CVS) on making it up-to-date with the RTP spec (Simon, is it usable yet?), but the earlier versions

On Fri, Dec 13, 2002 at 01:21:17AM -0500, Jean-Marc Valin wrote: > Speex is getting close to beta4, which I'd like to be feature-complete > (or as close as possible). That's why I'd like to ask if anyone here has > needs for a feature that hasn't been implemented yet. If so, please let > me know. Hi Jean, I've one small request - an option on speexenc that allows