ACOUSTIC ECHO CANCELLATION (AEC) WITH CONFERENCING ENVIRONMENT TEMPLATES (CETs)

CROSS-REFERENCE TO RELATED APPLICATIONS

0001The present application may be related to each of the following applications: U.S. application Ser. No. 12/551,273, filed Aug. 31, 2009, and entitled “COMMUNICATION APPLICATION”; U.S. application Ser. No. ______ (Atty. Docket No. 2774-14600), filed ______, and entitled “MEDIA PIPELINE FOR A CONFERENCING SESSION”; and U.S. application Ser. No. ______ (Atty. Docket No. 2774-14800), filed ______, and entitled “COMMUNICATION APPLICATION WITH STEADY-STATE CONFERENCING”, all hereby incorporated herein by reference in their entirety.

BACKGROUND

0002Acoustic echo cancellation (AEC) techniques need to perform two functions: echo detection and echo cancellation. Implementation of AEC is not a trivial task and many AEC techniques have reduced effect due to overly simplistic algorithms and/or improper use of AEC parameters.

BRIEF DESCRIPTION OF THE DRAWINGS

0003For a detailed description of exemplary embodiments of the invention, reference will now be made to the accompanying drawings in which:

0004<figref idrefs="DRAWINGS">FIG. 1</figref> illustrates a system in accordance with embodiments of the disclosure;

0005<figref idrefs="DRAWINGS">FIG. 2</figref> illustrates various software components of a communication application in accordance with an embodiment of the disclosure;

0006<figref idrefs="DRAWINGS">FIG. 3</figref> illustrates components of a media pipeline in accordance with an embodiment of the disclosure;

0007<figref idrefs="DRAWINGS">FIG. 4</figref> illustrates a conferencing technique in accordance with an embodiment of the disclosure; and

0008<figref idrefs="DRAWINGS">FIG. 5</figref> illustrates a method in accordance with embodiments of the disclosure.

NOTATION AND NOMENCLATURE

0009Certain terms are used throughout the following description and claims to refer to particular system components. As one skilled in the art will appreciate, computer companies may refer to a component by different names. This document does not intend to distinguish between components that differ in name but not function. In the following discussion and in the claims, the terms “including” and “comprising” are used in an open-ended fashion, and thus should be interpreted to mean “including, but not limited to . . . .” Also, the term “couple” or “couples” is intended to mean either an indirect, direct, optical or wireless electrical connection. Thus, if a first device couples to a second device, that connection may be through a direct electrical connection, through an indirect electrical connection via other devices and connections, through an optical electrical connection, or through a wireless electrical connection.

DETAILED DESCRIPTION

0010The following discussion is directed to various embodiments of the invention. Although one or more of these embodiments may be preferred, the embodiments disclosed should not be interpreted, or otherwise used, as limiting the scope of the disclosure, including the claims. In addition, one skilled in the art will understand that the following description has broad application, and the discussion of any embodiment is meant only to be exemplary of that embodiment, and not intended to intimate that the scope of the disclosure, including the claims, is limited to that embodiment.

0011Embodiments of the invention are directed to techniques for remote conferencing via at least one intermediary network. In accordance with embodiments, a communication application provides an acoustic echo cancellation (AEC) feature during a conferencing session via the intermediary network. As an example, the AEC feature may be part of a media pipeline associated with the communication application and is an integral part of audio communications. As used herein, “media pipeline” refers to software components that transform media from one form to another. For example, in addition to providing the disclosed AEC feature, a media pipeline may compress and mix media to be transmitted, format media for transmission via a network, recover media received via a network, unmix received media, and de-compress received media. Such a media pipeline comprises software components executed by a media transmitting device and a media receiving device.

0012In accordance with at least some embodiments, the disclosed AEC feature is associated with a user interface that enables a user to select between a plurality of conferencing environment templates (CETs) for use with AEC. Each CET corresponds to a set of AEC parameters, referred to herein as CET parameters. The value of at least some CET parameters varies for each of the plurality of CETs. The disclosed AEC feature also may have other AEC parameters that are not affected by CET selection. In some embodiments, a user is presented with a simplified interface that facilitates CET selection without user knowledge of the underlying CET parameters associated with each CET.

0013<figref idrefs="DRAWINGS">FIG. 1</figref> illustrates a system <b>100</b> in accordance with embodiments of the disclosure. As shown in <figref idrefs="DRAWINGS">FIG. 1</figref>, the system <b>100</b> comprises a computer system <b>102</b> coupled to a communication endpoint <b>140</b> via a network <b>120</b>. The computer system <b>102</b> is representative of a desktop computer, a laptop computer, a “netbook,” a smart phone, a personal digital assistant (PDA), or other electronic devices. Although only one communication endpoint <b>140</b> is shown, it should be understood that the computer system <b>102</b> may be coupled to a plurality of communication endpoints via the network <b>120</b>. Further, it should be understood, that the computer system <b>102</b> is itself a communication endpoint. As used herein, a “communication endpoint” refers to an electronic device that is capable of running a communication application and supporting a remote conferencing session.

0014In accordance with embodiments, the computer system <b>102</b> and communication endpoints (e.g., the communication endpoint <b>140</b>) employ respective communication applications <b>110</b> and <b>142</b> to facilitate efficient remote conferencing sessions. As shown, the communication application <b>110</b> comprises an AEC module <b>112</b>. Although not required, the communication application <b>142</b> may comprise the same module(s) as the communication application <b>110</b>. Various operations related to the AEC module <b>112</b> will later be described.

0015As shown in <figref idrefs="DRAWINGS">FIG. 1</figref>, the computer system <b>102</b> comprises a processor <b>104</b> coupled to a system memory <b>106</b> that stores the communication application <b>110</b>. In accordance with embodiments, the processor <b>104</b> may correspond to at least one of a variety of semiconductor devices such as microprocessors, central processing units (CPUs), microcontrollers, main processing units (MPUs), digital signal processors (DSPs), advanced reduced instruction set computing (RISC) machines, ARM processors, application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs) or other processing devices. In operation, the processor <b>104</b> performs a set of predetermined functions based on data/instructions stored in or accessible to the processor <b>104</b>. In at least some embodiments, the processor <b>104</b> accesses the system memory <b>106</b> to obtain data/instructions for the predetermined operations. The system memory <b>106</b> is sometimes referred to as a computer-readable storage medium and may comprise volatile memory (e.g., Random Access Memory), non-volatile memory (e.g., a hard drive, a flash drive, an optical disk storage, etc.), or both.

0016To support a remote conferencing session, the computer system <b>102</b> comprises communication devices <b>118</b> coupled to the processor <b>104</b>. The communication devices may be built-in devices and/or peripheral devices of the computer system <b>102</b>. As an example, the communication devices <b>118</b> may correspond to various input devices and/or output devices such as a microphone, a video camera (e.g., a web-cam), speakers, a video monitor (e.g., a liquid crystal display), a keyboard, a keypad, a mouse, or other devices that provide a user interface for communications. Each communication endpoint (e.g., the communication endpoint <b>140</b>) also may include such communication devices.

0017To enable remote conferencing sessions with communication endpoints coupled to the network <b>120</b>, the computer system <b>102</b> further comprises a network interface <b>116</b> coupled to the processor <b>104</b>. The network interface <b>116</b> may take the form of modems, modem banks, Ethernet cards, Universal Serial Bus (USB) interface cards, serial interfaces, token ring cards, fiber distributed data interface (FDDI) cards, wireless local area network (WLAN) cards, radio transceiver cards such as code division multiple access (CDMA) and/or global system for mobile communications (GSM) radio transceiver cards, or other network interfaces. In conjunction with execution of the communication application <b>110</b> by the processor <b>104</b>, the network interface <b>116</b> enables initiation and maintenance of a remote conferencing session between the computer system <b>102</b> and a communication endpoint.

0018In accordance with at least some embodiments, execution of the AEC module <b>112</b> (e.g., by the processor <b>104</b>) enables various AEC features for use with a conferencing session. As shown, the AEC module <b>112</b> provides a user interface, CETs, CET parameters, and other AEC parameters.

0019The user interface enables a conference participant to provide input regarding the conferencing environment (e.g., room size, room shape, speaker location, microphone location) and/or to select from a plurality of predetermined conferencing environments. The conferencing environment user input causes the AEC module <b>112</b> to select a CET that matches (or most closely matches) the conferencing environment indicated by the user. The CET parameters corresponding to the selected CET will be applied during the conferencing session (e.g., by the media pipeline for the conferencing session). The AEC module <b>112</b> also may implement other AEC parameters that are not affected by CET selection. Such AEC parameters may include, but are not limited to, gain controls, DC removal, spectral estimation, and functions attributed to intrinsic properties of audio signals.

0020In some embodiments, predetermined conferencing environments are visible by a conference participant. For example, the predetermined conferencing environments may be labeled as “office”, “conference room”, and “auditorium”. Further, a user may designate an “office”, “conference room”, or “auditorium” selection as “small” or “large”. In alternative embodiments, a user is able to enter conferencing environment information (e.g., room size, room shape, speaker location, and microphone location) that leads to automated selection of a matching CET or closest CET match. Further, in some embodiments, CET parameters corresponding to different CETs are visible to a conference participant. Alternatively, CET parameters are not visible to a conference participant, but are visible to a conference administrator. Similarly, in some embodiments, other AEC parameters are visible to a conference participant. Alternatively, the other AEC parameters are not visible to a conference participant, but are visible to a conference administrator.

0021In accordance with at least some embodiments, the CETs comprise an office room template, a conference room template, and an auditorium template. The CET parameters corresponding to the office room template, the conference room template, and the auditorium template vary. Such CET parameters may include, but are not limited to, estimation filter size parameters, the rate of adaptation, regularization parameters, sensitivity to double-talk parameters, noise level estimates, and overall parameters that control adaptation behavior. As an example, the rate of adaptation parameter value for a large reverberant room may be two or three times the rate of adaptation parameter value for an acoustically treated room.

0022In at least some embodiments, the plurality of CETs are categorized by room size. Additionally or alternatively, the plurality of CETs are categorized by room shape. Additionally or alternatively, the plurality of CETs are categorized by speaker location and microphone location within a room. Thus, by enabling a user to provide information regarding room size, room shape, speaker location, microphone location and/or other relevant parameters, an appropriate CET may be selected.

0023In some embodiments, AEC parameters associated with the AEC module <b>112</b> may comprise a suppression method parameter (e.g., “Suppression_Method”), a suppression level parameter (e.g., “Suppression_Level”), a rate of adaptation parameter (e.g., “samplingRate”), estimation filter size parameters (e.g., “AEC_Len”, “ASIO_data_size”, and “history_win_size”), regularization parameters, sensitivity to double-talk parameters (e.g., “slide_win_size”, “BLK_Num_Decision”, and “delay block”), noise level estimates, and overall parameters that control adaptation behavior.

0024In accordance with at least some embodiments, the communication application <b>110</b> establishes a peer-to-peer conferencing session between the computer system <b>102</b> and a communication endpoint based on “gateway remoting”. As used herein, “gateway remoting” refers to a technique of indirectly populating a contact list of potential conference clients for the communication application <b>110</b> and maintaining presence information for these potential conference clients using predetermined contact list and presence information maintained by at least one gateway server.

0025In order to access a contact list and presence information maintained by a given gateway server, a user at the computer system <b>102</b> often logs into the communication service provided by the given gateway server. Although the user could log into each gateway server communication service separately, some embodiments of the communication application <b>110</b> enable management of the login process for all gateway service accounts associated with the user of the computer system <b>102</b>. For example, when a user successfully logs into the communication application <b>110</b>, all gateway server accounts associated with the user are automatically activated (e.g., by completing a login process for each gateway server account). Additionally or alternatively, contact list information and presence information may be entered manually by via a local gateway connection.

0026To initiate a remote conferencing session, a user at the computer system <b>102</b> selects a conference client from the populated contact list of the communication application <b>110</b>. The communication application <b>110</b> then causes an initial request to be sent to the selected conference client via an appropriate gateway server communication service provided by at least one gateway server. In some cases, there may be more than one appropriate gateway server communication service since the user of the computer system <b>102</b> and the selected conference client may be logged into multiple gateway server accounts at the same time. Regardless of the number of appropriate gateway server communication services, the computer system <b>102</b> does not yet have direct access to the communication endpoint associated with the selected conference client. After indirectly exchanging connection information (e.g., IP addresses and user names associated with the communication application <b>110</b>) via a gateway server communication service (e.g., Gmail®, Jabber®, and Office Communicator®), the computer system <b>102</b> and the appropriate communication endpoint are able to establish a peer-to-peer conferencing session without further reliance on a gateway server or gateway server communication service. For more information regarding gateway remoting, reference may be had to U.S. application Ser. No. 12/551,273, filed Aug. 31, 2009, and entitled “COMMUNICATION APPLICATION”, which is hereby incorporated herein by reference.

0027<figref idrefs="DRAWINGS">FIG. 2</figref> illustrates various software components of a communication application <b>200</b> in accordance with an embodiment of the disclosure. The communication application <b>200</b> may correspond, for example, to either of the communication applications <b>110</b> and <b>142</b> of <figref idrefs="DRAWINGS">FIG. 1</figref>. As shown, the communication application <b>200</b> comprises a management module <b>202</b> that supports various management functions of the communication application <b>200</b>. As shown, the management module <b>202</b> supports a “Buddy Manager”, a “Property Manager”, a “Log Manager”, a “Credentials Manager”, a “Gateway Manager”, a “Conference Manager”, an “Audio/Video (A/V) Manager”, and a “Remote Command Manager.”

0028The Buddy Manager of the management module <b>202</b> maintains a contact list for the communication application <b>200</b>. The Property Manager of the management module <b>202</b> enables administrative modification of various internal properties of the communication application <b>200</b> such as communication bandwidth or other properties. The Gateway Manager of the management module <b>202</b> provides an interface for the communication application <b>200</b> to communicate with gateway servers <b>254</b>A-<b>254</b>C. As shown, there may be individual interfaces <b>232</b>A-<b>232</b>C corresponding to different gateway servers <b>254</b>A-<b>254</b>C since each gateway server may implement a different protocol. Examples of the interfaces <b>232</b>A-<b>232</b>C include, but are not limited to, an XMPP interface, an OCS interface, and a local interface.

0029Meanwhile, the Conference Manager of the management module <b>202</b> handles communication session features such as session initiation, time-outs, or other features. The Log Manager of the management module <b>202</b> is a debug feature for the communication application. The Credentials Manager of the management module <b>202</b> handles login information (e.g., username, password) related to the gateway servers <b>254</b>A-<b>254</b>C so that an automated login process to the gateway servers <b>254</b>A-<b>254</b>C is provided by the communication application <b>200</b>. The NV Manager of the management module <b>202</b> sets up an A/V pipeline to support the communication session. The Remote Commands Manager of the management module <b>202</b> provides remoting commands that enable the communication endpoint (e.g., the computer system <b>102</b>) that implements the communication application <b>200</b> to send information to and receive information from a remote computer.

0030As shown, the management module <b>202</b> interacts with various other software modules. In at least some embodiments, the management module <b>202</b> sends information to and receives information from a user interface (UI) module <b>204</b>. The UI module <b>204</b> may be based on, for example, Windows Presentation Foundation (WPF) or “Qt” software. In the embodiment of <figref idrefs="DRAWINGS">FIG. 2</figref>, the management module <b>202</b> sends information to the UI module <b>204</b> using a “boost” event invoker <b>208</b>. As used herein, “boost” refers to a set of C++ libraries that can be used in code. On the other hand, the UI module <b>204</b> sends information to the management module <b>202</b> using a C++ interop (e.g., a Common Language Infrastructure (CLI) interop). To carry out the communication session, the management module <b>202</b> interacts with a media pipeline module <b>226</b>. In at least some embodiments, the media pipeline module <b>226</b> comprises the AEC module <b>112</b> of <figref idrefs="DRAWINGS">FIG. 1</figref> to provide some or all of the features described for the AEC module <b>112</b> (e.g., the user interface, CETs, CET parameters, and other AEC parameters). In operation, the media pipeline module <b>226</b> discovers, configures (e.g., codec parameters), and sends information to or receives information from communication hardware <b>236</b>. Examples of communication hardware <b>236</b>, include but are not limited to, web-cams <b>238</b>A, speakers <b>238</b>B and microphones <b>238</b>C.

0031In the embodiment of <figref idrefs="DRAWINGS">FIG. 2</figref>, the UI module <b>204</b> and the management module <b>202</b> selectively interact with a UI add-on module <b>214</b> and a domain add-on module <b>220</b>. In accordance with at least some embodiments, the “add-on” modules (<b>214</b> and <b>220</b>) extend the features of the communication application <b>200</b> for remote use without changing the core code. As an example, the add-on modules <b>214</b> and <b>220</b> may correspond to a “desktop sharing” feature that provides the functionality of the communication application <b>200</b> at a remote computer. More specifically, the UI add-on module <b>214</b> provides some or all of the functions of the UI module <b>204</b> for use by a remote computer. Meanwhile, the domain add-on module <b>220</b> provides some or all of the functions of the management module <b>202</b> for use by a remote computer.

0032Each of the communication applications described herein (e.g., communication applications <b>110</b>, <b>142</b>, <b>200</b>) may correspond to an application that is stored on a computer-readable medium for execution by a processor. When executed by a processor, a communication application causes a processor to select one of a plurality of CETs based on user input and provide a conferencing session based on AEC parameters corresponding to the selected CET. A communication application, when executed, may further cause a processor to select between an office room CET, a conference room CET, and an auditorium CET based on user input. A communication application, when executed, may further cause a processor to select one of the plurality of CETs based on room size input, room shape input, speaker location input, and microphone location input. A communication application, when executed, may further cause a processor to implement AEC based on parameters such as a suppression method parameter, a suppression level parameter, a rate of adaptation parameter, estimation filter size parameters, regularization parameters, sensitivity to double-talk parameters, noise level estimates, and overall parameters that control adaptation behavior. More specifically, a communication application, when executed, may further cause a processor to implement AEC based on an echo suppression method parameter and an echo suppression level parameter that selectively vary for different CETs. Additionally or alternatively, a communication application, when executed, may further cause a processor to implement AEC based on an estimation filter size parameter, an adaptation rate parameter, and a double-talk sensitivity parameter that selectively vary for different CETs.

0033<figref idrefs="DRAWINGS">FIG. 3</figref> illustrates components of a media pipeline <b>300</b> in accordance with an embodiment of the disclosure. The media pipeline <b>300</b> is abstracted by software (e.g., Nizza software) as tasks that are connected together. In accordance with at least some embodiments, at least some of the disclosed AEC features are part of a media pipeline such as media pipeline <b>300</b>. As shown, the media pipeline <b>300</b> comprises a “DS Source” block <b>302</b> connected to a converter block <b>308</b>. The DS Source block <b>302</b> represents a digital media source (e.g., a web-cam) and the converter block <b>308</b> converts the digital media (e.g., video data) from the digital media source <b>302</b> from one format to another. As an example, the converter block <b>308</b> may change the color space of video data from a RGB pixel format to YUV format. The converted video data from the converter block <b>308</b> is provided to a compressor block <b>316</b> to compress the converted video data. The converted/compressed video data (CCVD) is then sent to a network sender block <b>342</b>, which prepares the CCVD for transmission via a network. The network sender block <b>342</b> also receives converted/compressed audio data (CCAD) for transmission via a network. The audio data stream initiates at the Audio Stream Input/Output (ASIO) block <b>332</b>, which handles data received from one or more microphones. The ASIO block <b>332</b> forwards microphone data to mix block <b>336</b>, which adjusts the audio gain. The output of the mix block <b>336</b> is received by packet buffer <b>326</b> to control the rate of data (providing a latency guarantee). An echo control block <b>328</b> receives the output of the packet buffer <b>326</b> and performs echo cancellation on the audio data. In accordance with at least some embodiments, the operation of echo control block <b>328</b> is based on a user interface, CET selection, CET parameters, and other AEC parameters as disclosed herein.

0034The output of the echo control block <b>328</b> is then provided to transmitter gain block <b>330</b> to selectively adjust the audio transmission gain. The audio data from the transmitter gain block <b>330</b> becomes CCAD by the operation of a fragment <b>1</b> block <b>334</b>, a converter <b>1</b> block <b>338</b>, and an audio compressor block <b>340</b>. As previously mentioned, the CCVD and CCAD are received by network sender block <b>342</b> for transmission via a network.

0035In <figref idrefs="DRAWINGS">FIG. 3</figref>, two participants receive the CCVD and CCAD from the network sender block <b>342</b>. Alternatively, there could be more or less than two participants. With two participants, network receiver blocks <b>304</b>A and <b>304</b>B receive the CCVD and CCAD from the network. The CCVD is passed to decompressor blocks <b>310</b>A and <b>310</b>B, which provides decompressed video for presentation by viewer blocks <b>318</b>A and <b>318</b>B. Meanwhile, the CCAD received by the network receiver blocks <b>304</b>A and <b>304</b>B is provided to audio decompressors <b>314</b>A and <b>314</b>B. The decompressed audio from decompressors <b>314</b>A and <b>314</b>B is converted to another format by converter <b>2</b> block <b>320</b>, then is fragmented by fragment <b>2</b> block <b>322</b>. The output of the converter <b>2</b> block <b>320</b> is provided to receiver gain block <b>324</b> to selectively adjust the receiver gain of the audio data. The output of the receiver gain block <b>324</b> is handled by packet buffer <b>326</b> to control the rate of data (providing a latency guarantee) related to the ASIO block <b>332</b>. The echo control block <b>328</b> receives audio data from the packet buffer <b>326</b> and provides AEC as disclosed herein. The output of the echo control block <b>328</b> is provided to the ASIO block <b>332</b> for presentation by speakers (e.g., left and right speakers).

0036<figref idrefs="DRAWINGS">FIG. 4</figref> illustrates a conferencing technique <b>400</b> in accordance with an embodiment of the disclosure. In <figref idrefs="DRAWINGS">FIG. 4</figref>, the steps begin chronologically at the top (nearest the blocks representing endpoints <b>402</b>, <b>404</b> and instant messaging (IM) server <b>406</b>) and proceed downward. As shown, the IM server <b>406</b> authenticates a user of the endpoint A <b>402</b>. In response, the endpoint A <b>402</b> receives a contact list from the IM server <b>406</b>. Next, the IM server <b>406</b> authenticates a user of the endpoint B <b>404</b>. In response, the endpoint B <b>404</b> receives a contact list from the IM server <b>406</b>. Based on the contact list from the IM server <b>406</b>, endpoint A <b>402</b> sends connection information to the IM server <b>406</b>, which forwards endpoint A connection information to the endpoint B <b>404</b>. Similarly, endpoint B <b>404</b> sends connection information to the IM server <b>406</b>, which forwards endpoint B connection information to the endpoint A <b>402</b>. In other words, the endpoint A <b>402</b> and the endpoint B <b>404</b> exchange primary connection information via the IM server <b>406</b>. Subsequently, the endpoint A <b>402</b> is able to initiate a conference with endpoint B <b>404</b> based on a media pipeline having the disclosed AEC features. After initiation of a conferencing session (e.g., a user of endpoint B <b>804</b> accepts a request to participate in a remote conferencing session with a user of endpoint A <b>802</b>), a media exchange occurs. In accordance with at least some embodiments, AEC is applied during the media exchange based on a user-selected CET with corresponding CET parameters and/or other AEC parameters. Eventually, the conference terminates.

0037<figref idrefs="DRAWINGS">FIG. 5</figref> illustrates a method <b>500</b> in accordance with embodiments of the disclosure. As shown, the method <b>500</b> comprises selecting one of a plurality of CETs based on user input (block <b>502</b>). In some embodiments, selecting one of the plurality of CETs based on user input comprises selecting between an office room template, a conference room template, and an auditorium template based on user input. Additionally or alternatively, selecting one of the plurality of conferencing environment templates based on user input comprises selecting a template based on room size input, room shape input, speaker location input, and microphone location input. The method <b>500</b> further comprises providing a conferencing session based on acoustic echo cancellation (AEC) parameters corresponding to the selected conferencing environment template (block <b>504</b>).

0038The method <b>500</b> may comprise additional steps that are added individually or in combination. As an example, the method <b>500</b> may additionally comprise selectively varying an AEC suppression technique parameter and an AEC suppression level parameter based on CET selection. The method <b>500</b> may additionally comprise selectively varying an AEC estimation filter size parameter, an AEC adaptation rate parameter, and an AEC double-talk sensitivity parameter based on CET selection. The method <b>500</b> may additionally comprise preventing at least some AEC parameters associated with the CETs from being viewed by conference participants.

0039In conclusion, another exemplary embodiment of the disclosed AEC feature is described herein without limitation to other embodiments. The disclosed AEC solution is part of conferencing software referred herein as “Overture”. In the Overture embodiment, AEC can be very efficient if some of the characteristics of the environment are known. Environment characteristics that are relevant to Overture-based AEC include, but are not limited to, the size and shape of the room, background noise level, linearity of the audio input and output devices, volume levels, placement of people, placement of audio input devices, placement of audio output devices, reflectivity of items in the room, and the capabilities of the AEC algorithm. For different CETs at least some of these variables should be adjusted to provide effective AEC.

0040In accordance with the Overture embodiment, approximately 35-40 parameters are defined in relation to AEC operations. The Overture parameters determine how the AEC responds to the environment it is attempting to sample. Although the Overture parameters can be tuned such that AEC works extremely well in one environment, the same tuning is ineffective for other environments. So in accordance with embodiments, varied tuning of Overture AEC parameters is accomplished by establishing a plurality of CETs corresponding to tuned Overture AEC parameters and enabling CET selection based on user input.

0041For example, the user input may enable selection of CETs corresponding to a cubical, an office, a conference room, or an auditorium. The Overture AEC parameters can be easily tuned for each environment. For example, for a cubical environment, Overture AEC parameters may be tuned for a static place with quick return paths. In other words, the cubicle environment template assumes only a couple of users positioned close to the microphone and speakers. Alternatively, an auditorium template may tune Overture AEC parameters for a large room with longer return paths, numerous audience members but few close to the speakers or microphone. Further, the auditorium template may tune Overture AEC parameters for a microphone that moves (i.e., the Overture AEC parameters should allow for quick decision making and adjustment to prevent feedback due to a mobile microphone).

0042The Overture software may provide an audio adjustment panel in both the First-Use-Wizard (FUW) and the settings. Within this panel a user can define a small set of audio properties. One of these properties is the room characteristic. When set, the room characteristic property causes the Overture conferencing subsystem to substitute default or generic AEC parameters with specific AEC parameters corresponding to the selected room characteristic. It should be noted that not all 35-40 parameters need to be specified for each environment. If a given parameter does not exist for the room type specified, the parameter is assigned a default or generic room value. In at least some embodiments, the settings panel may comprise a dropdown box that will allow a user to select a room type. Selecting a room type will then set AEC parameters for the conferencing subsystem.

0043Provided herein is a compilation of various Overture parameters related to controlling audio transmitted via a media pipeline. For each media pipeline parameter, various parameter characteristics are determined such as: “parameter required during conferencing” (characteristic “C1”), “debug only” (characteristic “C2”), “initialized by property default” (characteristic “C3”), “visible in property file” (characteristic “C4”), “negotiated during initialization with conference participant” (characteristic “C5”), “negotiated during initialization of HW” (characteristic “C6”), “visible in the user interface” (characteristic “C7”), “default value” (characteristic “C8”), and “system dependent” (characteristic “C9”). Table 1 shows a listing of Overture parameters and relevant characteristics. In Table 1: “Y” refers to “yes”; “N” refers to “no”; and “D” refers to “it depends”.

0000<tables id="TABLE-US-00001" num="00001"><table frame="none" colsep="0" rowsep="0" pgwide="1"><tgroup align="left" colsep="0" rowsep="0" cols="11"><colspec colname="1" colwidth="105pt" align="left" /><colspec colname="2" colwidth="49pt" align="center" /><colspec colname="3" colwidth="14pt" align="left" /><colspec colname="4" colwidth="14pt" align="left" /><colspec colname="5" colwidth="14pt" align="left" /><colspec colname="6" colwidth="14pt" align="left" /><colspec colname="7" colwidth="14pt" align="left" /><colspec colname="8" colwidth="14pt" align="left" /><colspec colname="9" colwidth="14pt" align="left" /><colspec colname="10" colwidth="49pt" align="center" /><colspec colname="11" colwidth="14pt" align="left" /><thead><row><entry namest="1" nameend="11" rowsep="1">TABLE 1</entry></row><row><entry namest="1" nameend="11" align="center" rowsep="1" /></row><row><entry>PARAMETER</entry><entry>PROPERTY</entry><entry>C1</entry><entry>C2</entry><entry>C3</entry><entry>C4</entry><entry>C5</entry><entry>C6</entry><entry>C7</entry><entry>C8</entry><entry>C9</entry></row><row><entry namest="1" nameend="11" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>SynchMode</entry><entry>Target</entry><entry>Y</entry><entry>N</entry><entry>Y</entry><entry>Y</entry><entry>N</entry><entry>N</entry><entry>N</entry><entry>Target</entry><entry>N</entry></row><row><entry /><entry>Natural</entry></row><row><entry /><entry>Synchronized</entry></row><row><entry>TargetLatency</entry><entry>msec</entry><entry>D</entry><entry>N</entry><entry>Y</entry><entry>Y</entry><entry>N</entry><entry>Y</entry><entry>N</entry><entry>100</entry><entry>N</entry></row><row><entry>AudioCodec</entry><entry>Mpeg</entry><entry>Y</entry><entry>N</entry><entry>Y</entry><entry>Y</entry><entry>Y</entry><entry>N</entry><entry>N</entry><entry>Mpeg</entry><entry>N</entry></row><row><entry /><entry>UMC</entry></row><row><entry>AudioSource</entry><entry>None</entry><entry>Y</entry><entry>N</entry><entry>Y</entry><entry>Y</entry><entry>N</entry><entry>N</entry><entry>N</entry><entry>DirectSound</entry><entry>Y</entry></row><row><entry /><entry>DirectSound</entry></row><row><entry /><entry>File</entry></row><row><entry /><entry>ASIO</entry></row><row><entry /><entry>directKS</entry></row><row><entry /><entry>waveRT</entry></row><row><entry>AudioSink</entry><entry>DirectSound</entry><entry>Y</entry><entry>N</entry><entry>Y</entry><entry>Y</entry><entry>N</entry><entry>N</entry><entry>N</entry><entry>DirectSound</entry><entry>Y</entry></row><row><entry /><entry>ASIO</entry></row><row><entry /><entry>directKS</entry></row><row><entry /><entry>waveRT</entry></row><row><entry>AEC</entry><entry>true</entry><entry>Y</entry><entry>N</entry><entry>Y</entry><entry>Y</entry><entry>N</entry><entry>Y</entry><entry>Y</entry><entry>true</entry><entry>Y</entry></row><row><entry /><entry>false</entry></row><row><entry>Adaptation</entry><entry>true</entry><entry>Y</entry><entry>N</entry><entry>Y</entry><entry>Y</entry><entry>N</entry><entry>N</entry><entry>N</entry><entry>true</entry><entry>N</entry></row><row><entry>Status</entry><entry>false</entry></row><row><entry>Suppression_Method</entry><entry>gain</entry><entry>Y</entry><entry>N</entry><entry>Y</entry><entry>Y</entry><entry>N</entry><entry>N</entry><entry>N</entry><entry>spectrum</entry><entry>N</entry></row><row><entry /><entry>spectrum</entry></row><row><entry /><entry>hybrid</entry></row><row><entry>Suppression_Level</entry><entry>none</entry><entry>Y</entry><entry>N</entry><entry>Y</entry><entry>Y</entry><entry>N</entry><entry>N</entry><entry>N</entry><entry>mild</entry><entry>N</entry></row><row><entry /><entry>mild</entry></row><row><entry /><entry>aggressive</entry></row><row><entry>Mute_Near_End</entry><entry>true</entry><entry>Y</entry><entry>N</entry><entry>Y</entry><entry>Y</entry><entry>Y</entry><entry>N</entry><entry>Y</entry><entry>false</entry><entry>N</entry></row><row><entry /><entry>false</entry></row><row><entry>RX_Gain</entry><entry /><entry>Y</entry><entry>N</entry><entry>Y</entry><entry>Y</entry><entry>N</entry><entry>N</entry><entry>Y</entry><entry>1.0</entry><entry>N</entry></row><row><entry>TX_Gain</entry><entry /><entry>Y</entry><entry>N</entry><entry>Y</entry><entry>Y</entry><entry>N</entry><entry>N</entry><entry>N</entry><entry>1.0</entry><entry>N</entry></row><row><entry>MicGain</entry><entry /><entry>Y</entry><entry>N</entry><entry>Y</entry><entry>Y</entry><entry>N</entry><entry>N</entry><entry>N</entry><entry>1.0</entry><entry>N</entry></row><row><entry>loadStateData</entry><entry>true</entry><entry>N</entry><entry>N</entry><entry>Y</entry><entry>Y</entry><entry>N</entry><entry>N</entry><entry>N</entry><entry>false</entry><entry>N</entry></row><row><entry /><entry>false</entry></row><row><entry>loadStateFile_Name</entry><entry>path</entry><entry>N</entry><entry>N</entry><entry>Y</entry><entry>Y</entry><entry>N</entry><entry>N</entry><entry>N</entry><entry>?</entry><entry>N</entry></row><row><entry>saveStateData</entry><entry>true</entry><entry>N</entry><entry>N</entry><entry>Y</entry><entry>Y</entry><entry>N</entry><entry>N</entry><entry>N</entry><entry>N</entry><entry>N</entry></row><row><entry /><entry>false</entry></row><row><entry>saveStateFile_Name</entry><entry>path</entry><entry>N</entry><entry>Y</entry><entry>Y</entry><entry>Y</entry><entry>N</entry><entry>N</entry><entry>N</entry><entry>?</entry><entry>N</entry></row><row><entry>gAudioVerbosity</entry><entry>true</entry><entry>Y</entry><entry>Y</entry><entry>Y</entry><entry>Y</entry><entry>N</entry><entry>N</entry><entry>N</entry><entry>false</entry><entry>N</entry></row><row><entry /><entry>false</entry></row><row><entry>Calibration_Noise_STD</entry><entry /><entry>Y</entry><entry>N</entry><entry>Y</entry><entry>Y</entry><entry>N</entry><entry>N</entry><entry>N</entry><entry>0.02</entry><entry>N</entry></row><row><entry>numMicrophones</entry><entry>1-4</entry><entry>Y</entry><entry>Y</entry><entry>Y</entry><entry>Y</entry><entry>N</entry><entry>Y</entry><entry>N</entry><entry>1</entry><entry>N</entry></row><row><entry>micsMixWeights</entry><entry>float</entry><entry>Y</entry><entry>Y</entry><entry>Y</entry><entry>Y</entry><entry>N</entry><entry>N</entry><entry>N</entry><entry>1.0</entry><entry>N</entry></row><row><entry /><entry>float</entry></row><row><entry>samplingRate</entry><entry>44100</entry><entry>Y</entry><entry>Y</entry><entry>Y</entry><entry>Y</entry><entry>Y</entry><entry>Y</entry><entry>N</entry><entry>48000</entry><entry>N</entry></row><row><entry /><entry>48000</entry></row><row><entry>ASIO_Data_Size</entry><entry>44100</entry><entry>Y</entry><entry>Y</entry><entry>Y</entry><entry>Y</entry><entry>N</entry><entry>Y</entry><entry>N</entry><entry>640</entry><entry>Y</entry></row><row><entry /><entry>144</entry></row><row><entry /><entry>288</entry></row><row><entry /><entry>576</entry></row><row><entry /><entry>1152</entry></row><row><entry /><entry>48000</entry></row><row><entry /><entry>160</entry></row><row><entry /><entry>320</entry></row><row><entry /><entry>640</entry></row><row><entry /><entry>1280</entry></row><row><entry>Slide_Win_Size</entry><entry>44100</entry><entry>Y</entry><entry>Y</entry><entry>Y</entry><entry>Y</entry><entry>N</entry><entry>Y</entry><entry>N</entry><entry>320</entry><entry>Y</entry></row><row><entry /><entry>144</entry></row><row><entry /><entry>288</entry></row><row><entry /><entry>576</entry></row><row><entry /><entry>1152</entry></row><row><entry /><entry>48000</entry></row><row><entry /><entry>160</entry></row><row><entry /><entry>320</entry></row><row><entry /><entry>640</entry></row><row><entry /><entry>1280</entry></row><row><entry>History_Win_Size</entry><entry>2-5</entry><entry>Y</entry><entry>Y</entry><entry>Y</entry><entry>Y</entry><entry>N</entry><entry>Y</entry><entry>N</entry><entry>4</entry><entry>Y</entry></row><row><entry>AEC_Len</entry><entry>integer</entry><entry>Y</entry><entry>Y</entry><entry>Y</entry><entry>Y</entry><entry>N</entry><entry>Y</entry><entry>N</entry><entry>6600</entry><entry>Y</entry></row><row><entry /><entry>6600, 14000</entry></row><row><entry>DC_Offset_Filter_Value</entry><entry> 0.9-0.999</entry><entry>Y</entry><entry>Y</entry><entry>Y</entry><entry>Y</entry><entry>N</entry><entry>N</entry><entry>N</entry><entry>0.99</entry><entry>N</entry></row><row><entry>Delay_Block</entry><entry>integer</entry><entry>Y</entry><entry>Y</entry><entry>Y</entry><entry>Y</entry><entry>N</entry><entry>Y</entry><entry>N</entry><entry>4</entry><entry>D</entry></row><row><entry>Mu_Htil</entry><entry>float</entry><entry>Y</entry><entry>Y</entry><entry>Y</entry><entry>Y</entry><entry>N</entry><entry>N</entry><entry>N</entry><entry>0.2</entry><entry>N</entry></row><row><entry>Noise_Power</entry><entry>float</entry><entry>Y</entry><entry>Y</entry><entry>Y</entry><entry>Y</entry><entry>N</entry><entry>N</entry><entry>N</entry><entry>0.000001</entry><entry>N</entry></row><row><entry>NearEnd_Power</entry><entry>float</entry><entry>Y</entry><entry>Y</entry><entry>Y</entry><entry>Y</entry><entry>N</entry><entry>N</entry><entry>N</entry><entry>0.00001</entry><entry>N</entry></row><row><entry>FarEnd_Power</entry><entry>float</entry><entry>Y</entry><entry>Y</entry><entry>Y</entry><entry>Y</entry><entry>N</entry><entry>N</entry><entry>N</entry><entry>0.00001</entry><entry>N</entry></row><row><entry>DTD_Threshold</entry><entry>float</entry><entry>Y</entry><entry>Y</entry><entry>Y</entry><entry>Y</entry><entry>N</entry><entry>N</entry><entry>N</entry><entry>0.00001</entry><entry>N</entry></row><row><entry>BLK_Num_Decision</entry><entry>float</entry><entry>Y</entry><entry>Y</entry><entry>Y</entry><entry>Y</entry><entry>N</entry><entry>N</entry><entry>N</entry><entry>10</entry><entry>N</entry></row><row><entry>DTCohTime</entry><entry>integer</entry><entry>Y</entry><entry>Y</entry><entry>Y</entry><entry>Y</entry><entry>N</entry><entry>N</entry><entry>N</entry><entry>25</entry><entry>N</entry></row><row><entry>Lagrange</entry><entry>float</entry><entry>Y</entry><entry>Y</entry><entry>Y</entry><entry>Y</entry><entry>N</entry><entry>N</entry><entry>N</entry><entry>0.00001</entry><entry>N</entry></row><row><entry>Shadow_Estimate_Power_FAC</entry><entry>float</entry><entry>Y</entry><entry>Y</entry><entry>Y</entry><entry>Y</entry><entry>N</entry><entry>N</entry><entry>N</entry><entry>0.99</entry><entry>N</entry></row><row><entry>Room_Change_Decision_Lag</entry><entry>integer</entry><entry>Y</entry><entry>Y</entry><entry>Y</entry><entry>Y</entry><entry>N</entry><entry>N</entry><entry>N</entry><entry>4</entry><entry>N</entry></row><row><entry>Adapt_CNT_Init</entry><entry>integer</entry><entry>Y</entry><entry>Y</entry><entry>Y</entry><entry>Y</entry><entry>N</entry><entry>N</entry><entry>N</entry><entry>400</entry><entry>N</entry></row><row><entry>PFPDControl</entry><entry>float</entry><entry>Y</entry><entry>Y</entry><entry>Y</entry><entry>Y</entry><entry>N</entry><entry>N</entry><entry>N</entry><entry>20</entry><entry>N</entry></row><row><entry>scaleError_Spectrum</entry><entry>float</entry><entry>Y</entry><entry>Y</entry><entry>Y</entry><entry>Y</entry><entry>N</entry><entry>N</entry><entry>N</entry><entry>0.2</entry><entry>N</entry></row><row><entry>scaleHhat_Spectrum</entry><entry>float</entry><entry>Y</entry><entry>Y</entry><entry>Y</entry><entry>Y</entry><entry>N</entry><entry>N</entry><entry>N</entry><entry>10</entry><entry>N</entry></row><row><entry namest="1" nameend="11" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0044From Table 1, the SynchMode parameter defines the audio and video synchronization mode before driving the speakers. SynchMode is valid for audio modes such as DirectSound and DirectShow, but synchronization is not done for ASIO. With ASIO, the Nizza network receiver spits out the audio and video streams and hopes for the best. The SynchMode property is “target”, “natural” or “synchronized”. The “target” property matches a specified targeted latency and pushes audio out when the real latency is within 5% of the target latency. The “natural” property plays as soon as the AudioSink routine has a packet to process. The “synchronized” property synchronizes the video window with the audio output.

0045The TargetLatency parameter is the target latency of the audio output or speaker block. The target latency is not used for the ASIO driver and is only valid when SynchMode is set to Target. The AudioCodec and AudioCodecMode parameters define the codec mode for the audio decompressor connected to the network receiver for conferencing. The codec mode does not define the compression mode associated with the audio compressor block. The compression mode is always forced to Mpeg2. The decompression mode is defined by the participants. For conferencing, the audio codec can be reduced to a single parameter which is negotiated with each connection. In such case, a separate compressor and decompressor is used per connection.

0046The AudioSource parameter determines the interface for receiving an audio source. As an example, AudioSource may be selected as either “none”, DirectSound, file, ASIO, directKS, or waveRT. “None” implies that no audio input will be enabled for conferencing. The “file” type is not specified as it will be interpreted when the file is opened. The AudioSink parameter determines what API to use when conferencing audio is output. As an example, AudioSink may be selected as DirectSound, ASIO, directKS, or waveRT.

0047The AEC parameter enables/disables the echo cancellation. For conferencing, echo cancellation is enabled only when ASIO is the audio interface. Further, echo cancellation may be disabled based on the audio interface or audio device. For example, if the user chooses a headphone for conferencing, echo cancellation may be disabled. When echo cancellation is disabled the user interface may block the user from adjusting other AEC parameters.

0048The Adaptation_Status parameter enables the echo cancellation circuit to update its filter parameters. If Adaptation_Status is disabled, then the shadow filter and main filters are not updated. In such case, echo cancellation may still be performed based on prefined or default values. The Suppression_Method parameter defines a method of reducing the residual echo and noise. The Suppression_Method property is “gain”, “spectrum” or “hybrid” and is associated with a module that attempts to hide transition times of the echo canceller. In at least some embodiments, the suppression method is applied after the echo cancellation is added. The “gain” property reduces the overall signal strength of the audio input after the echo cancellation is removed. The gain is adjusted between a minimum and maximum gain level. The minimum gain is adjusted based on the suppression level. An aggressive suppression level causes the minimum gain to be low allowing more adjustment to the signal. The “spectrum” property compares the spectrum of the data after echo cancellation to the spectrum of the data coming from the network. In some embodiments, temporal averaging is applied during the spectrum estimation. The “hybrid” property applies an adjustment to the input signal after echo cancellation by: 1) applying an adjustment based on the spectrum; and 2) applying an adjustment based on gain. The input to this block from the network is delayed by the specified “Delay_Block” parameter.

0049The Suppression_Level parameter operates with a selected suppression method to determine how much to dampen the audio input in an attempt to hide errors in the echo cancellation. The Suppression_Level property may be “none”, “mild” or “aggressive”. The “none” property disables the suppression code such that the suppression method is irrelevant. The “mild” property attempts to minimally dampen the audio input when the echo control tries to adapt to changes in the room. The “aggressive” property makes more aggressive change to the audio input when the echo control tries to adapt to changes in the room. In stable environments, the “mild” and “aggressive” properties make no noticeable difference in the audio quality. However, in changing environments the “mild” property performs better than the “aggressive” property. Accordingly, the “mild” property is the default for the Suppression_Level parameter. The Mute_Near_End parameter mutes the local signal so that it is not sent to the remote systems. This feature is sometimes used during conferencing.

0050There are several gain parameters to control the audio pipeline for Overture conferencing. If the gains are larger than one; clipping can occur. The RX_Gain parameter is used for signals received from the remote system. For conferencing, an RX_Gain per connection is needed. The TX_Gain parameter is used for signals transmitted from the local system to all remote systems. When more than one system is connected there will still be only one TX_Gain parameter. The MicGain parameter is used to increase the microphone volume locally. There should be one microphone volume control for conferencing. MicGain is applied to the microphone signal after all microphone inputs are combined using the weighted micMixedWeights parameter mentioned below.

0051The loadStateData parameter tells Nizza whether to load the pre-calibrated impulse response and other state information. The loadStateData parameter is enabled based on the initial setup procedure. For example, if a calibration step is performed and a file is stored, then loading the state data may occur. If a calibration is not performed, then loading of state data makes does not occur. The loadStateFileName parameter is used to point to the pre-calibrated impulse response and other state information. Whether it is read is dependent on the loadStateData parameter mentioned above. The saveStateData parameter tells Nizza whether to save an impulse response file for initialization at the next startup. The saveStateFileName parameter is used to point to the location to store the precalibrated impulse response and other state information. Under normal usage it should match the location of the loadStateFileName.

0052Various diagnostic parameters are described herein. The gAudioVerbosity parameter is enabled to show echo control diagnostic information in a command window or log. The Calibration_Noise_STD parameter is a float value used to define the standard deviation of calibration noise. Exciting the system with noise that is uniform in the frequency spectrum allows for a richer excitation of the system and better echo cancellation parameters.

0053The numMicrophones parameter specifies the number of microphones in the system. For each microphone a pin is created on the ASIO driver which is then sent to the mixer. The mixer combines all inputs so that a single mono signal is sent to both the echo control and the remote systems. Any microphone gain specified is applied before the combination of inputs. If there is a single microphone gain, this gain is applied equally to all microphone inputs. The micsMixWeights parameter accumulates the microphone signals as defined for each microphone input. The micsMixWeights value determines the specific weighting to apply for the associated microphone. This weighting is applied before MicGain is applied.

0054The numLoadspeakers parameter defines the number of loadspeakers in Nizza with a maximum of 4. The selected value determines the number of output pins to define for ASIO. The samplingRate parameter is the audio sampling frequency. Additional sampling frequencies (in addition to 44100 and 48000) may be supported in Overture conferencing. If a participant joining a conference does not match the local sampling rate then either the sampling rate must change locally, or a re-sampling block needs to be inserted to take care of the new sampling frequency from the participant. The ASIO_Data_Size parameter is the default ASIO buffer size. This parameter is set, for example, based on negotiation with the hardware. The Slide_Win_Size parameter defines the number of samples to use when processing both the echo cancellation and the post processing suppression. The value of Slide_Win_Size is a divisor of ASIO_Buffer_Size and should be determined automatically during system initialization.

0055The History_Win_Size parameter is an integer number that defines the number of slide windows used as history in decision making. This value will affect performance. The history window size is set in light of the FFT sizes. The FFT sizes are in powers of two. The AEC_Len parameter is an integer value that defines the length of the adaptive filter. The DC_Offset_Filter_Value parameter determines the value for DC offset removal filter. Nizza currently defines a minimum value of 0.8 and a maximum value of 0.9999 for this value. The DC_Offset_Filter_Value removes the dc offset from both the packets coming in from the network and the packets from the microphone. The Delay_Block parameter defines an integer compensation value for the delay introduced in Nizza in the near-end loop. The data from the network used in the echo control is delayed by the value of Delay_Block to compensate for the hardware delay (audio out=>audio in).

0056Various parameters set the initial state for echo cancellation. The Mu_Htil parameter defines the adaptation step size and affects the accuracy and speed of convergence. Nizza defines a range 0.01 to 0.99 for Mu_Htil. The Noise_Power parameter is a float value for the initial background noise power. Nizza defines a range of 0.001 to 0.000001 for Noise_Power. The NearEnd_Power parameter is a float value for the initial signal power. Nizza defines a range of 0.01 to 0.00001 for NearEnd_Power. The FarEnd_Power is a float value for the far-end signal power. Nizza defines a range of 0.01 to 0.0001 for FarEnd_Power. The DTD_Threshold parameter is a float value for the initial double-talk detection threshold. The BLK_Num_Decision parameter is an integer value that defines the number of blocks of Slide_Win_Size used to make a decision about double-talk. As BLK_Num_Decision increases in value, there is more delay and potential accuracy in determining double-talk. “Double-talk” refers to when both local and remote participants are talking. During double-talk, the shadow filter and main filters cannot be updated. The DTCohTime parameter is an integer value that defines the number of blocks of Slide_Win_Size used for hysteresis of the double-talk state. The Slide_Win_Size value is selected to prevent the AEC algorithm from switching in and out of the double-talk state too quickly.

0057The Lagrange parameter is a float value for the nominal value for a lagrange multiplier in suboptimal optimization. This parameter sacrifices accuracy for stability and is used to stabilize the behavior of the AEC algorithm. Nizza defines a range of 0.00001 to 1.0 for Lagrange. The Shadow_Estimate_Power_FAC parameter is a float value for averaging in spectrum estimation and affects how agile the shadow is. Shadow_Estimate_Power_FAC also affects double-talk detection and hence the convergence. The Room_Change_Decision_Lag parameter is an integer value defining the number of blocks used as a lag in making decisions about room change. As the Room_Change_Decision_Lag value increases, the echo canceller takes longer to determine that a room has changed. This prevents the AEC algorithm from declaring a room change unless it is noticeable. The Adapt_CNT_Init parameter is a positive integer value used in adaptive tracking of the room impulse response. The Adapt_CNT_Init value controls how fast the AEC algorithm needs to react to a room change.

0058The PFPDControl parameter is a float value used in controlling the probably of false alarms versus probability of detection. As the PFPFControl value increases, the AEC algorithm is more sensitive to declare double-talk. Also, as the PFPFControl value increases, NLP would be less aggressive and the echo might be heard more often. The scaleErrorSpectrum parameter is a float value for scaling the error spectrum in the preconditioning matrix. The Nizza software takes a ratio of the maximum power from the network with the maximum power from the microphone and scales it by the scaleErrorSpectrum value. The scaled value is used to define the error spectrum and affects stability of echo cancellation. The scaleHhatSpectrum parameter is a float value for scaling the average that spectrum in the preconditioning matrix.

0059In accordance with at least some embodiments, at least some of the Overture parameters described above are varied for different CETs selectable based on user input. Without limitation to other embodiments, CETs selection may affect an AEC suppression method parameter (e.g., “Suppression_Method”), an AEC suppression level parameter (e.g., “Suppression_Level”), an AEC rate of adaptation parameter (e.g., “samplingRate”), AEC estimation filter size parameters (e.g., “AEC_Len”, “ASIO_data_size”, and “history_win_size”), and sensitivity to double-talk parameters (e.g., “slide_win_size”, “BLK_Num_Decision”, and “delay block”). As a specific example, for a sampling frequency of 4 KHz, the AEC_Len value may be 7000 for CET of a cubicle or a conference room with sound treatment. However, for the CET of a conference room (size 10 ft*12 ft*18 ft) without sound treatment, the AEC_Len value may be about 12000 to 15000.

0060The above discussion is meant to be illustrative of the principles and various embodiments of the present invention. Numerous variations and modifications will become apparent to those skilled in the art once the above disclosure is fully appreciated. It is intended that the following claims be interpreted to embrace all such variations and modifications.