Hi everyone, I'm about to release version 1.2-beta1 (which I could have called 1.1.13), which includes many, many changes. It would help if everyone could give the svn version (http://svn.xiph.org/trunk/speex/) a try and see if it works fine. I'll check my email next week when I'm back from some vacations and if nothing bad has been reported, I'll make the release. Have fun, Jean-Marc
Hi I have tested speex from svn trunk r11792, here are my findings: * Builds ok for Symbian, with 1 warning (patch to fix this this attached.) - not tested on hardware * Builds ok for Ubuntu 6.06 (AMD64), although there are some issues with 'make -j4' (try it). Runs fine on AMD64 (64-bit mode), tested 8000Hz and 32000Hz * Stereo encoding/decode goes at half the frequency, but this problem is also present in 1.1.11 and 1.1.2 from Debian, so it might be a problem in my application.. in general it works as expected, no major issues found.. /alfred Jean-Marc Valin wrote:> Hi everyone, > > I'm about to release version 1.2-beta1 (which I could have called > 1.1.13), which includes many, many changes. It would help if everyone > could give the svn version (http://svn.xiph.org/trunk/speex/) a try and > see if it works fine. I'll check my email next week when I'm back from > some vacations and if nothing bad has been reported, I'll make the release. > > Have fun, > > Jean-Marc > _______________________________________________ > Speex-dev mailing list > Speex-dev@xiph.org > http://lists.xiph.org/mailman/listinfo/speex-dev-- Alfred E. Heggestad <aeh@db.org> Web: http://aeh.db.org/ VoIP: <sip:alfredh@symbianos.org>, <sip:aeh@oplug.org> Phone: +47 85 24 72 75 Mobile: +47 94 29 65 87 Skype: alfredheggestad -------------- next part -------------- Index: libspeex/nb_celp.c ==================================================================--- libspeex/nb_celp.c (revision 11792) +++ libspeex/nb_celp.c (working copy) @@ -1145,7 +1145,7 @@ static void nb_decode_lost(DecState *st, spx_word16_t *out, char *stack) { - int i, sub; + int i; int pitch_val; spx_word16_t pitch_gain; spx_word16_t fact;
> I'm about to release version 1.2-beta1 (which I could have called > 1.1.13), which includes many, many changes. It would help if everyone > could give the svn version (http://svn.xiph.org/trunk/speex/) a try and > see if it works fine. I'll check my email next week when I'm back from > some vacations and if nothing bad has been reported, I'll make the > release.Jean-Marc, st->highpass_enabled is typed inconsistently. It is "int" in the structure, but "spx_int32_t" in the SET, GET cases in nb(sb)_encoder(decoder)_ctl. The parameter is "int" in testenc.c, and in the TI version ti\testenc-TI-C5x.c. This breaks for 16 bit platforms, where "int" is 16 bits. The types in the state structure and the _ctl routines really should match. For now, I have changed testenc-TI-C5x.c to pass a 32-bit parameter, which works with no change elsewhere. I can send a patch for this. Another inconsistency is that GET_COMPLEXITY returns a spx_int32_t, but the field st->complexity is an int. - Jim
On 8/18/06, Jean-Marc Valin <jean-marc.valin@usherbrooke.ca> wrote:> Hi everyone, > > I'm about to release version 1.2-beta1 (which I could have called > 1.1.13), which includes many, many changes. It would help if everyone > could give the svn version (http://svn.xiph.org/trunk/speex/) a try and > see if it works fine. I'll check my email next week when I'm back from > some vacations and if nothing bad has been reported, I'll make the release. > > Have fun, > > Jean-MarcBuilds fine for me on fedora core 6, test 2- amd64. FWIW, attached is the rpm .spec file I used to build it. sean -------------- next part -------------- A non-text attachment was scrubbed... Name: Speex.svn.spec Type: application/octet-stream Size: 2410 bytes Desc: not available Url : http://lists.xiph.org/pipermail/speex-dev/attachments/20060818/eee9b16a/Speex.svn-0001.obj
Is there Speex ready for Symbian ,or is there anyone use it on Symbian successfully? if i should use it on symbian ,how to do or how to change the source code?> > _______________________________________________ > Speex-dev mailing list > Speex-dev@xiph.org > http://lists.xiph.org/mailman/listinfo/speex-dev
> * Builds ok for Symbian, with 1 warning (patch to fix this > this attached.) - not tested on hardwarePatch applied.> * Builds ok for Ubuntu 6.06 (AMD64), although there are > some issues with 'make -j4' (try it). Runs fine on > AMD64 (64-bit mode), tested 8000Hz and 32000HzOdd. Not sure what causes that.> * Stereo encoding/decode goes at half the frequency, but > this problem is also present in 1.1.11 and 1.1.2 from > Debian, so it might be a problem in my application..Can you describe the problem more precisely?> in general it works as expected, no major issues found..Good. Jean-Marc
Hi Jim, Actually, I don't see anything wrong with the internal structure having a different type than the interface, as long both types are big enough to hold the possible values (in this case 0 and 1). Though, as you pointed out, testenc needs to be fixed to use spx_int32_t instead of int. I'll change that. Jean-Marc Jim Crichton a ?crit :> st->highpass_enabled is typed inconsistently. It is "int" in the > structure, but "spx_int32_t" in the SET, GET cases in > nb(sb)_encoder(decoder)_ctl. The parameter is "int" in testenc.c, and > in the TI version ti\testenc-TI-C5x.c. This breaks for 16 bit platforms, > where "int" is 16 bits. > > The types in the state structure and the _ctl routines really should > match. For now, I have changed testenc-TI-C5x.c to pass a 32-bit > parameter, which works with no change elsewhere. I can send a patch for > this. > > Another inconsistency is that GET_COMPLEXITY returns a spx_int32_t, but > the field st->complexity is an int. > > - Jim > > _______________________________________________ > Speex-dev mailing list > Speex-dev@xiph.org > http://lists.xiph.org/mailman/listinfo/speex-dev >
> * Builds ok for Ubuntu 6.06 (AMD64), although there are > some issues with 'make -j4' (try it). Runs fine on > AMD64 (64-bit mode), tested 8000Hz and 32000HzThe "make -j" issue is now fixed in svn (thanks to Ralf). Jean-Marc