The present disclosure relates generally to streaming high-quality audio between Bluetooth devices and control of the streaming to save power.
Portable devices such as smartphones, tablets, portable digital assistants (PDA), portable music players, book readers, and laptop computers have become popular devices for playing high-quality audio. Along with these devices, it is also popular to listen to and control the audio by way of a wireless device that wirelessly communicates with the portable device. Such wireless audio devices may include headsets, earphones, hearing aid devices, wearables, or car kits. Short range wireless communications for communication between the portable devices and wireless audio devices may include WiFi Direct and Bluetooth (BT). Among types of wireless communications, Bluetooth (BT) includes profiles for streaming audio between devices and for control of the state of streaming. The Advanced Audio Distribution Profile (A2DP) defines the protocols and procedures to stream high-quality mono or stereo audio between BT devices. This profile relies on Audio/Video Distribution Transport Protocol (AVDTP) to stream audio over an L2CAP channel. Since a stream represents unidirectional media data, the devices assume roles of source (SRC) and sink (SNK). The audio stream generating entity is the SRC whereas the consuming device is the SNK. The Audio/Video Remote Control Profile (AVRCP) is used in conjunction with A2DP for remote control on devices such as headphones, Car-Kits and wearable devices.
The Audio Video Remote Control Profile (AVRCP) in BT may be used to control A2DP state using different commands, notifications and events. The profile adopts the AV/C device model and command format for control messages, and those messages are transported by the Audio/Video Control Transport Protocol (AVCTP). Usage Examples are: play/pause/next/stop commands, play position change/filename change/audio volume change etc. are notifications. Similar to A2DP, AVRCP defines Controller (CT) and Target (TG) roles. The CT is a device that initiates a transaction by sending a command frame to a target and the TG is a device that receives a command frame and accordingly generates a response frame. The A2DP focuses on audio streaming while AVRCP is mainly used to control, browse media contents and its states.
A2DP profile establishes signaling and a media session between BT devices. AVRCP is a profile that is used to control (start/stop) the A2DP session and to observe progress of A2DP session, such as play progress, volume change, play file change and browsing of files.
Notifications generated by AVRCP while Bluetooth (BT) audio is streaming are huge. Even with BT audio offloaded to a BT controller, AVRCP notifications cause the host processor to awake. Subsequently, notifications generated by AVRCP consume portable device battery. Also, AVRCP Notifications are generated without user knowledge or checking status of the remote host processor.
From the perspective of the wireless audio device, the huge number of AVRCP notifications generated from the portable device causes battery drain in the low power designed wireless audio device. The portable device generates notifications without knowledge or necessity in the wireless audio device. Thus, although AVRCP Notifications are very important messages between wireless communications devices while A2DP audio streaming, there is a need to save battery consumption in the devices during notifications.
Although aspects of the present disclosure relate to Bluetooth, wireless communication by way of other standards such as WiFi Direct may benefit from reduced battery consumption by applying the aspects of the present disclosure.
The foregoing “Background” description is for the purpose of generally presenting the context of the disclosure. Work of the inventors, to the extent it is described in this background section, as well as aspects of the description which may not otherwise qualify as prior art at the time of filing, are neither expressly nor impliedly admitted as prior art against the present invention.
A more complete appreciation of the disclosure and many of the attendant advantages thereof will be readily obtained as the same becomes better understood by reference to the following detailed description when considered in connection with the accompanying drawings, wherein:
Referring now to the drawings, wherein like reference numerals designate identical or corresponding parts throughout several views, the following description relates to alternative approaches to reducing power usage where A2DP and AVRCP profiles stream audio between BT connected devices.
Regarding
Regarding
The media framework 105 reads the contents to be streamed from the file system 113, encodes according to AVDTP signaling and, with the AVDTP and L2C headers, sends streams over the air via the BT controller 109. A device 201 serving as a SNK receives the audio streams via its own BT controller 209. The device 201 may include a display 211, media framework 205, A2DP/AVRCP profiles 207 that are controlled by a host processor 203 which is separate from the BT controller 209. The media framework 205 may output audio to a speaker and may output messages or video to display 211.
An aspect of reducing battery power consumption may be an architecture in which the audio frames encoding responsibility is shifted from main host processor to a co-processor. In such architecture, the battery hungry host processor can be put into sleep state while A2DP audio streaming is in progress. The co-processor may pump encoder A2DP frames to BT controller via a hardware interface without intervention of host processor. The co-processor will be controlled from the host processor on A2DP signaling events. Via this architecture, portable devices can reduce their battery consumption. Via this architecture, only AVRCP runs in the host processor and updates audio playing progress information. There is a need for further reduction in power consumption by the host processor.
According to AVRCP, a CT requests information of changes of a variety of items like playback position, playback status, track change, volume change, now playing list change, etc. In addition, for each request the CT receives information of the changes. In particular, AVRCP mandates three handshaking sequences between CT and TG.
1. RegisterNotification command
2. RegisterNotification Interim response
3. RegisterNotification Changed response
All AVRCP notifications follow this notification sequence. These notifications use a lot of power as power is used each time the Host is waked up on TG and notification information is requested.
An aspect of reducing power consumption may be to introduce a new event among actions that are controlled or monitored over the course of streaming audio.
An initial handshake may be performed for a regular event, such as a change in play position, which includes the controller CT sending a Register Notification message 401 and the target TG responding with an Interim Response message 403 to register the play position changed event. The new event may be initiated by the portable device 101 as a request to monitor status of the display 211. The new AVRCP event may be registered by a handshaking sequence in which the target TG sends a Registration Notification
“DISPLAY_STATUS_CHANGED” 411 to controller CT which invokes an Interim Response 413. The audio streaming will start according to the AVDT protocol. The target TG will notify of a play position change 405. At some point during audio streaming, the controller CT may be informed that the display 211 will be turned off, for example after two seconds. The controller CT will notify the target TG of the change in display status by a Changed Response notification message 415. Subsequently, provided the notification of changed status “Changed Response” 415, the BT controller 109 will not wake up the host 103 to send further notifications, as the remote display 211 is off.
Introduction of a new event, such as display status changed reduces the number of notifications and saves battery consumption. During the period of time that the audio is being transmitted while the display 211 is off, the BT controller will not wake up the host processor 103 of the TG device 101 to send and receive notification messages with the CT device 201. The host processor of the TG device will remain in a sleep state and use less battery power.
An aspect of reducing power consumption may be to offload processing from the host processor to the controller during audio transmission.
An aspect is offloading AVRCP notification depending on a change in status of display 211. The AVRC Target TG may initiate an event as a request to monitor status of the display 211. The request may be registered by a handshaking sequence in which the target TG sends a Registration Notification “DISPLAY_STATUS_CHANGED” to controller CT which invokes an Interim Response. The audio streaming will start according to the AVDT protocol. At some point during audio streaming, the controller CT may be informed that the display 211 will be turned off, for example after two seconds. The controller CT will notify the target TG of the change in display status by a Changed Response notification message. Subsequently, provided the notification of changed status event “Changed Response”, the TG host processor 103 invokes a vendor specific command 501 to offload handling of the event. The TG BT controller 109 handles the Register Notification DISPLAY STATUS CHANGED event by processing the block of code for the predetermined period. Power consumption by the battery of the AVRCP Target TG 101 can be reduced by not involving the host processor 103 in processing notifications for a predetermined period. Instead, the lower power BT controller 109 performs the offloaded event handling for the predetermined period, for example by handling play position notifications. The host processor may be waked after completion of the predetermined period.
An aspect is to piggyback audio frames with notification messages so that fewer notification messages are separately transmitted.
In order to implement this aspect of piggybacking AVRCP notifications with A2DP frames, the media framework 105 may be modified to accommodate different size frames. However, the main intention of reducing battery consumption will be served with this aspect. An example implementation of piggybacking may be to link a co-processor or audio offload with a media player index.
An aspect is to bundle different AVRCP notifications so that the host processor will be waked fewer times. Instead of a Register Notification and Interim Response handshake sequence for each type of notification, a single Register Notification and Interim Response handshake sequence may be made for several notifications. For example, a Register Notification and Interim Response handshake sequence may be made for a group of notifications including VOLUME CHANGED, PLAY POSITION CHANGED, DISPLAY STATUS CHANGED. The handshaking signals for the registration sequence can be reduced by avoiding the registration notification/interim response sequence each time a change happens. Instead, over the course of song length, changed response notifications for the group of notifications such as volume change notification and play position change notification can be sent by the target TG at regular intervals.
An aspect to reduce power consumption may be to add an expire parameter to a notification message. The expire parameter may allow a host processor to skip sending of notification messages for an optional period.
An aspect to reduce power consumption by including a function in the controller CT of identifying the status of the display 211. In this aspect, during the period that the display 211 is off, the controller CT does not send a Register Notification message.
The above alternative approaches may be implemented in various ways. Other events may be monitored such as a new AVRCP subscribe event to receive status change of display 211 corresponding to AVRCP Controller 209. Alternatively, an “expire” parameter may be introduced to reduce AVRCP Subscribe messages. Furthermore, AVRCP notifications may be appended with A2DP messages. Specific time notification can be offloaded to and handled by the BT controller 109 of AVRCP TG 101.
Numerous modifications and variations are possible in light of the above teachings. It is therefore to be understood that within the scope of the appended claims, the invention may be practiced otherwise than as specifically described herein.
Thus, the foregoing discussion discloses and describes merely exemplary embodiments of the present invention. As will be understood by those skilled in the art, the present invention may be embodied in other specific forms without departing from the spirit or essential characteristics thereof. Accordingly, the disclosure of the present invention is intended to be illustrative, but not limiting of the scope of the invention, as well as other claims. The disclosure, including any readily discernible variants of the teachings herein, defines, in part, the scope of the foregoing claim terminology such that no inventive subject matter is dedicated to the public.
The present application is a continuation of U.S. application Ser. No. 16/674,006, filed on Nov. 5, 2019, entitled “Apparatus to Save Power Smartly from Bluetooth Audio Visual Remote Control Protocol Notifications,” which is a continuation of U.S. application Ser. No. 15/796,389, filed on Oct. 27, 2017, entitled “Apparatus to Save Power Smartly from Bluetooth Audio Visual Remote Control Protocol Notifications,” now U.S. Pat. No. 10,477,471, the entire contents of each of which is incorporated herein by reference.
Number | Name | Date | Kind |
---|---|---|---|
9277255 | Rowe | Mar 2016 | B1 |
9326012 | Dorwin | Apr 2016 | B1 |
9384271 | Goldin et al. | Jul 2016 | B1 |
9768974 | Lewis | Sep 2017 | B1 |
9826529 | Jorgovanovic | Nov 2017 | B1 |
10212474 | Xu | Feb 2019 | B2 |
10491964 | Kellar | Nov 2019 | B2 |
10609030 | Newstadt | Mar 2020 | B1 |
10838691 | Geng | Nov 2020 | B2 |
20020023237 | Yamada et al. | Feb 2002 | A1 |
20050075148 | Park | Apr 2005 | A1 |
20070041578 | Ohsawa | Feb 2007 | A1 |
20070247449 | Mack et al. | Oct 2007 | A1 |
20080261524 | Grushkevich | Oct 2008 | A1 |
20080287063 | Kidron et al. | Nov 2008 | A1 |
20090197533 | Luk | Aug 2009 | A1 |
20090207014 | Ayed | Aug 2009 | A1 |
20090312010 | Hall | Dec 2009 | A1 |
20100009725 | Banerjea | Jan 2010 | A1 |
20100054519 | Mulvey | Mar 2010 | A1 |
20100142500 | Sudak | Jun 2010 | A1 |
20100292821 | Mehta | Nov 2010 | A1 |
20100299700 | Choi et al. | Nov 2010 | A1 |
20100309831 | Yeh | Dec 2010 | A1 |
20110111708 | Tu | May 2011 | A1 |
20120164948 | Narasimha | Jun 2012 | A1 |
20120275618 | Tan et al. | Nov 2012 | A1 |
20130014184 | Mank | Jan 2013 | A1 |
20140009334 | Lee et al. | Jan 2014 | A1 |
20140064695 | Cho et al. | Mar 2014 | A1 |
20140095669 | Kang | Apr 2014 | A1 |
20140119407 | Miller et al. | May 2014 | A1 |
20140130073 | Yu et al. | May 2014 | A1 |
20140161274 | Singamsetty et al. | Jun 2014 | A1 |
20140240755 | Pizot | Aug 2014 | A1 |
20140293145 | Jones | Oct 2014 | A1 |
20150043427 | K.M. | Feb 2015 | A1 |
20150133056 | Kang et al. | May 2015 | A1 |
20150228000 | Bijor | Aug 2015 | A1 |
20160018959 | Yamashita et al. | Jan 2016 | A1 |
20160277522 | Singh | Sep 2016 | A1 |
20160286337 | Thekkedathu Sivaraman | Sep 2016 | A1 |
20160379472 | Schuler et al. | Dec 2016 | A1 |
20170078962 | Hassan et al. | Mar 2017 | A1 |
20170094677 | Liu | Mar 2017 | A1 |
20180116003 | Gu | Apr 2018 | A1 |
20180184152 | Kirkpatrick et al. | Jun 2018 | A1 |
Entry |
---|
Advanced Audio Distribution Profile Specification, Audio Video Working Group, pub Jul. 14, 2015, pp. 1-75. |
Number | Date | Country | |
---|---|---|---|
20220322228 A1 | Oct 2022 | US |
Number | Date | Country | |
---|---|---|---|
Parent | 16674006 | Nov 2019 | US |
Child | 17723457 | US | |
Parent | 15796389 | Oct 2017 | US |
Child | 16674006 | US |