Patent Application
20240265908
Software applications are used on a regular basis to facilitate communication between users. As some examples, software applications can facilitate text-based communications such as email and other chatting/messaging platforms. Software applications can also facilitate audio and/or video-based communication platforms. Many other types of software applications for facilitating communications between users exist.
Software applications are increasingly being relied on for communications in both personal and professional capacities. It is therefore desirable for software applications to provide sophisticated features and tools which can enhance a user's ability to communicate with others and thereby improve the overall user experience. Thus, any tool that can improve a user's ability to communicate with others is desirable.
One of the oldest communication challenges faced by people around the world is the barrier presented by different languages. Further, even among speakers of the same language, accents can sometimes present a communication barrier that is nearly as difficult to overcome as if the speakers were speaking different languages. For instance, a person who speaks English with a German accent may have difficulty understanding a person who speaks English with a Scottish accent.
Today, there are relatively few software-based solutions that attempt to address the problem of accent conversion between speakers of the same language. One type of approach that has been proposed involves using voice conversion methods that attempt to adjust the audio characteristics (e.g., pitch, intonation, melody, stress) of a first speaker's voice to more closely resemble the audio characteristics of a second speaker's voice. However, this type of approach does not account for the different pronunciations of certain sounds that are inherent to a given accent, and therefore these aspects of the accent remain in the output speech. For example, many accents of the English language, such as Indian English and Irish English do not pronounce the phoneme for the digraph “th” found in Standard American English (SAE), instead replacing it with a “d” or “t” sound (sometimes referred to as th-stopping). Accordingly, a voice conversion model that only adjusts the audio characteristics of input speech does not address these types of differences.
Some other approaches have involved a speech-to-text (STT) conversion of input speech as a midpoint, followed by a text-to-speech (TTS) conversion to generate the output audio content. However, this type of STT-TTS approach generally involves a degree of latency (e.g., up to several seconds) that makes it impractical for use in real-time communication scenarios such as an ongoing conversation (e.g., a phone call).
To address these and other problems with existing solutions for performing accent conversion, disclosed herein is new software technology that utilizes machine-learning models to receive input speech in a first accent and then output a synthesized version of the input speech in a second accent, all with very low latency (e.g., 300 milliseconds or less). In this way, accent conversion may be performed by a computing device in real time, allowing two users to verbally communicate more effectively in situations where their different accents would have otherwise made such communication difficult.
Accordingly, in one aspect, disclosed herein is a method that involves a computing device (i) receiving an indication of a first accent, (ii) receiving, via at least one microphone, speech content having the first accent, (iii) receiving an indication of a second accent, (iv) deriving, using a first machine-learning algorithm trained with audio data comprising the first accent, a linguistic representation of the received speech content having the first accent, (v) based on the derived linguistic representation of the received speech content having the first accent, synthesizing, using a second machine learning-algorithm trained with (a) audio data comprising the first accent and (b) audio data comprising the second accent, audio data representative of the received speech content having the second accent, and (vi) converting the synthesized audio data into a synthesized version of the received speech content having the second accent.
In another aspect, disclosed herein is a computing device that includes at least one processor, a communication interface, a non-transitory computer-readable medium, and program instructions stored on the non-transitory computer-readable medium that are executable by the at least one processor to cause the computing device to carry out the functions disclosed herein, including but not limited to the functions of the foregoing method.
In yet another aspect, disclosed herein is a non-transitory computer-readable storage medium provisioned with software that is executable to cause a computing device to carry out the functions disclosed herein, including but not limited to the functions of the foregoing method.
One of ordinary skill in the art will appreciate these as well as numerous other aspects in reading the following disclosure.
The following disclosure refers to the accompanying figures and several example embodiments. One of ordinary skill in the art should understand that such references are for the purpose of explanation only and are therefore not meant to be limiting. Part or all of the disclosed systems, devices, and methods may be rearranged, combined, added to, and/or removed in a variety of manners, each of which is contemplated herein.
The processor 102 may comprise one or more processor components, such as general-purpose processors (e.g., a single- or multi-core microprocessor), special-purpose processors (e.g., an application-specific integrated circuit or digital-signal processor), programmable logic devices (e.g., a field programmable gate array), controllers (e.g., microcontrollers), and/or any other processor components now known or later developed. In line with the discussion above, it should also be understood that processor 102 could comprise processing components that are distributed across a plurality of physical computing devices connected via a network, such as a computing cluster of a public, private, or hybrid cloud.
In turn, data storage 104 may comprise one or more non-transitory computer-readable storage mediums that are collectively configured to store (i) software components including program instructions that are executable by processor 102 such that computing device 100 is configured to perform some or all of the disclosed functions and (ii) data that may be received, derived, or otherwise stored, for example, in one or more databases, file systems, or the like, by computing device 100 in connection with the disclosed functions. In this respect, the one or more non-transitory computer-readable storage mediums of data storage 104 may take various forms, examples of which may include volatile storage mediums such as random-access memory, registers, cache, etc. and non-volatile storage mediums such as read-only memory, a hard-disk drive, a solid-state drive, flash memory, an optical-storage device, etc. In line with the discussion above, it should also be understood that data storage 104 may comprise computer-readable storage mediums that are distributed across a plurality of physical computing devices connected via a network, such as a storage cluster of a public, private, or hybrid cloud. Data storage 104 may take other forms and/or store data in other manners as well.
The communication interface 106 may be configured to facilitate wireless and/or wired communication between the computing device 100 and other systems or devices. As such, communication interface 106 may communicate according to any of various communication protocols, examples of which may include Ethernet, Wi-Fi, Controller Area Network (CAN) bus, serial bus (e.g., Universal Serial Bus (USB) or Firewire), cellular network, and/or short-range wireless protocols, among other possibilities. In some embodiments, the communication interface 106 may include multiple communication interfaces of different types. Other configurations are possible as well.
The I/O interfaces 108 of computing device 100 may be configured to (i) receive or capture information at computing device 100 and/or (ii) output information for presentation to a user. In this respect, the one or more I/O interfaces 108 may include or provide connectivity to input components such as a microphone, a camera, a keyboard, a mouse, a trackpad, a touchscreen, or a stylus, among other possibilities. Similarly, the I/O interfaces 108 may include or provide connectivity to output components such as a display screen and an audio speaker, among other possibilities.
It should be understood that computing device 100 is one example of a computing device that may be used with the embodiments described herein, and may be representative of the computing devices 200 and 300 shown in
Turning to
For example, as shown in
The speech content may then be passed to the accent-conversion application 203 shown in
Further, the virtual microphone interface 205 may include a drop-down menu 207 or similar option for selecting the input source from which the accent-conversion application 203 will receive speech content, as the computing device 200 might have multiple available options to use as an input source. Still further, the virtual microphone interface 205 may include a drop-down menu 208 or similar option for selecting the desired output accent for the speech content. As shown in
Advantageously, the accent-conversion application 203 may accomplish the operations above, and discussed in further detail below, at speeds that enable real-time communications, having a latency as low as 50-700 ms (e.g., 200 ms) from the time the input speech received by the accent-conversion application 203 to the time the converted speech content is provided to the communication application 204. Further, the accent-conversion application 203 may process incoming speech content as it is received, making it capable of handling both extended periods of speech as well as frequent stops and starts that may be associated with some conversations. For example, in some embodiments, the accent-conversion application 203 may process incoming speech content every 160 ms. In other embodiments, the accent-conversion application 203 may process the incoming speech content more frequently (e.g., every 80 ms) or less frequently (e.g., every 300 ms).
Turning now to
At block 402, the computing device 300 may receive speech content 301 having a first accent. For instance, as discussed above with respect to
The ASR engine 302 includes one or more machine learning models (e.g., a neural network, such as a recurrent neural network (RNN), a transformer neural network, etc.) that are trained using previously captured speech content from many different speakers having the first accent. Continuing the example above, the ASR engine 302 may be trained with previously captured speech content from a multitude of different speakers, each having an Indian English accent. For instance, the captured speech content used as training data may include transcribed content in which each of the speakers read the same script (e.g., a script curated to provide a wide sampling of speech sounds, as well as specific sounds that are unique to the first accent). Thus, the ASR engine 302 may align and classify each frame of the captured speech content according to its monophone and triphone sounds, as indicated in the corresponding transcript. As a result of this frame-wise breakdown of the captured speech across multiple speakers having the first accent, the ASR engine 302 may develop a learned linguistic representation of speech having an Indian English accent that is not speaker-specific.
On the other hand, the ASR engine 302 may also be used to develop a learned linguistic representation for an output accent that is only based on speech content from a single, representative speaker (e.g., a target SAE speaker) reading a script in the output accent, and therefore is speaker specific. In this way, the synthesized speech content that is generated having the target accent (discussed further below) will tend to sound like the target speaker for the output accent. In some cases, this may simplify the processing required to perform accent conversion and generally reduce latency.
In some implementations, the speech content collected from the multiple Indian English speakers as well as the target SAE speaker for training the ASR engine 302 may be based on the same script, also known as parallel speech. In this way the transcripts used by the ASR engine 302 to develop a linguistic representation for speech content in both accents are the same, which may facilitate mapping one linguistic representation to the other in some situations. Alternatively, the training data may include non-parallel speech, which may require less training data. Other implementations are also possible, including hybrid parallel and non-parallel approaches.
It should be noted that the learned linguistic representations developed by the ASR engine 302 and discussed herein may not be recognizable as such to a human. Rather, the learned linguistic representations may be encoded as machine-readable data (e.g., a hidden representation) that the ASR engine 302 uses to represent linguistic information.
In practice, the ASR engine 302 may be individually trained with speech content including multiple different accents, across different languages, and may develop a learned linguistic representation for each one. Accordingly, at block 404, the computing device 300 may receive an indication of the Indian English accent associated with the received speech content 301, so that the appropriate linguistic representation is used by the ASR engine 302. As noted above, this indication of the incoming accent (e.g., incoming accent 303 in
At block 406, the ASR engine 302 may derive a linguistic representation of the received speech content 301, based on the learned linguistic representation the ASR engine 302 has developed for the Indian English accent. For instance, the ASR engine 302 may break down the received speech content 301 by frame and classify each frame according to the sounds (e.g., monophones and triphones) that are detected, and according to how those particular sounds are represented and inter-related in the learned linguistic representation associated with an Indian English accent.
In this way, the ASR engine 302 functions to deconstruct the received speech content 301 having the first accent into a derived linguistic representation with very low latency. In this regard, it should be noted that the ASR engine 302 may differ from some other speech recognition models that are configured predict and generate output speech, such as a speech-to-text model. Accordingly, the ASR engine 302 may not need to include such functionality.
The derived linguistic representation of the received speech content 301 may then be passed to the VC engine 304. Similar to the indication of the incoming accent 303, the computing device 300 may also receive an indication of the output accent (e.g., output accent 305 in
Similar to the ASR engine 302, the VC engine 304 includes one or more machine learning models (e.g., a neural network) that use the learned linguistic representations developed by the ASR engine 302 as training inputs to learn how to map speech content from one accent to another. For instance, the VC engine 304 may be trained to map an ASR-based linguistic representation of Indian English speech to an ASR-based linguistic representation of a target SAE speaker, using individual monophones and triphones within the training data as a heuristic to better determine the alignments. Like the learned linguistic representations themselves, the learned mapping between the two representations may be encoded as machine-readable data (e.g., a hidden representation) that the VC engine 304 uses to represent linguistic information.
Accordingly, at block 408, the VC engine 304 may utilize the learned mapping between the two linguistic representations to synthesize, based on the derived linguistic representation of the received speech content 301, audio data that is representative of the speech content 301 having the second accent. The audio data that is synthesized in this way may take the form of a set of mel spectrograms. For example, the VC engine 304 may map each incoming frame in the derived linguistic representation to an outgoing target speech frame.
In this way, the VC engine 304 functions to reconstruct acoustic features from the derived linguistic representation into audio data that is representative of speech by a different speaker having the second accent, all with very low latency. Advantageously, because the VC engine 304 works at the level of encoded linguistic data and does not need to predict and generate output speech as a midpoint for the conversion, it can function more quickly than alternatives such as a STT-TTS approach. Further, the VC engine 304 may more accurately capture some of the nuances of voice communications, such as brief pauses or changes in pitch, which may be lost if the speech content were converted to text first and then back to speech.
At block 410, the output speech generation engine 306 may convert the synthesized audio data into output speech, which may be a synthesized version of the received speech content 301 having the second accent. As noted above, the output speech may further have the voice identity of the target speaker whose speech content was used to train the ASR engine 302. In some examples, the output speech generation engine 306 may take the form of a vocoder or similar component that can rapidly process audio under the real-time conditions contemplated herein. The output speech generation engine 306 may include one or more additional machine learning algorithms (e.g., a neural network, such as a generative adversarial network, one or more Griffin-Lim algorithms, etc.) that learn to convert the synthesized audio data into waveforms that are able to be heard. Other examples are also possible.
As shown in
Although the examples discussed above involve a computing device 300 that utilizes the accent-conversation application for outgoing speech (e.g., situations where the user of computing device 300 is the speaker), it is also contemplated that the accent-conversion application may be used by the computing device 300 in the opposite direction as well, for incoming speech content 301 where the user is a listener. For instance, rather than being situated as a virtual microphone between a hardware microphone and the communication application 307, the accent-conversion application may be deployed as a virtual speaker between the communication application 307 and a hardware speaker of the computing device 300, and the indication of the incoming accent 303 and the indication of the output accent 305 shown in
As a further extension, the examples discussed above involve an ASR engine 302 that is provided with an indication of the incoming accent. However, in some embodiments it may be possible to use the accent-conversion application discussed above in conjunction with an accent detection model, such that the computing device 300 is initially unaware of one or both accents that may be present in a given communication. For example, an accent detection model may be used in the initial moments of a conversation to identify the accents of the speakers. Based on the identified accents, the accent-conversion application may determine the appropriate learned linguistic representation(s) that should be used by the ASR engine 302 and the corresponding learned mapping between representations that should be used by the VC engine 304. Additionally, or alternatively, the accent detection model may be used to provide a suggestion to a user for which input/output accent the user should select to obtain the best results. Other implementations incorporating an accent detection model are also possible.
In addition, for the example flow chart in
The program code may be stored on any type of computer readable medium, for example, such as a storage device including a disk or hard drive. The computer readable medium may include non-transitory computer readable medium, for example, such as computer-readable media that stores data for short periods of time like register memory, processor cache and Random-Access Memory (RAM). The computer readable medium may also include non-transitory media, such as secondary or persistent long-term storage, like read only memory (ROM), optical or magnetic disks, compact disc read only memory (CD-ROM), for example. The computer readable media may also be any other volatile or non-volatile storage systems. The computer readable medium may be considered a computer readable storage medium, for example, or a tangible storage device. In addition, for the processes and methods disclosed herein, each block in
Example embodiments of the disclosed innovations have been described above. Those skilled in the art will understand, however, that changes and modifications may be made to the embodiments described without departing from the true scope and spirit of the present invention, which will be defined by the claims.
Further, to the extent that examples described herein involve operations performed or initiated by actors, such as “humans,” “operators,” “users,” or other entities, this is for purposes of example and explanation only. Claims should not be construed as requiring action by such actors unless explicitly recited in claim language.
This application is a continuation of U.S. patent application Ser. No. 17/460,145, filed on Aug. 27, 2021, which claims the benefit of priority under 35 U.S.C. § 119 to U.S. Provisional Patent Application No. 63/185,345, filed on May 6, 2021, each of which is incorporated herein by reference in its entirety.
| Number | Date | Country | |
|---|---|---|---|
| 63185345 | May 2021 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 17460145 | Aug 2021 | US |
| Child | 18596031 | US |
