NOTICE: The Processors Wiki will End-of-Life on January 15, 2021. It is recommended to download any files or other content you may need that are hosted on processors.wiki.ti.com. The site is now set to read only.
DA8xx PA/F Integration tips
Contents
Audio sample-size[edit]
The audio sample-size is an indication of the magnitude of the audio sample data on each channel. The samsiz
variable is used by the ASP Algorithm to indicate the magnitude of the audio data on each channel. For algorithms like Bass Management, the magnitude of the SUB (subwoofer) channel can exceed 0 dB. The ASP Algorithm must provides the audio sample-size information so that the audio data samples can be adjusted during the encode process (conversion from floating-point to fixed-point) to ensure that no clipping of audio data occurs. The unit of the audio sample-size register is in 0.5 dB step. The audio sample-size information should not be written directly, but appended to the already present sample-size for each channel. If the audio level generated by ASP Algorithm is expected to never exceed 0 dB and an external entity (e.g., a microcontroller) adjusts the DSP’s output levels to ensure that no clipping occurs, then setting the audio sample-size register in the ASP Algorithm is not necessary.
How to set the audio sample-size register?[edit]
The *samsiz
element of the AudioFrameData
structure is a pointer to an array of size M, where M is the maximum number of channels.
samsiz = pAudioFrame->data.samsiz; // Audio size
Each element of the array is an audio sample-size register that is used to represent the theoretical maximum value that an audio channel can reach after the ASP has operated on it. The audio sample-size registers represent values in decibels in units of 0.5 dB. That is, the audio size registers are in Q1 format. For example, the bit pattern 0x0004 represents the value 2 dB.
Example1: In EQU example, max gain applied to all the channels is tracked and samsiz is updated accordingly so that no attenuation happens in analog domain. For all available channels, the samsiz is set as: For channel i; the audio size is set as:
samsiz[i] += 2 * 20 *log10 (maxgain);
The multiplication by 2 is because the audio size represetation is in Q1 format; ie, in units of 0.5dB.
Example2: Generating Centre channel from Left and Right channels:
Denoting the i
th sample on the left, center, and right channels as left[i]
, cntr[i]
,and rght[i]
respectively, the center channel is calculated as:
cntr[i] = ccScale * (left[i] + rght[i]);
where ccScale
is a scale factor. Assuming that the i
th sample on the left and right channels, left[i]
and rght[i]
, have the same maximum possible value (size), then the corresponding sample for the center channel cntr[i]
, can be twice as large as left[i]
(or rght[i]
).
The value of "twice" is equivalent to 6 dB. The multiplication of 6 by the value 2, resulting in:
samsiz[PAF_CNTR] = 2*6 + samsiz[PAF_LEFT];
Recommendation for Memory usage[edit]
Placement of buffers in IRAM/L3RAM/SDRAM[edit]
DA8xx device DSP internal memory consists of L1P, L1D and L2 cache memory. The internal memory configuration is:
- L1P memory includes 32KB of RAM. The DSP program memory controller allows to configure part or all of the L1P RAM as normal program RAM or as cache.
- L1D memory includes 32 KB of RAM. The DSP data memory controller (DMC) allows to configure part of the L1D RAM as normal data RAM or as cache.
- L2 memory includes 256 KB of RAM. The DSP unified memory controller (UMC) allows to configure part or all of the L2 RAM as normal RAM or as cache.
- L2 memory also includes 1024 KB of ROM.
This device also offers an on-chip 128-KB shared RAM, apart from the internal memories. This shared RAM is referred to as L3RAM in PA/F context. Access to L3RAM happens via cache. This device has two external memory interfaces that provide multiple external memory options accessible by the CPU and master peripherals:
- EMIFA: 16-bit SDRAM with 128-MB address space
- EMIFB: 32-/16-bit SDRAM with up to 256-MB SDRAM address space
See the RAM usage report in SDK for information on the memory usage in each feature set. This should give a feel of how much of IRAM/L3RAM is free for use by custom ASPs. Since the device has cache based architecture, it is recommended to make use of L3RAM and SDRAM wherever possible except for performance critical applications.
It is also recommended to set the memTab
parameters as configurable via the IAlg_Config
structure; so that placement of buffers can be changed init-time.
Scratch Memory Usage[edit]
ASPs may use some scratch memory whose contents need not be maintained across the decode processing calls. Hence this memory can be shared among other algorithms active in the system. The PA/F allocates a scratch memory equal to the maximum scratch requirement of all algorithms present in the chain (This is approx 8K in the PA SDK, see memory footprint of each featureset for exact information). If scratch requirement of the custom ASP falls within this maximum; no additional scratch allocation happens for the custom ASP, otherwise the maximum scratch allocated is as per the custom ASP. Setting memTab
attribute to IALG_SCRATCH
takes care of this.
Adding more channels ( > 8 )[edit]
How to add more channels in the system?[edit]
By default PA SDK has support for 12 channels. See PA Reference Guide for details on the supported channels and paf-hd.pdf for additional channel definitions. In order to add more channels in the system following changes are required:
- Allocate frame buffers for additional channels by changing number of channels in
pa/f/s19/I14/params.c
const SmInt PAF_AST_params_numchan_PAi[1] = { 12, };
- Modify
ipce_i14.c
to set the number of output channels
#define IPCE_OUTPUT_NUMCHAN 12
- Modify
pa/asp/std/ccm.c
to select the channels used - Add
ccm.c
to final project. - Update Channel configuration for additional channels as explained in section Channel Configuration Settings.
How to test 10ch output on DA8xx EVM?[edit]
Only 8 channels can be output from the EVM simultaneously. But more than 8 channels can be tested on the DA8xx EVM using channel mapping alpha commands. See PA Reference Guide for detailed information on channel mapping alpha commands. EncChannelMapFrom and EncChannelMapTo alpha commands can be used to test all channels on EVM. These alpha commands route the frame buffer output of any channel to the desired MCASP pins. For Eg: In order to check height channel output; you can route it to the back channels on the MCASP pins using below alpha commands:
writeENCChannelMapFrom16(PAF_LEFT,PAF_RGHT,PAF_LSUR,PAF_RSUR,PAF_CNTR,PAF_SUBW,PAF_LBAK,PAF_RBAK,PAF_LHED,PAF_RHED,-3,-3,-3,-3,-3,-3) writeENCChannelMapTo16(0,4,1,5,2,6,-1,-1,3,7,-1,-1,-1,-1,-1,-1)
Channel Configuration Settings[edit]
A Channel Configuration is the manner in which the channels of the AudioFrame are organized:
- The Request Channel Configuration is the form of output audio that an ASP Algorithm should attempt to produce for system output, typically a read-only but application-variable quantity.
- The Stream Channel Configuration describes the actual form of the AudioFrame data. As such, this is a read/write, application-variable quantity that describes the form of the AudioFrame data presented to an ASP Algorithm, which is to be updated by that ASP Algorithm to describe the AudioFrame data that is output.
Channel configuration registers are 32-bit wide and it consists of four, 8-bit fields or parts:
- The satellite part indicates the channel configuration for satellite, that is, non-bass channels. This includes front channels Left, Right, and Center, as well as rear channels Left and Right Surround and Left and Right Back.
- The subwoofer part indicates the channel configuration for bass channels. This consists of either the LFE channel (before bass management) or subwoofer channels (after bass management).
- The auxiliary part indicates special information about the encoding of the data in the channels:
- If the satellite part indicates that the channel configuration is two-channel, the auxiliary part gives auxiliary information about how that two-channel data should be interpreted. This includes stereo, stereo-unknown, surround-encoded, mono, and dual-mono. Note that only two-channel data uses the auxiliary part in this manner.
- If the satellite part indicates that the channel configuration is multi-channel with two channel surround, the auxiliary part gives auxiliary information about how that two channel surround data should be interpreted. This includes stereo-surround, surround-unknown, back-encoded surround, and mono-surround. Note that only multi-channel data with two surround channels uses the auxiliary part in this manner.
- extMask part contain 8-bits each sepcifying one or two extended channels, as shown in Table 1. These indicate the presence of additional channels from the standard 7.2 channels.
Table 1 Extension Mask of Channel Configuration
Bit Position | Indicated Channels |
---|---|
PAF_CC_EXT_LwRw (0) | Lw + Rw |
PAF_CC_EXT_LcRc (1) | Lc + Rc |
PAF_CC_EXT_LhRh (2) | Lh + Rh |
PAF_CC_EXT_Cvh (3) | Cvh |
PAF_CC_EXT_Ts (4) | Ts |
PAF_CC_EXT_LhsRhs (5) | Lhs + Rhs |
PAF_CC_EXT_LhrRhr (6) | Lhr + Rhr |
PAF_CC_EXT_Chr (7) | Chr |
Channel Assignment of these channels are indicated in paf-hd.pdf. Bit positions in “extMask” are enum-erated in “t:/pa/f/include/pafcc.h”. The extMask for each of the above channel/channel pair is indicated below:
#define PAF_CC_EXTMASK_LwRw (1u << PAF_CC_EXT_LwRw) #define PAF_CC_EXTMASK_LcRc (1u << PAF_CC_EXT_LcRc) #define PAF_CC_EXTMASK_LhRh (1u << PAF_CC_EXT_LhRh) #define PAF_CC_EXTMASK_Cvh (1u << PAF_CC_EXT_Cvh) #define PAF_CC_EXTMASK_Ts (1u << PAF_CC_EXT_Ts) #define PAF_CC_EXTMASK_LhsRhs (1u << PAF_CC_EXT_LhsRhs) #define PAF_CC_EXTMASK_LhrRhr (1u << PAF_CC_EXT_LhrRhr) #define PAF_CC_EXTMASK_Chr (1u << PAF_CC_EXT_Chr)
When an ASP generates any extended channels it is required to set the extMask correspoding to that channel(s)in PAF_ChannelConfiguration.
Channel Mask[edit]
The Channel Configuration Mask Table is a data structure to be used for conversion of channel configuration information into Channel Masks. It is a read-only, application-constant quantity. The Channel Configuration Mask Table is typically used via the channelMask member function of the Audio Frame Data Structure. The original Channel Mask is 16-bits wide and does not represnt all extendec channels. A new 32-bit Channel Mask has been added for representing the newly added channels.
typedef XDAS_Int32 PAF_ChannelMask_HD;
There is a one-to-one correspondence between bits in the Channel Mask and channels in Audio Frame. The helper function “pAudioFrame->fxns->channelMask()” has been changed to return a 32-bit PAF_ChannelMask_HD, instead of a 16-bit PAF_ChannelMask. This function now takes care of extMask field of PAF_ChannelCOnfiguration. ASPs can check for the presence of additional channels by making use of function pAudioFrame->fxns->channelMask().
Sample Process[edit]
The Sample Process is a multi-byte bit mask of values of the form (1<<PAF_PROCESS_X) that indicates the processing algorithms that have operated on the Audio Frame Data. It is a read/write quantity, and it is the responsibility of an ASP Algorithm to realize this update if appropriate.
For example, if the PL Algorithm and BM Algorithms have operated on the Audio Frame data, the Sample Process value will be (1<<PAF_PROCESS_PL)|(1<<PAF_PROCESS_BM)
if the corresponding symbols exist. Sample Process symbols shall be defined on an as-needed basis, depending upon whether such information is required subsequently in the audio stream processing chain.
How to measure peak mips?[edit]
Peak mips refers to the worst mips taken in block processing for a frame. PA/F works on block of samples (256) and there could be situations where there is high variation in mips across various calls. If there is high difference between mips for processing different blocks; there could be peak mips problems. You could see the worst case mips associted with your ASP by measuring mips across each apply call after cache-flush operation. The ASP wrapper code in the package shows how to measure mips under worst case conditions.If there is a very significance difference in mips across different blocks; this could lead to real-time issues when run with PA. So algorithm has to take care of averaging out mips across all the calls for a frame. If this is not possible; this may have to be solved at framwork level by managing output buffers. Please contact PA support if there exists such a situation.