mp4-sa-> sfront reference manual-> developers intro

From The sfront Reference Manual by John Lazzaro and John Wawrzynek.

Part II/1: Developing With Sfront

Sections

Introduction

Part II of the sfront reference manual is written for two audiences:

  • People who are writing end-user audio applications, such as sequencers, sound design tools, and streaming audio clients, and who want to use sfront instead of writing a Structured Audio decoder themselves.
  • People who are using sfront directly as a command-line tool, and want to add new functions to the program, such as audio output support for an unsupported operating system.

In this chapter, we introduce both audiences to developing code for sfront. We begin with a description of how to use the off-the-shelf sfront in simple end-user applications, and show the limits of this approach.

We then introduce the driver interface, a mechanism for adding application-specific code to sfront. The driver interface offers a more flexible way for application developers to use sfront in their programs. In addition, people wishing to add a new general-purpose feature to sfront can often use the driver interface, instead of directly modifying the sfront sources.

The chapter ends with a roadmap for the following two chapters, which describe the driver interface in detail. These chapters describe control drivers, which lets user C code directly control the sound generation process, and audio drivers, which handle moving audio-rate streams into and out of the sound engine.

Sfront in Applications

Some end-user applications have simple requirements for a sound-generation engine. For example, consider a program that is a graphical score editor, that lets users manually enter traditional music notation onto staves.

A common feature of score editors is an audio preview function, that lets users listen to rendered versions of the audio. The right panel shows a C language code fragment that implements the feature, for Linux systems.

The code on the right panel assumes that the application program has created a SASL file ss, that contains the notes values and durations from the graphical score in SASL notation.

The code also assumes that the program has created a SAOL file, sl, to orchestrate the score. Typically, the application will have a library of SAOL programs available, and includes a user-interface for mapping different musical lines to SAOL instruments.

The code on the right panel uses the ANSI C library call system() to execute other programs. As an ANSI library function, this method should work with any ANSI-compliant C compiler. However, the commands to be executed must exist on the platform.

Three programs are executed in sequence:

  1. sfront. The generated SAOL and SASL files are converted into a C file (sa.c, the default name). lity funcition.

    In order to request MIDI and SASL events, the control driver needs to know details about the SAOL file, such as the names of instruments and variables. The next section of the control driver chapter describes the data structures and service functions that inform the SAOL program and the run-time environment.

    The final section of the control driver chapter describes the calling syntax and semantics for the five functions listed above. It also describes the registration process, by which the sfront program learns the characteristics of a new control driver.

    Next section: Part II/2B: Control Drivers Data Structures

Example

sfront -cin fstr -bitc t.mp4 
       -aout linux -playback
gcc -O3 sa.c -o sa
./sa


Notes:

[1] The control driver is 
specified by "-cin fstr"

[2] We use -bitc instead of
-bit to tell sfront to not
compile in the SA_access_unit
data into sa.c.

[3] We use -aout linux -playback
to tell sfront to send its audio
directly to the soundcard, instead
of its default behavior of writing
an output.wav file.

Functions in Control Drivers

/* called at program start */

int csys_setup(void);

/* called each k-cycle */

int csys_newdata(void);

/* called each kcycle that */
/* csys_newdata() requests */

int csys_saslevent( ... );
int csys_midievent( ... );

/* called at program end */

void csys_shutdown(void);
mp4-sa-> sfront reference manual-> control driver overview

Copyright 1999 John Lazzaro and John Wawrzynek. ./usr/share/doc/sfront/html/sfman/devel/intro/0000755000000000000000000000000010162670555021455 5ustar rootroot00000000000000./usr/share/doc/sfront/html/sfman/devel/intro/index.html0000644000000000000000000002775210162670555023467 0ustar rootroot00000000000000 Sfront Reference Manual: Part II/1: Developing With Sfront
mp4-sa-> sfront reference manual-> developers intro

From The sfront Reference Manual by John Lazzaro and John Wawrzynek.

Part II/1: Developing With Sfront

Sections

Introduction

Part II of the sfront reference manual is written for two audiences:

  • People who are writing end-user audio applications, such as sequencers, sound design tools, and streaming audio clients, and who want to use sfront instead of writing a Structured Audio decoder themselves.
  • People who are using sfront directly as a command-line tool, and want to add new functions to the program, such as audio output support for an unsupported operating system.

In this chapter, we introduce both audiences to developing code for sfront. We begin with a description of how to use the off-the-shelf sfront in simple end-user applications, and show the limits of this approach.

We then introduce the driver interface, a mechanism for adding application-specific code to sfront. The driver interface offers a more flexible way for application developers to use sfront in their programs. In addition, people wishing to add a new general-purpose feature to sfront can often use the driver interface, instead of directly modifying the sfront sources.

The chapter ends with a roadmap for the following two chapters, which describe the driver interface in detail. These chapters describe control drivers, which lets user C code directly control the sound generation process, and audio drivers, which handle moving audio-rate streams into and out of the sound engine.

Sfront in Applications

Some end-user applications have simple requirements for a sound-generation engine. For example, consider a program that is a graphical score editor, that lets users manually enter traditional music notation onto staves.

A common feature of score editors is an audio preview function, that lets users listen to rendered versions of the audio. The right panel shows a C language code fragment that implements the feature, for Linux systems.

The code on the right panel assumes that the application program has created a SASL file ss, that contains the notes values a