[Speex-dev] Problem with Blackfin assembly optimizations -- bug
in fixed_bfin.h / resampler saturation???
Jean-Marc Valin
jean-marc.valin at usherbrooke.ca
Wed Mar 5 13:25:24 PST 2008
Can you also try disabling the DIV* macros from fixed_bfin.h and see if
it makes a difference? I've asked other people using Speex on the
Blackfin whether they were having problems and they said no, so maybe
it's toolchain-related (bug could be in the toolchain or just exposed by
the toolchain). Can you try with a different version of gcc?
Also, if there's any actual regression, it should be relatively easy to
track down by doing a bisection, either manually using svn or using
git-bisect (I can show you how to use that).
Jean-Marc
Stephane Menard a écrit :
> Jean-Marc, Frank,
>
>
>
> I have stumbled across a similar situation regarding optimization.
>
>
>
> I seem to have a similar setup as Frank does with a fixed 48khz in
> and out. The wideband mode and ultra-wideband modes are really what
> I’m looking for.
>
>
>
> I have a test application that reads audio, downsample to 16kHz (or
> 32kHz), speex encode, speex decode, upsample back to 48kHz, and
> playback.
>
>
>
> If I remove the speex encode and decode, I get perfect audio, up and
> down resampling is great.
>
>
>
> When I use the encoder/decoder pass, and I use the non-asm-optimized
> speex library, I get good results (aside using a lot of CPU). Audio
> is good.
>
>
>
> When I used the asm-optimized library, I seem to get good audio only
> if I configure the encoder in mode 10. Anything below results in
> noisy speech). These results are similar for 1.2beta3 and 1.2beta2.
> Changing the complexity doesn’t seem to affect the results.
>
>
>
> I tried the most recent git/svn trunk, and I get a bus error in the
> encoder. I noticed that the only thing that seem different (for what
> I’m using) is the file quant_lsp_bfin.h. So I replaced that file only
> in a 1.2beta3 package and I got the same bus error. (this patched
> version works fine if I don’t use asm-optimization).
>
>
>
> I’m in a similar situation as Frank once again where I need both the
> libspeex and libspeexdsp, so I have not been able to enable
> fixed-debug.
>
>
>
> Please let me know if you have any clues on how to fix the issue and
> if there’s anything I can do to help.
>
>
>
> Kind Regards,
>
>
>
> Stephane
>
>
>
>
>
>> / after some problems with getting svn to work here I finally made
>> it./
>
>> / Problem is, you write that I cannot use libspeex and libspeexdsp
>> at/
>
>> / the same time now -- because I use a "live" system (mic-in ->/
>
>> / speex_enc -> speex_dec -> headphone out) and I can run the
>> AD1836/
>
>> / audio codec on 48 kHz only, I cannot use my program now (because
>> I/
>
>> / use speex resampling...)/
>
>
>
> Well, you can't use libspeex and libspeexdsp together *only if* you
>
> enable fixed-point debugging. I'll fix that when I get some time.
>
>
>
>> / So I tried to do file I/O, but the described problem (that the/
>
>> / encoder corrupts its input buffer) is gone in this
>> configuration./
>
>
>
> The encoder always corrupts its input buffer. This is not new.
>
>
>
>> / But nevertheless, when I try to encode an overdriven (saturated)/
>>
>
>> / signal, the strange toggling between -MAX and MAX values on a/
>
>> / sample-by-sample basis still happens. The debug output for this
>> is as/
>
>> / follows:/
>
>
>
> What happens if you first saturate the signal to (e.g.) +/- 32000
>
> instead of +/- 32767? BTW, can you send the signal you were using.
>
>
>
> ...
>
>
>
>> / So there seem to be three different positions in code where/
>
>> / assumptions are "broken". It should be pointed out that the
>> above/
>
>> / debug outputs occur only on frames with overdriven signal, but
>> not/
>
>> / every frame with overdriven signal produces a debug-output./
>
>
>
> Yes, I've always assumed sort of a "non totally broken" input signal
> and
>
> I'm not sure what to do here... Sure I could fix it, but then it
> would
>
> make the code less optimal for the normal case (and it doesn't change
>
>
> anything if you've got saturating arithmetic anyway).
>
>
>
> BTW, what happens if you turn on the Blackfin assembly? Do you get
> the
>
> same output (approximately) or does it get worse?
>
>
>
> Jean-Marc
>
>
>
>> / best regards, Frank/
>
>> / /
>
>> / /
>
>> / -----Ursprüngliche Nachricht----- Von: "Jean-Marc Valin"/
>
>> / <jean-marc.valin at usherbrooke.ca
>> <http://lists.xiph.org/mailman/listinfo/speex-dev>> Gesendet:
>> 12.02.08 22:49:49 An:/
>
>> / Frank Lorenz <Frank_wtal at web.de
>> <http://lists.xiph.org/mailman/listinfo/speex-dev>> CC: *Le Service
>> des Technologies de l'Information de l'UdeS veut vous mettre en
>> garde contre "lists.xiph.org" qui semble être une tentative de
>> fraude envers* speex-dev at xiph.org
>> <http://lists.xiph.org/mailman/listinfo/speex-dev> Betreff: Re:/
>
>> / [Speex-dev] Problem with Blackfin assembly optimizations -- bug
>> in/
>
>> / fixed_bfin.h / resampler saturation???/
>
>> / /
>
>> / /
>
>> / OK, a few things got accidentally broken. I've partially fixed it
>> in /
>
>> / svn/git (the limitation is that you can't link with both libspeex
>> and/
>
>> / libspeexdsp if configured as fixed-point debug)./
>
>> / /
>
>> / Can you compile/test now?/
>
>> / /
>
>> / Jean-Marc/
>
>> / /
>
>> / Frank Lorenz a écrit :/
>
>>> / Hi,/
>
>>> / /
>
>>> / when I compile with FIXED_DEBUG enabled, I get an error --
>>> both/
>
>>> / when make tries to build testenc.o and when I try to link my
>>> app/
>
>>> / against the speex lib:/
>
>>> / /
>
>>> / /
>
>>> / lorenz at panelmaker
>>> <http://lists.xiph.org/mailman/listinfo/speex-dev>:~/Blackfin/tests/speex_loopthrough$
>>> make /
>
>>> / bfin-uclinux-gcc -c -g -I/home/lorenz/include -o main.o main.c
>>> /
>
>>> / bfin-uclinux-gcc -gl -elf2flt -L/home/lorenz/lib -o
>>> speex_through/
>
>>> / main.o -lspeex_debug -lspeexdsp -lm /
>
>>> / /home/lorenz/lib/libspeex_debug.a(bits.o): In function/
>
>>> / `speex_bits_set_bit_buffer': /
>
>>> / /home/lorenz/Blackfin/speex-1.2beta3/libspeex/bits.c:72:
>>> multiple/
>
>>> / definition of `_spx_mips' /
>
>>> /
>>> /home/lorenz/lib/libspeex_debug.a(speex.o):/home/lorenz/Blackfin/speex-1.2beta3/libspeex/speex.c:52:/
>>>
>
>>> / first defined here /home/lorenz/lib/libspeex_debug.a(modes.o):
>>> In/
>
>>> / function `speex_mode_query': /
>
>>> / /home/lorenz/Blackfin/speex-1.2beta3/libspeex/modes.c:359:
>>> multiple/
>
>>> / definition of `_spx_mips' /
>
>>> /
>>> /home/lorenz/lib/libspeex_debug.a(speex.o):/home/lorenz/Blackfin/speex-1.2beta3/libspeex/speex.c:52:/
>>>
>
>>> / first defined here
>>> /home/lorenz/lib/libspeex_debug.a(modes_wb.o):/
>
>>> / In function `speex_lib_get_mode': /
>
>>> / /home/lorenz/Blackfin/speex-1.2beta3/libspeex/modes_wb.c:293:/
>
>>> / multiple definition of `_spx_mips' /
>
>>> /
>>> /home/lorenz/lib/libspeex_debug.a(speex.o):/home/lorenz/Blackfin/speex-1.2beta3/libspeex/speex.c:52:/
>>>
>
>>> / first defined here
>>> /home/lorenz/lib/libspeex_debug.a(nb_celp.o): In/
>
>>> / function `_ADD32': /
>
>>> /
>>> /home/lorenz/Blackfin/speex-1.2beta3/libspeex/fixed_debug.h:207:/
>>>
>
>>> / multiple definition of `_spx_mips' /
>
>>> /
>>> /home/lorenz/lib/libspeex_debug.a(speex.o):/home/lorenz/Blackfin/speex-1.2beta3/libspeex/speex.c:52:/
>>>
>
>>> / first defined here
>>> /home/lorenz/lib/libspeex_debug.a(quant_lsp.o):/
>
>>> / In function `compute_quant_weights': /
>
>>> / /home/lorenz/Blackfin/speex-1.2beta3/libspeex/quant_lsp.c:72:/
>
>>> / multiple definition of `_spx_mips' /
>
>>> /
>>> /home/lorenz/lib/libspeex_debug.a(speex.o):/home/lorenz/Blackfin/speex-1.2beta3/libspeex/speex.c:52:/
>>>
>
>>> / first defined here
>>> /home/lorenz/lib/libspeex_debug.a(sb_celp.o): In/
>
>>> / function `_DIV32': /
>
>>> /
>>> /home/lorenz/Blackfin/speex-1.2beta3/libspeex/fixed_debug.h:466:/
>>>
>
>>> / multiple definition of `_spx_mips' /
>
>>> /
>>> /home/lorenz/lib/libspeex_debug.a(speex.o):/home/lorenz/Blackfin/speex-1.2beta3/libspeex/speex.c:52:/
>>>
>
>>> / first defined here /
>
>>> / /home/lorenz/lib/libspeex_debug.a(speex_callbacks.o): In
>>> function/
>
>>> / `speex_default_user_handler': /
>
>>> /
>>> /home/lorenz/Blackfin/speex-1.2beta3/libspeex/speex_callbacks.c:140:/
>>>
>
>>> / multiple definition of `_spx_mips' /
>
>>> /
>>> /home/lorenz/lib/libspeex_debug.a(speex.o):/home/lorenz/Blackfin/speex-1.2beta3/libspeex/speex.c:52:/
>>>
>
>>> / first defined here /
>
>>> / /home/lorenz/lib/libspeex_debug.a(window.o):(.bss+0x0):
>>> multiple/
>
>>> / definition of `_spx_mips' /
>
>>> /
>>> /home/lorenz/lib/libspeex_debug.a(speex.o):/home/lorenz/Blackfin/speex-1.2beta3/libspeex/speex.c:52:/
>>>
>
>>> / first defined here
>>> /home/lorenz/lib/libspeex_debug.a(cb_search.o):/
>
>>> / In function `compute_weighted_codebook': /
>
>>> /
>>> /home/lorenz/Blackfin/speex-1.2beta3/libspeex/cb_search_bfin.h:38:/
>>>
>
>>> / multiple definition of `_spx_mips' /
>
>>> /
>>> /home/lorenz/lib/libspeex_debug.a(speex.o):/home/lorenz/Blackfin/speex-1.2beta3/libspeex/speex.c:52:/
>>>
>
>>> / first defined here
>>> /home/lorenz/lib/libspeex_debug.a(filters.o): In/
>
>>> / function `normalize16': /
>
>>> /
>>> /home/lorenz/Blackfin/speex-1.2beta3/libspeex/filters_bfin.h:37:/
>>>
>
>>> / multiple definition of `_spx_mips' /
>
>>> /
>>> /home/lorenz/lib/libspeex_debug.a(speex.o):/home/lorenz/Blackfin/speex-1.2beta3/libspeex/speex.c:52:/
>>>
>
>>> / first defined here /home/lorenz/lib/libspeex_debug.a(lsp.o):
>>> In/
>
>>> / function `lsp_enforce_margin': /
>
>>> / /home/lorenz/Blackfin/speex-1.2beta3/libspeex/lsp.c:594:
>>> multiple/
>
>>> / definition of `_spx_mips' /
>
>>> /
>>> /home/lorenz/lib/libspeex_debug.a(speex.o):/home/lorenz/Blackfin/speex-1.2beta3/libspeex/speex.c:52:/
>>>
>
>>> / first defined here /home/lorenz/lib/libspeex_debug.a(ltp.o):
>>> In/
>
>>> / function `inner_prod': /
>
>>> / /home/lorenz/Blackfin/speex-1.2beta3/libspeex/ltp_bfin.h:38:/
>
>>> / multiple definition of `_spx_mips' /
>
>>> /
>>> /home/lorenz/lib/libspeex_debug.a(speex.o):/home/lorenz/Blackfin/speex-1.2beta3/libspeex/speex.c:52:/
>>>
>
>>> / first defined here /home/lorenz/lib/libspeex_debug.a(vbr.o):
>>> In/
>
>>> / function `vbr_destroy': /
>
>>> / /home/lorenz/Blackfin/speex-1.2beta3/libspeex/vbr.c:272:
>>> multiple/
>
>>> / definition of `_spx_mips' /
>
>>> /
>>> /home/lorenz/lib/libspeex_debug.a(speex.o):/home/lorenz/Blackfin/speex-1.2beta3/libspeex/speex.c:52:/
>>>
>
>>> / first defined here /home/lorenz/lib/libspeex_debug.a(vq.o): In/
>>>
>
>>> / function `vq_nbest': /
>
>>> / /home/lorenz/Blackfin/speex-1.2beta3/libspeex/vq_bfin.h:38:/
>
>>> / multiple definition of `_spx_mips' /
>
>>> /
>>> /home/lorenz/lib/libspeex_debug.a(speex.o):/home/lorenz/Blackfin/speex-1.2beta3/libspeex/speex.c:52:/
>>>
>
>>> / first defined here /home/lorenz/lib/libspeex_debug.a(lpc.o):
>>> In/
>
>>> / function `_spx_lpc': /
>
>>> / /home/lorenz/Blackfin/speex-1.2beta3/libspeex/lpc.c:78:
>>> multiple/
>
>>> / definition of `_spx_mips' /
>
>>> /
>>> /home/lorenz/lib/libspeex_debug.a(speex.o):/home/lorenz/Blackfin/speex-1.2beta3/libspeex/speex.c:52:/
>>>
>
>>> / first defined here collect2: ld gab 1 als Ende-Status zurÃŒck
>>> make:/
>
>>> / *** [speex_through] Fehler 1/
>
>>> / /
>
>>> / /
>
>>> / again: any ideas how to proceed?/
>
>>> / /
>
>>> / best regards, Frank/
>
>>> / /
>
>>> / /
>
>>> / /
>
>>> / -----Ursprüngliche Nachricht----- Von: "Jean-Marc Valin"/
>
>>> / <jean-marc.valin at usherbrooke.ca
>>> <http://lists.xiph.org/mailman/listinfo/speex-dev>> Gesendet:
>>> 08.02.08 21:50:56 An:/
>
>>> / Frank Lorenz <Frank_wtal at web.de
>>> <http://lists.xiph.org/mailman/listinfo/speex-dev>> CC: *Le
>>> Service des Technologies de l'Information de l'UdeS veut vous
>>> mettre en garde contre "lists.xiph.org" qui semble être une
>>> tentative de fraude envers* speex-dev at xiph.org
>>> <http://lists.xiph.org/mailman/listinfo/speex-dev> Betreff:/
>
>>> / Re: [Speex-dev] Problem with Blackfin assembly optimizations --
>>> bug/
>
>>> / in fixed_bfin.h / resampler saturation???/
>
>>> / /
>
>>> / /
>
>>> / Frank Lorenz a écrit :/
>
>>>> / Yes, this is another point: I wrote that the resampler
>>>> breaks,/
>
>>>> / but this is not the case. Instead, the speex encoder corrupts
>>>> its/
>
>>>> / input buffer when the "DIV32_16 bug" described above happens.
>>>> Do/
>
>>>> / you have any idea how to proceed?/
>
>>> / Can you try enabling --enable-fixed-point-debug (FIXED_DEBUG)
>>> and/
>
>>> / see if any error gets printed. I suspect there might be a
>>> place/
>
>>> / where the assumptions of DIV32_16 are violated, i.e. either
>>> the/
>
>>> / right hand side doesn't fit in 16 bits or the result doesn't
>>> fit in/
>
>>> / 16 bits. Can you check?/
>
>>> / /
>
>>> / Jean-Marc/
>
>>> / /
>
>>>> / best regards, Frank/
>
>>>> / /
>
>>>> / /
>
>>>> / -----Ursprüngliche Nachricht----- Von: "Jean-Marc Valin" /
>
>>>> / <jean-marc.valin at usherbrooke.ca
>>>> <http://lists.xiph.org/mailman/listinfo/speex-dev>> Gesendet:
>>>> 06.02.08 11:07:46 An: /
>
>>>> / Frank Lorenz <Frank_wtal at web.de
>>>> <http://lists.xiph.org/mailman/listinfo/speex-dev>> CC: *Le
>>>> Service des Technologies de l'Information de l'UdeS veut vous
>>>> mettre en garde contre "lists.xiph.org" qui semble être une
>>>> tentative de fraude envers* speex-dev at xiph.org
>>>> <http://lists.xiph.org/mailman/listinfo/speex-dev> Betreff:/
>
>>>> / Re: [Speex-dev] Problem with Blackfin assembly optimizations
>>>> --/
>
>>>> / bug in fixed_bfin.h / resampler saturation???/
>
>>>> / /
>
>>>> / /
>
>>>> / Frank Lorenz a écrit :/
>
>>>>> / I just started to examine the DIV32_16 function (Blackfin
>>>>> ASM /
>
>>>>> / version), and wondered why the return value of the
>>>>> function/
>
>>>>> / inside 'fixed_bfin.h' is of type 'spx_word16_t', but the
>>>>> local/
>
>>>>> / variable 'res' which is returned by this function is of
>>>>> type/
>
>>>>> / 'spx_word32_t'. Is this a trick of optimization or a bug?
>>>>> (Same/
>
>>>>> / question for PDIV32_16 and MAX16, too!)/
>
>>>> / Neither (AFAIK). The idea is that sometimes gcc does /
>
>>>> / silly/counter-intuitive things when I specify a 16-bit
>>>> variable/
>
>>>> / as a constraint. That way, I force the top 16 bits to be
>>>> zero./
>
>>>> / /
>
>>>> / Jean-Marc/
>
>>>> / /
>
>>>>> / best regards, Frank/
>
>>>>> / /
>
>>>>> / /
>
>>>>> / -----Ursprüngliche Nachricht----- Von: "Jean-Marc Valin" /
>
>>>>> / <jean-marc.valin at usherbrooke.ca
>>>>> <http://lists.xiph.org/mailman/listinfo/speex-dev>> Gesendet:
>>>>> 02.02.08 06:26:08/
>
>>>>> / An: speex-dev <*Le Service des Technologies de
>>>>> l'Information de l'UdeS veut vous mettre en garde contre
>>>>> "lists.xiph.org" qui semble être une tentative de fraude
>>>>> envers* speex-dev at xiph.org
>>>>> <http://lists.xiph.org/mailman/listinfo/speex-dev>> Betreff:
>>>>> Re: FW: Re:/
>
>>>>> / [Speex-dev] Problem with Blackfin assembly optimizations --
>>>>> bug/
>
>>>>> / in fixed_bfin.h / resampler saturation???/
>
>>>>> / /
>
>>>>> / /
>
>>>>> / Frank Lorenz a écrit :/
>
>>>>>> / And yes, the same "overflow" happens even when I disable/
>>>>>>
>
>>>>>> / Blackfin ASM optimizations./
>
>>>>> / Indeed, that shouldn't happen. Just to make sure I
>>>>> understand,/
>
>>>>> / so far there's two problems: 1) DIV32_16() in Blackfin
>>>>> assembly/
>
>>>>> / causes problems 2) The resampler overflows/
>
>>>>> / /
>
>>>>> / When you fix/workaround those two, is the encoder/decoder/
>
>>>>> / working correctly or are there other issues?/
>
>>>>> / /
>
>>>>> / About the DIV32_16() issue, could you try and replace it
>>>>> with a/
>
>>>>> / function that compares the Blackfin-asm result with the
>>>>> real /
>
>>>>> / division and dumps the args and output when they don't
>>>>> match./
>
>>>>> / I'd like to understand for what inputs that functions
>>>>> fails./
>
>>>>> / That would help in fixing the problem./
>
>>>>> / /
>
>>>>> / Thanks,/
>
>>>>> / /
>
>>>>> / Jean-Marc/
>
>>>>> / /
>
>>>>>> / best regards, Frank/
>
>>>>>> / /
>
>>>>>> / -----Ursprüngliche Nachricht----- Von: "Jean-Marc Valin"
>>>>>> /
>
>>>>>> / <jean-marc.valin at usherbrooke.ca
>>>>>> <http://lists.xiph.org/mailman/listinfo/speex-dev>>
>>>>>> Gesendet: 01.02.08 12:11:39/
>
>>>>>> / An: Frank Lorenz <Frank_wtal at web.de
>>>>>> <http://lists.xiph.org/mailman/listinfo/speex-dev>> CC: *Le
>>>>>> Service des Technologies de l'Information de l'UdeS veut
>>>>>> vous mettre en garde contre "lists.xiph.org" qui semble
>>>>>> être une tentative de fraude envers* speex-dev at xiph.org
>>>>>> <http://lists.xiph.org/mailman/listinfo/speex-dev>/
>
>>>>>> / Betreff: Re: FW: Re: [Speex-dev] Problem with Blackfin/
>
>>>>>> / assembly optimizations -- bug in fixed_bfin.h /
>>>>>> resampler/
>
>>>>>> / saturation???/
>
>>>>>> / /
>
>>>>>> / /
>
>>>>>> / Frank Lorenz a écrit :/
>
>>>>>>> / didn't get a reply to my last post (see below) -- do
>>>>>>> you/
>
>>>>>>> / have no idea what happens here?/
>
>>>>>> / Sorry, been quite busy lately. Still have a backlog of
>>>>>> things/
>
>>>>>> / to respond to (sorry to others as well), some of it
>>>>>> quite/
>
>>>>>> / old./
>
>>>>>> / /
>
>>>>>>> / After some more tests, I disabled the DIV32_16 Blackfin
>>>>>>> /
>
>>>>>>> / optimizations and now get good quality on the
>>>>>>> Blackfin./
>
>>>>>> / OK, I'll need to investigate that one. It's mostly taken
>>>>>> from/
>
>>>>>> / the ADI manual, so I don't see what could have happened./
>>>>>>
>
>>>>>> / /
>
>>>>>>> / But when I have overdrive on the input, things become
>>>>>>> very/
>
>>>>>>> / bad/
>
>>>>>> / Does that happen without any assembly. Some amount of
>>>>>> badness/
>
>>>>>> / is expected from the fixed-point because of saturation/
>
>>>>>> / issues. It shouldn't overflow though (can you check?)/
>
>>>>>> / /
>
>>>>>>> / -- I'm not sure if this is really a filter stability
>>>>>>> issue/
>
>>>>>>> / like I wrote some weeks ago./
>
>>>>>> / I don't think it has to do with filters./
>
>>>>>> / /
>
>>>>>>> / I use the speex resampler to downsample from 48 to 16
>>>>>>> kHz./
>
>>>>>>> / When I look to the downsampled signal before passing it
>>>>>>> to/
>
>>>>>>> / the encoder, there seems to be a bug in saturation. On/
>>>>>>>
>
>>>>>>> / overdrive, instead of holding a too big signal value
>>>>>>> at/
>
>>>>>>> / maximum (e.g. 32767) for some samples, the sample
>>>>>>> values I/
>
>>>>>>> / get from the resampler are [-32768,32767,-32768,...],
>>>>>>> i.e./
>
>>>>>>> / the output of the resampler alters between the biggest/
>>>>>>>
>
>>>>>>> / possible negative value and the biggest possible
>>>>>>> positive/
>
>>>>>>> / value./
>
>>>>>> / This is definitely bad. Can you send me an example file./
>>>>>>
>
>>>>>> / Also, can you reproduce that problem without the
>>>>>> Blackfin/
>
>>>>>> / assembly?/
>
>>>>>> / /
>
>>>>>>> / Does the resampler use the hardware saturation
>>>>>>> available on/
>
>>>>>>> / Blackfin, or does it saturate by software? Can you
>>>>>>> point/
>
>>>>>>> / me to the place I have to look at inside the resampler/
>>>>>>>
>
>>>>>>> / function for saturation?/
>
>>>>>> / Saturation is entirely done in software. The resampler
>>>>>> does/
>
>>>>>> / the conversion using the WORD2INT macro./
>
>>>>>> / /
>
>>>>>> / Jean-Marc/
>
>>>>>> / /
>
>>>>>> / /
>
>>>>>> / /
>
>>>>>> /
>>>>>> _______________________________________________________________________/
>>>>>>
>
>>>>>> / Jetzt neu! Schützen Sie Ihren PC mit McAfee und WEB.DE.
>>>>>> 30/
>
>>>>>> / Tage kostenlos testen. /
>
>>>>>> / http://www.pc-sicherheit.web.de/startseite/?mc=022220/
>
>>>>>> / /
>
>>>>>> / /
>
>>>>>> / /
>
>>>>> /
>>>>> _________________________________________________________________________/
>>>>>
>
>>>>> / In 5 Schritten zur eigenen Homepage. Jetzt Domain sichern
>>>>> und/
>
>>>>> / gestalten! //Nur 3,99 EUR/Monat! /
>
>>>>> / //http://www.maildomain.web.de/?mc=021114///
>
>>>>> / /
>
>>>>> / /
>
>>>>> / /
>
>>>> / /
>
>>>> /
>>>> _______________________________________________________________________/
>>>>
>
>>>> / Jetzt neu! Schützen Sie Ihren PC mit McAfee und WEB.DE. 30
>>>> Tage/
>
>>>> / kostenlos testen. /
>
>>>> / http://www.pc-sicherheit.web.de/startseite/?mc=022220/
>
>>>> / /
>
>>>> / /
>
>>>> / /
>
>>> / /
>
>>> / /
>
>>> /
>>> _________________________________________________________________________/
>>>
>
>>> / In 5 Schritten zur eigenen Homepage. Jetzt Domain sichern und/
>>>
>
>>> / gestalten! //Nur 3,99 EUR/Monat!/
>
>>> / //http://www.maildomain.web.de/?mc=021114///
>
>>> / /
>
>>> / _______________________________________________ Speex-dev
>>> mailing/
>
>>> / list *Le Service des Technologies de l'Information de l'UdeS
>>> veut vous mettre en garde contre "lists.xiph.org" qui semble être
>>> une tentative de fraude envers* Speex-dev at xiph.org
>>> <http://lists.xiph.org/mailman/listinfo/speex-dev> /
>
>>> / http://lists.xiph.org/mailman/listinfo/speex-dev/
>
>>> / /
>
>>> / /
>
>> / /
>
>> / /
>
>> / /
>
>> /
>> _______________________________________________________________________/
>>
>
>> / Jetzt neu! Schützen Sie Ihren PC mit McAfee und WEB.DE. 30 Tage
>> /
>
>> / kostenlos testen./
>
>> / http://www.pc-sicherheit.web.de/startseite/?mc=022220/
>
>> / /
>
>> / /
>
>> / /
>
>
>
>
> ------------------------------------------------------------------------
>
>
> _______________________________________________ Speex-dev mailing
> list Speex-dev at xiph.org
> http://lists.xiph.org/mailman/listinfo/speex-dev
More information about the Speex-dev
mailing list