Controlling audio broadcast configuration based on sink capability

Abstract

A method and system to control processing of audio broadcast from a broadcast source (SRC). The SRC receives, respectively for each broadcast sink (SNK) of a plurality of SNKs that will wirelessly receive and play out the audio broadcast from the SRC, capability information defining one or more capabilities of the SNK. The SRC then uses the received capability information of the plurality of SNKs as a basis to configure the audio broadcast from the SRC. For instance, the SRC may use the capability information of the multiple SNKs as a basis (i) to control whether to broadcast multiple audio channels in a single broadcast isochronous stream (BIS), (ii) to configure how many times to repeatedly broadcast each audio packet of a series, and / or (iii) to configure a presentation delay to facilitate synchronized audio playout, among other possibilities.

Description

CONTROLLING AUDIO BROADCAST CONFIGURATION BASED ON SINK CAPABILITYREFERENCE TO RELATED APPLICATION

[0001] This application claims priority to U.S. Provisional Patent Application No. 63 / 571,186, filed March 28, 2024, the entirety of which is hereby incorporated by reference.BACKGROUND

[0002] The present disclosure relates to wireless communication of audio from an audio source and receipt and rendering of the audio by one or more audio presentation devices.

[0003] Audio communication can be carried out largely in accordance with any of various wireless communication protocols. Without limitation, an example protocol is Bluetooth™, and more particularly Bluetooth Low Energy (BLE) with the Basic Audio Profile (BAP), as defined by the Bluetooth Special Interest Group (SIG). Other examples, including but not limited to WI-FI and ZIGBEE, are possible as well.

[0004] In order to communicate a stream of audio under an example protocol, an audio source may encode the audio using an audio codec (e.g., an LC3 codec), divide the encoded audio into a sequence of service data units (SDUs), translate the SDUs into protocol data units (PDUs), and transmit the sequence of PDUs over a radio-frequency (RF) air interface for receipt, decoding, and playout of the audio by one or more receiving devices. Further, under an example protocol, the transport of the PDU sequence may occur on an “isochronous stream,” which is divided over time into defined intervals and sub-intervals for carrying audio packets and associated information. In particular, each audio packet may contain a respective PDU with an appended header (e.g., 16-bits) carrying useful overhead information. As a receiving device receives this sequence of audio packets, the receiving device may then read the PDUs in sequence and decode the audio for playout.SUMMARY

[0005] Some disclosed aspects relate to multi-channel (e.g., stereo) audio broadcast, where a broadcast audio source (SRC) device wirelessly broadcasts multi-channel audio and where each of one or more broadcast sink (SNK) devices wirelessly receives and plays out the broadcast audio in real time. An example SNK device is a pair of earbuds (e.g., conventionalearbuds or canalphones), a set of headphones, another personal listening device, or a pair of speakers, among other possibilities.

[0006] In contrast to unicasting of audio, where an audio source transmits audio directly to one intended recipient device for playout, broadcasting of audio facilitates playout of the same audio by potentially multiple recipient devices at once. Broadcasting of audio allows numerous new services, such as audio communication of public-service announcements to multiple people wearing compatible earbuds within public areas (e.g., airports, train stations, or gyms), sharing of performance audio to audience members wearing compatible earbuds in a theater or other performance venue, and sharing of audio from a personal device such as a smartphone, tablet, or computer to earbuds worn by multiple friends, colleagues, or family members within range of the personal device.

[0007] Broadcasting of multi-channel audio under an example protocol occurs on one or more broadcast isochronous streams (BISs), each divided into recurring sub-intervals for carrying digitized audio with associated header information, among other data. Considering stereo audio for instance, to facilitate broadcasting of left and right audio channels concurrently for playout by one or more recipient SNKs, the SRC may broadcast BISs respectively for the left and right channels or may broadcast a single BIS carrying both the left and right channels, among other possibilities.

[0008] The example protocol may further define a process that enables a SNK to discover the presence of an audio broadcast stream and to determine how to receive and decode the audio data carried by that stream. For instance, in accordance with the protocol, the SRC may broadcast various interrelated advertising-control messages including one or more such messages that provide information that indicates audio stream type (e.g., context type) and BIS structure, coding, and timing. A SNK may thus regularly scan for and discover presence of these advertising messages and thereby learn of the existence of a broadcast audio stream of a desired type, determine the associated BIS structure, coding, and timing, and accordingly receive, decode, and play out the broadcast audio.

[0009] Because many SNKs, such as earbuds, may be power limited, an example protocol may also allow for use of a broadcast assistant (AST) device to assist a SNK with the scanning for and discovering presence of broadcast streams. In one arrangement, for instance, a user’s smartphone may function as an AST to discover presence of broadcast streams for receipt by the user’s earbuds as a SNK. In practice, the AST and SNK may establish a control communication connection (e.g., an asynchronous connection-oriented logical transportsession, or ACL link) with each other. Through this control connection, the SNK may inform the AST what types of stream(s) the SNK may be interested in receiving (e.g., per a userconfiguration setting). The AST may then scan for presence of the indicated types of stream(s) and, upon discovering presence of such a stream, direct the SNK to read SRC -broadcasted advertising that defines for that stream the BIS structure, coding, and timing, as noted above, so that the SNK can then start to receive and play out the broadcast audio.

[0010] In general, for broadcasting of audio, there may be no need for, and no sense in, having a control connection (e.g., an ACL link) between the AST and the SRC, or between the SNK and the SRC for that matter, since the SRC would simply advertise and broadcast audio in a standardized manner for receipt and playout by any and all interested SNKs within range.

[0011] In some situations, however, it may be useful to establish and make use of a control connection (e.g., an ACL link) between the AST and the SRC.

[0012] For instance, consider a scenario where two users, A and B (such as friends or family members) each wear a respective pair of earbuds and each have a respective smartphone, and where both users want to listen to the same audio as each other from user A’s smartphone. In this scenario, each user’s pair of earbuds may define a respective SNK, each user’s smartphone may be configured with AST logic that functions as an AST for that user’s earbuds, and user A’s smartphone may also be configured with SRC logic that functions as a SRC to broadcast the audio for receipt and playout by one or more recipient SNKs.

[0013] With this arrangement, it may be useful in some cases to establish a control connection between the AST logic in user B’s smartphone and the SRC logic in user A’s smartphone, to facilitate exchange of broadcast-related control signaling between user B’s earbuds and the SRC logic in user A’s smartphone, via the AST logic in user B’s smartphone. Further, it may be useful in some cases to establish a control connection (i.e., control communication) internally in user A’s smartphone between the AST logic in user A’s smartphone and the SRC logic in user A’s smartphone, to facilitate exchange of broadcast- related control signaling between user A’s earbuds and the SRC logic in user A’s smartphone, via the AST logic in user A’s smartphone.

[0014] Alternatively, it may be useful to establish a more direct control connection between user B’s earbuds and the SRC logic in user A’s smartphone, without use of an AST. However, if a control connection will already exist between user B’s earbuds and the AST logic in user B’s smartphone, then, rather than adding another connection with user B’s earbuds, itmay be more efficient to simply make use of the existing control connection between user B’s earbuds and the AST logic in user B’s smartphone, and to add a control connection between the AST logic in user B’s smartphone and the SRC logic in user A’s smartphone to facilitate exchange of control information ultimately between user B’ s earbuds and the SRC logic in user A’s smartphone.

[0015] Providing a control connection respectively between each SNK’s AST and the SRC (or directly between each SNK and the SRC) can facilitate technical improvements in the SRC’s audio broadcast, by enabling the SRC to configure the audio broadcast in a manner that takes into account capabilities of the one or more SNKs that will receive and play out the SRC’s audio broadcast.

[0016] In contrast to unicasting of audio, the act of broadcasting audio is normally recipient-agnostic. The SRC would not take into account capabilities of the SNKs that will receive its audio broadcast, at least because the SRC would normally be unaware of which if any SNKs will receive and play out its audio broadcast. At best, the SRC may assume that each recipient SNK would be compliant with the wireless audio communication protocol used by the SRC.

[0017] Unfortunately, however, this creates several technical issues. First, the protocol used by the SRC may define a default broadcast configuration that is relatively inefficient, even if the SRC and each of the one or more recipient SNKs actually happen to support using a technically more efficient broadcast configuration. Second, the protocol used by the SRC may provide for the SRC to automatically broadcast each audio packet of the stream multiple times to help ensure successful receipt and play out of the audio by any recipient SNKs, even if each of the one or more recipient SNKs happens to be employing some other technique that may itself sufficiently help to ensure successful receipt and playout of the audio.

[0018] In an example control arrangement, a control connection between each SNK’s AST and the SRC (or directly between each SNK and the SRC) can overcome technical issues such as those mentioned above. For instance, through each such control connection, the SRC learns certain capability information of each SNK that will receive and play out the SRC’s audio broadcast, and the SRC uses that information as a basis to control its audio broadcast.

[0019] This control arrangement can facilitate various technical improvements.

[0020] In some implementations, for instance, the SRC makes use of this control arrangement to efficiently broadcast multiple audio channels (e.g., left and right audio channels) in a single BIS rather than in separate BISs upon learning that each recipient SNKwould support the single-BIS configuration. Without the present control arrangement, the SRC may default to broadcasting the multiple audio channels in separate respective BISs, to help ensure compatibility with recipient SNKs that may or may not support broadcast of multiple channels in a single BIS. With an example of the present control arrangement, on the other hand, the SRC learns whether each of the one or more SNKs that will receive and play out the SRC’s audio broadcast supports audio broadcast with the multiple audio channels in a single BIS. Upon determining that each of the one or more SNKs that will receive and play out the SRC’s audio broadcast supports audio broadcast with the multiple audio channels in a single BIS, the SRC then efficiently broadcasts the multiple audio channels in a single BIS.

[0021] Further, in some implementations, the SRC makes use of the control arrangement to facilitate taking into account relay capability of each of the one or more recipient SNKs, as a basis to control how many times the SRC will automatically transmit each audio packet that the SRC will broadcast. Relay functionality at a recipient SNK having two or more receiving nodes (e.g., a pair of earbuds) may help the SNK successfully receive and play out broadcast audio. In practice, the SRC may automatically transmit each audio packet multiple, N, times to help ensure successful receipt and playout of each audio packet by recipient SNKs, and the number N may be set to a relatively high default value designed to help provide a desired level of success. With an example of the present control arrangement, the SRC learns whether each of the one or more SNKs that will receive and play out the SRC’s audio broadcast supports (e.g., will apply) the relay functionality and, if so, sets N to a lower value, in order to engage in fewer automatic transmissions respectively of each audio packet, because the relay functionality may sufficiently improve success of transmissions.

[0022] Still further, in some implementations, the SRC makes use of the control arrangement to facilitate taking into account the audio-processing duration of each of the one or more recipient SNKs, as a basis to configure timing for playout of the broadcast audio by the one or more SNKs. In example implementations, this applies for broadcast of multi-channel audio that would be received by one or more SNKs each having multiple nodes for receiving and playing out the respective audio channels. In that context, the SRC may configure a presentation delay that defines how long the nodes in each SNK should wait after a defined synchronization time point before playing out their respective audio channel, in order to synchronize playout by the nodes. Without the present control arrangement, the SRC may by default configure a relatively long presentation delay that would likely work for any recipient SNK. With the present control arrangement, on the other hand, the SRC learns the audio-processing delay respectively of each of the one or more SNKs that will receive and play out the SRC’s audio broadcast, and the SRC uses that information as a basis to configure a more optimal presentation delay for its broadcast.

[0023] Accordingly, in one respect, disclosed is a method to control processing of audio broadcast from a device. The method includes (i) the device receiving, respectively for each SNK of a plurality of SNKs that will wirelessly receive and play out the audio broadcast from the device, capability information defining one or more capabilities of the SNK and (ii) the device using the received capability information of the plurality of SNKs as a basis to configure the audio broadcast from the device.

[0024] In another respect, disclosed is a device that has a wireless communication interface through which to provide an audio broadcast from the device, a processor, non- transitory data storage, and that has program instructions stored in the non-transitory data storage and executable by the processor to cause the device to carry out operations for controlling processing of the audio broadcast from the device. The operations carried out by the device include (i) receiving, respectively for each SNK of a plurality of SNKs that will wirelessly receive and play out the audio broadcast from the device, capability information defining one or more capabilities of the SNK and (ii) the device using the received capability information of the plurality of SNKs as a basis to configure the audio broadcast from the device.

[0025] Further, in another respect, disclosed is a non-transitory computer-readable medium having stored thereon program instructions executable by a processor of a device to cause the device to carry out operations for controlling audio broadcast from the device. The operations include (i) receiving, respectively for each SNK of a plurality of SNKs that will wirelessly receive and play out the audio broadcast from the device, capability information defining one or more capabilities of the SNK and (ii) using the received capability information of the plurality of SNKs as a basis to configure the audio broadcast from the device.

[0026] Still further, in another respect, disclosed is a system that includes various means for carrying out each of the operations described herein.

[0027] In these or other implementations, as discussed above, (i) each SNK may optionally have a control connection with a respective AST, as a SNK-AST control connection of the SNK, (ii) the device may function as a wireless broadcast source, SRC, and (iii) each SNK’s AST may have a respective control connection with the SRC, as an AST-SRC control connection of the SNK. Receiving the capability information respectively for each SNK can then optionally involve the device receiving each SNK’s capability information reported fromthe SNK to the SNK’s AST over the SNK’s SNK-AST control connection and in turn from the SNK’s AST to the SRC over the SNK’s AST-SRC control connection.

[0028] Further, each of one or more of the SNKs may already be receiving and playing out the audio broadcast from the SRC when this controlling occurs, and may continue to receive and play out the audio broadcast from the SRC. Alternatively, as to each of one or more SNKs, the controlling may occur before the SNK starts to receive the audio broadcast from the SRC.

[0029] These as well as other aspects, advantages, and alternatives will become apparent to those of ordinary skill in the art by reading the following detailed description, with reference where appropriate to the accompanying drawings. Further, it should be understood that the descriptions provided in this summary and below are intended to illustrate the invention by way of example only and not by way of limitation.BRIEF DESCRIPTION OF THE DRAWINGS

[0030] Figure 1 is a simplified illustration of an example scenario in which various features can be implemented.

[0031] Figure 2 is a simplified illustration of how the devices of Figure 1 can be involved with an audio broadcast.

[0032] Figure 3 is a simplified block diagram illustrating inclusion of example SRC and AST logic modules.

[0033] Figure 4 is a simplified block diagram illustrating SNK-AST connections and AST-SRC connections.

[0034] Figure 5 is a flow chart illustrating an example method.

[0035] Figure 6 is another flow chart illustrating an example method.

[0036] Figure 7 is another flow chart illustrating an example method.

[0037] Figure 8 is a simplified block diagram of an example device that can function as an SRC.

[0038] Figure 9 is a simplified block diagram of an example SNK.DETAILED DESCRIPTION

[0039] The present disclosure will discuss example implementations in the context of a SRC being a smartphone and multiple SNKs each being a pair of earbuds, and further using BLE with BAP as an example wireless audio communication protocol. It will beunderstood, however, that various principles disclosed can apply in any of a variety of other contexts, such as where the SRC is another type of audio source device and / or where the SNKs are or include one or more types of devices other than earbuds. Further, the disclosed principles can apply as well with respect to other wireless audio communication protocols, not limited to BLE with BAP.

[0040] More generally, it will be understood that the disclosed arrangements and processes are set forth for purposes of example only and may take various other forms. For instance, elements and operations can be re-ordered, distributed, replicated, combined, omitted, added, or otherwise modified. In addition, it will be understood that functions described herein as being carried out by one or more components can be implemented by and / or on behalf of those components, through hardware, firmware, and / or software, such as by one or more processing units executing program instructions or the like.

[0041] Referring to the drawings, as noted above, Figure l is a simplified illustration of an example scenario in which features of the present disclosure can be implemented. Without limitation, this example scenario involves three users, A, B, and C, each having a respective smartphone and each wearing a respective pair of earbuds. In particular, the figure depicts user A having a respective smartphone 100 and wearing a respective pair of earbuds 102, user B having a respective smartphone 104 and wearing a respective pair of earbuds 106, and user C having a respective smartphone 108 and wearing a respective pair of earbuds 110.

[0042] With the arrangement shown, each user’s earbuds may be wirelessly paired with the user’s smartphone, having an established Bluetooth connection such as an ACL link through which the earbuds and the smartphone can engage in control signaling with each other. For instance, each user may have engaged in a pairing process to pair the user’s earbuds with the user’ s smartphone, with the earbuds broadcasting an inquiry message requesting to connect, the smartphone discovering the inquiry message and sending an inquiry response, and the earbuds and smartphone then engaging in further signaling with each other to establish a secure ACL link through which they can exchange data such as control signaling with each other. As to a given pair of earbuds that may define a coordinated set of devices, one earbud of the pair may be an endpoint for this ACL link with the user’s smartphone.

[0043] This ACL link between a user’s smartphone and the user’s earbuds may facilitate setup and control of unicast audio transmission directly from the user’s smartphone (as an “initiator”) to the user’s earbuds (as an “acceptor” or coordinated set of acceptors). For instance, through this ACL link, the user’s smartphone and earbuds may work with each otherto agree on configuration of an audio codec and a physical layer structure for the unicast audio transmission, and specifically setup of one or more connected isochronous streams (CISs) that carry unicast audio transmission from the smartphone to the earbuds.

[0044] With BLE unicasting of audio by way of example, each CIS defines a physical layer timing structure for carrying the unicast audio data transmissions spaced by a constant time interval, or isochronous interval, and for carrying associated acknowledgement signaling from the acceptor to the initiator. In particular, for unicast audio, the initiator would divide the audio stream into a sequence of audio packets as noted above and, in each successive isochronous interval, would transmit to an access address of the acceptor a next one of the audio packets and then receive from the acceptor an acknowledgement message indicating whether the acceptor successfully received (e.g., successfully received and decoded) that audio packet.

[0045] Further, each CIS would be configured to support an acknowledgement and retransmission scheme for the unicast audio transmission. In particular, each isochronous interval of the CIS would be configured to define multiple sub-intervals, each for carrying a respective transmission attempt and an associated acknowledgement message. In an example unicast acknowledgement and retransmission scheme, (i) if the acceptor successfully receives a given audio packet, the acceptor sends a positive acknowledgement (ACK) to the initiator, after which the initiator may proceed to transmit a next audio packet to the acceptor, but (ii) if the acceptor fails to successfully receive a given audio packet, the acceptor may send a negative acknowledgement (NACK) to the initiator, and if the initiator receives a NACK or at least does not receive an ACK, the initiator may then responsively re-transmit the audio packet to the acceptor.

[0046] Thus, upon transmission of an audio packet in a given sub-interval of a given isochronous interval, if the initiator does not then receive in that sub-interval an ACK from the acceptor (e.g., if the initiator receives a NACK from the acceptor), the initiator can retransmit the audio packet in a next sub-interval of the isochronous interval, repeating this process for as many sub-intervals as the CIS configuration defines per isochronous interval, until achieving successful transmission, and then turning to transmission of a next audio packet in a next isochronous interval.

[0047] BLE also defines a connected isochronous group (CIG) construct that would be made up of one or more CISs to be unicast from an initiator to an acceptor (or to a coordinated set of acceptors), which supports unicasting of stereo or other multiple channelaudio, with one audio channel per CIS. With a pair of earbuds or other coordinated set of acceptors, for instance, the initiator may have a separate ACL link respectively with each acceptor and may use that ACL link to set up a respective CIS for unicasting audio to that acceptor. The multiple CISs of the CIG would have the same isochronous intervals as each other but would be shifted serially in time from each other, as the initiator’s transmissions on the two CISs would be time-division multiplexed with each other. For instance, the initiator may transmit a left channel audio packet, then receive an acknowledgement for that transmission, then transmit a right-channel audio packet, then receive an acknowledgement for that transmission, and so forth.

[0048] Further, to facilitate synchronized playback of unicast audio by multiple acceptors of a coordinated set, such as pair of earbuds, a CIG can have a defined synchronization point per isochronous interval, which is a common point in time by which every acceptor in the coordinated set would have had an opportunity to receive the audio packet destined to it in that interval. This synchronization point may be established by timing measurement conducted on the acceptors’ associated ACL links. Further, the CIG can have a presentation delay, as a time delay that all of the acceptors in the coordinated set should wait after the synchronization point before playing out their respectively received audio packet, allowing enough time for each acceptor to decode and play out the audio.

[0049] Aside from possibly supporting unicast audio transmission, the devices of the example implementation can support wireless audio broadcast service. For instance, one of the users’ smartphones can be configured to function as a wireless audio broadcast source, SRC, and each of the three users’ pairs of earbuds can be configured to function respectively as a wireless audio broadcast recipient, SNK. As shown next in Figure 2, for instance, user A’s smartphone 100 can be configured to operate as a SRC, and each user’s pair of earbuds 102, 106, 110 can be configured to operate as a SNK, to receive an audio stream broadcast 112 from user A’s smartphone 100 and to play out that audio in real time to its respective user.

[0050] With example wireless audio broadcast service, there is generally no ACL link between the SRC and a SNK, and so the SRC and SNK generally would not work with each other to configure audio transmission from the SRC. Rather, the SRC would simply broadcast configuration information about its audio broadcast, and the SRC would simply broadcast audio in accordance with that configuration. Any SNK within range of the SRC can then read the broadcast configuration information to discover presence of the SRC’s broadcast and can then receive and play the broadcast audio.

[0051] As noted above, BLE broadcasting of audio makes use of one or more broadcast isochronous streams (BISs) that carry broadcast audio transmission from the SRC for receipt and playout by any applicable SNKs.

[0052] These BISs can be similar in structure to the CIS arrangement described above. As with a CIS, a BIS is divided over time into isochronous intervals. However, unlike a CIS, there are no acknowledgements from the acceptor (SNK) to the initiator (SRC). Instead, to help ensure successful receipt of the audio packet transmitted in each isochronous interval, the BIS can be configured to include automatic retransmission of the audio packet in each isochronous interval. Namely, each BIS isochronous interval can be divided over time into subintervals, and the SRC can be configured to transmit the same audio packet repeatedly in a group of those sub-intervals. Further, the BIS can define particular time spacing between subintervals.

[0053] Also similar to the CIS arrangement, BLE audio defines a broadcast isochronous group (BIG) that can be made up of one or more BISs, such as one BIS respectively for each of multiple audio channels. With a BIG, each isochronous interval can contain separate sub-intervals for respective BISs. For instance, there can be multiple sub-intervals to carry respectively multiple transmissions of an audio packet of one channel, followed by multiple sub-intervals to carry respectively multiple transmissions of an audio packet of another channel. Or the sub-intervals of respective audio channels can be interleaved with each other over time in the isochronous interval. The BIG may also define spacing between these subintervals, at least in part to enable a receiving SNK to switch between BISs.

[0054] Further, to facilitate broadcast of control information from the SRC to any recipient SNKs without having the benefit of an ACL link, one of the BIS sub-intervals per isochronous interval can be used to carry broadcast control signaling. In particular, the BIG can define a BIG control sub-event for carrying a BIG control packet (e.g., containing a control PDU) from the SRC. The SRC can set a flag (e.g., a control sub-event transmission flag (CSTF) in a packet header) to indicate when such a control packet is present, so that any recipient SNKs can read that control packet.

[0055] BLE further defines a process for a SNK to discover the presence of a broadcast stream from a SRC and to determine how to receive and decode that broadcast stream. In particular, as noted above, the SRC can broadcast a hierarchical set of advertising messages that would ultimately carry BIG configuration information for a given audio broadcast from the SRC, and each applicable SNK can scan for and detect this advertising inorder to learn of the presence of an audio broadcast of interest and to then receive and play out that audio broadcast

[0056] More specifically, according to BLE, the SRC can periodically broadcast extended advertising (ADV_EXT) messages, auxiliary advertising (AUX ADV IND) messages, and periodic advertising (PA) messages. The ADV EXT messages can contain a pointer pointing to and thus allowing a SNK to find the AUX ADV IND messages. And the AUX ADV IND messages can include a universally unique identifier (UUID) of a broadcast audio announcement service and a pointer pointing to and thus allowing the SNK to find the PA messages. The PA messages (which the SRC may broadcast on the order of every 100 or 200 milliseconds (ms)) may then carry additional controller advertising information (ACAD) that includes BIG information (BIGInfo), which defines the BIG structure including one or more BISs, indicating the interval structure of the BIS, pointing to and thus allowing the SNK to find a next periodic BIS interval per BIS, and also includes broadcast audio stream endpoint (BASE) information defining details about each BIS in the BIG, such as codec configuration and metadata regarding the content in the audio stream.

[0057] As further noted above, considering that many SNKs are power sensitive and that the act of regularly scanning for these advertising messages can consume a lot of power, BLE also supports use of a broadcast assistant (AST) to help a SNK more efficiently detect presence of a broadcast stream. The AST can be defined as logic running in a device separate from the SNK. Further, in some cases, a SNK’s AST can be defined as logic running in the same device that functions as the SRC.

[0058] With the example arrangement of Figures 1 and 2, for instance, each user’s respective pair of earbuds can have a respective AST running as program logic in the user’s smartphone, or in another device. Thus, turning next to Figure 3, (i) user A’s smartphone 100 can run SRC logic 114 to function as a broadcast source as noted above and can also run AST logic 116 to function as an AST for user A’s earbuds 102, (ii) user B’s smartphone 104 can run AST logic 118 to function as an AST for user B’s earbuds 106, and (iii) user C’s smartphone 108 can run AST logic 120 to function as an AST for user C’s earbuds 110.

[0059] In this arrangement, each user’s respective earbuds can have an established ACL link with its associated AST in the user’s smartphone. For instance, to support broadcast audio service, the user’s earbuds can engage in pairing signaling with the user’s smartphone as described above to set up this ACL link between the user’s earbuds and the user’s smartphone and specifically between the user’s earbuds and the AST logic running in the user’ssmartphone. As with the discussion above regarding unicast audio transmission, one earbud of the pair of earbuds may be an endpoint for this ACL link with the user’s smartphone. (Further, in some possible implementations, a given AST may function as an AST for multiple SNKs.)

[0060] Thus, as shown in Figure 3, (i) there can be an established ACL link 122 as a SNK-AST connection between user A’s earbuds 102 and the AST logic 116 in user A’s smartphone 100, (ii) there can be an established ACL link 124 as a SNK-AST connection between user B’s earbuds 106 and the AST logic 118 running in user B’s smartphone 104, and (iii) there can be an established ACL link 126 as a SNK-AST connection between user C’s earbuds 110 and the AST logic 120 running in user C’s smartphone 108.

[0061] With the SNK-AST connection thereby established respectively for each user’s earbuds, the AST logic running in the user’s smartphone can work to assist the user’s earbuds as SNK with detecting the presence of a broadcast audio stream. For instance, through the ACL link, the user’s earbuds as SNK can engage in signaling with the associated AST to cause the user’s smartphone to scan for advertising messaging and to cause the AST to report back to the SNK when the smartphone detects applicable advertising from a SRC, e.g., advertising messaging that includes broadcast audio announcement service UUID. The AST can then cause the smartphone to engage in that scanning, and once the smartphone detects that advertising from a SRC, the AST can then report back to the SNK, providing the SNK with a pointer to the SRC’s PA messaging that carries the BIGInfo data for the audio broadcast. Given this pointer, the SNK can then conveniently find the PA messaging to get the BIGInfo data and can proceed to start receiving one or more BISs from the SRC.

[0062] To further facilitate this process, each user’s earbuds as SNK can expose its capabilities as Published Audio Capabilities Service (PACS) to the AST, which can allow the AST to determine if a detected audio broadcast is of interest to the SNK, and accordingly to control whether to inform the SNK of the broadcast. For instance, the user’s earbuds as SNK may be pre-provisioned with this capabilities data, which may indicate parameters such as information about audio codec and configurations that the earbuds support, as well as types of audio (e.g., audio contexts) that the earbuds support. Over the established ACL link between the earbuds and the AST, the earbuds can thus report this PACS to the AST. (For instance, the AST can request the PACS from the earbuds, and the earbuds can respond by transmitting the PACS to the AST.) Provided with this capability information of the user’s earbuds, the AST can then limit which detected audio broadcasts to tell the earbuds about.

[0063] As discussed above, the present disclosure provides a method that can leverage the existence of an AST beyond (or instead of) having the AST help a SNK to discover presence of broadcast streams. In particular, in an example implementation, the disclosure provides that, when a SNK is going to receive and play out an audio broadcast from a SRC, the SNK’s AST can inform the SRC of capability information of the SNK, so that the SRC can use that capability information as a basis to configure the SRC’s audio broadcast, possibly in a manner more efficient than it may otherwise be able to do. Moreover, the SRC can receive such capability information as to multiple SNKs that will be receiving and playing out the SRC’s audio broadcast, with the AST of each SNK respectively informing the SRC of that SNK’s capability information, and the SRC using the capability information of the multiple SNKs as a basis to configure the SRC’s audio broadcast.

[0064] To facilitate this in practice, each SNK’s respective AST can have an established ACL link or other such connection with the broadcasting SRC, as an AST-SRC connection for the SNK. For instance, when the AST discovers presence of an audio broadcast from a SRC and informs the SNK of this audio broadcast, the SNK may inform the AST that the SNK will receive and play out the discovered audio broadcast from the SRC. Knowing that the SNK will receive and play out the audio broadcast from the SRC, the AST may then engage in pairing signaling with the SRC to establish an ACL link as an AST-SRC connection for the SNK.

[0065] In the arrangement of Figure 3, where the SRC is in user A’ s smartphone and where each user’s smartphone also has a respective AST to assist the user’s earbuds as SNK, a reasonable approach would be to establish AST-SRC connections respectively between user B’s smartphone 104 and user A’s smartphone 100 and between user C’s smartphone 108 and user A’s smartphone 100.

[0066] For instance, when the AST 118 in user B’s smartphone 104 discovers and reports to user B’s earbuds 106 the presence of an audio broadcast from the SRC 114 in user A’s smartphone 100 and / or receives signaling from user B’s earbuds 106 indicating that user B’s earbuds 106 will receive and play out that audio broadcast, the AST 118 in user B’s smartphone 104 can responsively also cause user B’s smartphone 104 to engage in pairing signaling with user A’s smartphone 100 to establish an AST-SRC connection for user B’s earbuds 106. Likewise, when the AST 120 in user C’s smartphone 108 discovers and reports to user C’s earbuds 110 the presence of an audio broadcast from the SRC 114 in user A’s smartphone 100 and / or receives signaling from user C’s earbuds 110 indicating that user C’searbuds 110 will receive and play out that audio broadcast, the AST 120 in user C’s smartphone 108 can responsively also cause user C’s smartphone 108 to engage in pairing signaling with user A’s smartphone 100 to establish an AST-SRC connection for user C’s earbuds 110. Alternatively, in some scenarios, one or more of these ACL links may exist already.

[0067] As to an AST-SRC connection for user A’s earbuds 102, the process may be different, since the AST 116 and SRC 114 are both in user A’s smartphone 100. Rather than establishing an ACL link in that context, the AST 116 may engage in signaling with the SRC 114 internally within user A’s smartphone 100, or they may otherwise be configured to communicate with each other, thereby providing an AST-SRC connection.

[0068] Accordingly, turning next to Figure 4, in addition to the established SNK- AST connections 122, 124, 126 for each SNK as discussed above, there can also be established AST-SRC connections for each SNK. Namely, (i) there can be an established AST-SRC connection 128 between user B’s smartphone 104 and user A’s smartphone 100 (ii) there can be an established AST-SRC connection 130 between user C’s smartphone 108 and user A’s smartphone 100, and (iii) there can be an established AST-SRC connection 132 internally within user A’s smartphone 100.

[0069] Note also that, in some scenarios, it may not be possible to establish an ACL link between an AST and a SRC. For instance, in some public broadcast situations (e.g., at airports, train stations, or theaters), a broadcasting source device may not support establishing a connection with an end-user’s device. However, there may be many scenarios where establishing an AST-SRC link may indeed be possible and practical. For instance, in a scenario like that shown in Figure 4, such as where users A, B, and C wish to share audio broadcast from user A’s smartphone, and especially if all three users’ smartphones support this functionality, the smartphones may establish these AST-SRC connections.

[0070] Further, as indicated above, an alternative arrangement may involve establishing an ACL link directly between a SNK and a broadcast source, SRC, through which the SNK can more directly share its capability information with the SRC. However, as also noted above, this may not be as practical as using an AST for this purpose, especially in a situation where the SNK and AST would already have an established SNK -AST connection.

[0071] As noted above, providing a SRC with capability information of each of one or more SRCs that will receive and play out an audio broadcast from the SRC can enable the SRC to use the capability information in various ways as a basis to control configuration of the SRC’s audio broadcast.Configuring Use of Single BIS for Multiple Audio Channels

[0072] One technical improvement that this arrangement can facilitate is enabling the SRC to broadcast multiple audio channels in a single BIS rather than in separate BISs. For instance, with stereo audio, the technical improvement can be enabling the SRC to broadcast left and right audio channels in a single BIS rather than in separate BISs. This becomes possible by having the SRC learn whether each of the one or more SNKs that will receive and play out the SRC’s audio broadcast support audio broadcast with the multiple audio channels in a single BIS.

[0073] Under an example protocol, such as BLE with BAP for instance, broadcasting of stereo audio can be done with at least either of two defined audio configurations: (i) audio configuration 13 (AC13), according to which the SRC would transmit the left and right audio channels in separate but time-division-multiplexed BISs or (ii) audio configuration 14 (AC 14), according to which the SRC would transmit the left and right audio channels aggregated together in a single BIS.

[0074] In general, ACM would be more efficient than AC 13, since AC 14 would aggregate packet header information and include fewer sub-interval spacing delays. For instance, as noted above, each audio packet that the SRC broadcasts may include an associated header (e.g., 16-bits), so a stereo pair of left and right audio packets would have twice that amount of header data in total. With AC 14, the SRC can aggregate left and right audio data together in a packet with a single header, and this reduction in overhead information being transmitted may usefully increase speed of transmission and reduce the processing burden at both the transmitting and receiving ends. Further, if a BIG will encompass a single BIS rather than two separate BISs, the BIG will also have fewer sub-interval spacing delays, as there would be no delay from switching between BISs, which may also usefully increase the speed of transmission.

[0075] Unfortunately, operation under an example protocol involves the SRC broadcasting audio using AC 13 even if the SRC and the users’ earbuds all support using the more efficient AC14. This unfortunate result may occur if the example protocol makes support for AC13 mandatory but makes support for ACM optional. (An example protocol may take that approach in order to provide compatibility among a widest variety of manufacturers, for instance.) In that scenario, as the SRC would not know the capabilities of the SNKs that would be receiving its broadcast, the SRC would have no way to determine that all of the SNKssupport ACM. Therefore, the SRC would need to default to using AC13, on grounds that all of the SNKs would need to support at least that audio configuration.

[0076] A control connection respectively between each SNK’s AST and the SRC (or directly between each SNK and the SRC) can help resolve the above-mentioned limitations, in a scenario where the SRC and all of the SNKs support AC14. In particular, each SNK can inform its respective AST that the SNK supports AC 14, and the SNK’s AST can in turn inform the SRC that the SNK supports AC 14. (Alternatively, each SNK can more directly inform the SRC of this capability.) In this way, the SRC can learn that each of the one or more SNKs that will be receiving and playing out the SRC’s audio broadcast support AC 14, so the SRC can efficiently provide its audio broadcast using AC 14 rather than the less efficient AC 13. Similar principles can be applied when choosing between other broadcast audio configurations as well.

[0077] Phrased another way, each SNK’s AST (or each SNK itself) may report to the SRC what broadcast audio configuration(s) the SNK supports, to enable the SRC to select and use the most efficient audio configuration that all of the reporting SNKs support. For instance, the SRC may thus determine, based on these reports of SNK audio-configuration capabilities, whether all of the SNKs that will receive the SRC’s audio broadcast support a particular audio configuration. If so, then the SRC may then conduct its audio broadcast using that particular audio configuration. Whereas, if not, then the SRC may instead conduct its audio broadcast using a different audio configuration, such as a default and possibly less efficient audio configuration.

[0078] In an example implementation, once the SRC determines what audio configuration it will use for its audio broadcast (e.g., whether to use AC14 or rather AC13), the SRC broadcasts control signaling indicating this determined audio configuration, and each recipient SNK receives and reads the control signaling and responsively sets itself to operate accordingly. For instance, the SRC may structure the BIGInfo data in its PA messaging to specify the determined audio configuration. If the timing works out, each SNK may therefore read that BIGInfo data and thereby determine which audio configuration the SRC’s broadcast will use, and each SNK may therefore set itself to operate accordingly (e.g., to receive and process multiple BISs or rather to receive and process just a single BIS). Alternatively or additionally, the SRC may specify the determined audio configuration within a BIG control packet that the SRC sends in an isochronous interval as discussed above, and each SNK may read that BIG control packet to learn the audio configuration and similarly set itself to operate accordingly.

[0079] With the example scenario illustrated in Figure 4, for instance, the SRC 114 in user A’s smartphone 100 may thereby learn whether user each users’ earbuds 102, 106, 110 supports AC14 and may use that information as a basis to control whether to configure its audio broadcast to use AC 14 or rather the default AC13.

[0080] For instance, user A’s earbuds 102 may use the SNK-AST control connection 122 with the AST 116 in user A’s smartphone 100 to report to the AST 116 in user A’s smartphone 100 that user A’s earbuds 102 support AC 14, and the AST 116 in user A’s smartphone 100 may in turn use the AST-SRC control connection 126 with the SRC 114 in user A’s smartphone 100 to report to the SRC 114 in user A’s smartphone 100 that user A’s earbuds 102 support AC14. Likewise, user B’s earbuds 106 may use the SNK-AST control connection 124 with the AST 118 in user B’s smartphone 104 to report to the AST 118 in user B’s smartphone 104 that user B’s earbuds 106 support AC14, and the AST 118 in user B’s smartphone 104 may in turn use the AST-SRC control connection 128 with the SRC 114 in user A’s smartphone 100 to report to the SRC 114 in user A’s smartphone 100 that user B’s earbuds 106 support ACM. And likewise, user C’s earbuds 110 may use the SNK-AST control connection 126 with the AST 120 in user C’s smartphone 108 to report to the AST 120 in user C’s smartphone 108 that user C’s earbuds 110 support ACM, and the AST 120 in user C’s smartphone 108 may in turn use the AST-SRC control connection 130 with the SRC 114 in user A’s smartphone 100 to report to the SRC 114 in user A’s smartphone 100 that user C’s earbuds 106 support ACM.

[0081] Assuming that the SRC 114 in user A’s smartphone 100 also supports ACM, the SRC 114 in user A’s smartphone 100 may then configure its audio broadcast to occur using ACM on grounds that it and each of the SNKs that will be receiving its audio broadcast support ACM, rather than defaulting to use the less efficient ACM.Configuring Number of Repeat Transmissions Per Audio Packet

[0082] Another technical improvement that the present control arrangement can facilitate is enabling the SRC to dynamically configure the number of times the SRC will transmit each audio packet that the SRC broadcasts. In particular, in an example implementation, the SRC takes into account an extent to which each of the one or more recipient SNKs supports and may therefore apply an intra-SNK relay function, using thatinformation as a basis for the SRC to configure how many times the SRC will automatically transmit each audio packet that the SRC broadcasts.

[0083] This technical advance can be illustrated in a scenario where each of the one or more receiving SNK devices is a respective pair of earbuds, although the principles can be applied in other scenarios as well, such as with a pair of speakers, among other possibilities.

[0084] In the example scenario, each pair of earbuds may optionally support a relay function (as an example of an intra-SNK relay function) that helps the earbuds of the pair successfully receive and play out broadcast audio when one of the earbuds has poor receive quality from the SRC. According to the relay function, each earbud in the pair may be configured to receive the SRC’s broadcast of both the left and right audio channels, and, through a defined communication channel with each other, the earbuds may engage in signaling with each other to supply missing data when one of the earbuds fails to successfully receive an expected audio packet. In particular, if one earbud fails to successfully receive a given audio packet of its respective audio channel, that earbud may inform the other earbud of the failure, and the other earbud may respond by providing the reporting earbud with the missing audio packet. Variations of this relay arrangement may be possible as well.

[0085] In addition, according to an example protocol as noted above, when an SRC broadcasts a sequence of audio packets, the SRC may be configured to automatically transmit each audio packet multiple times, to help ensure successful receipt of the audio packet. In practice, the BIGInfo that the SRC broadcasts as part of its PA messaging can indicate the number of times that the SRC will transmit each audio packet per BIS, such as by specifying a number of sub-events (NSE) and other associated information. The SRC can then automatically transmit each audio packet the indicated number of times, and, according to the BIGInfo, each recipient SNK can configure itself to expect that number of transmissions per audio packet. This repeat transmission of each packet may help account for the possibility that a recipient SNK has poor receive quality at the moment of one of the transmissions and has improved receive quality at the moment of another one of the transmissions.

[0086] (With unicast audio transmission as noted above, the transmitting device and receiving device may apply an acknowledgement and retransmission scheme in which the receiving device would send an ACK or NACK for each transmission attempt from the transmitting device, and the transmitting device would retransmit an audio packet if it receive a NACK or does not receive an ACK, the transmitting device would retransmit the audio packet. With example broadcasting of audio, this acknowledgement scheme does not exist, sothe broadcasting SRC instead just automatically transmits each audio packet a set number of times to help ensure successful receipt by each recipient SNK.)

[0087] With a pair of earbuds, there may be times when one earbud has good broadcast-receive quality and the other earbud has poor broadcast-receive quality. This difference in receive quality may result from a difference in positions of the two earbuds in relation to the position of the SRC. However, if the pair of earbuds supports the relay function noted above, the earbuds may make use of that relay function to help increase the likelihood that they will successfully receive transmitted audio.

[0088] In theory, this increase in likelihood of the earbuds successfully receiving transmitted audio based on the earbuds using the relay function may justify the SRC engaging in a reduced number of automatic transmissions of each audio packet. For instance, if the SRC would normally transmit each audio packet four times to help ensure successful receipt, it may be reasonable for the SRC to transmit each audio packet just two or three times instead if the earbuds will use the relay function, since the relay function may itself help increase likelihood of successful receipt.

[0089] Unfortunately, if the SRC does not know whether each of the one or more SNKs that will be receiving and playing out the SRC’s audio broadcast supports the relay function, this rationale may not apply. Namely, if at least one of the one or more SNKs that would be receiving and playing out the SRC’s audio broadcast does not support the relay function, then it may be reasonable for the SRC to still automatically transmit each audio packet a number of times that may help ensure successful receipt by any potential recipient SNK.

[0090] A control connection respectively between each SNK’s AST and the SRC (or directly between each SNK and the SRC) can help improve operation. In particular, each SNK can inform its respective AST that the SNK supports the relay function, and the SNK’s AST can in turn inform the SRC that the SNK supports the relay function. (Alternatively, each SNK can directly inform the SRC of this capability.) In this way, the SRC can learn whether each of the one or more SNKs that will be receiving and playing out the SRC’s audio broadcast supports the relay function, and the SRC can accordingly set how many times the SRC will automatically transmit each audio packet of the audio broadcast.

[0091] For instance, if the SRC thereby determines that each of the one or more SNKs that will be receiving the SRC’s audio broadcast supports the relay function, then the SRC can set its number of automatic transmissions of each audio packet to a first number (e.g., two or three). Whereas, if the SRC thereby determines that at least one of the one or moreSNKs that will be receiving the SRC’s audio broadcast does not support the relay function, then the SRC can set its number of automatic transmissions of each audio packet to be a second number higher than the first number (e.g., four or five).

[0092] In practice, the SRC may thereby dynamically set the number of its transmissions of each audio packet, based on consideration of whether each of the one or more SNKs that will be receiving and playing out the SRC’s audio broadcast supports the relay function. (Alternatively, the SRC may base this setting on what portion of the recipient SNKs supports the relay function, possibly setting the number of its automatic transmissions of each audio packet to a greater number in response to determining that fewer of the recipient SNKs support the relay function, and setting the number of its automatic transmissions of each audio packet to a lesser number in response to determining that more of the recipient SNKs support the relay function.)

[0093] Once the SRC thereby decides how many times it will broadcast each audio packet, the SRC can set itself to operate accordingly. Further, the SRC can broadcast control signaling indicating the determined number of per-packet transmissions, so that each recipient SNK can receive and read the control signaling and responsively set itself to operate accordingly as well. For instance, the SRC may structure the BIGInfo data in its PA messaging to indicate the determined number of per-packet transmissions, such as by setting the NSE value and / or other parameters accordingly. Alternatively or additionally, the SRC may specify the determined number of per-packet transmissions within a BIG control packet that the SRC sends in an isochronous interval as discussed above, and each SNK may read that BIG control packet to learn the number of per-packet transmissions and similarly set itself to operate accordingly.

[0094] This process may thus enable the SRC to reduce its number of automatic transmissions of each audio packet, in a scenario where each of the one or more recipient SNKs supports the relay function. Further, this reduction in number of automatic transmissions may help to speed up audio transmission by reducing the number of sub-intervals per isochronous interval and may also help to improve air-interface efficiency by freeing up time segments that would otherwise be used for more retransmissions.

[0095] Applying this process with the example scenario illustrated in Figure 4, for instance, the SRC 114 in user A’s smartphone 100 may learn whether user each users’ earbuds 102, 106, 110 supports the relay function and may use that information as a basis to control how many times the SRC will transmit each audio packet of its broadcast audio stream.

[0096] For instance, user A’s earbuds 102 may use the SNK-AST control connection 122 with the AST 116 in user A’s smartphone 100 to report to the AST 116 in user A’s smartphone 100 whether user A’s earbuds 102 support the relay function, and the AST 116 in user A’s smartphone 100 may in turn use the AST-SRC control connection 126 with the SRC 114 in user A’s smartphone 100 to report to the SRC 114 in user A’s smartphone 100 whether user A’s earbuds 102 support the relay function. Likewise, user B’s earbuds 106 may use the SNK-AST control connection 124 with the AST 118 in user B’s smartphone 104 to report to the AST 118 in user B’s smartphone 104 whether user B’s earbuds 106 support the relay function, and the AST 118 in user B’s smartphone 104 may in turn use the AST-SRC control connection 128 with the SRC 114 in user A’s smartphone 100 to report to the SRC 114 in user A’s smartphone 100 whether user B’s earbuds 106 support the relay function. And likewise, user C’s earbuds 110 may use the SNK-AST control connection 126 with the AST 120 in user C’s smartphone 108 to report to the AST 120 in user C’s smartphone 108 whether user C’s earbuds 110 support the relay function, and the AST 120 in user C’s smartphone 108 may in turn use the AST-SRC control connection 130 with the SRC 114 in user A’s smartphone 100 to report to the SRC 114 in user A’s smartphone 100 whether user C’s earbuds 106 support the relay function.

[0097] If through these or other such reports, the SRC 114 thereby learns that all three devices 102, 106, 110 that will be receiving the SRC’s audio broadcast support the relay function (perhaps assuming that each device will thus apply the relay function), then the SRC 114 may configure itself to broadcast each audio packet of its audio broadcast a first number of times. Whereas, if the SRC 114 thereby learns that at least one of the devices 102, 106, 110 that will be receiving the SRC’s audio broadcast does not support the relay function, then the SRC 114 may configure itself to broadcast each audio packet of its audio broadcast a second number of times that is greater than the first number of times.Configuring of Presentation Delay for Audio Broadcast

[0098] Another technical improvement that the present control arrangement can facilitate is enabling the SRC to take into account the audio-processing duration of each of the one or more recipient SNKs, as a basis for the SRC to configure timing for playout of the broadcast audio by each SNK.

[0099] This technical advance can also be illustrated in a scenario where each of the one or more receiving SNK devices is a respective pair of earbuds, although the principles herecan also be applied in other scenarios as well, such as with a pair of speakers, among other possibilities. In a system where audio is transmitted (unicast or broadcast) to left and right earbuds as a sequence of pairs of left and right audio packets, it may be important to ensure that the left and right audio of each pair gets rendered at exactly the same time as each other. This timing may be important, as even a slight difference in rendering time of left and right audio may cause the listener to experience an uncomfortable sensation of the audio source moving.

[0100] At least two factors can contribute to this rendering time: the transport duration and the processing duration. The transport duration of an audio packet defines how long it takes from initial transmission of the audio packet by the audio source to successful receipt of the audio packet to be decoded by the receiving device such as a given earbud. (This transport duration may in some cases encompass multiple retransmissions of the audio packet). The processing duration may then define how long it takes the receiving device to decode the received audio packet, apply any other processing such as active noise cancellation, and output the audio (e.g., start to output the audio) to be heard by the listener.

[0101] For a matching pair of earbuds made by a given manufacturer, both earbuds may have the same processing duration as each other. But if earbuds of a pair are of different versions or made by different manufacturers, they may have different processing duration than each other. Likewise, a pair of earbuds of one version and / or made by one manufacturer may have a different processing duration than a pair of earbuds of another version and / or made by another manufacturer.

[0102] As noted above, to facilitate synchronized rendering of left and right audio under an example protocol, the left and right devices can be made to play out their respective channels of audio upon expiration of a defined presentation delay after a defined synchronization point. In particular, the left and right devices can be configured to apply a common synchronization time point that defines an end of a maximum expected transport duration by which the left and right devices would be expected to have received their respective left and right audio packets. Further, under an example protocol, the audio source may also specify a presentation delay as a period of time sufficient to encompass the processing durations of the left and right devices.

[0103] For unicasting of audio to a pair of earbuds, an audio source may learn from the earbuds what their respective processing durations are and may then set a presentation delay that will work well for both earbuds. For instance, based on processing duration, each earbudmay store a specification its minimum presentation delay and (to account for buffering) its maximum presentation delay, and when setting up the unicast audio communication, each earbud may inform the audio source what the earbud’s minimum presentation delay and maximum presentation delay are. The audio source may then determine a presentation delay that is greater than the highest of the earbuds’ minimum presentation delays and less than the lowest of the earbuds’ maximum presentation delays and may direct both earbuds to apply that determined presentation delay.

[0104] With example broadcasting of audio, in contrast to unicasting of audio, this would not be possible - since there would be no control link between the earbuds and the broadcast SRC, so the earbuds cannot and would not convey their processing durations to the SRC. Therefore, for broadcasting of audio, the SRC would instead simply designate a default presentation delay that would likely work for any possible recipient SNK. For instance, the SRC may specify this presentation delay as a parameter in the BASE data that the SRC includes in its PA messaging, so that each SNK that will receive and play out the SRC’s broadcast audio stream can read that specified presentation delay and can then configure itself to apply the specified presentation delay when playing out the audio broadcast.

[0105] Under an example protocol, this default presentation delay may be 40 ms, as 40 ms is generally assumed to be long enough to encompass the processing delay of most or all recipient SNKs. Thus, for broadcasting of audio, the default delay from the synchronization point until the time of rendering for each of the one or more SNKs that would receive and play out the broadcasted audio may be 40 ms.

[0106] Unfortunately, there may be some use cases where applying such a default presentation delay would be inefficient. Some SNK devices, such as some newer and / or premium pairs of earbuds, may have far shorter processing durations. Forbroadcasting of audio to devices that have shorter processing durations, it would be inefficient to apply a relatively long presentation delay such as 40 ms, as the presentation delay would delay rendering of each audio packet for longer than necessary. Furthermore, gaming, dynamic spatial audio, and other audio applications may benefit from low latency.

[0107] A control connection respectively between each SNK’s AST and the SRC (or directly between each SNK and the SRC) (e.g., where each SNK is a pair of earbuds or an individual earbud of a pair) can help improve operation. In particular, each SNK can inform its respective AST what the SNK’s processing duration is, and the SNK’s AST can in turn inform the SRC what the SNK’s processing duration is. For instance, each SNK can inform its ASTwhat the SNK’s minimum and maximum presentation delays are, and the SNK’s AST can in turn inform the SRC what the SNK’s minimum and maximum presentation delays are. (Alternatively, each SNK can directly inform the SRC of this information.)

[0108] In this way, the SRC can select a presentation delay that would be supported by each of the one or more SNKs that will be receiving and rendering the audio broadcast from the SRC. In particular, the SRC can select a presentation delay that is no longer than necessary to work with each of the SNKs that will be receiving and rendering the SRC’s audio broadcast, and the SRC can configure the audio broadcast to designate use of the selected presentation delay. This process can thus usefully facilitate faster playout of audio in a broadcast context.

[0109] Once the SRC determines what presentation delay to configure for its audio broadcast, the SRC can then broadcast control signaling that indicates this determined presentation delay, so that each recipient SNK can receive and read the control signaling and responsively set itself to operate accordingly. For instance, the SRC may update the presentation-delay indication in the BASE data of the SRC’s PA messaging, and each recipient SNK may read this new presentation-delay value from the updated PA messaging broadcast by the SRC and accordingly configure itself to apply the indicated presentation delay. Alternatively or additionally, the SRC may specify the determined presentation delay within a BIG control packet that the SRC sends in an isochronous interval as discussed above, and each SNK may read that BIG control packet to learn the presentation delay and similarly set itself to operate accordingly.

[0110] With the example scenario illustrated in Figure 4, for instance, the SRC 114 in user A’s smartphone 100 may thereby learn the supported presentation delays of each users’ earbuds 102, 106, 110 and may use that information as a basis to control what presentation delay to configure for the SRC’s audio broadcast.

[0111] For instance, user A’s earbuds 102 may use the SNK- AST control connection 122 with the AST 116 in user A’s smartphone 100 to the AST 116 in user A’s smartphone 100 the minimum and maximum presentation delays of user A’s earbuds 102, and the AST 116 in user A’s smartphone 100 may in turn use the AST-SRC control connection 126 with the SRC 114 in user A’s smartphone 100 to report to the SRC 114 in user A’s smartphone 100 the minimum and maximum presentation delays of user A’s earbuds 102. Likewise, user B’s earbuds 106 may use the SNK-AST control connection 124 with the AST 118 in user B’s smartphone 104 to report to the AST 118 in user B’s smartphone 104 the minimum and maximum presentation delays of user B’s earbuds 106, and the AST 118 in user B’ssmartphone 104 may in turn use the AST-SRC control connection 128 with the SRC 114 in user A’s smartphone 100 to report to the SRC 114 in user A’s smartphone 100 the minimum and maximum presentation delays of user B’s earbuds 106. And likewise, user C’s earbuds 110 may use the SNK-AST control connection 126 with the AST 120 in user C’s smartphone 108 to report to the AST 120 in user C’s smartphone 108 the minimum and maximum presentation delays of user C’s earbuds 110, and the AST 120 in user C’s smartphone 108 may in turn use the AST-SRC control connection 130 with the SRC 114 in user A’s smartphone 100 to report to the SRC 114 in user A’s smartphone 100 the minimum and maximum presentation delays of user C’s earbuds 106 support AC 14.

[0112] Given these reports of the presentation delays respectively of each of the pairs of earbuds 102, 106, 110 that will receive the audio broadcast from the SRC 114 in user A’s smartphone 100, the SRC 114 in user A’s smartphone can then usefully configure for its audio broadcast a presentation delay that will be no longer than necessary to accommodate operation of those three SNKs that will be receiving its audio broadcast. For instance, the SRC 114 can configure this presentation delay through updated BASE data and / or in a BIG control packet as noted above. Each pair of earbuds 102, 106, 110 may then read that new presentationdelay value and accordingly configure itself to apply the indicated presentation delay. In particular, within each pair of earbuds, each earbud of the pair may accordingly configure itself, so that the earbuds of the pair would use the indicated presentation delay to help facilitate their playout of their respective channels of audio at the same time as each other.

[0113] This process may also work with other reports that indicate supported presentation delay, to facilitate configuration of an audio broadcast. For instance, each pair of earbuds may report their processing durations rather than their presentation delays, and the SRC may use those processing durations as a basis to configure an appropriate presentation delay. Further, each pair of earbuds may report just one representative presentation delay or just one representative processing duration rather than reporting both minimum and maximum presentation delays. Other examples may be possible as well.Example Process Flow

[0114] Figure 5 is a flow chart illustrating an example method that can be carried out in accordance with the present disclosure to help control processing of audio broadcast from a device. As shown in Figure 5, at block 500, the example method includes receiving into the device, respectively for each broadcast sink, SNK, of a plurality of SNKs that will wirelessly receive and play out the audio broadcast from the device, capability informationdefining one or more capabilities of the SNK. At block 502, the example method then includes the device using the received capability information of the plurality of SNKs as a basis to configure the audio broadcast from the device.

[0115] Figure 6 is next a flow chart illustrating more specifically an example method that can be carried out in accordance with the present disclosure to help control processing of audio broadcast from a device, where the audio broadcast will be received and played out by each of a plurality of broadcast sinks, SNKs. This example method assumes that each SNK has a respective control connection with a respective broadcast assistant, AST, as a SNK-AST control connection of the SNK, that the device functions as at least a broadcast source, SRC, and that each SNK’s AST has a respective control connection with the SRC, as an AST-SRC control connection of the SNK. Alternatively, the method may involve establishing of these control connections.

[0116] As shown in Figure 6, at block 600, the example method includes receiving into the device, respectively for each SNK of the plurality of SNKs that will wirelessly receive and play out the audio broadcast from the device, capability information defining one or more capabilities of the SNK, with the receiving of this capability information respectively for each SNK involving receiving into the SRC the SNK’s capability information reported from the SNK to the SNK’s AST over the SNK’s SNK-AST control connection and in turn from the SNK’s AST to the device over the SNK’s AST-SRC control connection. And at block 602, the example method includes the example method then includes the device using the received capability information of the plurality of SNKs as a basis to configure the audio broadcast from the device.

[0117] In these example methods, as discussed above, at least one SNK of the plurality of SNKs can be a pair of earbuds, and the device can be a smartphone, among other possibilities. Further, in line with the discussion above, the act of the device receiving the capability information of the plurality of SNKs can take various forms, and the act of the device using the received capability information of the plurality of SNKs as a basis to configure the audio broadcast from the device can take various forms.

[0118] For example, the act of receiving into the device the capability information respectively for each SNK of the plurality of SNKs that will wirelessly receive and play out the audio broadcast from the device can involve receiving into the device, respectively for each SNK, a report of whether the SNK supports receiving audio broadcast with multiple audio channels aggregated into a single BIS, and the act of the device using the received capabilityinformation of the plurality of SNKs as a basis to configure the audio broadcast from the device can involve using the received capability information as a basis to control whether the device will configure its audio broadcast to include multiple audio channels in a single BIS.

[0119] More particularly, with this example, the device can determine, based on the received reports, whether all of the plurality of SNKs support receiving audio broadcast with multiple audio channels aggregated into a single BIS. If the device thereby determines that all of the plurality of SNKs support receiving audio broadcast with multiple audio channels aggregated into a single BIS, then, based at least on that determination, the device can configure the audio broadcast from the device to provide multiple audio channels aggregated into a single BIS. Whereas, if the device determines that any of the SNKs of the plurality of SNKs does not support receiving audio broadcast with multiple audio channels aggregated into a single BIS, then, based at least on that determination, the device configure the audio broadcast from then device to provide multiple audio channels in separate respective BISs. Further, one of these options can be a default operation, and the device can responsively configure the other option in response to the indicated determination.

[0120] In another example, the act of receiving into the device the capability information respectively for each SNK of the plurality of SNKs that will wirelessly receive and play out the audio broadcast from the device can involve receiving into the device, respectively for each SNK, a report of whether the SNK supports intra-SNK relaying of broadcast audio, and the act of the device using the received capability information of the plurality of SNKs as a basis to configure the audio broadcast from the device can involve the device using the received capability information as a basis to control how many times the device will broadcast each audio packet of a series of audio packets of its audio broadcast.

[0121] More particularly, with this example, the device can determine, based on the received reports, whether all of the plurality of SNKs support intra-SNK relaying of broadcast audio. If the device thereby determines that all of the plurality of SNKs support intra-SNK relaying of broadcast audio, then, based at least on that determination, the device can configure the audio broadcast from the device to provide a first quantity of automatic transmissions respectively of each of a series of audio packets. Whereas, if the device determines that any of the SNKs of the plurality of SNKs does not support intra-SNK relaying of broadcast audio, then, based at least on that determination, the device can configure the audio broadcast from the device to provide a second quantity of automatic transmissions respectively of each of the series of audio packets, the second quantity being higher than the first quantity. Here too, oneof these options can be a default operation, and the device can responsively configure the other option in response to the indicated determination.

[0122] Still further, in another example, the act of receiving into the device the capability information respectively for each SNK of the plurality of SNKs that will wirelessly receive and play out the audio broadcast from the device can receive into the device, respectively for each SNK, a report of audio-processing duration of the SNK, and the act of the device using the received capability information of the plurality of SNKs as a basis to configure the audio broadcast from the device can involve the device using the received capability information as a basis to configure a presentation delay for its audio broadcast. Here, receiving the reported processing durations can be done by receiving supported presentation delays that are based on processing duration, which can effectively indicate or otherwise suggest processing duration.

[0123] More particularly, with this example, the device can establish an audiobroadcast presentation delay based on the reported processing durations, i.e., based on the SNKs’ supported presentation delays. For instance, the device can establish as the presentation delay a presentation delay that is no longer than a maximum presentation delay of the SNKs and no shorter than a minimum presentation delay of the SNKs. The device can then configure the audio broadcast from the device to have the established audio-broadcast presentation delay.

[0124] Note also that the act of controlling processing of audio broadcast from the device as described herein can involve controlling processing that occurs at the device, which may involve changing a configuration of how the device engages in the audio broadcast. Alternatively or additionally, the act of controlling processing of audio broadcast as described herein can involve controlling processing that occurs at one or more other entities such as one or more SNKs, which may involve setting one or more audio broadcast configurations in a manner that will cause the one or more other entities to control how they process receipt of the audio broadcast, among other possibilities.

[0125] Figure 7 is another flow chart illustrating an example method that can be carried out in accordance with the present disclosure to help control processing of audio broadcast from a device. As shown in Figure 7, at block 700, the example method includes receiving into the device, respectively for each SNK of a plurality of SNKs that will wirelessly receive and play out the audio broadcast from the device, capability information indicating one or more capabilities of the SNK. At block 702, the example method includes the device configuring the audio broadcast based on the received capability information of the pluralityof SNKs. And at block 704, the example method includes the device broadcasting the audio broadcast configured based on the received capability information of the plurality of SNKs.

[0126] In some example implementations, the device functions as an SRC, and the act of receiving into the device the capability information for each SNK involves the device receiving at least one SNK’s capability information reported from a respective AST of the SNK over a respective AST-SRC control connection of the SNK.

[0127] Further, in some implementations, the act of the receiving into the device the capability information respectively for each SNK of the plurality of SNKs that will wirelessly receive and play out the audio broadcast from the device involves receiving into the device, respectively for each SNK, a report of whether the SNK supports receiving audio broadcast with multiple audio channels aggregated into a single BIS.

[0128] The act of the device configuring the audio broadcast based on the received capability information of the plurality of SNKs may then involve (a) the device determining, based on the received reports, whether all of the plurality of SNKs support receiving audio broadcast with multiple audio channels aggregated into a single BIS, (b) if the device determines that all of the plurality of SNKs support receiving audio broadcast with multiple audio channels aggregated into a single BIS, then the device configuring the audio broadcast from the device to provide multiple audio channels aggregated into a single BIS, and (c) if the device determines that any of the SNKs of the plurality of SNKs does not support receiving audio broadcast with multiple audio channels aggregated into a single BIS, then the device configuring the audio broadcast from the device to provide multiple audio channels in separate respective BISs.

[0129] Alternatively or additionally, in some implementations, the act of the receiving into the device the capability information respectively for each SNK of the plurality of SNKs that will wirelessly receive and play out the audio broadcast from the device involves receiving into the device, respectively for each SNK, a report of whether the SNK supports intra-SNK relaying of broadcast audio.

[0130] The act of the device configuring the audio broadcast based on the received capability information of the plurality of SNKs may then involve (a) the device determining, based on the received reports, whether all of the plurality of SNKs support intra-SNK relaying of broadcast audio, (b) if the device determines that all of the plurality of SNKs support intra- SNK relaying of broadcast audio, then the device configuring the audio broadcast from the device to provide a first quantity of automatic transmissions respectively of each of a series ofaudio packets, and (c) if the device determines that any of the SNKs of the plurality of SNKs does not support intra-SNK relaying of broadcast audio, then the device configuring the audio broadcast from the device to provide a second quantity of automatic transmissions respectively of each of the series of audio packets, the second quantity being higher than the first quantity.

[0131] Still alternatively or additionally, in some implementations, the act of receiving into the device the capability information respectively for each SNK of the plurality of SNKs that will wirelessly receive and play out the audio broadcast from the device involves receiving into the device, respectively for each SNK, a report of audio-processing duration of the SNK.

[0132] The act of the device configuring the audio broadcast based on the received capability information of the plurality of SNKs may then involve (a) the device establishing an audio-broadcast presentation delay based on the reported processing durations of the plurality of SNKs and (b) the device configuring the audio broadcast from the SRC to have the established audio-broadcast presentation delay.

[0133] In some example implementations as discussed above, the device could comprise a smartphone. Further, the SNKs could comprise earbuds.Example Device Architecture

[0134] Figure 8 is a simplified block diagram illustrating components of an example device, such as but not limited to a smartphone for instance, that may be configured to carry out various features discussed herein, such as the features discussed above in connection with Figures 5, 6, and 7.

[0135] As shown in Figure 8, the example device includes a wireless communication interface 800, a processor 802 and non-transitory data storage 804. These components can be integrated together and / or communicatively linked together in various ways. For instance, the components can be linked together through a system bus, network, or other connection mechanism 806. Alternatively, various integrations and other arrangements are possible.

[0136] The wireless communication interface 800 can support wireless communication between the device and one or more other devices, such as to support providing an audio broadcast from the device for receipt by one or more SNKs, and to support control signaling with each of one or more ASTs serving respective SNKs.

[0137] As such, the wireless communication interface 800 can comprise one or more modules (e.g., one or more chipsets) supporting wireless communication according to a suitable wireless audio broadcast communication protocol. Without limitation, the communicationprotocol can be Bluetooth, including BLE with BAP as discussed above, so the wireless communication interface 800 can comprise a chipset configured to support Bluetooth communication and particularly BLE communication with BAP. Though other examples are possible as well. As shown, the wireless communication interface 800 can include a radio 808 configured to encode and modulate outgoing data communications for air-interface transmission and to demodulate and decode incoming data communications as well as an antenna structure 810 supporting air interface transmission and reception, among other components.

[0138] The processor 802, which may be a processor of the wireless communication interface 800 and / or a host processor or other processor of the device, can comprise one or more general purpose processors (e.g., one or more microprocessors, etc.) and / or one or more special-purpose processors (e.g., digital signal processors, application-specific integrated circuits, etc.) Further, the non-transitory data storage 804 can comprise one or more volatile and / or non-volatile storage components (e.g., optical, magnetic, or flash storage, RAM, ROM, EPROM, EEPROM, cache memory, and / or other computer-readable media, etc.), possibly integrated in whole or in part with the processor 802.

[0139] As shown, the non-transitory data storage 804 may then store program instructions 812, which may be executable by the processor 802 to carry out various operations described herein. In accordance with the examples above, for instance, these program instructions may define SRC logic, so that the processor 802 executing these instructions can cause the device to carry out various SRC operations described herein. Further, the program instructions may define AST logic, so that the processor 802 executing these instructions can cause the device to carry out various AST operations described herein. The program instructions 812 may thus be executable by the processor 802 of the device to carry out the methods described with respect to the flow charts of Figures 5-7, among other possibilities.

[0140] Accordingly, for instance, the present disclosure includes subject matter of a device comprising a wireless communication interface through which to provide an audio broadcast from the device, a processor, non-transitory data storage, and program instructions stored in the non-transitory data storage and executable by the processor to cause the device to carry out a method to control processing of audio broadcast from the device, the method including (i) receiving into the device, respectively for each SNK of a plurality of SNKs that will wirelessly receive and play out the audio broadcast from the device, capability information indicating one or more capabilities of the SNK, (ii) configuring by the device, the audiobroadcast based on the received capability information of the plurality of SNKs, and (iii) broadcasting by the device, the audio broadcast configured based on the received capability information of the plurality of SNKs. Further, other method features discussed above can be applied in this context as well.

[0141] Figure 9 is next a simplified block diagram illustrating components of an example SNK that may be configured to carry out various SNK operations described herein. As to a pair of earbuds, for instance, this block diagram may represent components of a given earbud of the pair, among other possibilities.

[0142] As shown in Figure 9, the example SNK includes a wireless communication interface 900, an audio-presentation interface 902, a processor 904, and non-transitory data storage 906. These components can be integrated together and / or communicatively linked together in various ways. For instance, the components can be linked together through a system bus, network, or other connection mechanism 908. Alternatively, various integrations and other arrangements are possible.

[0143] The wireless communication interface 900 can comprise one or more modules (e.g., one or more chipsets) supporting wireless communication between the SNK and one or more other devices, such as to support receiving an audio broadcast from a SRC and to support control signaling with an AST. Further, the wireless communication interface can support measuring per-channel quality of each of various channels available for use in adaptive channel hopping.

[0144] As such, the wireless communication interface 900 can comprise one or more modules (e.g., one or more chipsets) supporting wireless communication according to a suitable wireless audio broadcast communication protocol. Without limitation, the communication protocol can be Bluetooth, including BLE with BAP as discussed above, so the wireless communication interface 900 can comprise a chipset configured to support Bluetooth communication and particularly BLE communication with BAP. Though other examples are possible as well. As shown, the wireless communication interface 900 can include a radio 910 configured to encode and modulate outgoing data communications for air-interface transmission and to demodulate and decode incoming data communications as well as an antenna structure 912 supporting air interface transmission and reception, among other components.

[0145] The audio-presentation interface 902 can comprise one or more modules configured to provide acoustic sound output, such as to play a stream of audio being receivedfrom a broadcast source. The audio-presentation interface 902 may comprise or interwork with a digital signal processor that processes a received digital audio stream, a digital-to-analog converter that converts the processed digital audio to analog form, and one or more sound speakers, which, may comprise dynamic drivers and / or balanced armatures, among other possibilities.

[0146] The processor 904 can comprise one or more general purpose processors (e.g., one or more microprocessors, etc.) and / or one or more special-purpose processors (e.g., digital signal processors, application-specific integrated circuits, etc.), possibly including processors of the wireless communication interface 900 and the audio-presentation interface 902, among other possibilities. Further, the non-transitory data storage 906 can comprise one or more volatile and / or non-volatile storage components (e.g., optical, magnetic, or flash storage, RAM, ROM, EPROM, EEPROM, cache memory, and / or other computer-readable media, etc.), possibly integrated in whole or in part with the processor 904. As shown, the non- transitory data storage 906 may then store program instructions 814, which may be executable by the processor 904 to carry out various operations SNK described herein.Additional Implementations

[0147] The present disclosure also contemplates a system including a device and a plurality of SNKs, with the device being configured as discussed above for instance.

[0148] In addition, the present disclosure contemplates a non-transitory computer- readable medium (e.g., optical, magnetic, or flash storage, RAM, ROM, EPROM, EEPROM, etc.) having stored thereon program instructions executable by a processor of a device to cause the device to carry out various operations described herein, such as the methods described with respect to the flow charts for instance.

[0149] Further, the present disclosure contemplates a computer program comprising program instructions executable by a processor of a device to cause the device to carry out various operations described herein, such as the methods described with respect to the flow charts for instance.

[0150] Example embodiments have been described above. Those skilled in the art will understand, however, that changes and modifications may be made to these embodiments without departing from the true scope and spirit of the invention.

Claims

CLAIMSWhat is claimed is:

1. A method to control processing of audio broadcast from a device, the method comprising: receiving into the device, respectively for each broadcast sink (SNK) of a plurality of SNKs that will wirelessly receive and play out the audio broadcast from the device, capability information indicating one or more capabilities of the SNK; configuring by the device, the audio broadcast based on the received capability information of the plurality of SNKs; and broadcasting by the device, the audio broadcast configured based on the received capability information of the plurality of SNKs.

2. The method of claim 1, wherein the device functions as a broadcast source (SRC), and wherein receiving into the device the capability information for each SNK comprises receiving at least one SNK’s capability information reported from a respective broadcast assistant (AST) of the SNK over a respective AST-SRC control connection of the SNK.

3. The method of claim 1, wherein receiving into the device the capability information respectively for each SNK of the plurality of SNKs that will wirelessly receive and play out the audio broadcast from the device comprises receiving into the device, respectively for each SNK, a report of whether the SNK supports receiving audio broadcast with multiple audio channels aggregated into a single broadcast isochronous stream (BIS).

4. The method of claim 3, wherein configuring by the device the audio broadcast based on the received capability information of the plurality of SNKs comprises:(a) determining by the device, based on the received reports, whether all of the plurality of SNKs support receiving audio broadcast with multiple audio channels aggregated into a single BIS,(b) if the device determines that all of the plurality of SNKs support receiving audio broadcast with multiple audio channels aggregated into a single BIS, then configuring by thedevice the audio broadcast from the device to provide multiple audio channels aggregated into a single BIS, and(c) if the device determines that any of the SNKs of the plurality of SNKs does not support receiving audio broadcast with multiple audio channels aggregated into a single BIS, then configuring by the device the audio broadcast from the device to provide multiple audio channels in separate respective BISs.

5. The method of claim 1, wherein receiving into the device the capability information respectively for each SNK of the plurality of SNKs that will wirelessly receive and play out the audio broadcast from the device comprises receiving into the device, respectively for each SNK, a report of whether the SNK supports intra-SNK relaying of broadcast audio.

6. The method of claim 5, wherein configuring by the device the audio broadcast based on the received capability information of the plurality of SNKs comprises:(a) determining by the device, based on the received reports, whether all of the plurality of SNKs support intra-SNK relaying of broadcast audio,(b) if the device determines that all of the plurality of SNKs support intra-SNK relaying of broadcast audio, then configuring by the device the audio broadcast from the device to provide a first quantity of automatic transmissions respectively of each of a series of audio packets, and(c) if the device determines that any of the SNKs of the plurality of SNKs does not support intra-SNK relaying of broadcast audio, then configuring by the device the audio broadcast from the device to provide a second quantity of automatic transmissions respectively of each of the series of audio packets, the second quantity being higher than the first quantity.

7. The method of claim 1, wherein receiving into the device the capability information respectively for each SNK of the plurality of SNKs that will wirelessly receive and play out the audio broadcast from the device comprises receiving into the device, respectively for each SNK, a report of audioprocessing duration of the SNK.

8. The method of claim 7, wherein configuring by the device the audio broadcast based on the received capability information of the plurality of SNKs comprises:(a) establishing by the device an audio-broadcast presentation delay based on the reported processing durations of the plurality of SNKs, and(b) configuring by the device the audio broadcast from the SRC to have the established audio-broadcast presentation delay.

9. The method of claim 1, wherein the device comprises a smartphone.

10. A device comprising: a wireless communication interface through which to provide an audio broadcast from the device; a processor; non-transitory data storage; and program instructions stored in the non-transitory data storage and executable by the processor to cause the device to carry out the method of any of claims 1-9.

11. A system including a device and a plurality of broadcast sinks (SNKs), the device including: a wireless communication interface through which to provide an audio broadcast from the device; a processor; non-transitory data storage; and program instructions stored in the non-transitory data storage and executable by the processor to cause the device to carry out the method of any of claims 1-9.

12. A non-transitory computer-readable medium having stored thereon program instructions executable by a processor of a device to cause the device to carry out the method of any of claims 1-9.

13. A computer program comprising program instructions executable by a processor of a device to cause the device to carry out the method of any of claims 1-9.

Images