 (Do not delete) SWS-142 Template Revision Error! Reference source not found.



Mercury Standard Audio Encoder Interface Specification



















Sign Off Authorization


_______________	__________________________________	Date:	__________
Firmware Group Leader	Signature

_________________	__________________________________	Date:	__________
Author/Mercury DSP Engineer	Signature






	Date:	October 2, 2002
	Revision	D-2.15
	Filename: 	ENC_DEFS.DOC
	Author: 	Joe Barcelo, Catherine Cai
	Document #: 	SWS-142


INTEL CONFIDENTIAL

TABLE OF CONTENTS
1.	Overview	3
1.1	Revision History	3
1.2	Purpose	4
1.3	Scope	4
1.4	References	4
2.	Theory of Operation	5
2.1	Function of Encoder	5
2.2	Control of Encoder	5
2.3	Adding New Encoders	6
2.4	Start-up and Initialization - a brief summary	7
2.5	'Steady State' operation	7
3.	Environmental Requirements	9
3.1	Processor	9
3.2	Messaging	9
3.3	Kernel and Player Version	9
3.4	Internal Memory	9
4.	Messaging Protocol	10
4.1	Kernel Messages	10
4.2	Standard Component Messages	10
4.3	Dialogic Encoder-specific Messages to Instances	10
4.3.1	Encoder-specific messages from Recorder to Encoder Instance	10
4.3.2	Encoder-specific messages from Encoder Instance to Recorder	11
4.4	Use of messages to control a encoder instance	11
5.	Component Overview	13
6.	Message Set	14
6.1	MsgStart	15
6.2	MsgStartCmplt	17
6.3	MsgStop	18
6.4	MsgStopCmplt	20
6.5	MsgPause	21
6.6	MsgPauseCmplt	22
6.7	MsgResume	23
6.8	MsgResumeCmplt	24
6.9	MsgStatusEvt	25
6.10	MsgStart2	26
6.11	MsgStartx	27
7.	None.Error Codes	29
8.	Parameters	30
8.1	Parameter related to AGC	30
8.2	Parameter related to VAD	31
8.3	Parameters related to synchronized play/record (transcoding)	31
9.	Attributes	32
10.	Event Types	33
11.	Miscellaneous Equates	34
1. Overview
This document describes the message set used by the Mercury Standard Encoder Component. This is the Mercury Component which encodes audio data, typically for storage to disk.  It is used to implement the "Record" function. The messages described are those which the Component may receive from and transmit to the Player Component.
In addition to the written description of each message there is a Mercury Message Definition Language (MMDL) representation of each of the messages embedded in the description.  This allows a C header file of equates and definitions to be generated for each of the messages from this document using the MMDL Translation Utility.  This header file is then used to format messages by any component that wishes to send or receive messages to and from this Component.  
Messages are sent using the Mercury Messaging scheme. 
This Mercury Component does not communicates directly with the Host Software.
1.1 Revision History

REVISION HISTORY
Rev.
Date of Change
Description of Change
Rev Originator
0.1
11/23/94
Initial Draft
Joe Barcelo
0.2
7/5/95
Review Version - Beep Initiated Record added
Joe Barcelo
A
7/10/95
Status Event added
Joe Barcelo
A-1.0
8/16/95
cleaned for MMDL
Joe Barcelo
A-1.1
3/18/96
Changed document filename to be consistent with Decoder Spec
Luke Kiernan
B
7/16/96
Modified the AGC Parameters, added BytesRecorded and TimeRecorded in MsgStopCmplt message body.
Catherine Cai
 C
7/23/96
Changed the MsgStart to fit new qCStreamOpen (MDK.A106)
Catherine Cai
D
11/13/96
Changed message set range to 0x0400-0x04FF.
Catherine Cai
D-1.0
1/13/97
Changed InputStream to InputStreamID in MsgStart  
Arthur F. Elwell
D-2.0
03/23/97
Allows application change agc parameter and add agc on/off in component
Catherine Cai
D-2.1
6/27
Changed Std_ComponentType attribute value from "AEnc" to "Std_ComponentType=0x04".
Arthur Elwell
D-2.2
7/3/97
Added Mode to MsgStop to indicate whether the stop command is in response to a host exited message. Removed reference to "coders.h".
Arthur Elwell
D-2.3
8/1/97
Changed parameter presentation to table format; Added ParmBufferTruncate parameter; Removed all references to Beep Initiated Record, which is handled by the recorder; Added BrokenPipe stop reason.
Arthur Elwell
D-2.4
10/7/97
Changed event base value to 0x450. Changed AEnc_MsgStart  to integer class messaging; Added MsgStatusEvt message
Arthur Elwell
D-2.5
8/4/00
Added AEnc_MsgStart2 for transaction recording
Ling Chen
D-2.6
8/28/2000
Add the bit/nibble parameter
Catherine Cai
D-2.7
10/24/2000
Remove the bit/nibble parameter
Catherine Cai
D-2.8
1/15/2001
Update the AGC component parameter for AGC version 3.0
Catherine Cai
D-2.9
2/18/2001
Added VAD parameters
Ling Chen
D-2.10
3/1/2001
Added synchronized play/record parameter, ParmSyncRecord
Arthur Elwell
D-2.11
07/11/01
Clean up the file and updated table of contents
Bing Leng
D-2.12
05/13/02
Added Stop Reason Transcoding_Stop
Ranjan
D-2.13
09/25/02
Added new Start Msgx for Byte Record Mode
Himanshu
D-2.14
10/01/02
Comment Parmagc00 as unused
Jiangang
D-2.15
10/03/2002
Modified start Magx. Added parameter that send at the runtime( SyncRecord). Removed variable count from the mesaage.
Himanshu
1.2 Purpose
The purpose of this document is to describe the message interface between the Dialogic Standard Recorder (resident on the Mercury platform's control processor) and the Standard Encoder Component (which resides on a signal processor.)  Also mentioned here, but described in detail elsewhere1, are the standard messages supported by all components.  
This document will be used by the developers of the Mercury Standard Encoder Component, and by anyone adding an encoder to the Standard Recorder Resource.
1.3 Scope
This document defines all of the messages that the Standard Encoder Components may send and receive. It also defines all of the parameters that apply to these Components.
1.4 References
SWS-0047				Mercury Resource Firmware SAS by Luke Kiernan
SWS-0048				Mercury Kernel Architecture Specification by Steve Magnell
SWS-0049				Mercury Kernel API  by Steve Magnell
SWS-0138				Mercury MDL Specification by Steve Magnell
SWS-0140				Mercury Recorder Component Interface Specification by Luke Kiernan
SWS-0143				Standard Interface Specification for Mercury Components by Luke Kiernan
2. Theory of Operation

2.1 Function of Encoder
A encoder would typically be used to record an audio file.  The audio file would typically be written to the host system's disk or other mass storage device.  It would be coded so as to consume less storage space.  The coding might be some form of PCM, ADPCM or other.  The component that performs this function is referred to as a encoder when it resides on the Signal Processor.  The portion that resides on the Control Processor is referred to as a recorder.
In addition to encoding data received from the SC-bus the encoder may also provide Sample Rate conversion (for further data compression gains), AGC and silence compression.
2.2 Control of Encoder
A mechanism must be provided to inform the encoder where to get its input data, where to put its output data and what processing to perform on the data.  Messages sent to the encoder provide this mechanism.  They specify when the encoder instance starts and stops 'recording', what average volume level should be sought (AGC), and at what sample rate the data should be recorded.
These messages will originate in the Recorder Component residing on the Control Processor.  The Recorder component will, in turn, receive some control information from the host.  The Host will not, at this stage of development, communicate directly with the encoder component resident on the DSP.

Fig. 1	The Recorder may control several types of encoders
2.3 Adding New Encoders
For the Mercury architecture to be open, a mechanism must be provided to allow technology partners to provide support for other voice compression techniques; i.e., to add new encoders.  
There are two distinct ways that new coders may be added.  The first, shown in diagram below, uses the Standard Dialogic Audio Recorder interface.  Using this approach only the component resident on the DSP, the encoder, need be added.  The CP component is already provided.  It is necessary, then, to use the message set described in this specification.
 
Fig. 2	Addition of a new Encoder component using the Dialogic Standard Recorder Interface
The second approach, shown below, involves the creation of a new recorder resource.  This additional effort yields the benefit that the resource writer is free to define his/her own message set interface.

Fig. 3	Addition of a new Encoder component using a proprietary recorder interface
2.4 
Start-up and Initialization - a brief summary
Download: A encoder starts life as a component of a module,  a part of a component of a module (if several types of encoders are implemented by one component), or, possibly, collection of modules (some of which may be 'passive', i.e., libraries).  This code, referred hereafter simply as the 'module', must be placed into the DSP's local memory such that its entry point is known.  This process is called downloading.
Component Initialization: A encoder module that is implemented as a component on a signal processor will have a task associated with it.  This task must be 'started', allowing for some component-level initialization.  The component will also register itself with the resource manager giving it a list of the components attributes and will, in response, receive its component address.  
Instance creation: The component is now ready to receive messages.  It will probably receive one or more set parameter messages.  These may specify the number of instances to create, modify default volume settings, etc.  Eventually a Std_MsgInit message is sent to the component.  It then creates as many instances as are specified by the Std_ParmInstNum parameter, allocating any memory needed for control structures and initializing these structures.  

Fig. 4	Message flow during encoder initialization.
For a more detailed description of this phase of operation refer Mercury Kernel Architecture Specification.
2.5 'Steady State' operation
Once the encoder instance has been created and initialized it is ready to receive messages including 'start recording'.  The remainder of this document is concerned with the control of the encoder during this steady state phase.
3. Environmental Requirements
3.1 Processor
The encoder will execute on the signal processor.  It will have available all kernel services provided for the SP kernel.  These are described in document SWS-0049, Mercury Kernel API .
3.2 Messaging
The encoder receives and transmits standard Mercury messages. The Recorder will be the only Component to send messages to the encoder.  That is, all messages from the host or other components containing control information for the encoder (e.g., parameters) must be addressed to the primary component, the Recorder.
3.3 Kernel and Player Version

3.4 Internal Memory

4. Messaging Protocol
4.1 Kernel Messages
All messages described in the Mercury Kernel API are supported by this standard component.
4.2 Standard Component Messages
All messages defined in Standard Interface Specification for Mercury Components are supported by this component.
4.3 Dialogic Encoder-specific Messages to Instances
All encoder instances need to be given the following information:
* PCM input stream identifier,
* Host output stream identifier,
* when to start encoding,
* when to stop encoding and how many milliseconds worth of data should be truncated from the end of the record,
* when to pause record and how many milliseconds worth of data should be truncated from the end of the data stream recorded up to that point,
* when to continue record,
* whether to compress silence data and, if so, the values of parameters relevant to silence compression,
* what values to give to parameters (e.g., AGC, volume).
The encoder also needs to provide information to the CP recorder component including:
* parameter values,
* indication of completion of certain activities (events such as record complete)
Some of this control can be implemented using standard messages, e.g., set parameters or enable events.  Others require messages that are specific, or proprietary, to this component.  These proprietary messages are described below.
4.3.1 Encoder-specific messages from Recorder to Encoder Instance

message
MsgStart
MsgStop
MsgPause
MsgResume

4.3.2 Encoder-specific messages from Encoder Instance to Recorder


message
MsgStartCmplt
MsgStopCmplt 
MsgPauseCmplt
MsgResumeCmplt



4.4 Use of messages to control a encoder instance
Once the encoder instance has been initialized and registered (described above) it is ready to accept messages.  The first message the Dialogic Standard Encoder will accept is an Allocate Instance (InstAlloc).  The encoder instance will, in response, allocate any data buffers that it needs and return an Allocate Instance Complete message indicating whether it was successful.  
The existence of the Encoder Instance is now known to the Resource Manager.  It is now possible to get messages from other components.  For the Dialogic Standard Encoder the next message expected is a SetParms, to instruct the instance to set its parameters to specified values. However, it is possible for a Start to follow the InstAlloc message (if the default value of the parameters is acceptable) or a Free Instance (deallocate instance) might be received if, for example, a call is terminated prior to start of record.
To aid in the understanding of the role of the remaining messages a state transition diagram is shown below.  A basic encoder may be in any of  four states: deallocated, allocated but stopped ('IDLE'), started ('RECORDING') or PAUSED (not , recording, but maintaining data buffers).  
The legality of a message is, in part, dependent upon the state of the encoder when it is received.  For example, receipt of a MsgStart message while in the Paused state is considered to be an error and results in a standard error message being sent to the Recorder instance that issued the Start Record message.  Only a subset of the legal messages that may be sent to the Dialogic Standard Encoder are shown below.  


Fig. 5 - Encoder States Visible to Recorder 
For the most part the encoder is driven from one state to another by the receipt of command messages.  For example, if the encoder is in the IDLE state and receives a legal MsgStart command, it will make a transition into the RECORDING state.
Not all messages result in state transitions.  Specifically commands to 'set' or 'get' do not result in changes of state.  
The Encoder instance may receive a standard Exit message in any state.  It will perform those housekeeping functions associated with the receipt of a Stop followed by an deallocate (qCompFree).
5. Component Overview
Not applicable.

6. Message Set
The following messages are defined using the Mercury Message Definition Language (MMDL) with accompanying textual descriptions.  The output header file from this message description will be ENC_DEFS.H  

Message directional modifiers (i.e., in and out) are given with respect to the Encoder Component.

.file	"enc_defs.h"
.author	"Joe Barcelo, Catherine Cai"
.version	"Revision D-2.11"

<< 
MMDL comment: This file describes the list of  Standard Dialogic Encoder Messages.
>>
The Mercury Kernel definitions must not be used as definitions for any Component level information.

.sysdefs	"mercdefs.ext"

<< 
Standard Message Definitions
>>
.predefs "stddefs.ext"

For now we define the range for Encoder messages, error codes and parameters here. In future this may be automatically generated by the MMDL based on the Component Type.

.min	.message	0x0400
.max	.message	0x04FF
.min	.parameter	0x0400
.max	.parameter	0x04FF
.min	.error		0x0400
.max	.error		0x04FF

.component AEnc=0x04
{
.uses
{
}
.defines
{
<< encoder-specific messages defined in following sections >>
6.1 
MsgStart

		
.message .in MsgStart
	{	
	.uint24 EncoderType 
	.uint24 InputStreamID
	.uint24 Law {Mulaw, Alaw}
	.uint24 OutputStreamID
	}
	
( Description
	Target
This message may be sent to an encoder instance that is in the IDLE state.
	Interpretation
This message is interpreted as follows:
Open input stream, output stream.  If any can not be opened the encoder instance returns a standard error message and remains in the IDLE state.
The EncoderType specifies which encoder will be used for this instance when multiple encoders are  supported by an encoder component.
The Law specifies whether a-law or (-law data is to be received from front end and  converted to linear data by MMA.
Upon entering the RECORD state the encoder instance issues a MsgStartCmplt to the source of MsgStart and begin converting data from input stream into the appropriate form for output stream.
	Return message
Returns MsgStartCmplt if record is successfully started.  Returns Std_MsgError message if any error condition prevents the execution of the MsgStart command.
	Error conditions
	encoder instance already started
	encoder instance paused
	unable to open specified PCM input stream
	unable to open specified host output stream
	internal error: illegal parameter or state encountered
	Cautions
As the input stream and output stream is not opened until the receipt of this message, any failure that prevents opening of this stream will result in an error condition.  Similarly, the inability to allocate a memory block of the specified size will result in an error.


6.2 MsgStartCmplt

		
.message .out MsgStartCmplt

	
( Description
	Target
This message may be sent to the source of the MsgStart command.
	Interpretation
This message is interpreted to mean that the MsgStart message was received by the source address and was successfully executed (i.e., the recording of data has begun.)
	Return message
None.
	Error conditions
None.
	Cautions
None.
6.3 MsgStop

		
.message .in MsgStop
{
.uint24 Backspace
.uint24 Mode 		{Normal, Immediate }
}

	
( Description
	Target
This message may be sent to an Encoder instance that is in the RECORD, PAUSED or BEEP state.
	Interpretation
This message is interpreted to mean (for Normal Mode):
1. Close input stream,
2. move 'cursor' back Backspace samples2 ,
3. write an End-Of-File (set EOF flag and number of valid bytes in stream),
4. close host output stream,
5. upon receipt of kernel message indicating successful completion of return of streams, make state transition into IDLE state,
6. send MsgStopCmplt message to source of MsgStop,
7. and if status event is enabled, send a MsgStatusEvent message with the number of bytes recorded since issuance of the previous status message.
For Immediate Mode, steps 2, 3, and 4 are not performed, and the stream is "cancelled". Immediate Mode is used when the recorder has received notification that the host has abnormally exited.

	Return message
Returns MsgStopCmplt if Record is successfully stopped.  Returns Std_MsgError message if any error condition prevents the execution of the MsgStop command.
	Error conditions
	encoder instance already stopped
	unable to deallocate resources
	backspace specified exceeds size of buffered data
	Cautions
None.
6.4 MsgStopCmplt


		
.message .out MsgStopCmplt
{
.uint24 Reason {MsgStop=0, ErrorStop=1, BrokenPipe=2, TranscodingStop=4, ByteRecordStop=5}
.uint24 BytesRecorded
.uint24 TimeRecorded
}
	
	

( Description
	Target
This message may be sent to the source of the MsgStop message to acknowledge receipt of message and to indicate that MsgStop command has been executed, returning the encoder instance to the IDLE state..
	Interpretation
This message is interpreted to mean 
1.	The MsgStop message was received,
2.	The output cursor was moved backward, discarding the amount of data specified by the parameter backspace (possibly '0', meaning discard no data) or all data recorded (whichever is smaller),
3.	An EOF was written to the output stream,
4.	The input stream was closed and output stream was returned to the player instance, and
5.	Any resources allocated upon receipt of MsgStart were deallocated.
The reason that the instance stopped encoder output stream, the number of bytes recorded and the time recorded in millisecond are included in the message body.

	Return message
None.
	Error conditions
None.
	Cautions
None.
6.5 MsgPause

		
.message .in MsgPause
{
.uint24 Backspace
}

	
( Description
	Target
This message may be sent to an encoder instance that is in the RECORD state.
	Interpretation
The MsgPause message causes the encoder to stop the input stream, and to move the output pointer back through the output buffer by the number of samples captured during the duration (in milliseconds) specified by the parameter Backspace.  The effect is to discard the last Backspace milliseconds of data, or the amount captured since the start of recording, whichever is smaller.
If the encoder instance is in the BEEP state when  MsgPause is received, the beep tone terminate and the encoder will enter the PAUSE state.
	Return message
A MsgPauseCmplt message is sent to the source of the MsgPause message.
	Error conditions
	instance not in RECORD state
	backspace specified exceeds size of buffered data 
	Cautions
None.
6.6 MsgPauseCmplt
		
.message .out MsgPauseCmplt

	
( Description
	Target
This message is sent to the source of the MsgPause message.
	Interpretation
This message may be interpreted to mean that the MsgPause message was received and successfully executed.  Encoder instance has entered the PAUSED state.
	Return message
None.
	Error conditions
None.
	Cautions
None.
6.7 MsgResume

		
.message .in MsgResume
	
( Description
	Target
This message may be sent to an encoder instance that is in the PAUSED state.
	Interpretation
If Beep Initiated Record is disabled the receipt of the MsgResume message causes the encoder to exit the PAUSED state and enter the RECORD state.  It continues to consume data from the input stream from the current input pointer position and again places decoded data in the output stream.  The encoder must have been previously paused to be resumed.
	Return message
A MsgResumeCmplt message is sent to the source of the MsgResume message as the encoder instance enters the RECORD state.
	Error conditions
	instance not paused
	Cautions
None.
6.8 MsgResumeCmplt

		
.message .out MsgResumeCmplt
	
( Description
	Target
This message is sent to the source of the MsgResume message.
	Interpretation
This message is interpreted to mean that the encoder has received and executed the MsgResume message and entered the RECORD state.
	Return message
None
	Error conditions
None  
	Cautions
None

6.9 MsgStatusEvt


		
.message .out MsgStatusEvt
{
.uint24 BytesRecorded
}

	

( Description
	Target
This message is sent to the source of the MsgStart message.
	Interpretation
This message is generated every time the number of bytes of data specified by the ParmBytesRec parameter have been recorded. The number of bytes recorded is reported in this message.
	Return message
None.
	Error conditions
None.
	Cautions


6.10 MsgStart2
		

.message .in MsgStart2
	{	
	.uint24 EncoderType 
	.uint24 InputStreamID
	.uint24 Law {Mulaw, Alaw}
	.uint24 OutputStreamID
	.uint24 InputStreamID2
	}
	
( Description
	Target
This message may be sent to an encoder instance that is in the IDLE state. It is identical to MsgStart except for an additional field InputStreamID2 used as the 2nd input stream for transaction recording.
	Interpretation
This message is interpreted as follows:
Open input stream, output stream.  If any can not be opened the encoder instance returns a standard error message and remains in the IDLE state.
The EncoderType specifies which encoder will be used for this instance when multiple encoders are  supported by an encoder component.
The Law specifies whether a-law or (-law data is to be received from front end and  converted to linear data by MMA.
Upon entering the RECORD state the encoder instance issues a MsgStartCmplt to the source of MsgStart2 and begin converting data from input stream into the appropriate form for output stream.
	Return message
Returns MsgStartCmplt if record is successfully started.  Returns Std_MsgError message if any error condition prevents the execution of the MsgStart2 command.
	Error conditions
	encoder instance already started
	encoder instance paused
	unable to open specified PCM input stream
	unable to open specified host output stream
	internal error: illegal parameter or state encountered
	Cautions
As the input stream and output stream is not opened until the receipt of this message, any failure that prevents opening of this stream will result in an error condition.  Similarly, the inability to allocate a memory block of the specified size will result in an error.
MsgStart2 must be defined by appending InputStreamID2 to the last field of MsgStart.

6.11 MsgStartx
		

.message .in MsgStartx
	{	
 	.uint24 EncoderType 
	.uint24 InputStreamID
	.uint24 Law {Mulaw, Alaw}
	.uint24 OutputStreamID
	.uint24 InputStreamID2
	.uint24 bytesToBeRecorded
	 .uint32 SyncRecord
	}
	
( Description
	Target
This message may be sent to an encoder instance that is in the IDLE state. It is identical to MsgStart  and MsgStart2 except for an additional field count. For Future implementation just need to expand the same message. This message may be used in place of MsgStart and msgStart2 message.
	Interpretation
This message is interpreted as follows:
Open input stream, output stream.  If any can not be opened the encoder instance returns a standard error message and remains in the IDLE state.
The EncoderType specifies which encoder will be used for this instance when multiple encoders are  supported by an encoder component.
The Law specifies whether a-law or (-law data is to be received from front end and  converted to linear data by MMA.
BytestobeRecorded specified how many bytes to be recorded. If it is set to zero than it will behave like timed recorded mode.
SyncRecord is the value for the parameter AEnc_ParmSyncRecord.
Upon entering the RECORD state the encoder instance issues a MsgStartCmplt to the source of MsgStartx and begin converting data from input stream into the appropriate form for output stream.
	Return message
Returns MsgStartCmplt if record is successfully started.  Returns Std_MsgError message if any error condition prevents the execution of the MsgStartx command.
	Error conditions
	encoder instance already started
	encoder instance paused
	unable to open specified PCM input stream
	unable to open specified host output stream
	internal error: illegal parameter or state encountered
	Cautions
As the input stream and output stream is not opened until the receipt of this message, any failure that prevents opening of this stream will result in an error condition.  Similarly, the inability to allocate a memory block of the specified size will result in an error.

7. None.Error Codes 
The following is a list of error codes specific to the Encoder that are returned in the Error code field of the Std_MsgError message.
<< 
Standard Component Error Code Definitions
>>
		
.error	ErrInStmOpn		<< an error while opening the input PCM stream >>
.error	ErrHOStmOpn		<< an error while opening the host output stream >>
.error	ErrHOStmOvflw		<< host data not removed in time >>
.error	ErrBadStmData		<< some illegal input value, e.g. linear value not corresponding to a PCM value >>
.error	ErrGMAlloc		<< unable to allocate global memory buffer >>
.error	ErrLMAlloc		<< unable to allocate local memory buffer >>
.error	ErrBadBSpSize		<< backspace specified exceeds ParmHstOBufSiz >>
.error ErrInRecState		<< inappropriate message: encoder in record state >>
.error ErrInPauseState		<< inappropriate message: encoder in pause state >>
.error ErrInIdleState		<< inappropriate message: encoder in idle state >>
.error ErrInternalError		<< debug 'assert' >>


	
8. Parameters
The following is a list of parameters used with the Encoder component.
Parameter access is classified as read only (R), write only (W) and as read/write (R/W).

Parameter level is classified as Component (C), Instance (I), or Component and Instance (C/I).

<< 
Recorder Parameter Definitions
>>
8.1 Parameter related to AGC 

		
Parameter type and name
Access
Level
Description
.parameter .uint24 ParmAGC00		
R/W
C
<< Not used >>
.parameter .uint24 ParmAGC01		
R/W
C
<< AGC_K >>
.parameter .uint24 ParmAGC02		
R/W
C
<< AGC_CLIPLIM>>
.parameter .uint24 ParmAGC03		
R/W
C
<< AGC_MEM_SIL_RESET >>
.parameter .uint24 ParmAGC04	 	
R/W
C
<< AGC_MEM_MAX_SIZE>>
.parameter .uint24 ParmAGC05	
R/W
C
<< AGC_LO_AGC_THRESHOLD>>
.parameter .uint24 ParmAGC06		
R/W
C
<< AGC_NFLOR_LOW_THRESH >>
.parameter .uint24 ParmAGC07		
R/W
C
<< AGC_QUANTLEV_SCALE>>
.parameter .uint24 ParmAGC08		
R/W
C
<< AGC_MAX_GAIN>>
.parameter .uint24 ParmAGC09	
R/W
C
<<AGC_GATE_HANG>>
.parameter .uint24 ParmAGC10
R/W
C
<< AGC_NF_ATTSLOW>>
.parameter .uint24 ParmAGC11
R/W
C
<< AGC_NF_ATTFAST>>
.parameter .uint24 ParmAGC12
R/W
C
<< AGC_GAIN_INC_SPEECH>>
.parameter .uint24 ParmAGC13

C
<< RFU >>
.parameter .uint24 ParmAGC14

C
<< RFU >>
.parameter .uint24 ParmAGC15

C
<< RFU >>
.parameter .uint24 ParmAGC16

C
<< RFU >>
.parameter .uint24 ParmAGC17

C
<< RFU >>
.parameter .uint24 ParmAGC18

C
<< RFU >>
.parameter .uint24 ParmAGC19

C
<< RFU >>
.parameter .uint24 ParmAGCOn
R/W
I
<< 
Enable/Disable AGC, default = 1 (ON)
 >>













The parameter  AGC00 will allow the application to enable or disable AGC prior to initialization.  There is an instance parameter of AGC on/off ,  which allows the application to tune on/off AGC for a specified instance during  run time.  If the application does not disable AGC on a component-wide basis prior to initialization, the Encoder will pick the default value, thus enabling AGC.



8.2 Parameter related to VAD 

		
Parameter type and name
Access
Level
Description
.parameter .uint24 VADSpchHng
R/W
C
<< Speech hang , to be supported >>
.parameter .uint24 VADENSpchHng
R/W
C
<<Energy based speech hang, to be supported >>
.parameter .uint24 VADSpchPrO
R/W
C
<< Speech probability threshold, to be supported >>
.parameter .uint24 VADSpchPrC
R/W
C
<< Silence probability threshold, to be supported >>
.parameter .uint24 VADLoThr
R/W
C
<<Lower threshold of noice, to be supported >>
.parameter .uint24 VADHiThr
R/W
C
<<Higher threshold of noice, to be supported >>
.parameter .uint24 ParmVADOn
R/W
I
<< 
Enable/Disable VAD, default = 1 (ON)
 >>













8.3 Parameters related to synchronized play/record (transcoding)
This parameter indicates whether a synchronized play/record, or transcoding, is to occur. The corresponding parameters in the decoder and encoder must be set to the matching parameter value. If there is a mismatch in values, play or record failures will result.

.parameter .uint24 ParmSyncRecord {NOSYNC, SYNC}
9. Attributes
In addition to the standard attribute types Std_ComponentType, Std_ComponentID and Std_VendID which must be initialized by this component the following are attribute types specific to the encoder:
Attribute name
Description
.external .attribute Std_ComponentType 
{ Std_ComponentType = 0x04}

<<
Encoder Component Type definition.
>>
.attribute EncoderType 
<<
coders defined in coders.h 
>>
.attribute Feature {AGC=1, BIR=2, SilCmp=3, SilTrn=4, BckSp=5}
<<
Encoder features
>>
.external .attribute Std_ComponentId {DIALOGIC = 1}
<<
Dialogic Id.
>>



10. Event Types
The following is the only event type for the Mercury Encoder Component. It is supported by the encoder component and its instances.  When enabled, this event is sent to the Component specified in the ReturnAddress field of the Std_MsgDetectEvent message. It is sent using the Std_MsgEventDetected message.

<< Audio Encoder Event Type Definitions. >>
.message! out	Event
{
	.compdesc	ReturnAddress
	.uint32	Type	{EvtStatus=0x450}
	.uint32	Label
}

Event name
Description
.message! .out EvtStatus
{
    .uint32 Label
    .uint32 BytesRec
}
<<
EvtStatus is generated every time the number of bytes of data specified by the ParmBytesRec parameter have been recorded. The number of bytes recorded is reported in this message. 
>>
11. Miscellaneous Equates
<<
End of all Mercury Encoder Component Definitions
>>
}
}

1 Standard Interface Specification for Mercury Components
2 Number of samples is specified by the product of Backspace and sample-rate/1000.  The factor of 1000 is due to Backspace being expressed in milliseconds.
Mercury Standard Audio Encoder Interface Specification SWS-142
Revision  D-2.15 



INTEL CONFIDENTIAL
34 of 34

