US20210211800A1 - Method and system for audio sharing - Google Patents

Abstract

The present invention provide a method and system of audio sharing aimed to revolutionize the way people listen and share music and to give multiple uses to a wireless headphone referred to as HEDphone. A communication protocol referred to as HEDtech protocol is used in a HED system to allow users to share music amongst a plurality of HEDphones while using a single audio source. A wireless connection is established between the HEDphone and a mobile device including an audio source while simultaneously having the capability of allowing other HEDphone users to join wirelessly and listen to the same audio source. A feature of Super Human Hearing (SHH) goes beyond conventional ANR (ambient noise reduction) with additional features that allow the user to control their aural environment by being able to directionally increase or decrease selective frequencies.

Description

CROSS-REFERENCE TO RELATED APPLICATION
• The present application is a continuation of U.S. patent application Ser. No. 17/062,220 filed Oct. 2, 2020 and entitled “Method and System for Audio Sharing,” which is a continuation of U.S. patent application Ser. No. 16/842,065 filed Apr. 7, 2020 and entitled “Method and System for Audio Sharing,” now U.S. Pat. No. 10,932,028, which is a continuation of U.S. patent application Ser. No. 16/779,157 filed Jan. 31, 2020 and entitled “Method and System for Audio Sharing,” now U.S. Pat. No. 10,904,655, which is a continuation of U.S. patent application Ser. No. 16/729,232 filed Dec. 27, 2019 and entitled “Method and System for Audio Sharing,” now U.S. Pat. No. 10,750,270, which is a continuation of U.S. patent application Ser. No. 16/719,719 filed Dec. 18, 2019 and entitled “Method and System for Audio Sharing,” which is a continuation of U.S. patent application Ser. No. 16/413,384 filed May 15, 2019 and entitled “Method and System for Audio Sharing,” now U.S. Pat. No. 10,687,137, which is a continuation of U.S. patent application Ser. No. 14/757,655 filed Dec. 23, 2015 and entitled “Method and System for Audio Sharing,” now U.S. Pat. No. 10,390,122, which claims priority to U.S. Provisional Patent Application Ser. No. 62/096,209 filed Dec. 23, 2014 and entitled “Method and System for Audio Sharing,” which are hereby incorporated by reference herein.
BACKGROUND OF THE INVENTIONField of the Invention
• The present invention relates to a system including a headset which is used in connection with a multimedia device and in particular to a system and method for music sharing and communication amongst wireless headphones and an improved wireless headphone providing control of the aural environment to provide super human hearing.
Description of the Related Art
• Bluetooth enabled headphones are known for wireless communication to an audio source. U.S. Pat. No. RE43,872 describes that headsets or headphones are commonly used in connection with communication and/or multimedia devices in order to listen to audio signals produced by or transferred from these devices. Examples of such communication and/or multimedia devices are radio receivers, portable music players like CD players and MP3 players as well as mobile phones. The most recent generation of these headsets is represented by so-called on-ear Bluetooth voice headsets which have become more and more popular in the past. The reason is that these on-ear headsets provide a very convenient way in order to wear the headset for a hands-free communication. The head set can be used in connection with a communication and/or multimedia device and which allows to listen to audio signals either in a mono mode, which is sufficient for telephone communication, or in a stereo mode, which is desired for listening to music.
• U.S. Pat. No. 8,340,058 describes a headphone having ability to communicate using Internet Protocol (IP) standard. In an embodiment, the headphone is provided a wireless LAN (WLAN) network interface such that VOIP calls are conducted using a wireless medium. Similarly, a Bluetooth protocol type interface is also provided to communicate with a cellular phone and the communication forms the basis for the voice calls between the headphone and other cellular phones connected via the cellular network.
• It is desirable to provide a method and system to use wireless headphones for audio sharing between headphones.
SUMMARY OF THE INVENTION
• The present invention provide a method and system of audio sharing aimed to revolutionize the way people listen and share music and to give multiple uses to a wireless headphone referred to as HEDphone. A communication protocol referred to as HEDtech protocol is used in a HED system to allow users to share music amongst a plurality of HEDphones while using a single audio source. A wireless connection is established between the HEDphone and a mobile device including an audio source while simultaneously having the capability of allowing other HEDphone users to join wirelessly and listen to the same audio source. The HED system creates what is referred to as HEDmesh using the HEDtech protocol.
• In one embodiment, the HEDphone is a Hi-Fi stereo wireless headphone with the added capability of creating a wireless mesh (HEDmesh) in order to share audio with other HEDphone users within range. The HEDphone is wirelessly connected to a mobile device, such as a mobile phone or tablet via Bluetooth or cable, and is then able to broadcast the audio via the HEDtech protocol to others users within range.
• In one embodiment, the HEDphone provides a feature referred to as Super Human Hearing (SHH). Super Human Hearing (SHH) goes beyond conventional ANR (ambient noise reduction) with additional features that allow the user to control their aural environment by being able to directionally increase or decrease selective frequencies.
• In one embodiment, a detection device is used in combination with the HEDphone to detect whether the HEDphone is positioned on the head. The audio source to the HEDphone can be stopped when the HEDphone is detected as having been removed from the head.
• The invention will be more fully described by reference to the following drawings.
BRIEF DESCRIPTION OF THE DRAWINGS
• FIG. 1 is a schematic diagram of a system for audio sharing in accordance with the teachings of the present invention.
• FIG. 2 is a schematic diagram of a HEDphone.
• FIGS. 3A-3C are schematic diagrams of a HEDphone concept.
• FIG. 4 is a schematic diagram of a HEDmesh network of HEDphones.
• FIG. 5 is a schematic diagram of a HEDmesh network of HEDphones including a mobile device.
• FIG. 6 is a schematic diagram of a HEDmesh network of HEDphones including a plurality of mobile devices.
• FIG. 7 is a schematic diagram of the system for audio sharing in accordance with the teachings of the present invention.
• FIG. 8 is a schematic diagram of a packet used in the system.
• FIG. 9A is a schematic diagram of front view of a HEDphone used in accordance with the teachings of the present invention.
• FIG. 9B is a schematic diagram of rear view of the HEDphone.
• FIG. 10 is a schematic diagram of a printed circuit board that can be used for implementing the right side of the HEDphone.
• FIG. 11 is a schematic diagram of a printed circuit board that can be used for implementing the right side of the HEDphone.
• FIG. 12 is a schematic diagram of an active noise cancelling implementation that can be used in the HEDphone.
• FIG. 13 is a schematic diagram of a super human hearing (SHH) implementation with the HEDphone.
• FIG. 14 is a schematic diagram of an embodiment of a HEDapp19 to allow the user to control super human hearing (SHH) with a graphic interface.
• FIG. 15 is a schematic diagram of an embodiment of an implementation of the super human hearing (SHH).
• FIGS. 16A-16B is a schematic diagrams of head presence sensor system used with the HEDphone.
• FIG. 17 is a schematic diagram of an embodiment of the system for audio sharing in accordance with the teachings of the present invention.
• FIGS. 18A-R are schematic diagrams of screen shots of a 3D graphical interface generated at the HEDapp.
• FIG. 19A is a schematic diagram of used with a foam piece used in a headband of the HEDphone.
• FIG. 19B is a schematic diagram of a chassis used in the headband.
• FIG. 19C is a schematic diagram of a foam carrier used in the headband.
• FIG. 20A is a schematic diagram of a large size headband used in the HEDphone.
• FIG. 20B is a schematic diagram of a medium size headband used in the HEDphone.
• FIG. 20C is a schematic diagram of a small size headband used in the HEDphone.
• FIG. 21 is a schematic diagram of a HEDphone including housing of batteries in the headband.
• FIG. 22A is a schematic diagram of a portion of an outer casing including foam on an inner surface.
• FIG. 22B is a schematic diagram of a portion of an outer casing including fur material on an inner surface.
• FIG. 22C is a schematic diagram of an outer casing including fur material on an inner surface.
• FIG. 23 is a schematic diagram of the HEDphone with functionality for a left hand user,
• FIG. 24 is a schematic diagram of a cover for use with the HEDphone.
DETAILED DESCRIPTION
• Reference will now be made in greater detail to a preferred embodiment of the invention, an example of which is illustrated in the accompanying drawings. Wherever possible, the same reference numerals will be used throughout the drawings and the description to refer to the same or like parts.
• FIG. 1 is a schematic diagram of a system for audio sharing10, referred to as HEDsystem.HEDmesh14 usingHEDtech protocol15 is used inHED system10 to allow users to share music viaHEDphones12a-12nwhile using a single audio source. Awireless connection16 is established between HEDphone12aandaudio source18.Audio source18 can be a mobile device running a HED application19.Wireless connection16 can be for example a Bluetooth, SBC or AAC connection.HEDmesh14 usingHEDtech protocol15 allows HEDphones12b-12nto simultaneously join wirelessly and listen toaudio source18HEDtech protocol15 can use Wi-Fi transmission as a transport layer forHEDtech protocol15 to createHEDmesh14.HEDtech protocol15 can support for example the following Bluetooth profiles: Advanced Audio Distribution Profil (A2DP); Audio/Video Remote Control Profile (AVRCP); Cordless Telephony Profile (CTP); File Transfer Profile (FTP)(to transfer music files); Generic Audio/Video Distribution Profile (GAVDP); Generic Access Profile (GAP); Hands-Free Profile (HSP); Intercom Profile (ICP); LAN Access Profile (LAP); Message Access Profile (MAP); Personal Area Networking Profile (PAN); Phone Book Access Profile (PBAP, PBA); Video Distribution Profile (VDP); and Wireless Application Protocol Bearer (WAPB).
• FIG. 2 is a schematic diagram ofHEDphone12HEDphone12 is a headphone with functionality.HEDphone12 is controlled and configurable via HEDapp19 downloadable toaudio source18. HEDapp19 is a user interface that will allow the control of settings such as, noise reduction, microphone On/Off, EQ levels and control access toHEDmesh14. Processor20 communicates with serial peripheral interface (SPI)22 to Bluetooth and Wi-Fi Module23. Processor20 communicates with 12C bus protocol25 to NFC24 or12S bus protocol21 to CODEC26 and Active Noise Cancelling (ANC) amplifier27. Microphones29aand29band speakers28aand28bare coupled to Active Noise Cancelling (ANC) amplifier27. Microphones29aand29bcan be used to support conventional phone functionalities as well as communicate with members of HEDmesh14 (shown inFIG. 1) using VoIP or other methods.
• Anexample HEDphone12 is shown inFIGS. 3A-3C.HEDphone12 can have a power On/Off switch31. For example power On/Off switch31 can incorporate adual color LED34, Blue and Green. An example scheme forcolor LED34 is described below. When turned On,LED34 will be fixed blue. When charging, LED will flash Green until turning fix green when fully charged. IfHEDphone12 is operating in a group (HEDmesh) the LED will turn to green. IfHEDphone12 comes out of the group it will go back to Blue.HEDphone12 is turned On and Off by pressing On/Off switch31 for more than a second, whilst theHEDphone12 is turned On, it will always be in “paring mode” or discoverable by any portable device.HEDphone12 can be operated as follows:
• Turn Bluetooth to the ON position on mobile device18:
• 1. Search for Bluetooth devices.
• 2.Select HEDphone12 from the result list.
• 3. optionally Enter pin code 0000.
• Bluetooth pairing andHEDphone12 functionality must be possible even if the user has not downloaded the HEDapp mobile application. If the application is not downloaded theHEDphone12 will default to the factory settings. These settings can only be changed by downloading the HEDapp.
• Referring toFIG. 1, once HEDphone12ais paired tomobile device18, it will automatically enable the WiFi function to allow other HEDphones12b-12nto connect to it via Wifi Direct, or via the NFC (Near Field Communication) function. This functionality is also be possible if HEDphone12ais connected via an audio cable tomobile device18 rather than with a Bluetooth link. In this mode, (with cable) HEDphone12acan turn off the Bluetooth link automatically in order to save battery. This function may be overwritten via the HEDapp. This will allow the connection of theHEDphone12 to a laptop using the audio cable while still being connected tomobile phone18 via Bluetooth.
• Once the HEDapp is downloaded, the user will enter his/her HEDphone's name which will then be displayed on the app and onHEDmesh14 when in use.
• HEDmesh14 can be created to stream music, to talk to other HEDmesh members or for both. WhenHEDmesh14 is created or anew HEDphone12a-12njoins the group, an audible tone can be played onHEDphones12a-12nand the HEDapp user's list will be updated with the new user/player's name.
• HEDmesh14 can be created by anyHEDphone12a-12nuser who will become the administrator or master and will control the audio played toHEDmesh14.Other HEDphone12a-12nusers can join the group via NFC with anyHEDphone12a-12nalready inHEDmesh14 and not have to find who the master is. Every time a new player joins the group, the master and all other users/players will receive an audio tone and everyone onHEDmesh14 can see an updated list.
• HEDphone12a-12nusers can create aprivate HEDmesh14 where only “approved” members may join.Private HEDmesh14 groups can be saved for later use and all subscribed members can connect automatically when they are next in proximity. At the same time the administrator of the private Group can block and expulse a HEDphone user at any time, whether in range or not (from the HEDapp group). It should also be possible for a user to join a HEDmesh but to listen to its own music and only use the HEDmesh to communicate to others. This can only be achieved using the HEDapp, but it can be set to “talk lock” in the HEDapp. If talk lock is ON on the HEDapp the user can simply tap the HEDtak button to lock the channels. Rules may be then introduced to limit the number of simultaneous conversations.
• Several HEDmesh14 groups may coexist in the same area.
• While users are on aHEDmesh14, they can talk to each other by pressing theHED capacitance pad32 on the HEDphone touch pad shown inFIG. 3A. For example, this function can be operated by tapping once to talk on the HEDmesh group, tapping over 2 seconds with 2 fingers to exit the HEDmesh group. HED capacitance pad33 can be operated, for example, by tapping once to play music and tapping again to pause music. If call in place, for example, tap once to take call and tap over 2 seconds to hang up.HED capacitance pad32 controls the sharing and HEDmesh functions. HED capacitance pad33 controls all phone and music functions.HED capacitance pad32 can operate functions36 of activate SHH, deactivate SHH, activate SHH rear microphone and activate SHH front microphone. HED capacitance pad33 can operate functions37 of volume up, volume down, previous song and next song.
• Any user onHEDmesh14 should be able to take the call, text and carry out other function onportable device18 without affecting the HEDmesh communication.
• If a user receives a phone call while onHEDmesh18, the user can take the call without affecting the rest of the users in the group. As soon as a phone call is finished and the user hangs up it should be able to hear the audio streaming fromHEDmesh18. HED capacitance pad33 positioned abovespeaker34 can be used for controlling the audio source and the phone functions ofHEDphone12. For example, HED capacitance pad33 can control volume up, volume down, next song, previous song, pause music, play again, take calls and hang up calls.
• HEDphone12 can include a battery. The battery preferably provides 15 hours of Bluetooth use for music and at least 10 hours for HEDmesh operation. The battery may be charged while inHEDphones12 by using the micro USB cable or by using an external cradle. Alternatively, the battery may be charged by induction with a special cradle or hanger. A larger battery can also be fitted in a cavity ofHEDphone12.
• HEDphone12 can be fitted with a mini jack socket to allow the user to bypass the Bluetooth link. This will allow the user to save battery, obtain better audio and avoid latency. On the HEDapp the user will be able to select if the Bluetooth link is to stay live while using the cable but the system will default it to Off.HEDphone12 can provide a HIFI quality audio when operating with cable even when the battery is flat. In this mode, (with cable)HEDphone12 can turn off the Bluetooth link automatically in order to save battery. This function may be overwritten via the HEDapp. This will allow the connection of the HEDphone to a laptop using the audio cable while still being connected to a mobile phone via Bluetooth. This socket can support an aux microphone input in case an extra microphone boom is sold as an accessory for theHEDmesh18. All other settings and functions for the HEDphone will be adjusted and controlled via the HEDapp.
• In oneembodiment HEDphone12 provides a feature referred to as Super Human Hearing (SHH). SHH goes beyond conventional ANR (ambient noise reduction) with additional features that allow the user to control their aural environment by being able to directionally increase or decrease selective frequencies. This will allow the user to attenuate specific sounds around them. Conversely, the user will also be able to single out and amplify other sounds around them. For example, while exercising (running, skiing, cycling, etc.), users may be able to emphasize the sound levels behind them to help them hear if someone or something is approaching too close behind them; all of this while still enjoying their music.
• In this embodiment,HEDphone12 can be fitted with a plurality ofunidirectional microphones40a-40for an array of omni directional microphones in addition to the ones used for ANR as shown inFIG. 3B. The microphones will be located in various places on the device pointed in various directions in order to achieve a 360° audio image of the environment around the user. By a method of mixing the audio from the various inputs, the user will experience a new way to control the way they hear the world around them as shown inFIG. 3C. The user will be able to intuitively control SHH visually with the aid of a controller app for their mobile phone or device. SHH functionality can include the following features:
• 1. The ANR function will work as they exist on standard headphones. The user can either activate or deactivate ANR independently of SHH.
• 2. The additional microphones dedicated for the SHH function will pick up directional ambient sounds separately from the ANR microphones.
• 3. The user will be able to control the SHH function with the aid of a 3D visual app for their mobile telephone or device.
• 4. Reinserted into the signal path of the user's audio stream.
• 5. SHH function will allow the user to allow ambient noise at user-defined frequencies to filter into the HEDphone via the fitted microphones. For example, this new feature could allow the user to hear other people talking to them without having to remove the HEDphones or having to pause or mute the music. Users that wear headphones while walking, cycling or doing any other type of activity that requires some level of awareness of their immediate surrounding will greatly benefit from this new feature as well as increasing safety. The user will then be less likely to remove their headphones.
• 6. The user will be able to control the direction and frequency of the sounds they want to enhance.
• 7. A combination of both SHH and conventional noise reduction will allow the user to pass through the ambient noise but to also cancel out any noise from the “wanted” audio signal such as human voice. The idea is that if someone is talking to the headphone user in a noisy environment, the background noise can be cancelled out from the human voice, making the headphone a tool to communicate in noisy environments, where it would be clearer to communicate with the headphones than without them.
• 8. Amplification of the “good” inbound audio (human voice) to aid human hearing for people with difficulties, to be able to communicate in noisy environments or simply, to allow you to communicate without removing the headphones and hear better than without them. This may have a different level adjustment to the music level and it may require a separate mode activated in the HEDapp which we will also give control between the rear and forward mic in the headband. The HEDapp will provide a visual representation of the audio world around them.
• The SHH functionality can be based on four adjustments.
• a. Noise reduction level (gradual adjustment of the noise reduction level). This adjustment will be independent of the inbound audio level.
• b. Forward mic and rear mic levels (for good audio)
• c. Music volume. Adjusts the music level.
• d. Inbound audio level for the talk mic (the one used to talk to the HEDmesh and telephone) must be muted.
• The SHH must be achieved by dynamically adjusting the levels above. These adjustments maybe carried out by sliding the finger over the HEDpad up and down for volume and right and left for rear mic and front mic gain. To make it easier to the user there should be some pre-determined modes to be set via the HEDapp.
• Some of the modes could be:
• SHH On/Off
• Bicycle
• Factory
• City walk
• Windy
• Home
• HEDphone12 can support the following functionalities without HEDapp.
• Pairing to a portable device, play music and music controls, support phone functionality, create a HEDmesh network, stream audio to the HEDmesh network, able to talk to HEDmesh participants within the network and activate and control the Super Human Hearing function.
• To connectHEDphones12, a NFC device can be activated in oneHEDphones12. This can be achieved by shaking one HEDphones12 and getting them together facing the NFC side (HEDshake). Alternatively, a HEDmesh button can be activated with a HED button. This will create a sharing network between 2 ormore HEDphones12. This network will be created automatically by randomly allocating one ofHEDphones12 as a hotspot. The NFC time required is about 2 seconds. The new network is referred to as HEDmesh50, as shown inFIG. 4.
• Basic HEDmesh Network.
• At this stage, bothHEDphones12 can talk to each other by pressing HED button52 “

  

  ” or by activating the required action on capacitance pad.
• In a first scenario shown inFIG. 5, when HEDphones12ais paired tomobile device18 via Bluetooth they will be able to:
• HEDphone12a(connected to a mobile device) can play music, share music and talk to other HEDphone12bin the network (HEDmesh).
• HEDphone12bcan only talk. As soon as user A starts playing music, it is automatically sent to HEDphone12b.
• Music and voice can play simultaneously. When there is voice present on the HEDmesh network, volume of the music can be lowered.
• In a second scenario shown inFIG. 6, when two or more HEDphones12aand12bare paired tomobile devices18 via Bluetooth.
• In this case, all HEDphones12aand12bcan play music, share music and talk toother HEDphones12 in the network (HEDmesh).
• The HEDmesh network can have a predetermined number of players, for example a maximum of 15, and a maximum number of simultaneous voice calls, for example a maximum of 6. Every user will be able to play music to the HEDmesh network. Pressing play in their mobile devices, will override the current music player (Host) becoming the new HEDmeshHost.
• A headphone user can leave the HEDmesh network when:
• 1. He/she goes out of range
• 2. Turn the HEDphone OFF
• 3. Battery goes flat
• 4. Pressing HED button

  
• LEDs will indicate the users when he is on a HEDmesh or not there should also be an audible tone for entering and exiting a HEDmesh session.
• WhenHEDphone12 leaves the HEDmesh session, all data will be erased from all users in the HEDmesh.
• To re-join the HEDmesh, it will have to go to one ofHEDphones12 already in the HEDplay session and use the NFC logging method.
• When leaving the HEDmesh network there could be two scenarios:
• 1. The user leaving is the network Host:
• In this case, the entire HEDmesh will stop hearing the music until another remaining user presses play in one of their mobile devices. The network is not dissolved, so another user within the HEDmesh network becomes the hotspot. If the hotspot left and there was already someone playing music, this user will become the hotspot automatically so the music is only interrupted momentary.
• 2. The user leaving is not the network Hotspot:
• In this case, the rest of the HEDmesh network carry on operating normally, unless the user leaving was the one playing music which will obviously stop the music on the HEDmesh until another player presses play.
• If a HEDplayer (HEDphone12 user within a HEDmesh network) receives a call, there are two possible scenarios:
• 1. The HEDplayer is playing music:
• In this case, the music stops on the HEDmesh and any other user, already in the same network, can take over by pressing play in their mobile device. Music is then sent to all players except the one on the phone call. As soon as the phone call finishes, the player will automatically hear the music being played again.
• 2. The HEDplayer is not playing music:
• In this case, it will simply take the call and stop hearing the music being played in the HEDmesh network. Again, as the call finishes, it will automatically go back to listen what is being played on the HEDmesh network.
• FIG. 7 is a schematic diagram of an embodiment ofHEDtech protocol15. In this embodiment, HEDphone12ais considered the master or Host as the headphone playing music and HEDphones12b-12nare considered as users or Guests as the headphones listening to the music being played.HEDmesh14 usesHEDtech protocol15 to provide audio streaming from HEDphone12ato one or more destinations HEDphones12b-12n. All ofHEDphones12a-12nparticipating inHEDmesh14 are able to send and receive low bitrate data overwireless connection16. For example, data can be used to distribute information and events and talk to each other over a voice channel ofHEDphones12a-12nas described below.
• In one embodiment,HEDtech protocol15 is based on a multicast/unicast datagram data transfer.HEDmesh14 is created by HEDphone12awith one or more HEDphones12b-12nconnect to HEDmesh14, such as by means of a Service Set Identifier (SSID) and Wi-Fi Protected Access II (WPA2) password provided over Near Field communications (NFC) on a pairing event.
• In an embodiment ofHDtech proctocol15, time division can be used in which time is divided in default periods of 42.666 ms. On each time period, HEDphone12aas the Host will send up to 8packets100 to theHEDphones12a-12nas Guests. Eachpacket100 takes about 2 ms to be transmitted. Accordingly, in this embodiment a total of about 16 ms are used to sendpackets100 between HEDphone12aas the Host and HEDphones12b-12nas Guests. The remaining time of the 42.666 ms period is used by each of HEDphones12b-12n, in turn, to send acknowledgment and new data, if any, to HEDphone12aas the Host. There is always a minimum of 1packet100 sent by HEDphone12aas the Host every period. If there is no data to send, a special beacon packet is sent. HEDphones12b-12ncan send packets to HEDphone12aaspackets102.Packet100 can be a datagram multicast packets andpacket102 can be a datagram unicast packet as shown inFIG. 8.
• On eachpacket100 sent by HEDphone12aas Host there is a list oftime instants112 allocated to each Guests for their reply. This minimizes packet collision over the air and allows dynamic management of the time allocated for the reply of each Guest on each transmission period. Each Guest may reply with none or up to 4packets102 on each period.
• The duration of the time period is defined by the time between packets with burst index 0 sent by the Host. This means that the default 42.666 ms time period can be changed by the Host, if needed.
• In order for the time division to be accurate, synchronisation between the Host and all Guests is required. Wi-Fi network16 provides synchronisation between the members of a network using an internal timer identical on all members referred to as Time Synchronisation Function (TSF) timer. This timer is incremented every microsecond and the maximum deviation between members of the network is 25 μs.HEDtech protocol15 determines a time difference between the Time Synchronisation Function (TSF) and the local time which is broadcasted by the HEDphone12aas Host to all HED phones12b-12nas Guests, which also get their own difference between Time Synchronisation Function (TSF) timer and a local timer. Based on these two differences, each Guest can then calculate, at any time, what is the corresponding local time in the Host. Audio is synchronized by means of a 32-bit time stamp. At HEDphone12aas the Host, this time stamp corresponds to the 32 least significant bits of the local time in units of 0.1 ms. At the Guest, the calculation is made on the adjusted local time, so that the generated time stamp matches the Host's time stamp.
• Tables 1A-1B define the contents ofpackets100 exchanged between Host and Guest. All multi-byte values are represented in little-endian format with a Less Significant Byte first.
• Each byte is divided in 8 bits numbered from 0 to 7, with 0 being the Less Significant Byte (LSB) bit.
• The contents ofpacket100 from Host to Guest are shown in Table 1A as the following:

• TABLE 1A
  Offset	Size in
  in bytes	bytes	Name	Description

  0	4	audio_ts	Audio Time Stamp. For audio
  			streaming, indicates the time stamp
  			at which the contents of
  			this packet should be played.
  			In the special case of a beacon
  			packet, this item
  			holds the 32 LSB bits of “ref_tst_diff”.
  4	1	nr	Packet number
  5	1	codec_type	Codec type for the included
  			audio streaming data. The
  			following types are defined:
  			HED_AUD_CODEC_NONE
  			(0) (no streaming
  			audio available),
  			HED_AUD_CODEC_SBC (1)
  			HED_AUD_CODEC_AAC (2)
  6	2	frame_size	Frame size of the streaming audio
  			data. This is the number of
  			bytes on each audio block to be
  			decoded
  8	1	sample	rate Sample rate of the
  			streaming audio data. The
  			following rates are defined:
  			RED_AUD_RATE_NONE (0)
  			RED_AUD_RATE_16000 (1)
  			HED_AUD_RATE_32000 (2)
  			HED_AUD_RATE_44100 (3)
  			RED_AUD_RATE_48000 (4)
  9	4 LSB bits	burst_size	Burst size. Number of packets in this
  			transmission period (1 to 8).
  9	4 MSB bits	burst_idx	Burst index. Order number of the
  			packet in this transmission
  			period. Must start with 0 for the
  			first packet and increase by
  			one for each consecutive
  			packet up to “burst_size” −1.
  10	1	buf_ctrl	Buffer control. Bit mask
  			indicating which buffers in
  			the packet are active. Can be
  			an OR of the following bits:
  			BUF_VOICE(bit 0)-Voice buffer
  			BUF_DATA (bit 1)-User data buffer
  			BUF_STREAM (bit 2)-Audio
  			streaming buffer
  			BUF_CTRL (bit 3)-Control
  			information on the user data
  			buffer (cannot be used together with
  			BUF_DATA)
  			BUF_STREAM_FRAG (bit 6)-Audio
  			streaming buffer holding a partial
  			audio block
  			BUF_BEACON (all bits set)-
  			Special value to
  			identify beacon packets
  11	1	reserved	Reserved forfuture use
  12	4	ref_tsf_diff	Difference between TSF timer and
  			local time on Host. This is a
  			64 bit value that is multiplexed on
  			consecutive packets. On
  			each transmission
  			period, the first transmited
  			packet (“burst_idx” = 0) holds
  			the 32 MSB bits. The remaining
  			packet(s) (“burst idx” >0) hold
  			the 32 LSB bits.
  16	10	reply_win	Reply window start for each
  			Guest in 0.1 ms units, 0xFF for
  			no reply allowed on this frame
  26	10	ack_mask	Acknowledge masks sent
  			back to Guests. Each bit
  			corresponds to one packet
  			received in the previous period.
  36	952	stream	Audio stream buffer
  988	32	data	User data buffer
  1020	172	voice	Voice buffer

• The size of each transmitted packet is fixed, independent of its contents. The only exception is the beacon packet that does not include the “stream”, “data” and “voice” fields.
• The contents of eachpacket102 from Guest to Host are shown in Table 1B as the following:

• TABLE 1B
  Offset	Size in
  in bytes	bytes	Name	Description

  0	4	audio_ts	Audio Time Stamp. For audio
  			streaming, indicates the time
  			stamp at which the contents of
  			this packet should be played.
  			In the special case of a beacon
  			packet, this item holds
  			the 32 LSB bits of “ref_ tst_diff”.
  4	1	nr	Packet number
  5	1	codec_type	Codec type for the included
  			audio streaming data.
  			The following types are defined:
  			HED_AUD_CODEC_NONE
  			(0) (no streaming
  			audio available),
  			HED_AUD_CODEC_SBC (1)
  			HED_AUD_CODEC_AAC (2)
  6	2	frame_size	Frame size of the streaming audio
  			data. This is the number of
  			bytes on each audio block to be
  			decoded
  8	1	sample_rate	Sample rate of the streaming audio
  			data. The following rates are defined:
  			RED_AUD_RATE_NONE (0)
  			RED_AUD_RATE_16000 (1)
  			HED_AUD_RATE_32000 (2)
  			HED_AUD_RATE_44100 (3)
  			RED_AUD_RATE_48000 (4)
  9	4 LSB bits	burst_size	Burst size. Number of packets in this
  			transmission period (1 to 4).
  9	4 MSB bits	burst_idx	Burst index. Order number of the
  			packet in this transmission period.
  			Must start with 0 for the first
  			packet and increase by one
  			for each consecutive
  			packet up to “burst_size” −1.
  10	1	buf_ctrl	Buffer control. Bit mask indicating
  			the type of data included in
  			the packet. Can be an OR of the
  			following bits:
  			BUF_VOICE (bit 0)-Voice buffer
  			(2 voice buffers are included
  			when BUF_STREAM is 0)
  			BUF_DATA (bit 1)-User data buffer
  			BUF_STREAM (bit 2)-Audio
  			streaming buffer
  			BUF_CTRL (bit 3)-Control
  			information buffer
  			(cannot be used together
  			with BUF_DATA)
  			BUF_DATA2 (bit 5)-Second user
  			data buffer (cannot be used
  			together with BUF_STREAM,
  			BUF_STREAM_FRAG
  			or BUF_CTRL)
  			BUF_STREAM_FRAG
  			(bit 6)-Audio streaming
  			buffer holding a partial audio block
  11	1	reserved	Reserved for future use.
  12	1	dev_nr	Guest device number (1 to 10).
  			Assigned when joining the MESH.
  13	1	ack_base	Number of the oldest
  			acknowledgedpacket
  14	4	ack_mask	Bit mask with each bit
  			representing an acknowledged
  			packet. Bit 0 corresponds to the
  			“ack_base” packet number.
  18	1156	data	Buffer including streaming audio
  			(952 bytes) and/or user/control
  			data (32 bytes) and/or voice
  			data (172 bytes).
  			This buffer must be filled in the
  			following order, depending on
  			the active bits of “buf_ctrl”: stream
  			data, voice data, second voice data,
  			user/control data, second user
  			data. The second voice data and
  			second user data cannot be present
  			when stream data is present.

• The size of each transmitted packet is variable, depending on the data being transmitted as defined by the “buf_ctrl” field.
• TheHEDtech protocol15 provides a reliable transport layer for streaming audio and user data using an acknowledgement protocol. All packets sent in one direction must be acknowledged in the reverse direction. Considering the different nature of multicast and unicast, a different acknowledge protocol is used, depending on the direction of the transfer.
• On each time period, up to 8packets100 can be sent from the Host to the Guest. Of these, only 2 ofpackets100 can be new packets as never sent on previous time periods. The remainingpackets100 are retransmissions of unacknowledged packets. The Host must maintain, for each transmittedpacket100, a list of successful acknowledgements received from each active Guest. Eachpacket100 is transmitted continuously on consecutive time periods until all active Guests acknowledge the packet.
• A Guest is considered active whenever the Host receives data from it. When no data is received from a Guest for a defined amount of consecutive time periods, the Guest is then considered inactive.
• Eachpacket100 sent includes a packet number ranging from 0 to 255. Each new packet is assigned a consecutive number, wrapping to 0 after reaching 255. Each Guest must maintain a list of receivedpackets100, to be sent to the Host as an acknowledgement, on each time period. The list is composed of a packet number (“ack_base”) and a 32-bit mask (“ack_mask”). The “ack_base” packet number corresponds to bit0 of the mask, while the followingbits1 to N are related to “ack_base”+N packet numbers. This means that, as an example, if “ack_base”=253 (decimal) and “ack_mask”=77 (decimal, corresponding to a binary representation with 24 bits at 0 followed by 1001101), then the followingdata packets100 are acknowledged, reading bits from right to left: 253, 255, 0 and 3. The packet number following 255 is 0. Packets with numbers below “ack_base” are implicitly acknowledged too.
• Based in the acknowledge information sent by the Guests, the Host determines which ofpackets100 transmitted on the last time period were correctly received by all active Guests.Packets100 that were not received correctly by all active Guests are re-transmitted.
• On each time period, up to 4packets102 can be sent from the Guest to the Host. Of these, only 2packets102 can be new packets as never sent on previous time periods. The remainingpackets102 are retransmissions of unacknowledged packets.
• The Host must send acknowledge information to each Guest, on each time period, considering the correctly receivedpackets102 in the previous time period. The acknowledge information is sent on allpackets100 transmitted by the Host and comprises 1 byte for each Guest sent in “ack_mask” array. Each bit corresponds to the “burst_idx” of a successfully receiveddata packet102 in the previous time period.
• As an example, a particular Guest sends 3packets102 to the Host. Eachpacket102 is numbered with a consecutive “burst_idx” number from 0 to 2. If the Host only receives the last twopackets102, it will send value 6 (binary110) in the “ack_mask” entry corresponding to that particular Guest. This will indicate to the Guest that it must retransmit the last twopackets102.
• HEDtech protocol15 allows for simultaneous transfer of streaming audio and user/control data. Packet numbers are used to guarantee that the correct order of packets is preserved. Depending on errors and re-transmissions, successful reception of packets may occur in a different order than the initial transmission. Both Host and Guest must include mechanisms to re-order the received packets, if necessary, before delivering them to the corresponding recipients.
• When sending streaming audio, some additional data is included on eachpacket100 to allow the Guest to decode and play the audio stream at any point in time. The audio streaming related data can comprise the following components: 32-bit time stamp “audio_ts” to allow the Guest to start playing audio synchronously with all other devices inHDMesh14; Codec type “codec type” indicates the codec required to decode the streaming data, example supported codec are SBC and AAC; Frame size “frame_size” indicates the size in bytes of each audio block to decode; and sample rate “sample_rate” indicates the sample_rate to play the decoded audio. If the frame_size is bigger than the maximum space available for the stream buffer, then the “BUF_STREAM_FRAG” bit of “buf_ctrl” is set indata packets100 that hold the first fragment of a frame.
• User data can be sent from each device to another or to all devices. The Host is responsible for routing user data blocks105 to their destination. All data is divided in data blocks105 of 32 bytes. The Host can send a maximum of one data block105 on eachpacket100, while the Guests can send up to two data blocks105 on eachpacket102 when not sending audio streaming simultaneously. Alternatively, audio streaming is sent simultaneously one data block105 can be sent perdata packet102. The packet numbers are used to keep the correct order of data blocks105, allowing for a correct re-assembly at the destination device.
• HEDmesh14 requires some occasional information to be exchanged between the Host and the Guests. A mechanism is provided to re-use data blocks105 on the transmitted packets for this purpose. This is achieved by having a separate identification of control data block in the “buf_ctrl” field of each packet. Control data always has higher priority than user data. This means that if a user data transfer is in progress, it will be interrupted to send control data.
• The following control message primitives can be used which are sent as a first byte of the control message:
• • CTRL_DEV_NR_REQ (0): Request a new device number. Sent by Guests when registering to the Mesh. Includes the MAC address of the new Guest as a parameter inbytes 1 to 6 of the control message.
  • CTRL_DEV_NR_CFM (1): Confirm the new device number request is accepted. The new assigned device number is sent onbyte 1 of the control message.
  • CTRL_DEV_NR_REJ (2): Reject a new device number request.
  • CTRL_SWITCH_REQ (3): Request a switch between Host and Guest. Sent by the Host with the target Guest device number as a parameter inbyte 1 of the control message. The current list of Guests is sent in the beginning of the stream buffer. This message can only be sent after audio streaming is stopped.
  • CTRL_SWITCH_CFM (4): Confirm request to switch between Host and Guest. Sent by Guest when it is ready to switch to Host. When the current Host receives this message, stops transmissions and switches to Guest with the same device number as the Guest with which it switched.
• Voice data can be sent from eachHEDphones12a-12nto allother HEDphones12a-12n. Voice data is sent as voice data block107. The Host is responsible for broadcasting all received voice data blocks107 to all Guests. Voice streaming data is divided in blocks of 172 bytes. The Host can send a maximum of one voice data block107 on eachpacket100, while the Guests can send up to two voice data blocks107 on eachpacket102. Alternatively, audio streaming is sent simultaneously one voice data block107 can be sent perdata packet102. The packet numbers are used to keep the correct order of data blocks107, allowing for a correct re-assembly at the destination device. Sending up to two 172 bytes blocks, on each default time period of 42.666 ms, allows for a bit rate of around 64 kbit/s. Any codec supporting that bit rate can be used to encode/decode the voice stream data. Suitable codecs are G.722 and AAC.
• FIGS. 9A-9B show an embodiment ofHEDphone402 which can be used instead ofHEDphone12.HEDphone402 is a Hi-Fi stereo wireless headphone which can be us used withHEDmesh14 andHEDtech protocol15 as described above. In thisembodiment HEDphone402 includes a rectangular array of omnidirectional microphones200 of microphones40a. For example,microphones40 can be micro-electro-mechanical microphones (MEMS). This configuration allows the implementation integration of Super Human Hearing (SHH) feature described above. This allows the user to enhance or attenuate the outside audio in a selected direction.
• FIG. 10 is an example implementation of printed circuit board300 that can be used for implementing the right side ofHEDphone402. Battery301 is controlled by power manager302,battery management unit303, battery protection304 and FCI305 for poweringprocessor306 and diodes307. Embedded multi-media card308 and storage309 are coupled toprocessor306. Wi-Fi andblue tooth module310 and interintegrated bus311 are coupled toprocessor306.Processor306 controls serialperipheral interface312.Left touch sensor314 provides input toprocessor306.Level translator315 interfaces withdigital analog converter316 for controllingactive noise control318 of microphone40aand40bas shown inFIG. 12. Four channel analog to digital converter320 receives input from microphone40b,40c,40dand40e. Referring toFIG. 10, Codec322 encode/decode the voice stream data fromaudio jack323. Audio output fromactive noise control318 is received at speaker325.LED328 is controlled byprocessor306.
• FIG. 11 is an example implementation of printed circuit board500 that can be used for implementing the left side ofHEDphone402. Active noise control518 controls microphones200 for active noise cancelling as shown inFIG. 12. Referring toFIG. 11, audio output from active noise control518 is received at speaker525. Serialperipheral interface312 interfaces to near field communication527. Head detection sensor528 detects the presence of a user's head.
• HEDphone402 can include the functionality shown and the hardware requirements as shown in Table 2.

• TABLE 2
  Functionality	Description
  Hi-Fi audio	The Headphones are fitted with superb high
  	quality angled drivers together with an
  	optimised acoustic design. Extra care has
  	also been taken on the codecs, DSP and
  	compression processes, which have also
  	been optimised.
  Bluetooth	The Headphones connect via Bluetooth
  and Wi-Fi	with mobile devices and via Wi-Fi with
  connectivity	other HED Headphones and
  	Wi-Fi networks.
  HEDcom	The proprietary HEDcom protocol is for
  protocol	data, audio streaming and communication
  	between compatible HED Headphones.
  HED Mesh	Allows up to 11 Headphone users to create
  	a local wireless network to share music,
  	voice and data.
  Super-human	Four omnidirectional MEMS microphones
  hearing	are fitted in the ear pads for Shh,
  (Shh)	enabling the implementation of virtual
  	directional microphones (beams) by spatial
  	filtering. User can select a direction via
  	the HEDapp, thus allowing the user to hear
  	sound coming from one specific direction.
  Presence Sensor	The music is paused automatically when
  	the user removes the headphones.
  Active Noise	ANC improves the sound quality of music
  Control	and phone conversation by reducing
  (ANC)	background noise using inverted phase audio.
  Audio Equalizer	User adjustable 8 band equalizer
  	via the HEDapp
  Echo control	Acoustic echo occurs whenever the ear
  	pad microphones capture sound coming
  	from the drivers. The sound from the
  	drivers is delayed long enough (~20 ms) to
  	avoid feedback.
  Standard	The Headphone is able to answer a call,
  telephony	hear messages and alerts over the music or
  	the Mesh. Also supports voice
  	dialling/voice commands (Siri)
  Support for	The HEDcom protocol allows for VoIP
  VoIP	communication in the Mesh.
  Minimised	Latency is minimal in the Headphone
  latency	for music sharing and voice communication so
  	users hear the audio at the same time.
  Interference	The Mesh co-exists securely with other
  	Wi-Fi networks without receiving or
  	incurring interference with other
  	Wi-Fi networks/devices.
  Range	Maximum range of 30 m.
  Home Wi-Fi	The Headphone can connect directly to
  compatible	a Wi-Fi network. User can listen to music via
  	a home music server or other online services.
  Mobile App	User Interface to control Headphone
  (HEDapp)	functions via Bluetooth from an iOS and
  	Android app. Functionality described in
  	the HEDapp section.
  Software	Headphone firmware is upgradable
  upgradeable	via Bluetooth using the HEDapp.
  LEDs	RGB LED to signal power, charging,
  	connectivity with Bluetooth and Mesh
  	connection.
  Audio sensor	A sensor detects the absence of an audio
  for sleep	signal and puts the Headphone into sleep
  mode	mode automatically. The time to enter sleep
  	mode can be adjusted via the HEDapp.
  Capacitance	Two capacitance touch pads exist to control
  touch	playback, volume, telephony functions,
  pad for	Shh, Mesh, mute and Internal Talk. Touch
  controls	pad functions are swappable from left
  	pad to right pad.
  Battery	The Headphone is equipped with 3
  	batteries totalling 2040 mAh.
  Auto power	Enable/disable and set power off time
  off	via the HEDapp.
  On/Off Switch	On/Off Switch

• An example implementation ofsystem10 in operation ofLED328 is shown in Table 3.

• 	TABLE 3
  	Color	LED State	State
  	Green	Solid	ON/Not connected
  	Orange	Blinking	ON/Battery Low (20%)
  	Red	Blinking	Charging
  	Red	Solid	Fully Charged
  	Blue	Blinking	ON/BT pairing mode
  	Blue	Solid	ON/BT connected
  	Purple	Blinking	ON/MESH connecting
  	Purple	Solid	ON/MESH connected

• HEDphone402 can be connected to any Bluetooth device using the standardpairing method HEDphone402 is turned on and off by pressing the power switch for more than a second. When theHEDphone402 is turned on it will be in pairing mode, unless theHEDphone402 has already been paired. While in pairing mode theLED328 is blinking blue as described above. It will be appreciated that alternative color schemes forLED328 can be used in accordance with the teachings of the present invention.
• Turn ON Bluetooth on the mobile device:
• 1. Search for Bluetooth devices.
• 2. Select the HEDphone from the result list.
• 3. Enter pin code 0000. Depending on the Bluetooth version this step may not be required.
• In one embodiment, super human hearing (SHH) can be implemented withHEDphone402 as shown inFIG. 13. Super human hearing provides control ambient sounds atHEDphone402HEDphone402 is fitted with a rectangular or trapezoidal array of four omnidirectional microphones440 in addition to the ones used for ANC. The configuration allows the use of different virtual directive/cardioid microphones, by pairs in a line or even combining elements on the diagonal. Microphones440 are located inlower portion450 ofear pads452, mounted in a specific position in order to achieve a 360° audio image of the environment around the user.Ear pads452 can be one axis touch pads. Ear pad4521 can activate super human hearing (SHH) and to talk onHEDmesh14. Ear pad452rcan be used for volume adjustment, for activating playing and pausing or audio and to take a call overHEDmesh14. Audio received by the several inputs of microphones440 can be processed byHEDphone402 to give the user a new way to experience and to control the sound around them.
• TheHEDphone402 is fitted with mini jack plug460 to allow the user to bypass the Bluetooth link and listen to an analogue audio source, such as a music server or service. This allows the user to use sources that don't have Bluetooth. It also saves battery life.
• HEDphone402 still provides a Hi-Fi quality audio when operating with cable even when the battery is flat. While operating with a cable,HEDphone402 turns off the Bluetooth link automatically in order to save battery. This function may be overwritten in the HEDapp19.HEDphone402 can connect to a laptop using the audio cable while still being connected to a mobile phone via Bluetooth.
• FIG. 14 illustrates an embodiment of HEDapp19 to allow the user to control super human hearing (SHH) with graphic interface500. Super human hearing (SHH) is either activated by the user in HEDapp19 using activation graphic502 or is enabled directly fromHEDphone402 viaactivation button404 shown inFIG. 13. Microphones440 dedicated for super human hearing (SHH) pick up ambient sounds around the user. A super human hearing (SHH)module501 in HEDapp19 analyses and processes the ambient sounds, essentially mapping out the soundscape around the user.
• Activation graphic provides access to for super human hearing (SHH) functions in the HEDapp19 using an intuitive3dgraphical interface that represents the soundscape around them. The user will be able to control the direction of the incoming sound that they want to amplify or to attenuate using control graphic504. HEDapp19 provides a visual symbolic representation of the soundscape around the user in activation graphic502. In the absence of HEDapp19, super human hearing (SHH) will function in a default mode having a front focus.
• Super human hearing (SHH)module501 of HEDapp19 provides processed output to be reinserted into the user's audio stream as shown inFIG. 14. The user can enjoy the benefits of super human hearing (SHH) either while listening to music or not. In one embodiment, the super human hearing (SHH) functionality is achieved by the adjustment of parameters in super human hearing (SHH)module501 as follows:
• • a. Target sound direction, for enhancement or suppression. This will automatically trigger a configuration ofmicrophone array400 and processing to be used in in super human hearing (SHH)module501.
  • b. Music volume. Adjusts the music level independently of target sound direction and level the in super human hearing (SHH)module501.
  • c. Noise reduction level as an adjustment of the noise reduction level for affecting filter adaptation parameters. This adjustment is independent of the inbound audio level and dynamically adjusted automatically.
  • d. Inbound audio level for the microphone440 when the user wearing headphone440 talks, the microphones440 can be adjusted, through the presence of a near-field voice activity detector.
• The adjustment of parameters can be made via HEDapp19. For convenience, HEDapp19 has some pre-sets and automatically adjusted settings.
• Some examples of possible pre-sets are: Shh On/Off (speech enhancement), Bicycle, Factory, City walk, Windy, Party.
• The super human hearing (SHH) function allows ambient sound from user-defined directions to filter intoHEDphone402 via the fitted microphones440. For example, super human hearing (SHH) could allow the user to hear other people talking to them without having to remove theHEDphone402 or having to pause or mute the music. Users that wearHEDphone402 while walking, cycling or doing any other type of activity that requires some level of awareness of their immediate surroundings, will also greatly benefit from this new feature in terms of increased safety.
• FIG. 15 is an embodiment of implementation of the super human hearing (SHH) by using a combination of beamforming, calculation of correlation and cross-correlation functions with coherency analysis of the various input signals, adaptive filtering to increase or attenuate target sound direction and, perceptually motivated analysis and filtering to further suppress unwanted “noise” in times and frequencies where masking effects would be less effective.
• Perceptual filtering is implemented to increase intelligibility of the target direction by suppressing other directions when they would be more disturbing or distracting the perception of the target only, i.e. when masking of the target frequencies over the “noise” frequencies is not effective according to a psychoacoustic model. Noise estimators and thresholds are used to further separate the desired direction signal from disturbing signals.
• A further combination of both super human hearing (SHH) and usual, time-domain noise reduction will allow the user to pass through the ambient sound but also to suppress any stationary noise from a target audio signal such as human voice. The purpose is that, if someone is talking to theperson wearing HEDphone402 in a noisy environment, the target direction be privileged (or the disturbing direction attenuated) and at the same time the background noise can be cancelled out from the target sound. This makes of the HEDphone402 a tool to communicate in noisy environments, where it would be clearer to communicate with the headphones than without them.
• Enhancement of the target audio source (human voice) is intended to aid people with hearing impairment, to improve communication in noisy environments beyond the limitations of human perceptions or, simply, to allow communication or raise awareness without removing the Headphones and hear even better than without them.
• Input600 frommicrophones400, shown inFIG. 14, can be received at windowing and FastFourier Transform modules602 Output604 from FastFourier Transform modules602 can be received indirectional filtering module606 and correlation module608.Adaptive gain filter610 receives output612 fromdirectional filtering module606 andoutput614 from correlation module608. Perceptual processing module615 receives output613 fromadaptive gain filter610 and can provide functionality for suppressing other directions when they would be more disturbing or distracting the perception of the target only. Overlap and Inverse Fast Fourier Transform618 receives output616 from perceptual processing module615 to generateoutput620.
• The implementation of super human hearing (SHH) with the combination of beamforming and correlation analysis in a non-linear microphone array improves effectiveness of adaptive noise filtering. The combination of directive adaptive filtering and correlation analysis with perceptually motivated processing to further reduce spatial and temporal noise signals due to the peculiarity of the masking effects of the human auditory perception. Speech and ambient sound enhancement is provided with control of the direction of the target sound or control of the direction of the attenuated sound. A controllable mixing level between the ambient spatial sound and music playback. The Automatic gain control provides balance of the user own voice level with ambient spatial sound.
• FIGS. 16A-B are schematic diagrams of head presence sensor system700 which can be used withHEDphones12 and402 to detects when the user takes the HEDphone off their head. Sensor700 can provide a sensing signal toHEDphone12,HEDphone402 or HEDapp19. Upon receipt of thesensing signal HEDphone12,HEDphone402 or HEDapp19 can pause the audio automatically. Upon receipt of thesensing signal HEDphone12,HEDphone402 or HEDapp19 can putrespective HEDphone12 or HEDphone402 I a Sleep Mode when the absence of a head is detected. Sensor system700 can includesensor702 in eachear cup704.Sensor702 can be proximity and ambient light sensors such as manufactured by Osram as SF776.Sensor702 contains an infrared LED (IR-LED) and two detectors and performs two different functions.Sensor702 registers the ambient brightness and emits infrared light that is reflected by approaching objects, such as your head.Sensor702 can measure the distance fromear cup704 to the head and to measure available light withinear cup704, by combining these two values in software of HEDapp19. HEDapp19 can enable or disable the audio, such as music, and other functions such as turning the status LED off whileHEDphone12, or402 is on the head and status LED706 is not visible to the user.
• HEDapp19 is an iOS or Android compatible application that can be downloaded such as for free from either the App Store or Google Play. HEDapp19 provides the user with additional features and access to settings on theHEDphone12. HEDapp19 is also a powerful communications and social networking platform, where users can go beyond just connecting theirHEDphones12 to others, they are able to share their music tastes and discoveries, message and communicate with each other.
• HEDapp19 can provide a representation of this HEDMesh14 with all the user's name and avatars already inHEDMesh14, describing who is the host and who are the guests, the number of users in the current HEDMesh14 and the name of thisHEDMesh14. WhenHEDMesh14 is created or a new Headphone joins the group, the representation of the Mesh in HEDapp19 will be updated with the new user/player's name. If enabled, using location services onmobile device18, users can also seeother Headphones12,402 in the vicinity that are not already inHEDMesh14 and create HEDMesh without the use of NFC.
• In HEDapp19, a HEDMesh19 can also have Remote Guests. A Remote Guest connects to a HEDMesh19 viaInternet800 fromremote location802 as shown inFIG. 17. A Virtual HEDMesh814 may also be created that contain only Remote Guests.
• Every HEDMesh14 and Virtual HEDMesh814 configuration can be saved by each user in the respective HEDMesh14 and Virtual HEDMesh814, and all its guests will be able to recreate this HEDMesh14 or Virtual HEDMesh814 with the same Guests and same Host when they are within WI-FI range without using the NFC protocol. The Host can block or expel a Guest from aHEDMesh14 at any time.
• Within the HEDapp19, a user is able to create aPrivate HEDMesh14 where pre-approved members may join. APrivate HEDMesh14 may be saved for later use and all subscribed members should be able to connect automatically when they are next in proximity. At the same time, the Host of the Private HEDMesh may block and expel a Headphone user at any time, whether in range or not.
• More than one HEDMesh14 may coexist in the same area.
• HEDapp19 will allow the user to change, store and recall parameters of the supper human hearing SHH feature described above. Using a 3D graphical interface, the user will be able to adjust the volume and direction of incoming sound. The user will also be able to change the level of the incoming sound respective to the audio already playing in theHEDphone12 or402.
• Example screen shots of 3D graphical interface are shown inFIGS. 18A-18R.FIG. 18A is a screen shot of 3D graphical interface500 of a user tutorial.FIG. 18B is a screen shot of 3D graphical interface500 for a sign in with Facebook. The users are able to sign in with their social media account or create a new account.FIG. 18C is a screen shot of 3D graphical interface500 of a new registration. Users can create a new account.
• FIG. 18D is a screen shot of 3D graphical interface500 of a login to Spotify or other services.
• A user can login to different streaming music services to import their libraries.FIG. 18E is a screen shot of 3D graphical interface500 of a main menu.
• From the main menu the user can select function or page.FIG. 18F is a screen shot of 3D graphical interface500 of a Dashboard and control center. This is the default running screen where the user has control to the main features: SHH, Mesh, EQ, Audio effects, music library and ANC.FIG. 18G is a screen shot of 3D graphical interface500 of using the SHH interface, the user can modify the direction and level of incoming sound by moving their finger in the 3D graphical interface500.
• FIG. 18H is a screen shot of 3D graphical interface500 ofHEDMesh14.
• User can enable/disableHEDMesh14, see who is inHEDMesh14 and who the master is.
• FIG. 18I is a screen shot of 3D graphical interface500 of a Music Player:
• Users can control their music with the integrated player without having to come out of the app.
• FIG. 18jis a screen shot of 3D graphical interface500 of a Music library:
• User can import their music libraries and playlists from other services within the app.
• FIG. 18K is a screen shot of 3D graphical interface500 of Mesh Messaging:
• Users can chat to other members on the Mesh, rate songs, etc.
• FIG. 18L is a screen shot of 3D graphical interface500 of Equaliser:
• User can change frequency and adjust the level for each frequency. Custom presets and be created and stored. There are also standard presets included.
• FIG. 18M is a screen shot of 3D graphical interface500 of Room effects:
• A number of audio effects are available in the App.
• FIG. 18N is a screen shot of 3D graphical interface500 of an example of a room effect pre-set.
• FIG. 18O is a screen shot of 3D graphical interface500 of an example of a room effect pre-set.
• FIG. 18P is a screen shot of 3D graphical interface500 of settings. A user can change settings such as touch pad function swapping (left to right), enable/disable the presence sensors, power saving, send feedback and restore factory settings.
• FIG. 18Q is a screen shot of 3D graphical interface500 Power saving:
• The Headphone detects when there is complete silence and the user can select the time after which, the Headphone will go to sleep mode.
• FIG. 18R is a screen shot of 3D graphical interface500 of About to provide product information such as model number, serial number, firmware, terms and conditions, etc.
• HEDphone12 can be formed of foam on the inner part that extends across the entire length of the from ear to ear, that gives the Headphone a comfortable snug fit.
• Ear cup704 is elongated, shaped like the human ear rather than the standard round shape. The shape, together with the more solid chassis, creates a closer fit to the head. For extra comfort, injection moulded memory foam is used for the full length inner cushion providing a good fit, making this design more comfortable than current headphones.
• Foam piece710 can be formed as a single continuous piece and is also customizable and can be replaced giving the user a wide choice of fabrics, colors and foam densities.
• In one embodiment shown inFIGS. 19A-19C, headband710 includes foam piece710 and is formed in onesingle chassis715 fromleft ear cup7021 to right ear cup702rwith no mechanical hinges or sizing adjustments as shown inFIG. 19B.Chassis715 houses all electronic components and is then covered by theouter casing716 as shown inFIG. 19C.Outer casing716 can be made in one piece.Chassis715 is rigid inrigid areas720, such as near drivers, PCBs and batteries, and allows more flexing inflexible areas722 of headband710 where needed.
• Foam carrier725 snaps ontochassis715 as shown inFIG. 19C.Foam carrier725 can be made of one moulded piece.
• HEDphone402 can be formed by 3 completely detachable parts. The battery side, the electronics' side and the headband. The headband can be bought separately to the correct size. S, M, L, XL as shown inFIGS. 20A-20C. The HEDphone is fitted with 3 Lithium Ion batteries of 680 mAh each, totaling 2040 mAh, providing 15 hours of Bluetooth use with music and 8 hours of Mesh use. The batteries cannot be replaced by the user and can be fully recharged by using a micro USB cable in 3 hours.HEDphone12 does not fold, making it stronger, more solid and less likely to break. It also allows for more room inside to fit electronic components and bigger batteries.
• FIG. 21 illustrates an embodiment ofHEDphone12 including rechargeable batteries housed in headband710. A plurality ofbatteries750 are housed in headband710. In one embodiment, three rechargeable Lithium-Ion batteries are hosted in headband710.
• In an embodiment of the present invention,outer casing716 is formed of a single piece of injection-molded foam upholstered with fabric760 as shown inFIG. 22A. Foam770 can be provided on inner surface717 ofouter casing716. Foam770 provides additional cushioning during sport activities. Alternatively,fur material780 can be provided on inner surface717 ofouter casing716 as shown inFIGS. 22B-22C. A variety of densities, thicknesses, ear sizes, fabrics and colors, giving the user a large degree of personalization and customization for their ear size and personal style toouter casing716.
• In one embodiment, functions ofHEDphone402 can be reversed by software and using HEDapp19 for left handed users that prefer the most commonly used functions on the left side as shown inFIG. 23. The default function of the touch pads is to have the play/pause music and phone call actions on the right touch pad and the SHH and Talk mode on the left.
• FIG. 24 is a schematic diagram ofcover800. Cover800 can be attached toHEDphone12 to provide the ability to attach custom accessory covers to protect the outer surface of the headphone while allowing the user yet another way to express their individuality.
• The HEDapp is a user interface application downloadable to any mobile device which will allow theHEDphone12a-12nuser to control and monitor all its HEDphone's features. The HEDapp can be compatible with mobile operating systems such as for example IOS and Android. The HEDapp can have the functionality shown in Table 2.
• Embodiments of the present invention may be implemented in connection with a special purpose or general purpose processor device that include both hardware and/or software components, or special purpose or general purpose computers that are adapted to have processing capabilities.
• Embodiments may also include physical computer-readable media and/or intangible computer-readable media for carrying or having computer-executable instructions, data structures, and/or data signals stored thereon. Such physical computer-readable media and/or intangible computer-readable media can be any available media that can be accessed by a general purpose or special purpose computer. By way of example, and not limitation, such physical computer-readable media can include RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, other semiconductor storage media, or any other physical medium which can be used to store desired data in the form of computer-executable instructions, data structures and/or data signals, and which can be accessed by a general purpose or special purpose computer. Within a general purpose or special purpose computer, intangible computer-readable media can include electromagnetic means for conveying a data signal from one part of the computer to another, such as through circuitry residing in the computer.
• When information is transferred or provided over a network or another communications connection (either hardwired, wireless, or a combination of hardwired or wireless) to a computer, hardwired devices for sending and receiving computer-executable instructions, data structures, and/or data signals (e.g., wires, cables, optical fibers, electronic circuitry, chemical, and the like) should properly be viewed as physical computer-readable mediums while wireless carriers or wireless mediums for sending and/or receiving computer-executable instructions, data structures, and/or data signals (e.g., radio communications, satellite communications, infrared communications, and the like) should properly be viewed as intangible computer-readable mediums. Combinations of the above should also be included within the scope of computer-readable media.
• Computer-executable instructions include, for example, instructions, data, and/or data signals which cause a general purpose computer, special purpose computer, or special purpose processing device to perform a certain function or group of functions. Although not required, aspects of the invention have been described herein in the general context of computer-executable instructions, such as program modules, being executed by computers, in network environments and/or non-network environments. Generally, program modules include routines, programs, objects, components, and content structures that perform particular tasks or implement particular abstract content types. Computer-executable instructions, associated content structures, and program modules represent examples of program code for executing aspects of the methods disclosed herein.
• Embodiments may also include computer program products for use in the systems of the present invention, the computer program product having a physical computer-readable medium having computer readable program code stored thereon, the computer readable program code comprising computer executable instructions that, when executed by a processor, cause the system to perform the methods of the present invention.
• It is to be understood that the above-described embodiments are illustrative of only a few of the many possible specific embodiments, which can represent applications of the principles of the invention. Numerous and varied other arrangements can be readily devised in accordance with these principles by those skilled in the art without departing from the spirit and scope of the invention.

Claims (20)

1. A first headphone enabling a user to chat with one or more second headphones while the first headphone outputs audio sound waves, the first headphone comprising:

a first module configured to communicate with a first audio device, the first module further configured to receive first audio data from the first audio device;

a set of one or more first speakers configured to output first audio sound waves based on the first audio data;

at least one microphone configured to receive first voice sound waves from a user and to generate first voice data based on the first voice sound waves while the set of one or more first speakers is outputting the first audio sound waves, the first voice data being different than the first audio data;

an antenna configured to establish a wireless network to communicate with one or more second headphones over one or more unicast communication channels; and

a first processor configured to stream the first voice data over a respective unicast communication channel of the one or more unicast communication channels over the wireless network to each of the one or more second headphones, each of the one or more second headphones configured to output a respective instance of the first voice sound waves based on the first voice data while each of the one or more second headphones is respectively outputting second audio sound waves, the first processor further configured to receive over the wireless network second voice data from at least one of the one or more second headphones, the set of one or more first speakers further configured to output second voice sound waves based on the second voice data while the set of one or more first speakers is outputting the first audio sound waves, the first headphone being configured to receive configuration data from an application, the application providing a graphical user interface for receiving configuration settings from the user.

2. The first headphone ofclaim 1, wherein the wireless network is a Wi-Fi network.

3. The first headphone ofclaim 1, wherein the wireless network includes a mesh network.

4. The first headphone ofclaim 1, wherein the first audio device is a mobile device.

5. The first headphone ofclaim 1, wherein the first module is configured to communicate with the first audio device using a Bluetooth protocol.

6. The first headphone ofclaim 1, wherein the first module is configured to communicate with the first audio device over a wire.

7. The first headphone ofclaim 1, wherein the first audio device sources the first audio data from a music server or service.

8. The first headphone ofclaim 1, further comprising an array of second microphones, the array of second microphones being arranged to attenuate or amplify audio coming from a selected direction, the second microphones of the array of second microphones being pointed in various directions to achieve a 360° audio image of an environment around the user.

9. The first headphone ofclaim 8, wherein the second microphones are MEMS microphones configured to provide active noise cancelling.

10. The first headphone ofclaim 1, further comprising a chassis including a pair of ear cups, the pair of ear cups containing the set of one or more first speakers.

11. The first headphone ofclaim 10, wherein one or more batteries are housed in the chassis.

12. The first headphone ofclaim 1, further comprising a sensor configured to sense when the first headphone is removed from a head of the user.

13. The first headphone ofclaim 12, wherein the first headphone is turned off automatically if the sensor senses that the first headphone has been removed from the head of the user.

14. The first headphone ofclaim 1, wherein the first headphone is configured to allow a particular second headphone to override the first headphone and stream second audio data from a particular second audio device to the first headphone and to any other of the one or more second headphones connected to the wireless network.

15. The first headphone ofclaim 1, wherein the first headphone is configured to allow the user to stream the first audio data over the wireless network to each of the one or more second headphones connected to the wireless network.

16. The first headphone ofclaim 15, wherein the first headphone is configured to allow the user to switch the first audio device to a different audio device to stream different audio data over the wireless network to each of the one or more second headphones connected to the wireless network.

17. A first headphone enabling a user to chat with one or more second headphones while the first headphone outputs audio sound waves, the first headphone comprising:

at least one processor;

memory storing computer instructions, the computer instructions when executed by the at least one processor, configured to cause the first headphone to perform:

receiving configuration data from an application, the application providing a graphical user interface for receiving configuration settings;

receiving first audio data from a first audio device;

outputting on a set of one or more first speakers first audio sound waves based on the first audio data;

receiving by a first microphone first voice sound waves from a user;

generating first voice data based on the first voice sound waves while the set of one or more first speakers is outputting the first audio sound waves, the first voice data being different than the first audio data;

establishing a wireless network to communicate with one or more second headphones over one or more unicast communication channels;

streaming the first voice data over a respective unicast communication channel of the one or more unicast communication channels over the wireless network to each of the one or more second headphones, each of the one or more second headphones configured to output a respective instance of the first voice sound waves based on the first voice data while each of the one or more second headphones is respectively outputting second audio sound waves;

receiving over the wireless network second voice data from at least one of the one or more second headphones; and

outputting on the set of one or more first speakers second voice sound waves based on the second voice data while the set of one or more first speakers is outputting the first audio sound waves.

18. The first headphone ofclaim 17, wherein the computer instructions when executed by the at least one processor are further configured to cause the first headphone to allow a particular second headphone to override the first headphone and stream second audio data from a particular second audio device to the first headphone and to any other of the one or more second headphones connected to the wireless network.

19. The first headphone ofclaim 17, wherein the computer instructions when executed by the at least one processor are further configured to cause the first headphone to allow the user to stream the first audio data over the wireless network to each of the one or more second headphones connected to the wireless network.

20. The first headphone ofclaim 15, wherein the computer instructions when executed by the at least one processor are further configured to cause the first headphone to allow the user to switch the first audio device to a different audio device to stream different audio data over the wireless network to each of the one or more second headphones connected to the wireless network.

Images