2.00 DaVinci Linux Audio Driver
User's Guide
Literature Number: SPRUG98 September 2008 2 SPRUG98–September 2008 Submit Documentation Feedback Preface SPRUG98–September 2008 Read This First
About This Manual This user guide provides an overview of the audio driver by providing the driver architecture, design, and supported features. It also provides information on architecture, user Interface, and the sample applications. This user guide defines and describes the usage of user level and platform level interfaces of the ALSA Audio driver. How to Use This Manual This document includes the following Sections: • Chapter 1 - Introduction, provides an overview and supported features of the driver. • Chapter 2 - Architecture, describes the driver architecture and design concepts. • Chapter 3 - Software Interface, describes the application and driver interfaces. • Chapter 4 - Sample Applications, provides an overview about the examples provided along with the release package. Related Documentation From Texas Instruments The following documents are the reference documents from Texas Instruments. To obtain a copy of any of these TI documents, visit the Texas Instruments website at www.ti.com. • TMS320DM646x DMSoC Multichannel Audio Serial Port (McASP) User's Guide (SPRUER1) describes the operation of the multichannel audio serial port (McASP) in the TMS320DM646x Digital Media System-on-Chip (DMSoC). • TLVAIC32 Data Sheet (SLAS479B) provides the features and description of TLVAIC32. Related Documentation You can use the following document to supplement this user guide: • ALSA Project Homepage • ALSA User Space Library
SPRUG98–September 2008 Read This First 3 Submit Documentation Feedback Terms and Abbreviations www.ti.com Terms and Abbreviations The following terms and abbreviations are used in this document. Term/Abbreviation Description ALSA Advanced Linux Sound Architecture API Application Programming Interface DIT Digital Audio Interface Transmission DMA Direct Memory Access EDMA Enhanced Direct Memory Access EVM Evaluation Module PCM Pulse Code Modulation I2C Inter-Integrated Circuit I2S Inter-Integrated Sound McASP Multi Channel Audio Serial Port OSS Open Sound System TDM Time-Division Multiplexed
Trademarks DaVinci is a trademark of Texas Instruments.
4 Read This First SPRUG98–September 2008 Submit Documentation Feedback Chapter 1 SPRUG98–September 2008 Introduction
This chapter provides an overview and the supported features and constraints of the driver.
Topic ...... Page
1.1 Overview ...... 6 1.2 Features ...... 6 1.3 Constraints ...... 6
SPRUG98–September 2008 Introduction 5 Submit Documentation Feedback Overview www.ti.com
1.1 Overview The AIC32 codec transmits and receives audio data on DM700 DaVinci™HD. The AIC32 codec is connected via Multi-Channel Audio Serial Port (McASP) interface, a communication peripheral. McASP functions as a general-purpose audio serial port optimized for the needs of multi-channel audio applications. The McASP is useful for time-division multiplexed (TDM) stream, Inter-Integrated Sound (I2S) protocols, and inter component digital audio interface transmission (DIT). AIC32 supports I2S, Left/Right-Justified, DSP, and TDM Modes.
1.2 Features The ALSA Audio driver supports the following features: • ALSA framework • Simultaneous record and play back capability (full-duplex mode). • The McASP and Codec can work as slave and master or visa versa. This is not a runtime option, but a compile time option. • When Codec is the master and McASP is the slave, the driver supports 34 sample rates (from 7350 Hz - 96000 Hz). When McASP is the master and Codec is the slave, there are only two sampling rates supported (22050Hz and 44100 Hz). • Mono and stereo modes • I2S mode of operation • Interleaved access mode • Mixer support • Uses EDMA for data transfer
1.3 Constraints OSS framework is not supported by the audio driver. Formats other than I2S such as TDM, Left and Right Justified are currently not supported. Opening of the same stream (Play/Record) multiple times is not supported The audio driver will support a single input (RECORD) and single output stream (PLAY). The audio driver will not allow opening the same stream (Play/Record) multiple times concurrently.
6 Introduction SPRUG98–September 2008 Submit Documentation Feedback Chapter 2 SPRUG98–September 2008 Architecture
This chapter provides a Functional Overview and the System architecture and design aspects of the driver.
Topic ...... Page
2.1 Functional Overview ...... 8 2.2 Software Design Interfaces ...... 9
SPRUG98–September 2008 Architecture 7 Submit Documentation Feedback Functional Overview www.ti.com
2.1 Functional Overview The Advanced Linux Sound Architecture (ALSA) provides audio functionality to the Linux operating system. ALSA has the following significant features: • Efficient support for all types of audio interfaces, from consumer sound cards to professional multi-channel audio interfaces. • Fully modularized sound drivers • SMP and thread-safe design • User space library (alsa-lib) to simplify application programming and provide higher level functionality • Support for the older Open Sound System (OSS) API, providing binary compatibility for most OSS programs The system diagram is presented in Figure 2-1.
Figure 2-1. System Diagram
PCLKCR0/1/3 LOSPCP (System Ctrl Regs) (System Ctrl Regs) SYSCLK
Clock Enables LSPCLK
Peripheral I/O SPI-A/B, SCI-A Registers VBus16
Clock Enables /2
Peripheral I/O HECC-A, LIN-A Registers VBus32
Clock Enables
GPIO Peripheral Mux I/O ECAP1, EQEP1 Registers VBus32
Clock Enables
Peripheral I/O ETPWM1/.../5 + OTTO Registers VBus32 / VBUS32DP
Clock Enables
Peripheral I/O I2C-A Registers CPU-VBus16
Clock Enables
ADC CPU-VBus16 16 Ch 12-Bit ADC Registers Analog CPU & MCLA-Mem32 GPIO Mux Clock Enables
COMP 6 COMP1/2/3 Registers VBus32 / VBUS32DP
Clock Enables
DAC 10-Bit DAC1/2/3 Registers VBus32 / VBUS32DP
8 Architecture SPRUG98–September 2008 Submit Documentation Feedback www.ti.com Software Design Interfaces
2.2 Software Design Interfaces
2.2.1 ALSA Audio Applications The ALSA audio applications are compatible with the ALSA standard. They communicate with the ALSA user space library to receive/transmit audio data. Many applications that support ALSA could be downward compatible with OSS. But for this, the OSS emulation layer has to be enabled in the Linux kernel during the configuration time.
2.2.2 Mixer Applications The mixer applications control the overall behavior of the codec. These include setting of the volume in the codec and so on. This interface does not support data transfer. However, it is useful if only the control of the codec is desired.
2.2.3 ALSA Library The Advanced Linux Sound Architecture comes with a Kernel API and a library API. Application programmers should use the library API rather than the kernel API. The library offers 100% of the functionality of the kernel API, but adds major improvements in usability, making the application code simpler and better looking.
2.2.4 ALSA Kernel API The ALSA kernel API provides the basic infrastructure of ALSA and the hardware drivers. The top layer takes care of the detection of the device(s), creation of ALSA components and various destructors. The middle layer (ALSA common layer) has the device manager and provides the implementations for native ALSA modules like PCM, synth, rawmidi etc.
2.2.5 Davinci-HD ALSA Audio Driver The Davinci-HD audio base driver provides a codec-independent interface for the audio driver for OMAP processor-based platforms. It is necessary for each audio driver to implement the low-level functions to access its hardware. The driver encapsulates all the generic routines which are required to handle audio data and is codec independent in nature.
2.2.6 AIC32 Codec ALSA Driver The AIC32 component is codec specific and in turn may use the helper drivers to communicate with the actual codec. This includes the responsibilities of data transfer and control of the codec. The codec driver may expose a mixer device to give better codec specific control to the user space applications.
2.2.7 Helper Driver These are lower level helper drivers which provide APIs for access to specific communication media. This includes connectivity drivers such as McASP (for data) and I2C (for control).
SPRUG98–September 2008 Architecture 9 Submit Documentation Feedback 10 Architecture SPRUG98–September 2008 Submit Documentation Feedback Chapter 3 SPRUG98–September 2008 Software Interfaces
This chapter describes the Application Interface, Proc Interface and driver Interface for the ALSA Audio driver.
Topic ...... Page
3.1 Application Interface ...... 12 3.2 User Space Interactions...... 13 3.3 Driver Interface ...... 18
SPRUG98–September 2008 Software Interfaces 11 Submit Documentation Feedback Application Interface www.ti.com
3.1 Application Interface The application developer uses ALSA-lib, a user space library, rather than the kernel API. The library offers 100% of the functionality of the kernel API, but adds major improvements in usability, making the application code simpler and better looking. The online-documentation for the same is available at: http://www.alsa-project.org.
3.1.1 Device Interface The operational interface in /dev/ contains three main types of devices: • PCM devices for recording or playing digitized sound samples • CTL devices that allow manipulating the internal mixer and routing of the card • MIDI devices to control the MIDI port of the card, optional
Table 3-1. Device Interface Name Description /dev/snd/controlC0 Control devices (i.e. mixer, etc). /dev/snd/pcmC0D0c PCM Card 0 Device 0 Capture device /dev/snd/pcmC0D0p PCM Card 0 Device 0 Playback device
3.1.2 Proc Interface The /proc/asound kernel interface is a status and configuration interface. A lot of useful information about the sound system can be found in the /proc/asound subdirectory. Table 3-2 lists the different proc entries in /proc/asound:
Table 3-2. Proc Interface Entries Name Description cards List of registered cards version Version and date the driver was built on devices List of registered ALSA devices pcm The list of allocated PCM streams. cardX/ The card specific directory, where X = 0-7 cardX/pcm0p The directory of the given PCM playback stream. cardX/pcm0c The directory of the given PCM capture stream.
3.1.3 Commonly Used APIs Table 3-3 details some of the APIs commonly used to write an ALSA-based application.
Table 3-3. Commonly Used APIs Name Description snd_pcm_open Opens a PCM stream snd_pcm_close Closes a previously opened PCM stream snd_pcm_hw_params_any Fills params with a full configuration space for a PCM snd_pcm_hw_params_test_<
12 Software Interfaces SPRUG98–September 2008 Submit Documentation Feedback www.ti.com User Space Interactions
Table 3-3. Commonly Used APIs (continued) Name Description snd_pcm_readi Reads interleaved frames from a PCM snd_pcm_prepare Prepares PCM for use snd_pcm_drop Stops a PCM preserving pending frames snd_pcm_drain Stops a PCM preserving pending frames
3.2 User Space Interactions This section depicts the sequence of operations for a simple playback and capture application.
Figure 3-1. Sample Playback and Capture Application
User Space Audio Application Driver
1: snd_pcm_open - Open the PCM Sream (SND_PCM_STREAM_PLAYBACK)
2: snd_pcm_hw_params_set_access - Set Access Type
3: sdn_pcm_hw_params_set_format - Set the Format
4: sdn_pcm_hw_params_set_rate_near - Set the Sample Rate
5: sdn_pcm_hw_params_set_channels - Mono or Stereo
6: sdn_pcm_hw_params - Set the PCM to SETUP & PREPARED State
7: sdn_pcm_writei - Write Interleaved Data
8: sdn_pcm_close - Close the PCM Stream
Each application follows this sequence: 1. Open the audio device. 2. Set the parameters of the device. 3. Receive audio data from the device or deliver audio data to the device. 4. Close the device.
Note: User space ALSA libraries can be downloaded from www.alsa-project.org. You need to build and install the libraries before you start using the ALSA-based applications.
SPRUG98–September 2008 Software Interfaces 13 Submit Documentation Feedback User Space Interactions www.ti.com 3.2.1 A Minimal Playback Application This program opens an audio interface for playback, configures it for stereo, 16 bit, 44.1kHz, interleaved conventional read/write access. Then it delivers a chunk of random data to the audio interface and exits. This represents about the simplest possible use of the ALSA Audio API and is not meant to be a real program.
3.2.1.1 Opening the Audio Device To write a simple PCM application for ALSA, you first need a handle for the PCM device. Then you have to specify the direction of the PCM stream, which can be either playback or capture. You also have to provide some information about the configuration you would like to use, such as buffer size, sample rate, and pcm data format. So, first declare: #include
/* Handle for the PCM device */ snd_pcm_t *handle; /* This structure contains information about */ /* the hardware and can be used to specify the */ /* configuration to be used for the PCM stream. */ snd_pcm_hw_params_t *params; The most important ALSA interfaces to the PCM devices are the plughw and the hw interfaces. If you use the plughw interface, you need not care much about the sound hardware. If your soundcard does not support the sample rate or sample format you specify, data will be automatically converted. This also applies to the access type and the number of channels. With the hw interface, you have to check whether your hardware supports the configuration you would like to use. Otherwise, you can use the default interface for playback with this code: /* Name of the PCM device, like plughw:0,0 */ /* The first number is the number of the soundcard, */ /* the second number is the number of the device. */ static char *device = "default"; /* playback device */ Now open the PCM device: /* Open PCM. The last parameter of this function is the mode. */
rc = snd_pcm_open(&handle, "default", SND_PCM_STREAM_PLAYBACK, 0); if (rc < 0) { fprintf(stderr, "unable to open pcm device: %s\n", snd_strerror(rc)); exit(1); }
3.2.1.2 Setting the Parameters of the Device Now you initialize the variables and allocate the hwparams structure: /* Allocate the snd_pcm_hw_params_t structure on the stack. */
snd_pcm_hw_params_alloca(¶ms); Before you can write PCM data to the soundcard, you have to specify the access type, sample format, sample rate, number of channels, number of periods and period size. First, you initialize the hwparams structure with the full configuration space of the soundcard, for example: /* Init hwparams with full configuration space */
snd_pcm_hw_params_any(handle, params);
14 Software Interfaces SPRUG98–September 2008 Submit Documentation Feedback www.ti.com User Space Interactions Now configure the desired parameters. For this example, assume that the soundcard can be configured for stereo playback of 16-bit little-endian data, sampled at 44100 Hz. Therefore, you restrict the configuration space to match this configuration only. The access type specifies the way in which multi-channel data is stored in the buffer. For Interleaved access, each frame in the buffer contains the consecutive sample data for the channels. For 16-bit stereo data, this means that the buffer contains alternating words of sample data for the left and right channel. /* Set access type. */
snd_pcm_hw_params_set_access(handle, params, SND_PCM_ACCESS_RW_INTERLEAVED);
/* Set sample format */
snd_pcm_hw_params_set_format(handle, params, SND_PCM_FORMAT_S16_LE);
/* Set sample rate. If the exact rate is not supported */ /* by the hardware, use nearest possible rate. */
val = 44100; snd_pcm_hw_params_set_rate_near(handle, params, &val, &dir);
/* Set number of channels */
snd_pcm_hw_params_set_channels(handle, params, 2); Now apply the configuration to the PCM device pointed to by handle and prepare the PCM device: /* Apply HW parameter settings to PCM device and prepare device.*/ rc = snd_pcm_hw_params(handle, params); if (rc < 0) { fprintf(stderr, "unable to set hw parameters: %s\n", snd_strerror(rc)); exit(1); }
3.2.1.3 Writing Data to the Device After the PCM device is configured, you can start writing PCM data to it. The first write access starts the PCM playback. For interleaved write access, use this function: /* Write some junk data to produce sound. */
rc = snd_pcm_writei(handle, buffer, frames); if (rc == -EPIPE) { /* EPIPE means underrun */ fprintf(stderr, "underrun occurred\n"); snd_pcm_prepare(handle); } else if (rc < 0) { fprintf(stderr, "error from writei: %s\n", snd_strerror(rc)); } else if (rc != (int)frames) { fprintf(stderr, "short write, write %d frames\n", rc); } After the PCM playback is started, need to ensure that your application sends enough data to the soundcard buffer. Otherwise, a buffer under-run will occur. After such an under-run has occurred, snd_pcm_prepare should be called.
3.2.1.4 Closing the Device After the data has been transferred, the device needs to be closed by calling: snd_pcm_close(handle);
SPRUG98–September 2008 Software Interfaces 15 Submit Documentation Feedback User Space Interactions www.ti.com 3.2.2 A Minimal Record Application This program opens an audio interface for capture, configures it for stereo, 16 bit, 44.1 kHz, and interleaved conventional read/write access. Then its reads a chunk of random data from the interface, and exits. It is not intended to be a real program. Note that it is not possible to use one pcm handle for both playback and capture. So you have to configure two handles if you want to access the PCM device in both directions.
3.2.2.1 Opening the Audio Device To write a simple PCM application for ALSA, you first need a handle for the PCM device. Then you have to specify the direction of the PCM stream, which can be either playback or capture. You also have to provide some information about the configuration you would like to use; such as buffer size, sample rate, and pcm data format. So, first declare: #include
/* Handle for the PCM device */ snd_pcm_t *handle; /* This structure contains information about */ /* the hardware and can be used to specify the */ /* configuration to be used for the PCM stream. */ snd_pcm_hw_params_t *params; The most important ALSA interfaces to the PCM devices are the plughw and the hw interface. If you use the plughw interface, you need not care much about the sound hardware. If your soundcard does not support the sample rate or sample format you specify, your data will be automatically converted. This also applies to the access type and the number of channels. With the hw interface, you have to check whether your hardware supports the configuration you would like to use. Otherwise, you can use the default interface for playback by: /* Name of the PCM device, like plughw:0,0 */ /* The first number is the number of the soundcard, */ /* the second number is the number of the device. */ static char *device = "default"; /* playback device */ Now we can open the PCM device: /* Open PCM. The last parameter of this function is the mode. */
rc = snd_pcm_open(&handle, "default", SND_PCM_STREAM_CAPTURE, 0); if (rc < 0) { fprintf(stderr, "unable to open pcm device: %s\n", snd_strerror(rc)); exit(1); }
3.2.2.2 Setting the Parameters of the Device Now you initialize the variables and allocate the hwparams structure with the following: /* Allocate the snd_pcm_hw_params_t structure on the stack. */
snd_pcm_hw_params_alloca(¶ms); Before you can write PCM data to the soundcard, you have to specify the access type, sample format, sample rate, number of channels, number of periods and period size. First, you initialize the hwparams structure with the full configuration space of the soundcard as follows: /* Init hwparams with full configuration space */
snd_pcm_hw_params_any(handle, params);
16 Software Interfaces SPRUG98–September 2008 Submit Documentation Feedback www.ti.com User Space Interactions Now, configure the desired parameters. For this example, assume that the soundcard can be configured for stereo playback of 16-bit little-endian data, sampled at 44100 Hz. Therefore, you restrict the configuration space to match this configuration only. The access type specifies the way in which multi-channel data is stored in the buffer. For Interleaved access, each frame in the buffer contains the consecutive sample data for the channels. For 16-bit stereo data, this means that the buffer contains alternating words of sample data for the left and right channel. /* Set access type. */
snd_pcm_hw_params_set_access(handle, params, SND_PCM_ACCESS_RW_INTERLEAVED);
/* Set sample format */
snd_pcm_hw_params_set_format(handle, params, SND_PCM_FORMAT_S16_LE);
/* Set sample rate. If the exact rate is not supported */ /* by the hardware, use nearest possible rate. */
val = 44100; snd_pcm_hw_params_set_rate_near(handle, params, &val, &dir);
/* Set number of channels */
snd_pcm_hw_params_set_channels(handle, params, 2); Now apply the configuration to the PCM device pointed to by handle and prepare the PCM device: /* Apply HW parameter settings to PCM device and prepare device.*/ rc = snd_pcm_hw_params(handle, params); if (rc < 0) { fprintf(stderr, "unable to set hw parameters: %s\n", snd_strerror(rc)); exit(1); }
3.2.2.3 Reading Data from the Device After the PCM device is configured, you can start reading PCM data from it. The first read access starts the PCM capture. For interleaved write access, use this function: /*Read some junk data to produce sound. */
rc = snd_pcm_readi(handle, buffer, frames); if (rc == -EPIPE) { /* EPIPE means overrun */ fprintf(stderr, "overrun occurred\n"); snd_pcm_prepare(handle); } else if (rc < 0) { fprintf(stderr, "error from read: %s\n", snd_strerror(rc)); } else if (rc != (int)frames) { fprintf(stderr, "short read, read %d frames\n", rc); } After the PCM capture is started, you have to make sure that your application reads data in time from the soundcard buffer. Otherwise, a buffer over-run will occur. After such an over-run has occurred, snd_pcm_prepare should be called.
3.2.2.4 Closing the Device After the data has been transferred, the device needs to be closed by calling: snd_pcm_close(handle);
SPRUG98–September 2008 Software Interfaces 17 Submit Documentation Feedback Driver Interface www.ti.com 3.3 Driver Interface This section describes the various function entry points into the various platform specific drivers of the audio driver. The platform specific codec drivers are required to implement the mentioned entry points and register with the audio driver using audio_register_codec and on module exit, unregister the codec using the audio_unregister_codec function. The platform specific audio driver is required to register itself with the kernel to let the kernel know about its availability.
3.3.1 Description The platform-specific ALSA audio driver is instantiated as a platform_driver. The driver is expected to implement the following function hooks in order for the core ALSA layer to probe it and handle correctly: probe () This is the first function to be called from the core ALSA layer. It checks whether the real device is present or not. After that, it registers the audio driver as a new sound card and specifies the various functions which can be performed on the actual underlying codec. remove () Used for cleanup. suspend () Power management hook that is called for the codec to shut down the related operations, if required. This function is called once all the transfers are suspended. resume () Power management hook that is called for the codec to start up and the related operations, if required. It is only after this function is called that all the transfers are resumed. Both capture and playback side PCM functions need to be registered. Following is a list of all the functions which could be implemented for a specific codec: open () Codec initialization. The first function to be called during the initialization of the communication paths and to do the initial stuff required for the codec to become operational. Codec is assumed to be operational at the end of this stage. close () Codec clean up operations are done here. This function is the last to be called and is to be designed to request all the communication paths to shutdown. Codec is no longer operational at the end of this stage. ioctl () This is used for any special action to pcm ioctls. But usually you can pass a generic ioctl callback, snd_pcm_lib_ioctl. hw_params This is called when the hardware parameter (hw_params) is set up by the application; that is, once when the buffer size, the period size, the format, etc. are defined for the pcm substream. Many hardware setups should be done in this callback, including the allocation of buffers. hw_free This is called to release the resources allocated via hw_params. Prepare This callback is called when the PCM is prepared. You can set the format type, sample rate, etc. here. The difference from hw_params () is that the prepare callback is called at each time snd_pcm_prepare () is called, i.e. when recovered after under-runs, etc. Trigger This data transfer hook is called for transmits and receives to send/receive data.
18 Software Interfaces SPRUG98–September 2008 Submit Documentation Feedback www.ti.com Driver Interface Pointer This data transfer hook is used to query the codec driver as to the location of the transfer of the current buffer.
3.3.2 States On the driver initialization, the various data structures are initialized, all the devices are registered, and basic operations to make the driver ready for operation are done. It is the combination of both the codec's driver initialization along with the audio driver's initialization that the audio driver completes entry into the initialized state. When an application initiates an open, the codec is configured to default settings. Further configurations are done based on specific requests sent to the driver. These would include the volume control settings, the sampling rate information, whether the data is to be read/played to the device etc. On completion of the default configuration of the driver, the driver enters in to ready state where the driver is ready for data transfer. The application can now initiate data read/write operations based on which DMA is used to transfer the data to or from the codec. The operational stage is thus stated to be reached where transfers are operational. This DMA data transfer operation is done asynchronously. Once the data transfer is completed, the driver goes back into its ready state awaiting more data transfer. Once the application is completed, it initiates a close; at which time, if the driver is in operational mode, current pending transfers are emptied and it moves to ready stage. The driver then transitions to the initialized state after the codec is shutdown from the ready state. During the operational or ready stage, if a suspend request is received the driver locks out any further data transfers and enters into suspended state after shutting down the codec. On resumption, the driver moves into ready state after re-initializing the codec, awaiting further data transfers to happen. When the driver is being shutdown, the data structures, if any, are cleaned up and the driver exits.
SPRUG98–September 2008 Software Interfaces 19 Submit Documentation Feedback 20 Software Interfaces SPRUG98–September 2008 Submit Documentation Feedback Chapter 4 SPRUG98–September 2008 Sample Applications
This chapter describes the sample application provided along with the package. The binary and the source for these sample applications are available in the Examples directory of the Release Package folder.
Topic ...... Page
4.1 Multi-threaded Loop Back Application ...... 22 4.2 Example Application for S/PDIF ...... 22
SPRUG98–September 2008 Sample Applications 21 Submit Documentation Feedback Multi-threaded Loop Back Application www.ti.com
4.1 Multi-threaded Loop Back Application This sample application records and plays back the data simultaneously from the audio device. Connect a line-in cable from the PC (where the audio is playing) to the EVM and execute the application as follows: ./audio_loopback This should record the audio data and play it back through Line out/Head phone.
4.2 Example Application for S/PDIF
4.2.1 S/PDIF Playback The sample application for S/PDIF performs the following: 1. Opens the audio file supplied as the argument in read mode. 2. Opens the audio device (S/PDIF) in write mode. 3. In a loop: a. Read data from the audio file b. Write the same data to S/PDIF device 4. Press Ctrl C to exit. The following are the pre-requisites for this application: • A raw audio file to be used for playback • S/PDIF related h/w connected with DM6467 EVM Procedure: 1. Connect the optical cable and related S/PDIF h/w to EVM. 2. Switch on the DM6467 EVM. 3. Run the sample application (./saPlaySpdif <
4.2.2 S/PDIF Loopback The sample application for S/PDIF performs the following: 1. Opens the normal audio device in read mode. 2. Opens the audio device (S/PDIF) in write mode. 3. In a loop: a. Read data from the normal audio device b. Write the same data to S/PDIF audio device 4. Press Ctrl C to exit. The following are the pre-requisites for this application: • One PC for playing any recorded song at 44.1 or 48 KHz. • S/PDIF related h/w connected with DM6467 EVM
22 Sample Applications SPRUG98–September 2008 Submit Documentation Feedback www.ti.com Example Application for S/PDIF Procedure: 1. Connect the PC audio out cable (Y-cable) to the Line-in of the DM6467 EVM. 2. Connect the optical cable and related S/PDIF h/w to EVM. 3. Switch on the DM6467 EVM. 4. Play the pre-recorded song on the PC. 5. Run the sample application (./audio_spdif_loopback) on the EVM. Expected Output: The song should be played accurately on the speakers connected with S/PDIF.
SPRUG98–September 2008 Sample Applications 23 Submit Documentation Feedback