2006-09-19 12:28:12 About the linphone
yang yang (UNITED STATES)
Message: 13638 I compiled the linphone and want to try it.
But I cannot find any useful information on how to test it.If I want to try it to call the Host PC's linphone, what should do before test?
Is there any suggestion?
Thanks forward.
QuoteReplyEditDelete
2006-09-19 13:09:56 RE: About the linphone
Jerry Zeng (CHINA)
Message: 13642 Hi yang,
Take a look at this: http://docs.blackfin.uclinux.org/doku.php?id=linphone
-Jerry
QuoteReplyEditDelete
2009-01-06 10:54:11 RE: About the linphone
Rob Maris (GERMANY)
Message: 67481
The above path does not work (as of 2008...). This seems to be the correct URL:
http://docs.blackfin.uclinux.org/doku.php?id=uclinux-dist:linphone
QuoteReplyEditDelete
2009-01-06 11:30:51 RE: About the linphone
Mike Frysinger (UNITED STATES)
Message: 67483
tthat's because documents move around ... if you get a not found, just use the search function
QuoteReplyEditDelete
2009-01-06 13:39:50 RE: About the linphone
Rob Maris (GERMANY)
Message: 67489 I'm not sure about the current state of LinPhone for Blackfin. The document referred to above has its last revision as of March 2008. Further, I don't find a project "Linphone" on the projects page of KOOP. The above URL is referred to as a project, but only documentation is listed. I'd like to join the project, but don't know about who is who, to state it simple. At this time I'm going to review necessary resources for this project, especially flash memory resources - I guess that kernel, root file system and linphone resources fit within 4 MB, the size of the STAMP kit. It is my goal to first have Linphone working on a bluetechnix BF537 module and add DTMF detection to it. Rob
QuoteReplyEditDelete
2009-01-06 14:44:04 RE: About the linphone
Robin Getz (UNITED STATES)
Message: 67492
Rob:
linphone has been integrated into the uClinux-dist - there isn't a seperate project anymore.
People are shipping it in their production products...
-Robin
QuoteReplyEditDelete
2009-01-06 15:25:44 RE: About the linphone
Rob Maris (GERMANY)
Message: 67493 Thanks, Robin for your hint. I still was aware of the fact that Linphone 2.0.1 is shipped with the distribution, but nevertheless considered a project repository out there, I mean a repository of blackfin specific resources. Apparently the porting has been made possible without much necessary porting effort (which is hard to believe). Rob
QuoteReplyEditDelete
2009-01-06 15:39:38 RE: About the linphone
Mike Frysinger (UNITED STATES)
Message: 67495
the only changes we make to linphone are bugs in the code. there's nothing Blackfin specific about it.
QuoteReplyEditDelete
2009-01-07 02:39:45 RE: About the linphone
Rob Maris (GERMANY)
Message: 67505 Nothing specific to Blackfin? I'd suggest that code which performs compression, echo cancellation etc. requiring digital signal processing had to be converted to Blackfin DSP-specific code. When this is not the case, apparently the standard code processing speed be sufficient to run all these stuff? - Rob.
QuoteReplyEditDelete
2009-01-07 02:44:28 RE: About the linphone
Mike Frysinger (UNITED STATES)
Message: 67506
it's the compiler that converts C code into Blackfin assembly
QuoteReplyEditDelete
2009-01-07 07:40:42 RE: About the linphone
Robin Getz (UNITED STATES)
Message: 67552
Rob:
The code which performs the compression, echo cancellation, is not part of linphone - it is (mostly) in the speex library (which linphone uses).
While Mike is correct - there is no otimized assembly files in linphone (even for the G.711 codec - which is pretty trival, and doesn't need the performance boost), there is lots of optimized assembly in speex which does the echo cancellation, and compression (speex), and in the libbfgdots (G.729).
You were just asking the wrong question.
-Robin
QuoteReplyEditDelete
2009-01-12 07:29:49 RE: About the linphone
Rob Maris (GERMANY)
Message: 67797
er, I tried to activate Linphone in menuconfig according to the docs, but I don't find an entry, even not "blackfin canned demos".
Distro package: 2008R1.5-RC3 (contains kernel directory linux-2.6.x)
menuconfig has been configured for stamp-537 and shows "Linux Kernel v2.6.22.19 Configuration".
Thanks for any help.
Rob
QuoteReplyEditDelete
2009-01-12 07:33:45 RE: About the linphone
Mike Frysinger (UNITED STATES)
Message: 67798
you're looking in the kernel menuconfig, not the user/vendor settings
QuoteReplyEditDelete
2009-01-12 08:15:49 RE: About the linphone
Rob Maris (GERMANY)
Message: 67804
Thanks, Mike, for the quick response. You're right. At this time I was not aware of the hierarchical structure of uClinux' menuconfig and it extended nature (contrary to standard Linux). Off-topic: I'd consider to write a tiny "migration" document for those familiar with standard (embedded) Linux ports - if not already present.
Robin: thanks for giving some more detail regarding the linphone related porting efforts.
Rob
QuoteReplyEditDelete
2009-01-12 08:19:43 RE: About the linphone
Mike Frysinger (UNITED STATES)
Message: 67806
what exactly would you call "standard embedded linux ports" ? imo, there is no such thing.
QuoteReplyEditDelete
2009-01-12 08:31:47 RE: About the linphone
Rob Maris (GERMANY)
Message: 67809
Formally, you're right. I only preferred to refer to linux for embedded devices with MMU contrary to Linux on desktops, since the environment is (however) another one... - Rob
QuoteReplyEditDelete
2009-03-20 05:03:31 RE: About the linphone
Rob Maris (GERMANY)
Message: 71296
The code which performs the compression, echo cancellation, is not part of linphone - it is (mostly) in the speex library (which linphone uses).
While Mike is correct - there is no otimized assembly files in linphone (even for the G.711 codec - which is pretty trival, and doesn't need the performance boost), there is lots of optimized assembly in speex which does the echo cancellation, and compression (speex), and in the libbfgdots (G.729).
-Robin
---
From the speex manual:
"The filtering functions filter_mem16() and iir_mem16() are implemented in the direct form II transposed (DF2T).
However, for architectures based on multiply-accumulate (MAC), DF2T requires frequent reload of the accumulator, which
can make the code very slow. For these architectures (e.g. Blackfin and Coldfire), a better approach is to implement those
functions as direct form I (DF1), which is easier to express in terms of MAC."
A quick investigation shows that filters.c, containing these functions, are in original/unmodified state (2006). Hence, Blackfin with gcc provides enough "brute processing power" in order to do the filter functions without bottlenecks OR the compiler recognizes MAC coding lines as such and makes efficient DSP code out of it?
- Rob