Speex dev - Oct 2005 - Static linking without C runtime dependence?

hi,
 i have searched through the archives but did not manage
to find benchmarks of encoding/decoding speex on ARM
processor. esp interested in ARM9E. understand that ARM5E
has some dsp-like instructions, wonder whether they are compatible
with those in ARM9E.
 thanks in advance.
 tk
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.xiph.org/pipermail/speex-dev/attachments/20051015/3fb7b018/attachment.htm

Try --enable-arm5e-asm and see if it works.

	Jean-Marc

Le samedi 15 octobre 2005 ? 13:15 +0800, tk a ?crit :
> hi,
>  
> i have searched through the archives but did not manage
> to find benchmarks of encoding/decoding speex on ARM
> processor. esp interested in ARM9E.  understand that ARM5E 
> has some dsp-like instructions, wonder whether they are compatible
> with those in ARM9E. 
>  
> thanks in advance.
>  
> tk
> _______________________________________________
> Speex-dev mailing list
> Speex-dev@xiph.org
> http://lists.xiph.org/mailman/listinfo/speex-dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url :
http://lists.xiph.org/pipermail/speex-dev/attachments/20051015/1233c97c/attachment.pgp

Hi,

I'm writing a Speex-based IP interview tool.

What's cool (and unique) about it is that since the goal is a perfect 
_recording_ of an interview, rather than a perfect real-time experience, I 
can afford to skimp on jitter buffer and redundant speech samples in favor 
of lower interactive latency ... and incorporate a speech sample 
retransmission protocol so that the receiver can ask the sender to resend 
any lost speech samples ... thus saving a guaranteed-perfect recording of 
the interview to disk.

Anyway ... to my question ...

I have built and tested the v1.1.10 _DLL_, but I would prefer to statically 
link a Speex .OBJ to my application.  The trouble with doing that is that I 
am writing the application in Assembler (my preferred implementation 
language), so I don't have a C runtime around for things like malloc ... 
which the statically-linked code apparently wants.

I could hack the source of the DLL build to create an independent .OBJ 
without C runtime dependence, but I would MUCH rather be able to use the 
standard source from the project.

Is there any supported means for creating a C runtime-independent .OBJ for 
statically linking into a non-C program?

Thanks very much!
______________________________________________________________________
Steve.

Hi,

What you want is simply to override some of the functions in misc.c. I
made it easy to do by wrapping malloc() a speex_alloc() call. Aside from
what's in misc.c, the only other thing I use are some of the math
functions like cos().

	Jean-Marc
> I have built and tested the v1.1.10 _DLL_, but I would prefer to statically
> link a Speex .OBJ to my application.  The trouble with doing that is that I
> am writing the application in Assembler (my preferred implementation 
> language), so I don't have a C runtime around for things like malloc
...
> which the statically-linked code apparently wants.
> 
> I could hack the source of the DLL build to create an independent .OBJ 
> without C runtime dependence, but I would MUCH rather be able to use the 
> standard source from the project.
> 
> Is there any supported means for creating a C runtime-independent .OBJ for 
> statically linking into a non-C program?
> 
> Thanks very much!
> ______________________________________________________________________
> Steve.
> 
> _______________________________________________
> Speex-dev mailing list
> Speex-dev@xiph.org
> http://lists.xiph.org/mailman/listinfo/speex-dev
>

Thanks Jean-Marc,
>What you want is simply to override some of the functions in misc.c. I 
>made it easy to do by wrapping malloc() a speex_alloc() call. Aside from 
>what's in misc.c, the only other thing I use are some of the math 
>functions like cos().
That makes sense.  But how does the DLL version, which is not linked to the 
C runtime, get access to C's transcendental like cos() ??

______________________________________________________________________
Steve.