Patent Description:
This disclosure generally relates to personal active noise reduction (ANR) devices. More particularly, the disclosure relates to a computational architecture for efficiently handling disparate ANR processing functions.

Headphones and other physical configurations of personal ANR device worn about the ears of a user for purposes of isolating the user's ears from unwanted environmental sounds have become commonplace. ANR headphones counter unwanted environmental noise with the active generation of anti-noise signals. These ANR headphones contrast with passive noise reduction (PNR) headsets, in which a user's ears are simply physically isolated from environmental noises. Especially of interest to users are ANR headphones that also incorporate audio listening functionality, thereby enabling a user to listen to electronically provided audio (e.g., playback of recorded audio or audio received from another device) without the intrusion of unwanted environmental noise.

As ANR devices become more popular, the demand to increase performance and add more robust features drives the need for more complex computational requirements. For example, in addition to providing state of the art signal processing, ANR devices are tasked with providing enhanced features such as providing multiple I/O ports (e.g., Bluetooth, USB, etc.), high quality telephony services, noise level control management, event handling, user experience command processing, etc. With increased computational requirements, both cost and power consumption are increased as more complex hardware is added to ANR devices.

<CIT>, <CIT>, <CIT> and <CIT> disclose prior art active noise reduction devices.

The present invention relates to a personal active noise reduction device and an active noise reduction computational architecture according to the independent claims. Advantageous embodiments are set forth in the dependent claims.

Systems and methods are disclosed that describe a computational architecture for efficiently handling disparate ANR processing functions in an ANR device.

The described computational architecture includes at least three distinct processors, each configured to perform a set of computational functions suited to the individual processor. In these cases, the architecture allows different types of required functions to be handled by a processor that aligns with the requirements (e.g., priority, speed, memory resources) of the task. By dividing functions amongst the different processors, computational efficiencies are gained and power consumption is reduced.

One aspect provides a personal active noise reduction (ANR) device, that includes, among other parts, a communication interface configured to receive a source audio stream and control signals; a driver; a microphone system; and an ANR computational architecture.

The ANR computational architecture includes also: a first DSP processor configured to: receive the source audio stream and signals from the microphone system, perform ANR on the source audio stream according to a set of operational parameters deployed in the first DSP processor, and output a processed audio stream to the driver; a second DSP processor configured to: generate state data in response to an analysis of at least one of the source audio stream, signals from the microphone system, and the processed audio stream; and alter the set of operational parameters on the first DSP; and a general purpose processor operationally coupled to the first DSP processor and the second DSP processor and configured to: communicate control signals with the communication interface, process state data from the second DSP processor, and alter the set of operational parameters on the first DSP processor.

Implementations may include one of the following features, or any combination thereof.

In certain aspects, the operational parameters are selected from a group consisting of: filter coefficients, compressor settings, signal mixers, gain terms, and signal routing options.

In other aspects, the state data generated by the second DSP processor includes error conditions detected in the processed audio stream.

In further aspects, the state data generated by the second DSP processor includes frequency domain overload conditions detected in the processed audio stream.

In some implementations, the state data generated by the second DSP includes sound pressure level (SPL) information detected from the microphone system and processed audio stream.

In further implementations, the communication interface includes a Bluetooth system.

In particular cases, the general purpose processor includes a sleep mode to conserve power, and wherein the sleep mode is configured to be woken by at least one of the first DSP processor, second DSP processor and the communication interface.

In certain aspects, the general purpose processor is further configured to apply machine learning to the state data received from the second DSP processor.

In particular implementations, the general purpose processor is further configured to apply machine learning to time-based signals. In some cases, the time-based signals include blocks of raw audio data received from a microphone system and/or via a Bluetooth system.

In other aspects, the operational parameters include filter coefficients and the general purpose processor is further configured to calculate and install updated filter coefficients on the first DSP processor.

In some cases, the general purpose processor is further configured to: evaluate the state data to identify a damage condition with the personal ANR.

Two or more features described in this disclosure, including those described in this summary section, may be combined to form implementations not specifically described herein, as far as as they fall within the scope of the invention as set forth in the accompanying claims.

Other features, objects and benefits will be apparent from the description and drawings, and from the claims.

It is noted that the drawings of the various implementations are not necessarily to scale. The drawings are intended to depict only typical aspects of the disclosure, and therefore should not be considered as limiting the scope of the implementations.

Various implementations of the disclosure describes a computational architecture for an active noise reduction (ANR) device that includes at least three distinct processors, each configured to perform a set of computational functions suited to the individual processor. The architecture thus allows each required function to be handled by a processor that aligns with the requirements (e.g., priority, speed, memory resources) of the task. By dividing functions amongst the different processors, computational efficiencies can be gained and power consumption may be reduced.

While this disclosure provides an architecture for devices such as headphones that employ ANR, an exhaustive description of ANR is omitted for brevity purposes. To the extent necessary, illustrative ANR systems are for example described in <CIT>, and <CIT>.

The solutions disclosed herein are intended to be applicable to a wide variety of personal ANR devices, i.e., devices that are structured to be at least partly worn by a user in the vicinity of at least one of the user's ears to provide ANR functionality for at least that one ear. It should be noted that although various specific implementations of personal ANR devices may include headphones, two-way communications headsets, earphones, earbuds, audio eyeglasses, wireless headsets (also known as "earsets') and ear protectors, presentation of specific implementations are intended to facilitate understanding through the use of examples, and should not be taken as limiting either the scope of disclosure or the scope of claim coverage.

Additionally, the solutions disclosed herein are applicable to personal ANR devices that provide two-way audio communications, one-way audio communications (i.e., acoustic output of audio electronically provided by another device), or no communications, at all. Further, what is disclosed herein is applicable to personal ANR devices that are wirelessly connected to other devices, that are connected to other devices through electrically and/or optically conductive cabling, or that are not connected to any other device, at all. These teachings are applicable to personal ANR devices having physical configurations structured to be worn in the vicinity of either one or both ears of a user, including and not limited to, headphones with either one or two earpieces, over-the-head headphones, behind-the neck headphones, headsets with communications microphones (e.g., boom microphones), wireless headsets (i.e., earsets), audio eyeglasses, single earphones or pairs of earphones, as well as hats, helmets, clothing or any other physical configuration incorporating one or two earpieces to enable audio communications and/or ear protection.

Beyond personal ANR devices, what is disclosed and claimed herein is also meant to be applicable to the provision of ANR in relatively small spaces in which a person may sit or stand, including and not limited to, phone booths, car passenger cabins, etc..

<FIG> depicts a block diagram of a personal ANR device <NUM>, which in one example may be structured to be worn by a user to provide active noise reduction (ANR) in the vicinity of at least one of the user's ears. The personal ANR device <NUM> may have any of a number of physical configurations, including configurations that incorporate a single earpiece to provide ANR to only one of the user's ears, others that incorporate a pair of earpieces to provide ANR to both of the user's ears, and others that incorporate one or more standalone speakers to provide ANR to the environment around the user. However, it should be noted that for the sake of simplicity of discussion, only a single device <NUM> is depicted and described in relation to <FIG>. As will also be explained in greater detail, the personal ANR device <NUM> incorporates functionality that may provide either or both feedback-based ANR and feedforward-based ANR, in addition to possibly further providing pass-through audio.

In the illustrative embodiment of <FIG>, ANR device <NUM> includes a wireless communication interface, in this case Bluetooth system <NUM>, that provides communications with an audio gateway device (or simply, gateway device) <NUM>, such as a smartphone, wearable smart device, laptop, tablet, server, etc. Bluetooth system <NUM> may for example be implemented as a Bluetooth System-On-Chip (SoC), Bluetooth Low Energy (BLE) module, or in any other manner. It is noted that while ANR device <NUM> is shown using a Bluetooth system <NUM> to provide wireless communications, any type of wireless technology could be used in its place (e.g., Wi-Fi Direct, Cellular, etc.). Communication with the ANR device <NUM> may also occur via a first universal serial bus (USB) port <NUM> that interfaces with Bluetooth system <NUM> and/or a second USB port <NUM> that interfaces with a general purpose (GP) processor <NUM>. GP processor <NUM> is one of at least three processors implemented on ANR device <NUM>, the others being a first digital signal processing (DSP) processor <NUM> and a second DSP processor <NUM>, the two of which form a DSP system <NUM>.

In a typical application, a source audio stream <NUM> is received via the Bluetooth system <NUM> from gateway device <NUM> and passed to the DSP system <NUM>, where the first DSP processor <NUM> performs ANR and generates a processed audio stream <NUM>, which is then broadcast via an acoustic driver <NUM> (i.e., speaker). A microphone system <NUM> captures environmental noise sounds that are provided to the DSP system <NUM> to, e.g., provide a reference signal for generating anti-noise sounds for ANR. For instance, using the captured sounds, anti-noise signals are calculated and output by the acoustic driver <NUM> with amplitudes and time shifts calculated to acoustically interact with unwanted noise sounds in the surrounding environment. Microphone system <NUM> may also be used to capture the user's voice for telephony applications and the like which can be communicated via an output audio stream <NUM> to the Bluetooth system <NUM>, and then to gateway device <NUM>. It is understood that the number and position of individual microphones in the microphone system <NUM> will depend on the particular requirements of the ANR device <NUM>. In addition, as noted, rather than using Bluetooth system <NUM> to communicate with gateway device <NUM>, any type of communication interface may be implemented, e.g., USB ports <NUM>, <NUM> or other communication ports and protocols (not shown).

In addition to audio streams, control signals <NUM> can also be communicated between the gateway device <NUM> and the GP processor <NUM>. Control signals <NUM> may for example include: data packets from the gateway device <NUM> (e.g., to update controllable noise cancellation (CNC) levels); ANR device generated data packets that are communicated to the gateway device <NUM> (e.g., to provide coordination between a pair of ear buds); user generated control signals (e.g., skip to the next song, answer the phone, set CNC levels, etc.), etc. Moreover, as explained in further detail herein, GP processor <NUM> can generate feedback <NUM> (e.g., product usage characteristics, fault detections, etc.) that can be reported back to the gateway device <NUM> and/or to a remote service such as cloud platform <NUM>. Feedback <NUM> can for example be used to enhance the user experience by providing details regarding how the ANR device <NUM> is used, reporting on error conditions, etc..

ANR device <NUM> generally includes additional components, which are omitted for brevity, including, e.g., a power source, visual input/outputs such as a GUI and/or LED indicators, tactile inputs/outputs, power and control switches, additional memory, capacitive inputs, sensors, etc..

As noted, the computational architecture of ANR device <NUM> utilizes at least three distinct processors that provide a modular and hierarchical operational platform for implementing functions associated with the ANR device <NUM>. Using this architecture, the processing capabilities of each processor are aligned with specific tasks to enhance the efficiency of the system. In general, the first DSP processor <NUM> provides a set of core ANR algorithms <NUM> designed to provide active noise reduction to the audio stream <NUM>; the second DSP processor <NUM> provides a set of signal analytics (SA) algorithms <NUM> designed to analyze the ANR operations and provide state data such as operational characteristics, faults, etc., as well as automatically adjust parameters within ANR algorithms <NUM> in response to any available signals within ANR device <NUM>; and the GP processor <NUM> provides a set of high level functions <NUM> such as managing user controls, providing I/O processing, handling events generated by the DSP system <NUM>, implementing power mode levels, etc..

<FIG> depicts the processer hierarchy and characteristics in greater detail. The first DSP processor <NUM> and second DSP processor <NUM> share a common bus <NUM> such that they both have access to the GP processor <NUM>, microphone system <NUM>, audio streams, etc. As noted herein, the first DSP processor <NUM> includes a set of core ANR algorithms <NUM> that process an inputted audio stream <NUM> (<FIG>), including for example, feedback loop processing, compensator processing, feed forward loop processing, and audio equalization. The core ANR algorithms <NUM> may include operational ANR parameters that, for example, dictate filter coefficients, compressor settings, signal mixers, gain terms, signal routing options, etc. Core ANR algorithms <NUM> can generally be characterized as processes that are stream processing oriented and require a high level of processor performance but relatively low complexity. In particular, the functions performed by the core ANR algorithms <NUM> are intended to operate extremely quickly with a minimal amount of processing options and storage requirements. For these types of stream processing functions, very low latency is required, e.g., on the order of <NUM>-<NUM> microseconds. Additionally, because the first DSP processor <NUM> provides the core ANR functionality, the first DSP processor <NUM> must be continuously powered on so long as the ANR device <NUM> is operational. The first DSP processor <NUM>, consequently, is tailored to implement calculations for ANR algorithms <NUM> using as little power as possible.

The second DSP processor <NUM> includes a set of signal analytics algorithms <NUM> that do not directly provide ANR processing, but instead analyze signals and generate state data that, e.g., characterize signals within the ANR device <NUM> and ANR processing being performed by the first DSP processor <NUM>. The state data may include, for example, fault information, instability detection, performance characteristics, error conditions, frequency domain overload conditions, sound pressure level (SPL) information etc. The signal analytics algorithms <NUM> perform different types of analysis that may employ threshold values and rules. For instance, if a series of frequency characteristics deviate from an expected range, a fault can be triggered causing a corresponding "event" to be outputted to the GP processor <NUM>, which can then take corrective action.

Any process adapted to analyze signals can be deployed in the second DSP processor <NUM>. Non-limiting illustrative signal analytics algorithms <NUM> are described, for example, in: <CIT>, entitled, "Real-time detection of feedback instability" (e.g., describing instability detection); <CIT>, entitled, "Parallel Compensation in Active Noise Reduction Devices"; <CIT>, entitled, "Dynamic Compensation in Active Noise Reduction Devices"; <CIT>, entitled Automatic Gain Control in Active Noise Reduction (ANR) Signal Flow Path" (e.g., describing overload conditions); and <CIT>, entitled, "Compressive Hear-through in Personal Acoustic Devices" (e.g., describing control of ANR to produce maximum loudness at the ear).

As noted herein, the second DSP processor <NUM> can also directly alter the operational (i.e., ANR) parameters of the first DSP processor <NUM>. For example, in particular cases, the signal analytics algorithms <NUM> are deployed to automatically adjust ANR parameters (i.e., within core ANR algorithms <NUM>) to achieve a desired experience based upon internal signals captured from algorithms <NUM>, <NUM>, from GP processor <NUM>, from any of the microphones <NUM>, from the input audio stream <NUM>, and/or from control signals <NUM>. For example, in certain implementations, ANR parameters are adjusted using external signals monitored by algorithms <NUM> such as external sound pressure level (SPL) characteristics received by the microphone(s) <NUM>.

Because the second DSP processor <NUM> does not directly implement core ANR services, a relatively lesser amount of performance is required, however a relatively greater amount of computational complexity is provided. For example, in particular cases, tasks performed by the second DSP processor <NUM> may tolerate a greater amount of latency on the order of, e.g., <NUM> microseconds to <NUM> milliseconds. Similar to the first DSP processor <NUM>, the second DSP processor is also continuously powered when device <NUM> is operational. In certain implementations, the second DSP processor <NUM> is configured to perform both stream and block processing, and includes a moderate amount of data storage and programmability to perform analysis tasks in an effective manner.

GP processor <NUM> includes a set of high level functions <NUM> that are one level further removed from the ANR processing performed by the first DSP processor <NUM>. The specific functions <NUM> implemented by the GP processor <NUM> can depend on the requirements of the ANR device <NUM>. A set of illustrative functions are shown in <FIG>. In certain illustrative implementations, communication algorithms <NUM> handle I/O and command processing functions. In some cases, the communications algorithms <NUM> include a unified messaging interface for converting different communication protocols (e.g., USB versus Bluetooth) into a common protocol. The unified messaging interface allows code for interpreting commands to be stored and implemented in a single location (i.e., the GP processor <NUM>), and thus allows all commands to be routed to the GP processor <NUM> for handling.

GP processor <NUM> is generally tasked with handling larger and more complicated calculations. In some implementations, GP processor <NUM> calculates "one-time" filter coefficients that are customized to an individual user based on how the product fits on his or her head. In particular implementations, user experience algorithms <NUM> analyze user fit based, e.g., on control signals <NUM> and feedback <NUM>, and communication algorithms <NUM> inform the user to adjust the fit of the device <NUM> in response to a fitting algorithm.

In various implementations, the GP processor <NUM> further includes ANR control algorithms <NUM> that update operational parameters for the first DSP processor <NUM> in response to events received from the DSP system <NUM>, or in response to control signals <NUM> received from the gateway device <NUM> (<FIG>). In certain cases, control algorithms <NUM> implement CNC (controllable noise cancellation) features, etc..

As noted, GP processor <NUM> may receive "events" from the second DSP processor <NUM>, e.g., indicating instability or some other issue, e.g., detected using the techniques described in <CIT>. If immediate changes are required to mitigate instability based on one or more received events, the second DSP processor <NUM> would typically be responsible for altering ANR parameters in the first DSP processor <NUM>. Regardless as to whether immediate alterations are required, the GP processor <NUM> can record events are they are generated in local memory and report the event(s) out via the Bluetooth system <NUM> (<FIG>).

After collecting a series of events, GP processor <NUM> can utilize one or more of its algorithms to identify and/or address conditions. For example, if multiple instability events are detected, then system health algorithms <NUM> are deployed to determine if a more severe issue exists (e.g., a malfunction in the ANR device <NUM>). In the case that a malfunction is identified, the system health algorithm <NUM> is configured to characterize the malfunction, and based on the nature of the malfunction, system heath algorithm <NUM> directly initiates ANR parameter changes on the DSP processor <NUM>. In other cases, system health algorithms <NUM> take other actions such as analyze event data, report the analysis to the gateway device <NUM>, apply machine learning to determine the cause of the malfunction, etc. As noted, damage conditions of the ANR device <NUM> are reported back to the gateway device <NUM> to inform the device user (or another user) that the ANR device <NUM> is malfunctioning.

As an example, when an instability event is detected, e.g., using the technique described in <CIT>, the GP processor <NUM> logs the event. In the case that a detected number of instability events exceeds a predetermined threshold, the GP processor <NUM> is configured to provide a notification (e.g., to the device user or another user) that the device <NUM> appears to be malfunctioning. Similarly, if data measured when calculating filter coefficients customized to an individual user based on how the product fits on his or her head indicates something unusual (e.g., a poor fit, as characterized by unexpected differences in feedback versus feedforward microphone signals), the GP processor <NUM> provides feedback instructing the user to adjust the device, e.g., for fit.

In other cases, coordination algorithms <NUM> are deployed to coordinate performance between a pair of earphones (e.g., earbuds, over-ear audio devices, etc.). For example, in response to detecting that a first earphone is operating at a low ANR performance level (e.g., due to a detected fault), the coordination algorithm <NUM> cause the second earphone to match the ANR performance level of the first earphone to avoid a performance mismatch and ensure a better user experience.

In various implementations, user experience algorithms <NUM> are deployed to provide user controls such as volume, equalization, etc., and implement different operating modes such as telephony, music listening, etc. User experience algorithms <NUM> can be implemented to analyze sensor data to automatically control the ANR device <NUM> (e.g., provide special settings when on an airplane), collect and provide feedback that can be analyzed remotely, etc. In other cases, the algorithms <NUM> respond to state data that the ANR device <NUM> is poorly fit (e.g., a proper seal with the user's ear canal is not detected) and output a warning (e.g., to the device user or another user).

In additional implementations, GP processor <NUM> is configured to implement machine learning models or event classifiers. In some examples, the GP processor <NUM> is configured to apply machine learning to state data received from the second DSP processor <NUM>. In more particular examples, the GP processor <NUM> is configured to apply machine learning to state data received from the second DSP processor <NUM> and to time-based signals such as blocks of raw audio data. In some cases, the time-based signals (which can include raw, or unprocessed audio data) are received via microphone system <NUM> and/or Bluetooth system <NUM> (e.g., as an audio stream <NUM>). Illustrative machine learning techniques involving signal processing are described in <CIT>, titled "Automatic Active Noise Reduction (ANR) Control" and <CIT>, titled "Active Transit Vehicle Classification".

In further implementations, to instantiate the various functions <NUM> on GP processor <NUM>, a lightweight operating system (OS) and/or functional libraries <NUM> can be implemented that: allows algorithms and routines to be easily accessed, added and removed; allows software updates to be performed; provides access to storage; provides use of higher level scripts and/or programming languages, etc..

Because the GP processor <NUM> does not perform any time-critical signal processing services, the GP processor <NUM> is implemented with relatively low performance, but requires a relatively high amount of computational complexity in order to provide a wide assortment of functionality. Latency can be relatively high, e.g., on the order of <NUM> milliseconds to <NUM> seconds, when performing functions. Furthermore, because its functionality is not always required, GP processor <NUM> is configured to be placed into a lower power mode or sleep mode when not needed (e.g., when no events are detected or require analysis). The sleep mode is configured to be woken by at least one of the first DSP processor <NUM>, second DSP processor <NUM> and/or control signals received from one of the communications interfaces. Generally, GP processor <NUM> need not handle any stream processing, but rather processes data as blocks using standard memory configurations. Data storage can be implemented, e.g., using internal storage and/or flash drives as needed.

<FIG> is a schematic depiction of an illustrative wearable audio device <NUM> that includes the ANR device <NUM> of <FIG>. In this example, the wearable audio device <NUM> is an audio headset that includes two earphones (for example, in-ear headphones, also called "earbuds") <NUM>, <NUM>. While the earphones <NUM>, <NUM> are shown in a "true" wireless configuration (i.e., without tethering between earphones <NUM>, <NUM>), in additional implementations, the audio headset <NUM> includes a tethered wireless configuration (whereby the earphones <NUM>, <NUM> are connected via wire with a wireless connection to a playback device) or a wired configuration (whereby at least one of the earphones <NUM>, <NUM> has a wired connection to a playback device). Each earphone <NUM>, <NUM> is shown including a body <NUM>, which can include a casing formed of one or more plastics or composite materials. The body <NUM> can include a nozzle <NUM> for insertion into a user's ear canal entrance and a support member <NUM> for retaining the nozzle <NUM> in a resting position within the user's ear. Each earphone <NUM>, <NUM> includes an ANR device <NUM> for implementing some or all of the various functions described herein. Other wearable device forms could likewise be implemented with the ANR device <NUM>, including around-the-ear headphones, audio eyeglasses, open-ear audio devices etc..

It is understood that one or more of the functions in ANR device <NUM> may be implemented as hardware and/or software, and the various components may include communications pathways that connect components by any conventional means (e.g., hard-wired and/or wireless connection). For example, one or more non-volatile devices (e.g., centralized or distributed devices such as flash memory device(s)) can store and/or execute programs, algorithms and/or parameters for one or more systems in the ANR device <NUM> (e.g., Bluetooth system <NUM>, DSP system <NUM>, GP <NUM>, etc.). Additionally, the functionality described herein, or portions thereof, and its various modifications (hereinafter "the functions") can be implemented, at least in part, via a computer program product, e.g., a computer program tangibly embodied in an information carrier, such as one or more non-transitory machine-readable media, for execution by, or to control the operation of, one or more data processing apparatus, e.g., a programmable processor, a computer, multiple computers, and/or programmable logic components.

Actions associated with implementing all or part of the functions can be performed by one or more programmable processors executing one or more computer programs to perform the functions. All or part of the functions can be implemented as, special purpose logic circuitry, e.g., an FPGA (field programmable gate array) and/or an ASIC (application-specific integrated circuit). Generally, a processor may receive instructions and data from a read-only memory or a random access memory or both. Components of a computer include a processor for executing instructions and one or more memory devices for storing instructions and data.

Additionally, actions associated with implementing all or part of the functions described herein can be performed by one or more networked computing devices. Networked computing devices can be connected over a network, e.g., one or more wired and/or wireless networks such as a local area network (LAN), wide area network (WAN), personal area network (PAN), Internet-connected devices and/or networks and/or a cloud-based computing (e.g., cloud-based servers).

In various implementations, electronic components described as being "coupled" can be linked via conventional hard-wired and/or wireless means such that these electronic components can communicate data with one another. Additionally, sub-components within a given component can be considered to be linked via conventional pathways, which may not necessarily be illustrated.

Claim 1:
A personal active noise reduction, ANR, device, comprising:
a communication interface configured to receive a source audio stream and control signals;
a driver;
a microphone system; and
an ANR computational architecture, comprising:
a first DSP processor (<NUM>) configured to: receive the source audio stream and signals from the microphone system, perform ANR on the source audio stream according to a set of operational parameters deployed in the first DSP processor, and output a processed audio stream to the driver;
a second DSP processor (<NUM>) configured to: generate state data in response to an analysis of at least one of the source audio stream, signals from the microphone system, and the processed audio stream; and alter the set of operational parameters on the first DSP processor;
a general purpose processor (<NUM>) operationally coupled to the first DSP processor and the second DSP processor;
wherein the first DSP processor and second DSP processor share a common bus (<NUM>),
wherein, compared to the first DSP processor, the second DSP processor is configured to provide a relatively lesser amount of performance in terms of latency, but a relatively greater amount of computational complexity,
the personal ANR device being characterized in that:
the general purpose processor (<NUM>) is configured to: communicate control signals with the communication interface, process state data from the second DSP processor, and alter the set of operational parameters on the first DSP processor; and
wherein the first DSP processor and second DSP processor share the common bus (<NUM>) with which they both have access to the general purpose processor, the microphone system and the audio streams, and
wherein, compared to the first and second DSP processors, the general purpose processor is configured with relatively low performance in terms of latency, but a relatively high amount of computational complexity.