[Live-devel] embedded use of live classes?
Ross Finlayson
finlayson at live.com
Sun Feb 8 15:35:33 PST 2004
>we are investigating the live.com media classes for usage in an embedded
>environment; XScale running Linux.
Leon,
The "LIVE.COM Streaming Media" code was specifically intended for use
within embedded systems, and several organizations have already used it in
embedded environments.
>- Floating point operations are very expensive, and having many of them
>in the signal path (i.e. recurring often and repeatedly) is bad for
>performance.
Floating point is used in a few places in the code, but not
extensively. It's currently used mostly for some statistics gathering each
time a network packet is sent or received. (Some of these uses of floating
point could perhaps be replaced with fixed point if necessary.) So, even
if the host environment uses software for floating point emulation, there
is unlikely to be a significant performance impact.
>- Limited memory and performance available.
>- No user that can solve errors or read error messages.
To run the LIVE.COM code within a custom environment (such as an embedded
system), people typically develop their own subclasses of the
"UsageEnvironment" and "TaskScheduler" abstract base classes (see
"UsageEnvironment/include/UsageEnvironment.hh"). Note that the released
source code includes one particular implementation of these classes - the
"BasicUsageEnvironment" library. This uses the Unix (or Windows) console
for I/O, and so allows you to develop applications that you can run on
conventional OSs - e.g., for prototyping and debugging. But then, by using
your own custom subclasses of "UsageEnvironment" and "TaskScheduler" (i.e.,
instead of "BasicUsageEnvironment" and "BasicTaskaScheduler"), the same
code will run on your custom (e.g., embedded) environment.
>Depending on our findings, we will either develop our own minimal
>implementation, or use live.com classes and change them to our needs. In
>either case, we would like to work in an open way; (L)GPL.
In most cases you should not need to make many changes to the LIVE.COM code
proper. Instead, the code was designed so that - in most cases - new
functionality can be added by subclassing. Then, you can link your new
custom code with the existing libraries (and you will not be under any
obligation to release the source code to your new custom code).
However, if find that you need to make changes/improvements to the LIVE.COM
code proper - and these changes are of general applicability - then please
post them to this mailing list, so they can be included in future releases.
>Is live.com available as an CVS project, or will it be in the future?
No - for a code base as small as this, CVS tends to be more trouble than
it's worth, especially since 99% of the time that people want to use CVS,
it's just to download the latest version of the complete source
code. (Note that you can easily see what's changed in each new release by
running "diff -r".)
Ross Finlayson
LIVE.COM
<http://www.live.com/>
More information about the live-devel
mailing list