In-vehicle auxiliary audio technology for users with hearing loss

Abstract

A hearing application (162) for a vehicle audio system may include at least one speaker (148) configured to play playback content, and at least one hearing application programmed to receive optimization parameters from a hearing device (124) within a vehicle (104), the optimization parameters including signal processing parameters specific to the hearing device (124), applying the optimization parameters to the playback content, and outputting the playback content. And transmitting the playback content for playback by one of the hearing device (124) and / or the at least one speaker (148).

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims priority to U.S. Application No. 17 / 810,116, filed on June 30, 2022, the disclosure of which is incorporated herein by reference in its entirety. Technical Field

[0003] This article describes mechanisms for in-car assistive audio technology for users with hearing loss. Background Art

[0004] Users with hearing loss often wear hearing aids and also wear their hearing aids in a vehicle. However, when the user is in a vehicle, the vehicle audio system may not take into account the user's hearing loss and the presence of the hearing aid device. Summary of the invention

[0005] A hearing application for a vehicle audio system may include at least one speaker configured to play playback content, and at least one hearing application programmed to receive optimization parameters from a hearing device within the vehicle, the optimization parameters including signal processing parameters specific to the hearing device, apply the optimization parameters to the playback content, and transmit the playback content for playback by the hearing device and / or one of the at least one speaker.

[0006] A hearing application for a vehicle audio system, the system may include at least one speaker configured to play playback content, and at least one hearing application programmed to identify at least one user within the vehicle, receive an audio-consumer profile associated with the user, the audio-consumer profile including user-specific signal processing parameters, apply optimization data to the playback content, and transmit the playback content for playback by the at least one speaker. BRIEF DESCRIPTION OF THE DRAWINGS

[0007] Embodiments of the present disclosure are particularly pointed out 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, wherein:

[0008] FIG1 shows a block diagram of a hearing application in a car system according to one embodiment;

[0009] FIG. 2 illustrates an example block diagram of at least a portion of the system of FIG. 1 ;

[0010] FIG. 3 shows an example flow chart of a process for the hearing application of FIG. 1 ; and

[0011] FIG. 4 shows an example database of audio-consumer profiles for the hearing application of FIG. 1 . DETAILED DESCRIPTION

[0012] Hearing loss affects a large portion of the population. Approximately 360 million people worldwide suffer from hearing loss, most of whom are adults. Many of these adults prefer to use cars as their preferred form of transportation in one way or another. However, the sound systems within cars do not adequately take hearing loss or hearing devices into account during their operation.

[0013] Disclosed herein are systems and methods for providing hearing applications with in-vehicle assistive audio technology to those users with hearing loss. The hearing application will allow for better speech clarity and overall audio experience without the need to wear a hearing aid while driving or riding in a vehicle. The hearing application interfaces with the vehicle's infotainment system. The hearing application can maintain an audio-consumer profile with a personalized audio model that controls the audio processing layer applied to the audio output of the vehicle's audio system. This can include telephone and voice conversation systems, public announcement (PA) systems, public transportation systems, and the like. This additional processing layer also ensures a personalized audio experience, such as better speech clarity, desired equalization, stronger noise reduction, and the like. These experiences are individually customized to the user's needs to reduce the impact of existing hearing loss.

[0014] This enhanced audio can be played back through the vehicle's speakers, or streamed directly to the user's hearing aids. The audio-consumer profile can be received from the hearing aid itself, the hearing aid manufacturer, or from personalized data such as age and audiograms, personal hearing ratings, and the user's audio adjustment history. Such adjustments can be made in the hearing application and the infotainment device in the vehicle, or using hands-free software. The profile can be stored in the vehicle's hearing application or audio system, and can also be exported to an off-site server for further analysis or transferred to other vehicles via the user profile.

[0015] Users without hearing impairments may also benefit from hearing applications because the hearing application can issue a hearing test, identify unknown hearing problems, and provide a personal profile to the user in response to the hearing test.

[0016] FIG1 shows a block diagram of a hearing application 162 in an automotive system 100 according to one embodiment. The automotive system 100 may be designed for a vehicle 104 configured to transport passengers. The vehicle 104 may include various types of passenger vehicles, such as a crossover utility vehicle (CUV), a sport utility vehicle (SUV), a truck, a recreational vehicle (RV), a boat, an airplane, or other mobile machines for transporting people or goods. In addition, the vehicle 104 may be an autonomous, partially autonomous, self-driving, unmanned, or driver-assisted vehicle. The vehicle 104 may be an electric vehicle (EV), such as a battery electric vehicle (BEV), a plug-in hybrid electric vehicle (PHEV), a hybrid electric vehicle (HEV), etc.

[0017] The vehicle 104 may be configured to include various types of components, processors, and memory, and may communicate with a communication network 110. The communication network 110 may be referred to as a "cloud" and may involve data transmission via a wide area network and / or a local area network such as the Internet, a global positioning system (GPS), a cellular network, Wi-Fi, Bluetooth, etc. The communication network 110 may provide communication between the vehicle 104 and external or remote servers 112 and / or databases 114 and other external applications, systems, vehicles, etc. The communication network 110 may provide navigation, music or other audio, program content, marketing content, Internet access, speech recognition, cognitive computing, artificial intelligence to the vehicle 104.

[0018] The remote server 112 and database 114 may include one or more computer hardware processors coupled to one or more computer storage devices for performing the steps of one or more methods as described herein, and may enable the vehicle 104 to communicate and exchange information and data with systems and subsystems external to the vehicle 104 and local or onboard the vehicle 104. The vehicle 104 may include one or more processors 106 configured to execute certain instructions, commands, and other routines as described herein. An internal vehicle network 126 may also be included, such as a vehicle controller area network (CAN), an Ethernet network, and a media-oriented system transport (MOST). The internal vehicle network 126 may allow the processor 106 to communicate with other vehicle 104 systems (such as a vehicle modem, a GPS module and / or a global system for mobile communications (GSM) module configured to provide current vehicle position and heading information, and various vehicle electronic control units (ECUs) configured to cooperate with the processor 106).

[0019] The processor 106 may execute instructions for certain vehicle applications, including navigation, infotainment, climate control, etc. Various types of computer-readable storage media 122 may be used to maintain instructions for the respective vehicle systems in a non-volatile manner. The computer-readable storage media 122 (also referred to herein as memory 122 or storage device) includes any non-transitory medium (e.g., tangible medium) that participates in providing instructions or other data that can be read by the processor 106. The computer-executable instructions may be compiled or interpreted from a computer program created using various programming languages ​​and / or techniques, including, alone or in combination, but not limited to Java, C, C++, C#, Objective C, Fortran, Pascal, JavaScript, Python, Perl, and PL / Structured Query Language (SQL).

[0020] The processor 106 may also be part of a multi-mode processing system 130. The multi-mode processing system 130 may include various vehicle components, such as the processor 106, memory, sensors, input devices, displays, etc. The multi-mode processing system 130 includes one or more input and output devices for exchanging data processed by the multi-mode processing system 130 with the other elements shown in FIG. 1. Some examples of these processes may include navigation system output (e.g., time-sensitive directions for the driver), incoming text messages converted to output speech, vehicle status output, etc., such as output from a local or onboard storage medium or system. In some embodiments, the multi-mode processing system 130 provides input / output control functions with respect to one or more electronic devices, such as a head-up display (HUD), a vehicle display, and / or a driver's or passenger's mobile device, sensor, camera, etc. The multi-mode processing system 130 includes a hearing application 162 that is configured to help a user with hearing loss in the vehicle optimally receive audio signals from the vehicle infotainment system. The user may be a driver or one of the passengers in the vehicle 104. In some examples, passengers may be detected via weight sensors in the seats and sensors that observe whether seat belts are fastened.

[0021] The vehicle 104 may include a wireless transceiver 134 (such as a Bluetooth module, a ZIGBEE transceiver, a Wi-Fi transceiver, an IrDA transceiver, a radio frequency identification (RFID) transceiver, etc.) configured to communicate with compatible wireless transceivers of various user devices and with the communication network 110.

[0022] The vehicle 104 may include various sensors and input devices as part of the multi-mode processing system 130. For example, the vehicle 104 may include at least one microphone 132. The microphone 132 may be configured to receive audio signals from within the vehicle cabin, such as acoustic utterances including spoken words, phrases, or commands from a user. The microphone 132 may include an audio input configured to provide audio signal processing functions to the processor 106, including amplification, conversion, data processing, etc. The vehicle 104 may include at least one microphone 132 arranged throughout the vehicle 104. Although the microphone 132 is described herein as being used for the purpose of the multi-mode processing system 130, the microphone 132 may be used for other vehicle functions, such as active noise cancellation, hands-free interface, etc. The microphone 132 may facilitate speech recognition from the audio received via the microphone 132 according to the grammar associated with the available commands, as well as speech prompt generation. The microphone 132 may include multiple microphones 132 arranged throughout the vehicle cabin. The microphone 132 may be configured to receive audio signals from the vehicle cabin. These audio signals may include occupant speech, sounds, etc., and may include instructions, wake-up speech, etc. The microphone 132 may also detect and pick up noise levels and other ambient noise characteristics. This may be used for noise cancellation or other processing that may be noise-related.

[0023] The vehicle 104 may include an audio system having audio playback capabilities through an audio processor (sound system) 109 and vehicle speakers 148 or headphones. Audio playback may include audio from sources such as a vehicle radio, including satellite radio, decoded amplitude modulation (AM) or frequency modulation (FM) radio signals, audio playback from a compact disk (CD) or digital versatile disk (DVD), streaming audio from a mobile device, commands from a navigation system, etc.

[0024] As explained, the vehicle 104 may include various displays and user interfaces, including a HUD, a center console display, steering wheel buttons, etc. A touch screen may be configured to receive user input. A visual display may be configured to provide visual output to a user.

[0025] The carrier 104 may include other sensors, such as at least one sensor 152. The sensor 152 may be another sensor in addition to the microphone 132, and the data provided by it may be used by the hearing application 162. In one example, the sensor 152 may include a power pad configured to detect the presence of a device, such as a mobile device or a hearing device 124. The power pad may be configured to wirelessly charge these devices and may indicate the presence of the hearing device 124 to the hearing application 162. The hearing application 162 may then determine that the hearing device 124 is located on the power pad for charging and is not currently being worn by the user. In one example, the hearing device 124 may be turned off or charging. In this example, the hearing device 124 is not connected to the carrier 104. In another example, the hearing aid may be worn and already paired with the user device, and therefore no other device may be able to provide a connection to the hearing device 124.

[0026] In another example, the hearing device 124 can be charged within the housing or charging station. The charging station can provide a USB connection to the carrier to draw power. The housing itself can also rest on a charging pad to charge wirelessly and in turn recharge the hearing device 124 nested within the housing.

[0027] The hearing device 124 may be a device worn by a user within the vehicle 104 to provide acoustic amplification of sound to the user's ear. These devices are typically worn in and around the ear by users with impaired hearing. The hearing device 124 may be battery powered and may be recharged via wired or wireless charging. In some examples, the hearing device 124 may also include in-ear and on-ear headphones.

[0028] The hearing device 124 may communicate with the vehicle system via an internal vehicle network 126 or via other wireless networks including a wireless transceiver 134 such as Bluetooth, Wi-Fi, etc. The hearing device 124 may transmit the optimization data to a hearing application 162, and the vehicle 104 may transmit the playback signal and other information to the hearing device via the hearing application 162. Although the hearing application 162 is shown as being separate and distinct from the processor 106, the hearing application 162 may be included in the processor 106, have its own processor or controller, or be integrated into a user device such as a mobile device.

[0029] Although not specifically shown herein, the vehicle 104 may include many other systems (such as a GPS system, human machine interface (HMI) controls, video systems, etc.). The multi-modal processing system 130 may use inputs from various vehicle systems, including the audio processor 109 and the sensors 152. For example, the multi-modal processing system 130 may determine whether a user's utterance is system directed (SD) or non-system directed (NSD). SD utterances may be made by a user that are intended to affect an output within the vehicle 104 (such as a spoken command to "turn on the music"). NSD utterances may be utterances spoken during a conversation with another occupant, on the phone, or while speaking to someone outside the vehicle. These NSDs are not intended to affect vehicle outputs or systems. NSDs may be person-to-person conversations.

[0030] Although automotive systems are discussed in detail herein, other applications are contemplated. For example, similar functionality may also be applied to other non-automotive housings, such as augmented reality or virtual reality housings for use in living environments with smart glasses, phones, eye trackers, etc. Although the term "user" is used throughout, this term may be interchangeable with other terms such as speaker, occupant, etc.

[0031] FIG2 shows an example block diagram of at least a portion of the system of FIG1 including a hearing application 162, an audio processor 109, a speaker 148, and a hearing device 124. As described above, once the user is within the vehicle, the user's hearing device 124 can communicate with the vehicle system via an internal vehicle network 126 or via other wireless radio frequency channels including a wireless transceiver 134 of Bluetooth, Wi-Fi, ZIGBEE, etc. The hearing device 124 can also communicate via an optical channel such as infrared light. The hearing device 124 can transmit optimization data to the hearing application 162. The optimization data can include data about the hearing device 124 (such as manufacturing settings, user-specific preferences, settings or signal processing requirements, and other data related to the user's hearing impairment).

[0032] In response to the hearing device 124 being worn by the user in the vehicle 104, the hearing application 162 may transmit a playback signal to the hearing device 124. The playback signal may include an audio signal that is normally transmitted via the vehicle speaker 148. That is, in addition to the audio playback from a phone or voice conversation, or other channels such as navigation or alarms, and entertainment signals from radio, infotainment, etc. may be streamed to the hearing device 124. For example, when another user is in the vehicle 104, such streaming may run in parallel with the normal audio playback via the vehicle speaker 148. In this case, the hearing application may initiate a latency for the streaming so that the playback from both the hearing device 124 and the vehicle speaker 148 is synchronized to avoid reverberation. Depending on the audio architecture, the hearing application 162 may increase the latency of the audio processor 109 or the latency of the audio channel of the hearing device 124 (e.g., in the hearing application 162). The latency introduced by the audio processing in the hearing device 124 may be part of the optimization data transmitted to the hearing application 162. Since one of the configuration parameters of the hearing application 162 is the latency of the vehicle audio system, the hearing application 162 may calculate the required delay that needs to be introduced in the respective paths in order to synchronize the different playback systems.

[0033] The hearing device 124 may apply audio processing dictated by the device when receiving playback signals from the hearing application 162. That is, the settings normally applied by the hearing device 124 under normal amplification are also applied to the playback signal. This allows the user to receive playback of audio normally presented via the vehicle speaker 148 at the hearing device 124 using the user's settings. This may increase the ability to hear commands from the vehicle 104.

[0034] In the case where playback content is transmitted at both the speaker 148 and the hearing device 124, the playback at the speaker 148 may not be processed with the optimized parameters. This may be because there may be another user in the vehicle who does not require any hearing optimization processing, and to the extent that the other user would benefit from the optimized parameters, that user is already receiving optimized playback via the hearing device 124.

[0035] In contrast, users may often remove their hearing devices 124 when they enter a vehicle 104. This may be for comfort or for charging the hearing device 124. During this example, a phone call or voice conversation may be provided via the speaker 148, but the hearing application 162 may apply additional audio processing to the playback. The hearing application 162 may receive playback content from the vehicle 104, such as the vehicle infotainment system or the processor 106. The playback content may include a phone call or voice conversation, which may be processed by the hearing application 162 based on optimization data received from the hearing device 124. The optimization data may be received once by the hearing application 162 and stored for future use, but may also be continuously updated if user-specific or model-specific settings and data have changed. The settings may be provided by the vendor via the communication network 110, or may be provided from the hearing aid 124.

[0036] The hearing application 162 may apply parameters or optimizations based on the optimization data and then provide playback content to the speaker 148. The format of the parameters and audio processing algorithms are shared between the vendor of the hearing device 124 and the audio system of the vehicle 104, such as the audio processor 109. In some examples, a conversion module may be included to facilitate any misunderstanding of the various parameters and signal processing algorithms between the audio processor 109 and the hearing device 124. Regardless, the optimization data, whether provided by the vendor via the communication network 110 or the hearing device 124, allows the hearing impaired user to have a better listening experience within the vehicle, but the necessary audio processing is applied on top of the vehicle's processing.

[0037] The hearing application 162 can thus interface with the vehicle 104 and the hearing device 124 to facilitate communication therebetween. The hearing application 162 can be installed in the vehicle's non-volatile memory 122 and can be processed by the processor 106. Additionally or alternatively, the hearing application 162 can be on a user's mobile device that is configured to communicate with the vehicle 104 via telematics.

[0038] The hearing application 162 may also be configured to collect hearing-related data from the user within the vehicle 104. This may include a set of psychoacoustic tests within the vehicle. These tests may be seat-specific, as well as factor-specific (e.g., perceived loudness, preferred loudness and equalization, personal speech intelligibility in the presence of driving noise, etc.). The user's responses may be included in the hearing-related data and processed by the hearing application 162. The user may also provide personal data such as age, gender, etc. Pure tone audiometry results obtained from third parties may also be shared with the hearing application 162. Such results may be uploaded by the user via the hearing application 162 using the user's mobile device.

[0039] The hearing application 162 may use the hearing-related data and / or the personal data to generate an audio-consumer profile for the corresponding user. The audio-consumer profile may include optimization parameters or data specific to the user. That is, in the above example where the optimization parameters were specific to the hearing device 124, here, the optimization parameters are specific to the user. This may allow for an enhanced and personalized audio experience for all users, not just users with hearing devices.

[0040] The psychoacoustic test may be generated by the hearing device vendor or the hearing application 162 itself. In one example, the hearing application 162 may issue a query asking whether hearing impairment has been previously diagnosed, and if the user responds negatively, a typical or default sensitivity or threshold curve may be used. A third party may also generate a psychoacoustic test, and analyze responses thereto. In an example where there is a user with normal hearing function and no known hearing impairment has been previously diagnosed, a standardized hearing test may be given. It is worth noting that there are cases where a user scores normal (or near normal) in one hearing test, such as an audiogram-type test administered in silence, but has a lower-than-normal score in a test performed under more complex listening conditions (e.g., speech intelligibility in noise). Simple hearing tests can often be performed in silence, do not have the resolution to show realistic listening problems, and may be ignored. Therefore, such hearing tests should not be limited to a few simple audiogram tones, but may cover more realistic situations that match a given listening scenario. In addition, the order of the tests and exactly which tests are performed may depend on the results of previously performed tests. In addition to which vendor's test to use, the hearing application 162 may determine the order of existing tests, the type of tests, and the like.

[0041] The audio-consumer profile may be stored in the vehicle's memory (e.g., non-volatile memory 122) and / or the user's mobile phone and / or remote server 112. As explained, the remote server 112 may be associated with the vendor of the hearing device 124. The audio-consumer profile may be exported to the server 112 in order to save the profile. Then, if the user enters another hearing application-enabled vehicle, the audio-consumer profile may be used by the other vehicle. This may allow for a seamless user audio experience in each enabled vehicle that the user enters.

[0042] The user may be identified in one of several ways. One example is that the vehicle telematics system may detect the user's mobile device and identify the user based on a handshake with the mobile device. This may occur when the hearing application 162 or the vehicle telematics system is paired with the mobile device. The processor 106 may indicate the identity of the user to the hearing application 162 and may automatically retrieve a previously stored audio-consumer profile for the user. The user may also enter an ID and password via the vehicle display 160, the user's mobile device, etc. Audible recognition may also be used to identify the user.

[0043] Once a user is identified and authenticated via any of the mechanisms described above, the user may have an accessible user profile. The user profile may allow the user to periodically change the audio-consumer profile as well as settings and preferences. In one example, the user may update his or her hearing device vendor, or the brand and model of the hearing device. In an example where the hearing application 162 is housed on the user's mobile device, the user may also modify settings when not in the vehicle 104.

[0044] The audio-consumer profile can be continuously updated to improve the optimization parameters. In one example, the hearing application 162 can employ machine learning techniques to update the profile based on the most recent audio settings selected by the user. For example, the hearing application 162 can change the gain or equalization preferences in a given environmental condition or playback setting, etc. These adjustments can be made without input from the user. Adjustments can be made based on new data or aggregated data (including personal data of the relevant user, other psychoacoustic testing, etc.). By employing machine learning to continuously improve the audio-consumer profile, the user can enjoy continuously improved assistive hearing technology and personalized settings over the years and throughout the use of different car models.

[0045] 3 shows an example flow chart of a process 300 for the hearing application 162 of FIG. 1 , where the hearing application 162 establishes an interface between the vehicle 104 and the hearing device 124. The process 300 begins at block 305, where the hearing application 162 establishes communication with the hearing device 124. This may occur when the user enters the vehicle 104 and is within range of the wireless transceiver 134 detecting the hearing device 124. The transceiver 134 and the hearing device 124 may send requests and responses until the two devices are paired with each other. They may include Bluetooth or other similar radio frequency communications. The hearing application 162 may require certain security or PINs to be exchanged, at least upon initial pairing, but may otherwise automatically pair after the initial pairing.

[0046] Once the hearing application 162 and the hearing device 124 have established communication, the hearing application 162 may determine the state of the hearing device at box 310. The hearing device 124 state may be an indication of whether the hearing device 124 is in-ear or out-of-ear. The in-ear state may be a default state, and the hearing application 162 may determine that the hearing device 124 is in-ear, as opposed to an indication that the hearing device 124 is not in-ear. For example, detection of a magnetic field at the power pad may indicate the presence of the hearing device 124, and therefore the hearing device 124 is considered to be out-of-ear. The hearing application 162 may support a carrier sensor (such as sensor 152) to determine whether there is an indication that the hearing device 124 is out-of-ear. In one example, if the hearing device 124 or the housing of the hearing device 124 has been placed on a charger, or connected via USB, the charger may send a signal to the hearing application 162 that the hearing device is being charged.

[0047] At block 315, the hearing application 162 may establish an operating mode based at least in part on the hearing device state. In the out-of-ear state, the operating mode may be a speaker playback mode, where playback content is routed through the speaker 148. In the in-ear state, the operating mode may be a hearing device playback mode, where playback content is routed through the hearing device 124.

[0048] At block 320, the hearing application 162 may receive playback content from the vehicle 104. The playback content may include phone and voice content to be played back for the user, as well as audio such as music or other infotainment audio content. The playback content may have undergone signal processing traditionally performed by vehicle audio and infotainment systems, such as active noise cancellation, amplification, equalization, etc.

[0049] At block 325, the hearing application 162 may apply the optimization data received from the hearing device 124 and / or a supplier of the hearing device 124. As explained, the optimization data may include various parameters for applying additional signal processing to the playback content.

[0050] At block 330, the hearing application 162 may transmit the playback content to the speaker 148 in speaker playback mode or to the hearing device 124 in hearing device playback mode. The user may then enjoy playback with additional signal processing layers specific to the user and / or the user's hearing device 162.

[0051] FIG. 4 shows an example database 400 for audio-consumer profiles. As described above, the hearing application 162 can be configured to collect hearing-related data from users in the vehicle 104. This can include a set of psychoacoustic tests in the vehicle. These tests can be seat-specific, as well as factor-specific (e.g., perceived loudness, preferred loudness and equalization, personal voice intelligibility in the presence of driving noise, etc.). The user's response can be included in the hearing-related data and processed by the hearing application 162. The results can be collected via the vehicle speaker 148, or collected from the user's mobile device, display 160, etc. The user can also provide personal data (e.g., age, gender, etc.). Pure tone audiometry results performed by a third party can also be shared with the hearing application 162. Although FIG. 4 shows an example profile, more or less data can be included. The user can also choose to refuse to provide certain details (such as his or her age, etc.).

[0052] The hearing application 162 can use the hearing-related data and / or the personal data to generate an audio-consumer profile for the corresponding user. The audio-consumer profile can include optimization parameters specific to the user. That is, in the above example where the optimization parameters are specific to the hearing device 124, here, the optimization parameters are specific to the user. This can also be used for an enhanced and personalized audio experience for all users, not just users with hearing devices.

[0053] The audio-consumer profile can be stored in the vehicle's memory (e.g., non-volatile memory 122) and / or the user's mobile phone and / or remote server 112. As explained, the remote server 112 can be associated with the vendor of the hearing device 124. The audio-consumer profile can be exported to the server 112 in order to save the profile. Then, if the user enters another vehicle that enables the in-ear application, the audio-consumer profile can be used by the other vehicle. This can allow for a seamless user audio experience.

[0054] Once the user is identified and authenticated, an audio-consumer profile associated with the user may be retrieved. The user may periodically change the audio-consumer profile as well as settings and preferences. In one example, the user may update his or her hearing device vendor, or the brand and model of hearing device. In examples where the hearing application 162 is hosted on the user's mobile device, the user may also modify settings when not in the vehicle 104.

[0055] As explained, by deriving an audio-consumer profile, various servers, vendors, etc. can aggregate the data and use the data to improve optimization parameters. In one example, the hearing application 162 can employ machine learning techniques to update the profile based on the most recent audio settings selected by the user. For example, the hearing application 162 can change the gain or equalization preferences in a given environmental condition or playback setting, etc. These adjustments can be made without input from the user. Adjustments can be made based on new data or aggregated data (including personal data of the relevant user, other psychoacoustic testing, etc.). By employing machine learning to continuously improve the audio-consumer profile, the user can enjoy continuously improved assistive hearing technology and personalized settings over the years and throughout the use of different car models.

[0056] Thus, a vehicle audio system is described herein for allowing users, particularly hearing impaired users, to enjoy a better in-vehicle audio experience. Assistive listening technology allows for audio processing that is customized to the individual needs and preferences of the user, both hearing impaired users and normal hearing users. The user has the option of removing his or her hearing device during vehicle use. The inconvenience of wearing a hearing aid can be avoided, and the opportunity to charge the hearing device during the user's time in the vehicle is now possible. Furthermore, the system described herein can allow users who are unaware of any hearing deficiencies to become aware of, as well as increase in in-vehicle hearing capabilities. Users with normal hearing capabilities can enjoy a customized and personalized audio processing system that better matches their tastes and preferences.

[0057] Audio-consumer profiles can be dynamic and continuously change based on the user's demographics, life, habits, health, etc. The ability to store and export preferred settings and to continually develop and improve audio-consumer profiles by applying machine learning adds to the value of the technology. Such audio-consumer profiles can follow a user through hearing applications over years and through multiple vehicles.

[0058] The description of the various embodiments has been presented for purposes of illustration, but is not intended to be exhaustive or limited to the disclosed embodiments. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the described embodiments.

[0059] Aspects of the present embodiment may be embodied as a system, method, or computer program product. Therefore, aspects of the present disclosure may take the form of a complete hardware embodiment, a complete software embodiment (including firmware, resident software, microcode, etc.), or a combination of software and hardware embodiments, which may generally be referred to herein as a "module" or "system." In addition, aspects of the present disclosure may take the form of a computer program product embodied in one or more computer-readable media having a computer-readable program code embodied thereon.

[0060] Any combination of one or more computer readable media may be utilized. A computer readable medium may be a computer readable signal medium or a computer readable storage medium. A computer readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples of computer readable storage media (a non-exhaustive list) include the following: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the context of this document, a computer readable storage medium may be any tangible medium that can contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device.

[0061] Aspects of the present disclosure are described above with reference to flowchart illustrations and / or block diagrams of methods, devices (systems) and computer program products according to embodiments of the present disclosure. It should be understood that each frame of the flowchart illustration and / or block diagram and the combination of frames in the flowchart illustration and / or block diagram can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device enable the functions / actions specified in one or more frames of the flowchart and / or block diagram to be implemented. Such a processor can be, but is not limited to, a general-purpose processor, a special-purpose processor, a special-purpose processor or a field programmable processor.

[0062] The flowcharts and block diagrams in the accompanying drawings illustrate the possible implementation architectures, functions, and operations of the systems, methods, and computer program products according to various embodiments of the present disclosure. In this regard, each box in the flowchart or block diagram may represent a module, fragment, or portion of a code, which includes one or more executable instructions for implementing (one or more) specified logical functions. It should also be noted that in some alternative embodiments, the functions marked in the box may not occur in the order marked in the figure. For example, two boxes shown in succession may actually be executed substantially simultaneously, or the boxes may sometimes be executed in reverse order, depending on the functions involved. It will also be noted that each box illustrated in the block diagram and / or flowchart and the combination of boxes in the block diagram and / or flowchart can be implemented by a dedicated hardware-based system or a combination of dedicated hardware and computer instructions that performs a specified function or action.

[0063] Although exemplary embodiments are described above, these embodiments are not intended to describe all possible forms of the present invention. On the contrary, the words used in the specification are descriptive words rather than restrictive words, and it should be understood that various changes can be made without departing from the spirit and scope of the present invention. In addition, the features of various implementation embodiments can be combined to form other embodiments of the present invention.

Claims

1. A hearing application for a vehicle audio system, the system comprising: at least one speaker configured to play playback content; at least one hearing application programmed to receiving optimization parameters from a hearing device in the carrier, the optimization parameters comprising signal processing parameters specific to the hearing device; applying the optimization parameters to the playback content; as well as The playback content is transmitted for playback by one of the hearing device and the at least one speaker.

2. The system according to claim 1, wherein: The hearing application is further programmed to determine whether the hearing device is in an in-ear state or an out-of-ear state.

3. The system according to claim 2, wherein: The hearing application is further programmed to transmit the playback content to the hearing device in response to the hearing device being in an in-ear state.

4. The system according to claim 3, wherein: The hearing application is further programmed to transmit the playback content to the at least one speaker simultaneously with transmitting the playback content to the hearing device.

5. The system according to claim 4, wherein: The hearing application is further programmed to apply a time delay to the playback content transmitted to the hearing device to avoid reverberation, wherein the playback content at the at least one speaker is not optimized.

6. The system according to claim 2, wherein: The hearing application is further programmed to transmit the playback content to the at least one speaker in response to the hearing device being in an out-of-ear state.

7. The system according to claim 1, wherein: The optimization parameters are specific to the hearing device.

8. The system according to claim 1, wherein: The hearing device and the hearing application communicate via a wireless communication protocol.

9. A hearing application for a vehicle audio system, the system comprising: at least one speaker configured to play playback content; At least one hearing application, the at least one hearing application being programmed to: identifying at least one user within the vehicle; receiving an audio-consumer profile associated with the user, the audio-consumer profile comprising signal processing parameters specific to the user; applying the optimization data to the playback content; as well as The playback content is transmitted for playback by the at least one speaker.

10. The system according to claim 9, wherein: The audio-consumer profile comprises optimized parameters from a hearing device associated with the at least one user, the optimized parameters comprising signal processing parameters specific to the hearing device.

11. The system according to claim 10, wherein: The optimization parameters are received from a supplier of the hearing device.

12. The system according to claim 10, wherein: The hearing application is further programmed to determine whether the hearing device is in an in-ear state or an out-of-ear state.

13. The system according to claim 12, wherein: The hearing application is further programmed to transmit the playback content to the hearing device in response to the hearing device being in an in-ear state.

14. The system of claim 13, wherein the hearing application is further programmed to transmit the playback content to the at least one speaker simultaneously with transmitting the playback content to the hearing device.

15. The system of claim 14, wherein: The hearing application is further programmed to apply a time delay to the playback content transmitted to the hearing device to avoid reverberation, wherein the playback content at the at least one speaker is not optimized.

16. The system according to claim 11, wherein: The hearing application is further programmed to transmit the playback content to the at least one speaker in response to the hearing device being in an out-of-ear state.

17. The system of claim 11, wherein: The hearing device and the hearing application communicate via a wireless communication protocol.

18. The system of claim 9, wherein: The hearing application is also programmed to receive user preferences from a user input and update the audio-consumer profile based on the user preferences.

19. The system of claim 17, wherein: The hearing application is also programmed to transmit the updated audio-consumer profile to a remote server.

20. The system of claim 9, wherein: The hearing application is also programmed to receive aggregated system data from a remote server and apply machine learning to the audio-consumer profile to update the audio-consumer profile.

Images