style, not high efficiency. For our design objective of a
streaming implementation, SAOLC has several shortcomings in terms of I/O, memory and error handling,
which will be addressed below.
A Philips IREF board with a TriMedia TM1000 DSP
(100MHz) and 8MB of external SDRAM is used as the
host platform. The main differences between a file-I/O
based decoder and an embedded streaming decoder are
in the handling of data-I/O, memory and errors.
4.1 I/O Handling
In a data-driven, non-preemptive multitasking environment, task scheduling is synchronized at function
calls for data I/O. For this reason, a streaming component should retrieve and output data in a blockwise manner. One of the first steps for optimizing the
SAOLC reference was replacing each one of the many
fread/fwrite commands by calls to functions accessing
the component's I/O buffers. These buffers are retrieved in the component's main processing loop from
the FIFO queues provided by the operating system.
SA decoder
input output
packets of SA- buffer SA buffer,.packets of raw
bitstream data decoder PCM data
FIFO FIFO
4.2 Memory Handling
Memory handling plays a minor role on host platforms
offering a large amount of RAM with additional virtual memory. In case of embedded systems, it becomes a major aspect, especially when other components share the same platform in parallel. This is even
more critical for SA, since as opposed to perceptual audio decoders like AC-3 or AAC, the memory requirements for a streaming SA decoder cannot be known
in advance. As the decoding algorithm is not fixed
but data-dependant, memory must be dynamically allocated and freed at runtime.
In the memory allocation scheme employed by the
SAOLC reference, blocks as small as 8 bytes are allocated dynamically. This is very inefficient, since for
such small blocks the additional memory required for
memory management is in the same order of magnitude. Many of these small allocation calls could be removed in the streaming implementation by using local
variables (i.e. stack space) instead. In cases where the
available memory on the host platform is still not large
enough, the streaming decoder may actually have to
stop decoding the current stream. However, it should
never exit its processing loop.
4.3 Error Handling and Reporting
Error handling and reporting for the streaming SA decoder had to be adapted to match the requirements
of the streaming architecture. As the appropriate reactions to an error differ from one application to the
other, the only thing a component should do is reporting it to the application by calling the error callback
function. It is then up to the application to decide how
to react. Besides printing an error message, it could invoke a stop routine, call instanceConfig() for changing the properties of the component, or simply return
without any reaction.
Whenever the SAOLC reference decoder detects a
fatal error, it exits and leaves it to the operating system to perform the cleanup. In an embedded system,
a component should never exit its processing loop except on request by the application. All memory that
was allocated by a component must also be freed by
the component. This implies, that the design of the
memory management has to be done with a great deal
of care to prevent memory leakage. The component
has to guarantee that all steps for freeing memory and
resetting the component-specific values are taken without affecting concurrent components.
4.4 Computation Load
Similar to the case of memory requirements, information about the complexity of the SA content is not
available when the streaming decoder is initialized.
The fact that a worst-case scenario is difficult to anticipate makes it necessary to find solutions in cases
when the CPU load is too high to guarantee real-time
decoding. The SA standard offers two ways for graceful degradation of the synthesis process in case that
the terminals performance is not high enough to guarantee real-time output. One possibility is using the
cpuload parameter (ISO, 1999, 5.8.6.8.17), which allows for dynamic voice-stealing in an orchestra. To
make use of this parameter, the host processor needs
to monitor the current CPU load as a percentage
of its real-time capability. In an overload situation,
it may drop certain components of the orchestra as
indicated by the content authors. The second possibility is using the highpriority flag (ISO, 1999,
5.7.3.3.7) for SASL score events. Sound events with
the highpriority flag cleared may be prematurely
terminated if resources are not available for scheduling
an event for which the highpriority flag is set.
As long as there is no de-facto decoder reference
that both content authors and decoder implementors
agree on, such measures cannot be circumvented, even
though they contradict SA's objective to achieve normative reproduction quality. As long as computation
power is not as unbounded as artistic expression, the
implementation of mechanisms for graceful degrada
0
