This disclosure generally relates to digital audio filters, and specifically to aligning and trimming digital audio filters.
Virtual environments are ubiquitous in computing environments, finding use in video games (in which a virtual environment may represent a game world); maps (in which a virtual environment may represent terrain to be navigated); simulations (in which a virtual environment may simulate a real environment); digital storytelling (in which virtual characters may interact with each other in a virtual environment); and many other applications. Modern computer users are generally comfortable perceiving, and interacting with, virtual environments. However, users' experiences with virtual environments can be limited by the technology for presenting virtual environments. For example, conventional displays (e.g., 2D display screens) and audio systems (e.g., fixed speakers) may be unable to realize a virtual environment in ways that create a compelling, realistic, and immersive experience.
Virtual reality (“VR”), augmented reality (“AR”), mixed reality (“MR”), and related technologies (collectively, “XR”) share an ability to present, to a user of an XR system, sensory information corresponding to a virtual environment represented by data in a computer system. Such systems can offer a uniquely heightened sense of immersion and realism by combining virtual visual and audio cues with real sights and sounds. Accordingly, it can be desirable to present digital sounds to a user of an XR system in such a way that the sounds seem to be occurring—naturally, and consistently with the user's expectations of the sound—in the user's real environment. For example, when presenting a digital sound to a user's two ears via a speaker array (e.g., the left and right speakers of a pair of headphones), it is desirable that the speaker array render the sound in a manner consistent with the user's understanding of the location of that sound's origin in the environment. Further, this should remain true even as the origin of the sound moves throughout the environment. Techniques for filtering digital audio signals in XR environments to render them in such a natural and convincing manner are desired.
Systems and methods for rendering audio signals are disclosed. In some embodiments, a method may receive an input signal including a first portion and the second portion. A first processing stage comprising a first filter is applied to the first portion to generate a first filtered signal. A second processing stage comprising a second filter is applied to the first portion to generate a second filtered signal. A third processing stage comprising a third filter is applied to the second portion to generate a third filtered signal. A fourth processing stage comprising a fourth filter is applied to the second portion to generate a fourth filtered signal. A first output signal is determined based on a sum of the first filtered signal and the third filtered signal. A second output signal is determined based on a sum of the second filtered signal and the fourth filtered signal. The first output signal is presented to a first ear of a user of a virtual environment, and the second output signal is presented to the second ear of the user. The first portion of the input signal corresponds to a first location in the virtual environment, and the second portion of the input signal corresponds to a second location in the virtual environment.
In the following description of examples, reference is made to the accompanying drawings which form a part hereof, and in which it is shown by way of illustration specific examples that can be practiced. It is to be understood that other examples can be used and structural changes can be made without departing from the scope of the disclosed examples.
Example Wearable System
In some examples involving augmented reality or mixed reality applications, it may be desirable to transform coordinates from a local coordinate space (e.g., a coordinate space fixed relative to wearable head device 400A) to an inertial coordinate space, or to an environmental coordinate space. For instance, such transformations may be necessary for a display of wearable head device 400A to present a virtual object at an expected position and orientation relative to the real environment (e.g., a virtual person sitting in a real chair, facing forward, regardless of the position and orientation of wearable head device 400A), rather than at a fixed position and orientation on the display (e.g., at the same position in the display of wearable head device 400A). This can maintain an illusion that the virtual object exists in the real environment (and does not, for example, appear positioned unnaturally in the real environment as the wearable head device 400A shifts and rotates). In some examples, a compensatory transformation between coordinate spaces can be determined by processing imagery from the depth cameras 444 (e.g., using a Simultaneous Localization and Mapping (SLAM) and/or visual odometry procedure) in order to determine the transformation of the wearable head device 400A relative to an inertial or environmental coordinate system. In the example shown in
In some examples, the depth cameras 444 can supply 3D imagery to a hand gesture tracker 411, which may be implemented in a processor of wearable head device 400A. The hand gesture tracker 411 can identify a user's hand gestures, for example, by matching 3D imagery received from the depth cameras 444 to stored patterns representing hand gestures. Other suitable techniques of identifying a user's hand gestures will be apparent.
In some examples, one or more processors 416 may be configured to receive data from headgear subsystem 404B, the IMU 409, the SLAM/visual odometry block 406, depth cameras 444, a microphone (not shown); and/or the hand gesture tracker 411. The processor 416 can also send and receive control signals from the 6DOF totem system 404A. The processor 416 may be coupled to the 6DOF totem system 404A wirelessly, such as in examples where the handheld controller 400B is untethered. Processor 416 may further communicate with additional components, such as an audio-visual content memory 418, a Graphical Processing Unit (GPU) 420, and/or a Digital Signal Processor (DSP) audio spatializer 422. The DSP audio spatializer 422 may be coupled to a Head Related Transfer Function (HRTF) memory 425. The GPU 420 can include a left channel output coupled to the left source of imagewise modulated light 424 and a right channel output coupled to the right source of imagewise modulated light 426. GPU 420 can output stereoscopic image data to the sources of imagewise modulated light 424, 426. The DSP audio spatializer 422 can output audio to a left speaker 412 and/or a right speaker 414. The DSP audio spatializer 422 can receive input from processor 416 indicating a direction vector from a user to a virtual sound source (which may be moved by the user, e.g., via the handheld controller 400B). Based on the direction vector, the DSP audio spatializer 422 can determine a corresponding HRTF (e.g., by accessing a HRTF, or by interpolating multiple HRTFs). The DSP audio spatializer 422 can then apply the determined HRTF to an audio signal, such as an audio signal corresponding to a virtual sound generated by a virtual object. This can enhance the believability and realism of the virtual sound, by incorporating the relative position and orientation of the user relative to the virtual sound in the mixed reality environment—that is, by presenting a virtual sound that matches a user's expectations of what that virtual sound would sound like if it were a real sound in a real environment.
In some examples, such as shown in
While
Mixed Reality Environment
Like all people, a user of a mixed reality system exists in a real environment—that is, a three-dimensional portion of the “real world,” and all of its contents, that are perceptible by the user. For example, a user perceives a real environment using one's ordinary human senses sight, sound, touch, taste, smell—and interacts with the real environment by moving one's own body in the real environment. Locations in a real environment can be described as coordinates in a coordinate space; for example, a coordinate can comprise latitude, longitude, and elevation with respect to sea level; distances in three orthogonal dimensions from a reference point; or other suitable values. Likewise, a vector can describe a quantity having a direction and a magnitude in the coordinate space.
A computing device can maintain, for example, in a memory associated with the device, a representation of a virtual environment. As used herein, a virtual environment is a computational representation of a three-dimensional space. A virtual environment can include representations of any object, action, signal, parameter, coordinate, vector, or other characteristic associated with that space. In some examples, circuitry (e.g., a processor) of a computing device can maintain and update a state of a virtual environment; that is, a processor can determine at a first time, based on data associated with the virtual environment and/or input provided by a user, a state of the virtual environment at a second time. For instance, if an object in the virtual environment is located at a first coordinate at time, and has certain programmed physical parameters (e.g., mass, coefficient of friction); and an input received from user indicates that a force should be applied to the object in a direction vector; the processor can apply laws of kinematics to determine a location of the object at time using basic mechanics. The processor can use any suitable information known about the virtual environment, and/or any suitable input, to determine a state of the virtual environment at a time. In maintaining and updating a state of a virtual environment, the processor can execute any suitable software, including software relating to the creation and deletion of virtual objects in the virtual environment; software (e.g., scripts) for defining behavior of virtual objects or characters in the virtual environment; software for defining the behavior of signals (e.g., audio signals) in the virtual environment; software for creating and updating parameters associated with the virtual environment; software for generating audio signals in the virtual environment; software for handling input and output; software for implementing network operations; software for applying asset data (e.g., animation data to move a virtual object over time); or many other possibilities.
Output devices, such as a display or a speaker, can present any or all aspects of a virtual environment to a user. For example, a virtual environment may include virtual objects (which may include representations of inanimate objects; people; animals; lights; etc.) that may be presented to a user. A processor can determine a view of the virtual environment (for example, corresponding to a “camera” with an origin coordinate, a view axis, and a frustum); and render, to a display, a viewable scene of the virtual environment corresponding to that view. Any suitable rendering technology may be used for this purpose. In some examples, the viewable scene may include only some virtual objects in the virtual environment, and exclude certain other virtual objects. Similarly, a virtual environment may include audio aspects that may be presented to a user as one or more audio signals. For instance, a virtual object in the virtual environment may generate a sound originating from a location coordinate of the object (e.g., a virtual character may speak or cause a sound effect); or the virtual environment may be associated with musical cues or ambient sounds that may or may not be associated with a particular location. A processor can determine an audio signal corresponding to a “listener” coordinate—for instance, an audio signal corresponding to a composite of sounds in the virtual environment, and mixed and processed to simulate an audio signal that would be heard by a listener at the listener coordinate—and present the audio signal to a user via one or more speakers.
Because a virtual environment exists only as a computational structure, a user cannot directly perceive a virtual environment using one's ordinary senses. Instead, a user can perceive a virtual environment only indirectly, as presented to the user, for example by a display, speakers, haptic output devices, etc. Similarly, a user cannot directly touch, manipulate, or otherwise interact with a virtual environment; but can provide input data, via input devices or sensors, to a processor that can use the device or sensor data to update the virtual environment. For example, a camera sensor can provide optical data indicating that a user is trying to move an object in a virtual environment, and a processor can use that data to cause the object to respond accordingly in the virtual environment.
Filtering Audio Signals
Systems and methods for filtering audio signals for rendering in a binaural environment (e.g., left and right speakers presenting audio to left and right ears, respectively, in an XR environment) are disclosed. According to embodiments, two input audio signals (or channels) are presented to a filter network, which generates two output audio signals (e.g., left and right signals) for presentation to a user in the binaural environment. The two input signals may correspond to first and second audio sources, such as microphones in a coincident-pair microphone recording, or first and second audio assets originating from first and second locations, respectively, in an XR environment. In some embodiments, a mid-side (M-S) matrix (also known as a stereo shuffler) can be a useful tool for filtering and presenting audio signals as described above. A “mid” component may be considered to be equivalent to a sum of a two-channel input signal, and a “side” component may be considered to be equivalent to a difference of the two-channel input signal.
In the example shown in
In the example shown in
In the example shown in
In some embodiments, for example of signal processing, a M-S shuffle approach may be used to apply symmetrical stereo filters to two input signals.
As illustrated in the example shown in
In some embodiments, digital filters may include leading and trailing zeros or samples with very small values, which may make the filters long. Such filters may require more computing resources (e.g., processor cycles, memory) than shorter filters.
In some embodiments, filters (e.g., filters 920A, 920B, 922A, 922B of
In some embodiments, aligning a sum filter and a difference filter may reduce timbre artifacts during amplitude panning. For example, samples may be added or removed at a beginning of filters to obtain better alignment between filter pairs. A relative delay between filters within filter pairs, or inter-filter delays (IFDs) may be preserved.
In some embodiments, filters may be trimmed, for example, to retain “useful” portions thereof. In some examples, useful portions may be portions that contain non-zero, non-noise magnitude and/or phase information. Trimmed filters may require less computation to process than untrimmed filters. For example, trimming filters may include removing leading zeros or low level samples (e.g., samples that fall within a noise level of the filter, for example, where the noise level of the filter may be determined by analyzing a portion of a filter that is only noise and using that information to determine a noise gate threshold) at a beginning of some or all filters in a system. In some embodiments, a same number of leading zeros or low level samples must be removed from filters in a sum-difference filter pair, for example, to preserve/maintain IFDs. In some embodiments, trimming filters may include removing trailing zeros or low level samples at an end of some or all filter in a system. As described herein, trimming filters may include removing leading zeros or low level samples and/or removing trailing zeros or low level samples. The leading zeros or low level samples and/or the trailing zeros or low level samples may be identified, for example, by setting a level threshold and removing leading samples of a signal before the signal crosses the level threshold, by identifying a peak in an impulse response and applying a predetermined window around the identified peak, by identifying a peak in an envelope of an impulse response and applying a predetermined window around the identified peak, by trimming a filter to different length and analyzing a resulting magnitude and/or phase response to determine when the trimming starts introducing undesirable artifacts, and/or by trimming a filter to a different length and evaluating an introduced distortion by listening to audio content processed through the filters.
In some embodiments, filter alignment may be achieved by generating a minimum phase version of filters. In these embodiments, pre-ringing and pre-echo in filters may be removed/eliminated, which may allow further truncation of leading zeros and short filters.
In some embodiments, IFDs may be applied to a delayed filter only. In some embodiments, in the context of binaural rendering, applying IFDs to the delayed filter only may effectively time-align the filters for an ipsilateral ear. Since an ipsilateral ear signal may arrive in an ear first, and may be louder than a contralateral ear signal, better time alignment of ipsilateral ear filters may lead to better perceived timbre when panning audio content through a VSA using amplitude panning methods. In some embodiments, without time alignment of ipsilateral ear signals, spectral artifacts may be perceived as an audio signal is panned through the VSA, for example, due to constructive and destructive interference between misaligned signals.
In some embodiments, IFDs may be modified before applying the IFDs to filters at stage 1314. The IFDs may be modified, for example, to remove measurement errors. In some embodiments, modification of IFDs may be used to tune the IFDs to match anthropometric features of the user. In some examples, sensors can be used to tune the IFDs. For instance, sensors such as depth cameras, RGB cameras, LIDAR, sonar, orientation sensors, GPS, and so forth can be used to determine relevant acoustic parameters that can be used to modify the IFDs in accordance with those parameters. Such sensors are described above with respect to hardware for interacting with XR environments (e.g., wearable head device 100, handheld controller 200, and/or auxiliary unit 300 described above) and the use of such sensors for determining IFDs may be particularly beneficial in such applications.
In some embodiments, alignment of filters may be achieved by setting a level threshold (e.g., a threshold above a noise level of a filter) and removing samples at a beginning of a filter to a point where a signal crosses a threshold. In some embodiments, computational power of processing and memory for storing filters may be reduced by setting a second threshold (e.g., a threshold based on a level relative to a peak of an impulse response, or an immediately preceding amplitude, or a time delay subsequent to a peak impulse response) and trimming trailing zeros in the filters.
In some embodiments, alignment filters may be achieved using a cross-correlation measure to find a lag providing a highest correlation between filter responses.
In some embodiments, alignment of filters may be done empirically be measuring a transfer function of a full rendering system through a VSA and picking an alignment that provides a least amount of magnitude or phase distortion to one or both ear signals.
In some embodiments, alignment of filters may be done empirically by listening to content, for example, content that is likely to reveal artifacts, panned through a VSA and picking an alignment that provides a least amount of perceived timbral artifacts.
In some embodiments, filters such as described above with respect to
In such embodiments, sum and difference filters may be created by pulling/fetching/retrieving raw filters (e.g., unprocessed filters that may be derived from measurements or simulations), for example, from a discrete HRTF database and computing a sum and a difference. In some examples, such as in XR environments, the selection and creation of such filters can be informed by the outputs of sensors able to detect parameters of the user and/or the user's environment, in order to arrive at HRTF filters that may be preferred by the user in that particular environment. Such parameters can include morphological parameters of the user (e.g., the user's height, head width, and other physical dimensions), environmental parameters (e.g., the dimensions of a room in the user's environment), or other parameters relevant to selecting a HRTF filter.
As an example, a user can be equipped with a wearable head device, such as device 100 described above, to interact with a XR environment. As described above, the wearable head device can include one or more sensors to detect parameters of the user and/or the environment. Such sensors can include depth cameras, RGB cameras, LIDAR, sonar, orientation sensors, GPS, and similar sensors; these sensors can be used to determine parameters relevant to HRTF selection (e.g., environmental parameters and/or morphological parameters of the user), and HRTF filters can be selected accordingly. In some cases, such parameters (e.g., the user's height) can be input by the user and stored in a wearable system for later use.
With respect to the systems and methods described above, elements of the systems and methods can be implemented by one or more computer processors (e.g., CPUs or DSPs) as appropriate. The disclosure is not limited to any particular configuration of computer hardware, including computer processors, used to implement these elements. In some cases, multiple computer systems can be employed to implement the systems and methods described above. For example, a first computer processor (e.g., a processor of a wearable device coupled to a microphone) can be utilized to receive input microphone signals, and perform initial processing of those signals (e.g., signal conditioning and/or segmentation, such as described above). A second (and perhaps more computationally powerful) processor can then be utilized to perform more computationally intensive processing, such as determining probability values associated with speech segments of those signals. Another computer device, such as a cloud server, can host a speech recognition engine, to which input signals are ultimately provided. Other suitable configurations will be apparent and are within the scope of the disclosure.
Although the disclosed examples have been fully described with reference to the accompanying drawings, it is to be noted that various changes and modifications will become apparent to those skilled in the art. For example, elements of one or more implementations may be combined, deleted, modified, or supplemented to form further implementations. Such changes and modifications are to be understood as being included within the scope of the disclosed examples as defined by the appended claims.
This application is a continuation of U.S. application Ser. No. 16/789,201, filed on Feb. 12, 2020, which is a continuation of U.S. application Ser. No. 16/442,258, filed on Jun. 14, 2019, now U.S. Pat. No. 10,602,292, which claims priority to U.S. Provisional Application No. 62/685,258, filed on Jun. 14, 2018, the contents of which are incorporated by reference herein in their entirety.
Number | Date | Country | |
---|---|---|---|
62685258 | Jun 2018 | US |
Number | Date | Country | |
---|---|---|---|
Parent | 16789201 | Feb 2020 | US |
Child | 16987079 | US | |
Parent | 16442258 | Jun 2019 | US |
Child | 16789201 | US |