Patent Description:
Aspects disclosed herein generally related to a synchronized multichannel loopback with an embedded architecture. These aspects and others will be discussed in more detail below.

Often times, processing in embedded systems (e.g. in a Linux operating system) is not in real-time, as buffers that are applied to a data system are not constant. Such buffers may change over time due to memory usage and system load. This behavior makes those popular and generalpurpose System on a Chip (SoC) systems, widely used in mobile-phones, hardly usable for advanced algorithms such as, for example, acoustic echo cancellation (AEC) algorithms. This condition may also increase the need for expensive companion-chips.

<NPL>" discusses ambient noise and acoustic echo reduction with use of a multi-channel noise reduction and echo cancellation module integrated in a PulseAudio sound system.

In at least one embodiment, an embedded Linux system is provided as set out in claim <NUM>.

In at least another embodiment, a computer-program product embodied in a non-transitory computer readable medium that is programmed to prevent temporal misalignment between a reference signal and a measured signal for an embedded Linux system is provided as set out in claim <NUM>.

The embodiments of the present disclosure are pointed out with particularity in the appended claims. However, other features of the various embodiments will become more apparent and will be best understood by referring to the following detailed description in conjunction with the accompanying drawings in which:.

It is recognized that various electrical devices such as servers, controllers, and clients, etc. as disclosed herein may include various microprocessors, integrated circuits, memory devices (e.g., FLASH, random access memory (RAM), read only memory (ROM), electrically programmable read only memory (EPROM), electrically erasable programmable read only memory (EEPROM), or other suitable variants thereof), and software which co-act with one another to perform operation(s) disclosed herein. In addition, these electrical devices utilize one or more microprocessors to execute a computer-program that is embodied in a non-transitory computer readable medium that is programmed to perform any number of the functions as disclosed. Further, the various electrical devices as provided herein include a housing and various numbers of microprocessors, integrated circuits, and memory devices ((e.g., FLASH, random access memory (RAM), read only memory (ROM), electrically programmable read only memory (EPROM), electrically erasable programmable read only memory (EEPROM)) positioned within the housing. The electrical devices also include hardware-based inputs and outputs for receiving and transmitting data, respectively from and to other hardware-based devices as discussed herein.

Embodiments disclosed herein generally provide, among other things, a synchronized reference and measured embedded input signal architecture that may be used in connection with, for example, a LINUX operating system that enables the feasibility of many advanced algorithms. The architecture may be reliable and implemented for any number of adaptive control strategies. The Linux operating system may be used for any number of audio processing devices. For example, the architecture may utilize a synchronized reference and measured signals in connection with, but not limited to, for example, an Acoustic Echo Canceler or Cancellation (AEC) application, an active noise cancellation (ANC) system, any other suitable audio-based application or in general any control application which requires relative synchronized reference and measurement signals. The depicted enhancement (or architecture) may utilize a signal conditioning circuit that may be simple and yield a low-cost method that provides a relative synchronized design between reference and measured signals while the end-to-end latency may change dynamically. It is recognized that the embodiments as set forth herein may be applied to any system, not including an audio system whereby it is desired to achieve a control target by, for example, to minimize an error utilizing the relative synchronized reference and measured signals.

<FIG> depicts an example of an embedded adaptive control system <NUM>. The adaptive control system <NUM> may be implemented, for example, in an embedded Linux Operating System (OS) <NUM>. It is recognized that the system <NUM> may include a Linux kernel (e.g., a core of the OS) and related supporting tools and libraries. The system <NUM> generally includes an application layer <NUM>, a server (or server layer) <NUM>, a sound sub-system layer <NUM> or for example, an Advanced Linux Sound Architecture (ALSA) library layer <NUM> or an Open Sound System (OSS) library layer <NUM>, a kernel (or driver) layer (e.g., ALSA kernel/driver or OSS kernel/driver) <NUM>, and a hardware layer <NUM>. The application layer <NUM>, the server <NUM>, the sound sub-system layer <NUM>, the kernel layer <NUM>, and the hardware layer <NUM> may form at least a System on a Chip (SoC) device <NUM>. The SoC device <NUM> may be an integrated circuit that integrates all associated components therein. It is recognized that the SoC device <NUM> may include a central processing unit (CPU), memory <NUM>, input/output ports, and/or secondary storage that may be packaged on a single substrate or microchip. The SoC device <NUM> may also include digital, analog, and/or mixed-signal processing devices. The SoC device <NUM> may be part of the Linux embedded system.

It is recognized that the system <NUM> further includes at least one controller <NUM> (hereafter the controller <NUM>) for executing instructions to perform any and all of the tasks performed by the application layer <NUM>, the server layer <NUM>, the sound sub-system layer <NUM> and the kernel (or driver) layer <NUM>. In addition, the controller <NUM> may interface with the hardware layer <NUM> to process data as received from the hardware layer <NUM> or to transmit data to the hardware layer <NUM>.

It is recognized that the control system <NUM> may be utilized in any adaptive control implementation (or closed loop control strategy). For example, <FIG> depicts a control implementation <NUM> that employs a closed loop strategy. The implementation <NUM> includes a signal conditioning circuit <NUM> (or first circuit <NUM>), a controller <NUM>, a system or plant <NUM> (hereafter "plant <NUM>") under the control of the controller <NUM>, and a sensor <NUM>. The signal conditioning circuit <NUM> may include a mixer <NUM> to separate a signal REFERENCE from a system/plant input signal and a pack circuit <NUM> to combine the signal REFERENCE with a signal MEASURED to provide a signal CONTROLLER_INPUT. It is recognized that all references to any signal herein may be singular or plural (e.g., any number of signals for each respective input and output). The signal REFERENCE may be provided to the signal conditioning circuit <NUM> via the mixer <NUM> and may be separated by the system/plant input signal or by a separate input to the signal conditioner circuit <NUM>. The signal REFERENCE may directly correspond to audio output data that was previously output from the hardware layer <NUM> as illustrated in connection with <FIG>. This may also be designated as a loopback mechanism. The signal REFERENCE may include data that is provided on any number of audio channels, M. The signal REFERENCE may correspond to audio data that is determined undesirable for a user. The signal MEASURED may also be provided to the signal conditioning circuit <NUM>. The signal MEASURED may correspond to, for example, audio data that is transmitted from the sensor <NUM> (e.g., a microphone). The sensor <NUM> generates the signal MEASURED which corresponds to measured output from the plant <NUM> as also defined as a signal PLANT_OUTPUT from the plant <NUM>. In this case, the signal MEASURED may correspond to the audio on signal PLANT_INPUT or CONTROLLER_OUTPUT. The signal MEASURED may include actual audio that is heard in a listening environment by a user. The signal MEASURED may include any number of audio channels, N. The controller <NUM> receives the signal CONTROLLER_INPUT which is a synchronized combination of the signal REFERENCE and the signal MEASURED from, for example, the sensor <NUM> (or microphone). It is recognized that an analog to digital converter may be positioned between the sensor <NUM> and the signal conditioning circuit <NUM>. In general, the pack circuit <NUM> may merge data between the signal MEASURED and the signal REFERENCE. In one example, a merge operation may correspond to the pack circuit <NUM> adding or subtracting the signal MEASURED from the signal REFERENCE to provide a combined signal CONTROLLER_INPUT to the controller <NUM>. The signal CONTROLLER_INPUT may be in the form of M channels, since the signal REFERENCE is superimposed on the signal MEASURED. Alternatively, the merge operation may correspond to the pack circuit <NUM> to combine (or pack) the signal MEASURED with the signal REFERENCE to provide the signal CONTROLLER_INPUT. However, as a result of the pack operation, the signal CONTROLLER_INPUT may be in the form of M + N channels, since the signal REFERENCE and the signal MEASURED is packed into individual slots of the signal CONTROLLER_INPUT. For example, the signal CONTROLLER_INPUT may form M + N audio-based channels that provide a Time Division Multiplexing (TDM) data stream and is packed with M audio-based channels from the signal MEASURED and N audio-based channels from signal REFERENCE. In general, the signal conditioning circuit <NUM> is configured to merge the data on the signal REFERENCE with the data on the signal MEASURED to provide a combined system data stream to the SoC device <NUM> to prevent temporal misalignment between the data on the signal REFERENCE and the data on the signal MEASURED. Such a temporal misalignment may be caused by one or more of the layers <NUM>, <NUM>, <NUM>, and <NUM> during operation of the control implementation <NUM>. This aspect will be discussed in more detail below.

As noted above, embodiments herein may be applied to any system, not including an audio system whereby it is desired to reduce temporal misalignment between two signals that propagate through one or more software layers of the Linux system. In an adaptive control system, the signal REFERENCE may simply correspond to input data to the plant which utilizes loopback mechanism. The signal MEASURED may correspond to data as provided by a sensor in the adaptive control system where the sensor provides some form of feedback information. Thus, in this case the signal conditioning circuit <NUM> may merge the data on the signal REFERENCE with the data on the signal MEASURED. After merging the data between these signals, this signal conditioning circuit <NUM> provides a combined system data stream to the SoC device <NUM> to prevent temporal misalignment between the data on the signal REFERENCE and the data on the signal MEASURED. The temporal misalignment may generally be caused by one or more of the software layers <NUM>, <NUM>, <NUM>, and <NUM>. This aspect may achieve a control target by, for example, minimizing an error utilizing the relative synchronized signals REFERENCE AND MEASURED SIGNAL. It is recognized that the implementation as set forth herein may not be used solely for audio related purposes but may be used for any system that seeks to resolve or reduce temporal misalignment between two signals that propagate through software layers of the Linux system.

The controller <NUM> employs an adaptive control strategy to perform this process over and over based on the signal MEASURED and the signal REFERENCE to adapt the control implementation <NUM> toward the plant <NUM> in a desired manner. However, it is recognized that the controller <NUM> may not be fully capable of controlling the plant <NUM> to achieve the desired outcome due to inherent system errors or inconsistencies. The above noted adaptive control implementation <NUM> may be performed any number of times to provide a control action in an optimum manner which may require at least a relative stable latency and timing between the signal REFERENCE and MEASURED to ensure control stability and optimum performance for the plant <NUM> under control by the controller <NUM>. Any dynamic time/latency misalignment issue between the signal MEASURED and the signal REFERENCE as distributed in, for example, the LINUX system <NUM> such as the example illustrated in <FIG>, may cause the controller <NUM> (or the controller <NUM> as illustrated in <FIG>) to drop performance or even cause instability. However, it is recognized that the controller <NUM> may not be fully capable of controlling the plant <NUM> to achieve the desired outcome due to inherent system (or plant) errors or inconsistencies.

Referring back to <FIG>, the application layer <NUM> generally includes, for example, audio clients and related user programs that enable music playback. These audio clients may connect to sound-servers via audio streams. The server layer <NUM> (or sound server) may be software and manages the use of, and access to audio devices, for example, sound cards. The server layer <NUM> may commonly run as a background process for sink and source handling. The server layer <NUM> may be implemented as PulseAudio or an audio connection kit such as, for example, JACK. PulseAudio is generally a sound system for various operating systems. PulseAudio generally serves as a proxy for sound applications. In the event the server layer <NUM> is implemented for Pulse-Audio, it is recognized that the Pulse-Audio may be a sound server that is utilized in UBUNTU distributions that connects to lower software layers, such as for example, the kernel layer <NUM> (or the ASLA layer). PulseAudio provides server/client connectivity within the application layer <NUM>. JACK may be included in any number of LINUX applications.

The sound system layer <NUM> generally includes software to provide libraries for ALSA and OSS based on whether the ALSA or the OSS is utilized for implementation. The kernel or driver layer <NUM> may include sound drivers and sound devices. In the event the kernel layer <NUM> is utilized in connection with ALSA, the ALSA kernel layer <NUM> may support multichannel audio interfaces and provide application programming interface (API) access on managing hardware controls. ALSA may be a standard software layer within the multiprocessor LINUX based embedded systems to manage all audio streams and stream mixing including buffer handling between audio-hardware-peripherals and upper application-layers. In the event the kernel layer <NUM> is utilized in connection with OSS, the OSS kernel layer <NUM> includes LINUX kernel sound drivers and sound devices and connects the application layer with <NUM> with real audio-hardware-peripherals.

The system <NUM> further includes hardware-based input device(s) <NUM> that provide an input signal to the hardware layer <NUM>. The input devices <NUM> may include any number of sensors such as microphones, acceleration sensor, etc. The system <NUM> further includes hardware-based output devices <NUM> that receive an output signal from the hardware layer <NUM>. In one example, the hardware-based output devices <NUM> may include at least one controller for an audio system such as an acoustic echo cancellation (AEC), an active noise cancelation (ANC) system, etc. In general, as the system <NUM> receives an input signal from the input device <NUM> and the input signal propagates its way through the hardware layer <NUM>, the kernel layer <NUM>, the sound-subsystem layer <NUM>, and the server layer <NUM>, the processing performed by the controller <NUM> to execute such layers <NUM>, <NUM>, <NUM>, and <NUM>, the sound-subsystem layer <NUM>, and the server layer <NUM> may cause latency issues with respect to the different and separated input streams of data that are processed by the system <NUM>.

The application layer <NUM> generally includes a controller unit <NUM> that may utilize the signals REFERENCE and MEASURED independently of one another. For example, the signals REFERENCE and MEASURED each include individual and separate data from one another (e. g, the data between each signal is packed or added together (i.e., merged together). For example, the inputs to the controller unit <NUM> generally corresponds to the signal MEASURED as provided by the sensor <NUM> and the signal REFERENCE signal as set forth in <FIG>. However, in this case, the system <NUM> does not employ the signal conditioning circuit <NUM> as set forth in <FIG>. In this case, the system <NUM> buffers the signals REFERENCE and MEASURED as separate data streams. Hence, individual buffering of the signal MEASURED and REFERENCE in <FIG>, at the various layers <NUM>, <NUM>, <NUM>, and <NUM> (i.e., the dynamic buffer size modifications) may cause these individual signals to be misaligned or unsynchronized with one another. While the layer <NUM> may be hardware based, this layer <NUM> may not add to the latency issue between the signals REFERENCE and MEASURED.

However, notice that the stream of data on the signal Controller Output or Plant Input is processed by the layers <NUM>, <NUM>, <NUM>, <NUM> and <NUM> in a downstream manner and that such a signal may completely or partly be loopback for upstream processing as the signal REFERENCE. Further, notice that the layers <NUM>, <NUM>, <NUM>, and <NUM> process the signals MEASURED and REFERENCE in an upstream manner. Given that, the signal REFERENCE may be based on the signal Controller Output or Plant Input, this may add to the misalignment or non-synchronization as noted above. In general, the hardware layer <NUM> may include programmable sub-units and is generally defined as hardware in the LINUX system. The latency noted above may cause the hardware layer <NUM>, although programmable, to be deterministic and static. The kernel layer <NUM> along with all of the layers above the layer <NUM> may software-based layers and the latency attributed to such layers <NUM>, <NUM>, <NUM>, <NUM> may be assumed to be dynamic and not static (or deterministic due to Operating System (OS) setup within such layers <NUM>, <NUM>, <NUM>, <NUM>.

In general, the data provided by the hardware-based input device <NUM> may be digital. The hardware-based input devices <NUM> may include any number of analog to digital converters to provide the digital data on the signal MEASURED and within some controller applications as e.g. ANC would also provide the signal REFERENCE, as here the signal REFERENCE is not deviated from the signal Controller Output or Plant Input, but still requires the signal conditioner circuit <NUM> to add or pack the signal REFERENCE and MEASURED together into the combined signal Controller Input and forward that signal to the various layers <NUM>, <NUM>, <NUM>, and <NUM> upstream for processing (see e.g., <FIG>). Likewise, the data transmitted from the hardware-based output devices <NUM> may be digital. The hardware-based output devices <NUM> may include any number of digital to analog converters (DACs) to convert the digital data back to analog data.

<FIG> depicts an embedded adaptive control system <NUM>' in accordance to one embodiment. It is recognized that the system <NUM>' may be implemented in a mobile device (not shown) such as for example a cellular phone (or in any other device that enables cellular communication), laptop, tablet, etc. The system <NUM>' may be implemented in an audio processing device of the mobile device. The system <NUM> generally includes the signal conditioning circuit <NUM> that is positioned intermediate to the hardware layer <NUM> and to the hardware-based input device(s) <NUM> and the hardware-based output device(s) <NUM>. As noted above, the input device(s) <NUM> may correspond to a microphone or acceleration sensor, which provides measured audio data from a listening environment (e.g., see signal MEASURED from <FIG>). As also noted above, the hardware-based output devices <NUM> may include the power amplifier in addition to any number of D/A converters for converting the digital data on the signal Controller Output or Plant Input to analog data and to provide the same to any loudspeakers in the room or listening environment. As noted above, signal REFERENCE may fully or partly correspond to the signal Controller Output or Plant Input. In addition, the hardware-based output devices <NUM> may also include at least one controller for an audio system such as an acoustic echo cancelation (AEC), an active noise cancelation (ANC) system, etc. The signal conditioning circuit <NUM> may be a Field-Programmable Gate Array (FGPA), an Application-Specific Integrated Circuit (ASIC), a digital signal processor (DSP), etc. Similarly to the signal conditioning circuit <NUM> of <FIG>, the signal conditioning circuit <NUM> as illustrated in <FIG> may also include the mixer <NUM> and pack circuit <NUM> to combine the signals REFERENCE and MEASURED to provide a combined Controller Input data stream. As shown in <FIG>, the combined system data stream may be referred to as signal COMBINED REFERENCE AND MEASURED SIGNAL(S). As noted above, the signal REFERENCE may be utilized fully or may be partly deviated (or originated) from the signal CONTROLLER_OUTPUT or PLANT_INPUT but not shown in <FIG>.

As noted above, the layers <NUM>, <NUM>, <NUM>, and <NUM> may be software-based layers and may be considered non-deterministic (or time-varying). Therefore, such layers <NUM>, <NUM>, <NUM>, and <NUM>, when executed by the controller <NUM>, may generally contribute to causing misalignment between the signals REFERENCE and MEASURED due to dynamic buffer size modifications and/or processing latencies. However, given that the signal conditioning circuit <NUM> (e.g., the mixer <NUM> and/or the pack circuit <NUM>) is hardware based and time deterministic, the signal conditioning circuit <NUM> is generally applied or positioned before all of the non-time deterministic (or time varying) layers <NUM>, <NUM>, <NUM>, and <NUM> which may mitigate any misalignment between the signals REFERENCE and MEASURED as both signal are combined with one another via the signal conditioning circuit <NUM> to provide the signal COMBINED REFERENCE AND MEASURED called the signal CONTROLLER_INPUT.

For example, the typical dynamic buffer size modification between the layers <NUM>, <NUM>, <NUM>, and <NUM> may change the overall end-to-end latency. However, the signal conditioning circuit <NUM> may synchronize the signals REFERENCE AND MEASURED since the position of the signal conditioning circuit <NUM> is positioned beyond the potential dynamic buffer latency modification related to SW layer processing, the latency of the signals COMBINED REFERENCE AND MEASURED may be considered constant. For example, any latency applied to the signal COMBINED REFERENCE AND MEASURED may affect the signals REFERENCE and MEASURED in the same manner and therefore the relative latency can be considered as constant. The signals REFERENCE and MEASURED when present in the signal COMBINED REFERENCE AND MEASURED may correspond to the signals REFERENCE and MEASURED as set forth in <FIG>. The same may hold true for the signal COMBINED REFERENCE AND MEASURED which may correspond to the signal CONTROLLER_INPUT as set forth in <FIG>. The signal conditioning circuit <NUM> (via the pack circuit or the mixer) merges or combines the signals REFERENCE and MEASURED with one another to provide a combined system input (or combined system data stream) to the SoC device <NUM> to prevent any temporal misalignment within one or more of the non-deterministic software layers <NUM>, <NUM>, <NUM>, and <NUM> during device operation.

<FIG> depicts an example of an adaptive control system <NUM>" as used in connection with an AEC system in accordance to one embodiment. The server layer <NUM> (or PulseAudio Daemon) generally includes a sink layer <NUM> and a source layer <NUM>. The adaptive control system <NUM>" generally illustrates the case of independent sink and source processing embedded into a typical pulse audio daemon framework. The pulse audio I/O buffer of the server layer <NUM> cannot be assumed to be synchronized.

The hardware-based input device(s) <NUM> may provide audio data on signal MEASURED as captured from a microphone or acceleration sensor (not shown) as used in connection with the AEC system. The captured audio data may correspond to desired voice data but including undesired echo data that is captured in a room or listening environment (e.g., data on the signal MEASURED). The signal conditioning circuit <NUM> may forward the audio data from the signal SYSTEM_INPUT and provide the same to the hardware-based output device(s) <NUM> to be broadcasted to the acoustic path, which is representing the plant <NUM> as shown in <FIG>. As noted above, the signal REFERENCE may correspond to the signal SYSTEM_INPUT. In case of AEC, the audio data on the signal SYSTEM_INPUT may correspond to music data that is played back independent of the controller operation but is considered as the undesired echo once forward to the system or plant during playback. The signal conditioning circuit <NUM> may fully or partly mix the signal SYSTEM_INPUT as signal REFERENCE and combine this with the signal MEASURED to allow echo cancelation within the controller. It is recognized that the hardware-based output device(s) <NUM> may include a power amplifier in addition to any number of D/A converters for converting the digital data on the signal SYSTEM_INPUT to analog data and to provide the same to any loudspeakers in the room or listening environment.

The signal conditioning circuit <NUM> may, in real time, pack or add data on the signal REFERENCE with the measured microphone data (i.e., desired voice with undesired echo) on the signal MEASURED to provide the signal COMBINED REFERENCE AND MEASURED or signal CONTROLLER_INPUT. The signal COMBINED REFERENCE AND MEASURED or signal CONTROLLER_INPUT may be considered robust against any dynamic system behavior, as the latency between microphone data and reference data may stay relatively constant on the signal COMBINED REFERENCE AND MEASURED or signal CONTROLLER_INPUT. Although the input/output (I/O) end-to-end latency may dynamically change, the AEC convergence may be guaranteed due to the stable/constant relative latency between the microphone data and reference data on the signal COMBINED REFERENCE AND MEASURED.

<FIG> depicts an example of an adaptive control system <NUM>‴ as used in connection with an ANC system in accordance to one embodiment. The server layer <NUM> (or PulseAudio Daemon) generally includes a sink layer <NUM> and a source layer <NUM>. The adaptive control system <NUM>‴ generally illustrates the case of independent sink and source processing embedded into a typical pulse audio daemon framework. The pulse audio I/O buffer of the server layer <NUM> may not be assumed to be synchronized.

The hardware-based input device(s) <NUM> may provide audio data on the signal MEASURED as captured from a microphone or acceleration sensor (not shown) as used in connection with the ANC system. The captured audio data may correspond to undesired noise along with desired music or voice data that is captured in a room or listening environment (e.g., data on the signal MEASURED). The signal conditioning circuit <NUM> may forward the audio data from the signal CONTROLLER_OUTPUT and provide the same to the hardware-based output device(s) <NUM> to be broadcasted to the acoustic path for noise cancelation, which is representing the plant as shown in <FIG>. As noted above, the signal REFERENCE may not correspond to the signal CONTROLLER_OUTPUT but may correspond to only undesired noise as provided by another sensor that provides only undesired noise, which is not illustrated in <FIG>. In case of ANC, the audio data on the signal CONTROLLER_OUTPUT may correspond to anti-noise data that is serves as a loopback via the controller operation within application layer <NUM> toward the audio source in order to playback anti-noise signals for noise cancelation through the plant <NUM>. The signal conditioning circuit <NUM> merges the signal REFERENCE with the signal MEASURED to allow noise cancelation by the controller via the plant <NUM>. It is recognized that the hardware-based output device(s) <NUM> may include a power amplifier in addition to any number of D/A converters for converting the digital data on the signal CONTROLLER_OUTPUT to analog data and to provide the same to any loudspeakers in the room or listening environment.

The signal conditioning circuit <NUM> may, in real time, pack or add data (i.e., merge data) on the signal REFERENCE with the measured microphone data (i.e., desired music/voice with undesired noise) on the signal MEASURED to provide the signal COMBINED REFERENCE AND MEASURED or signal CONTROLLER_INPUT. The signal COMBINED REFERENCE AND MEASURED or signal CONTROLLER_INPUT may be considered robust against any dynamic system behavior, as the latency between microphone data and reference data may stay relatively constant on the signal COMBINED REFERENCE AND MEASURED or signal CONTROLLER_INPUT. Although the input/output (I/O) end-to -end latency may dynamically change, the ANC convergence may be guaranteed due to the stable/constant relative latency between the microphone data and reference data on the signal COMBINED REFERENCE AND MEASURED.

The data streams that correspond to signals MEASURED, REFERENCE, COMBINED REFERENCE AND MEASURED, CONTROLLER_INPUT, PLANT_INPUT and CONTROLLER_OUTPUT may be implemented as Time Division Multiplex (TDM) data streams or internal linear or ring buffers between the software layers <NUM>, <NUM>, <NUM>. For the example noted in connection with <FIG> above, the TDM data streams are partly filled with the input data (e.g., audio data from the measured microphone), output data (e.g., data from the signal CONTROLLER_OUTPUT) and the data from the signal REFERENCE. In the example as noted in connection with the system <NUM>'', the TDM based data streams may be packed with <NUM> to N + M channels (or bits of data), where M corresponds to the audio data from the measured microphone (or from the hardware-based input device(s) <NUM>) and N corresponds to reference data. In the case of AEC, the microphone content may include desired voice and undesired echo after the AEC controller processes the echo ideally is fully canceled and the voice is treated as SINK for further application services. In general, the music may serve as a SOURCE (device transceiver music). The voice may serve as a SINK since the device receives the voice for communication propose, as e.g. telephone calls. In the case of ANC, the microphone content may include desired music/voice and undesired noise after the ANC controller processes the noise ideally is fully canceled and the anti-noise signal is treated as SINK for the audio SOURCE application, so the controller anti-noise signal can loopback to the device output and perform the noise cancelation within the acoustic path.

Claim 1:
An embedded Linux system (<NUM>) for an audio processing device, the system (<NUM>) comprising:
a system on a chip, SoC, device (<NUM>) including a memory, a hardware layer (<NUM>) and a plurality of software layers (<NUM>, <NUM>, <NUM>, <NUM>) of the Linux system (<NUM>), the SoC being programmed to process at least a reference signal indicative of undesired audio content and a measured signal indicative of measured audio data in a listening environment;
the system (<NUM>) characterized by
a first circuit (<NUM>) being programmed to:
receive the reference signal, as a plurality of N audio-based channels;
receive the measured signal as a plurality of M audio-based channels;
merge the reference signal with the measured signal to generate M + N audio-based channels to form a Time Division Multiplexing, TDM, data stream; and
provide the merged reference and measured signal to the hardware layer (<NUM>) of the SoC device (<NUM>) to prevent temporal misalignment between the reference signal and the measured signal caused by the plurality of software layers (<NUM>, <NUM>, <NUM>, <NUM>) of the Linux system (<NUM>), wherein the hardware layer (<NUM>) is located between the first circuit (<NUM>) and the plurality of software layers of the Linux system.