Title of Invention: Accessory for a voice-controlled device Abstract: This disclosure describes techniques and systems for encoding instructions in audio data that, when output on a speaker of a first device in an environment, cause a second device to output content in the environment. In some instances, the audio data has a frequency that is inaudible to users in the environment. Thus, the first device is able to cause the second device to output the content without users in the environment hearing the instructions. In some instances, the first device also outputs content, and the content output by the second device is played at an offset relative to a position of the content output by the first device. Detailed Description: Part general_description_paragraphs: Part CROSS REFERENCE TO RELATED APPLICATIONS: This disclosure is a continuation of, and claims priority under 35 USC § 120 to, U.S. patent application Ser. No. 15/595,658, filed May 15, 2017, of the same title, which is incorporated herein by reference as if fully set forth below. Part BACKGROUND: Homes are becoming more connected with the proliferation of computing devices such as desktops, tablets, entertainment systems, and portable communication devices. As these computing devices evolve, many different ways have been introduced to allow users to interact with computing devices, such as through mechanical devices (e.g., keyboards, mice, etc.), touch screens, motion sensors, and image sensors. Another way to interact with computing devices is through natural language processing, such as that performed on speech input. Discussed herein are technological improvements for, among other things, these computing devices and systems involving the computing devices. Part DETAILED DESCRIPTION: This disclosure is directed to systems, devices, and techniques pertaining to coordinated operation of a device and one or more accessory devices in an environment. An environment may include at least one device and one or more accessory devices. The “device” is configured to receive voice commands from a user in the environment, and to cause performance of operations via the devices and/or the one or more accessory devices in the environment. In order to accomplish this, the device is coupled, via one or more computer network(s), to a remote system that comprises a speech recognition system used to process audio data received from the device, and to send information and instructions to the device and/or the one or more accessory devices in the environment. The information and instructions, upon receipt and subsequent processing at the device and the one or more accessory devices, cause coordinated operation of the device and the one or more accessory devices. In some instances, the device is configured to output primary content in an environment, while one or more accessory devices output supplemental content in the environment. For example, the device may output first audio data, while the accessory devices may output second audio data in coordination with the first audio data. For instance, the accessory device(s) may output supplemental content at a particular offset relative to a position in the first audio data. In other instances, the device may output visual data in addition or alternative to audio data, and the accessory device(s) may output visual data, audio data, or any combination thereof. Further, the timing of the output of the supplemental content may or may not be coordinated with the timing of the output of the primary content. In some instances, the primary content comprises content that corresponds to a request received from a user. For instance, if a user requests information about the day's weather forecast, the primary content may comprise audio and/or visual data indicate the weather forecast. In another example, if the user requests that a device output a certain song or video, the primary content may comprise the requested content. The supplemental content, meanwhile, may comprise content that is related to but ancillary to the initial request. For instance, if the user requests information regarding the weather forecast, the supplemental content may comprise audio and/or visual content depicting certain weather effects, such as a picture of a sun or clouds or the sound of thunder or rain. Of course, while a few examples have been provided, it is to be appreciated that the techniques may apply to any other type of primary and/or supplemental content. Further, the primary and supplemental content may be related in any number of ways. For instance, the primary content may include metadata specifying certain content that has been deemed supplemental to the primary content. Or, the techniques may utilize a database that maps certain pieces of primary content to certain pieces of supplemental content, or vice versa. Again, other techniques may be used to store associations between primary content and supplemental content. In some instances, the device, the accessory device(s), and/or other device(s) in the environment may communicate with a remote system over a network (e.g., over a wireless local area network (WLAN) utilizing the IEEE 802.11 standards, over a wired network, or the like). For example, the remote system may provide the primary content and/or the supplement content for output in the environment. In some instances, a user interacts with the device, which in turn communicates with the remote system. The remote system then determines primary content to output on the device (or another device) based on the particular request of the user. In addition, the remote system may determine supplemental content to output by one or more accessory devices within the environment. After identifying the primary and/or supplemental content, the remote system may determine how to send this content to the devices in the environment. In some instances, the remote system sends the primary content (or information for acquiring the primary content) and the supplemental content (or information for acquiring the supplemental content) to the device. The device may then output the primary content and may send the supplemental content (or the information for acquiring the supplemental content) to the accessory device(s). For example, the device may send the supplemental content or the information for acquiring the supplemental content to the accessory device(s) over a short-range wireless communication channel, such as a wireless personal area network (WPAN) utilizing the IEEE 802.15 protocol (e.g., WiFi direct, Bluetooth, Bluetooth Low-Energy, Zigbee, or the like). In another example, the remote system may send, over the network, the primary content (or the information for acquiring the primary content) to the device while sending the supplemental content (or the information for acquiring the supplemental content) to the accessory device(s) over the network. In yet another example, the remote system may encode instructions for causing the accessory device(s) to output the supplemental content in data sent to the device. For example, the remote system may generate audio data that encodes or otherwise includes the instructions for causing the accessory device to identify and output the supplemental content. The remote system may then send this audio data to the device, which may in turn output this audio data. Microphone(s) of the accessory device(s) may then generate an audio signal based on the captured sound and may decode or otherwise determine the audio signal represents the instructions. Some types of accessory devices can store content locally along with a map of audio-data-to-content, such that upon analyzing the audio signal the at least one of the accessory devices identifies the locally stored supplemental content to output and outputs this content in the environment. In some instances, the audio data generated by the remote system that encodes the instructions may comprise high-frequency audio data having a frequency that is inaudible to the human ear. For instance, the high-frequency audio data may have a frequency range of between 3,000 hertz (Hz) and 30,000 Hz, above 20,000 Hz, etc. Regardless of the particular frequency range, in some instances the instructions may be encoded in the audio data using frequency-key shifting (FSK) techniques, where the frequency is modulated in a predefined manner, with this frequency modulation corresponding to specific content to output on the accessory device(s). These FSK techniques may include binary FSK, continuous-phase FSK, Gaussian FSK, minimum shift-keying, audio FSK, or the like. Of course, while the above example describes encoding the instructions using FSK techniques, the instructions to output the supplemental content may be encoded using other techniques. Further, while the above example describes encoding the instructions into audio data, the instructions may be encoded into visual data, such as via a flashing light that switches between on and off according to a predefined pattern, with the pattern corresponding to certain supplemental content. As an illustrative example, a user in the environment can ask (by uttering a voice command) the device about the weather (e.g., “wakeword, what is the weather today?”). The device in the environment may capture, via one or more microphone(s), sound in the environment that corresponds to the uttered voice command, generate audio data based on the captured sound, and send the audio data (e.g., starting just before, during, or after “wakeword”) to a remote system that performs speech recognition processing on the audio data. Speech recognition processing can include automatic speech recognition (ASR) processing to generate text data corresponding to the audio data. ASR is a field of computer science, artificial intelligence, and linguistics concerned with transforming audio data associated with speech into text representative of that speech. The ASR text data can be processed through natural language understanding (NLU) processing. NLU is a field of computer science, artificial intelligence, and linguistics concerned with enabling computers to derive meaning from text input containing natural language. ASR and NLU can be used together as part of a speech processing system. Here, the ASR/NLU systems are used to identify, in some instances, one or more domains of the NLU system, and one or more intents associated with the multiple domains. For example, the speech recognition system, via the NLU processing, may identify a first intent associated with a first domain. Continuing with the above example, the first intent may comprise a “weather_inquiry” intent, and the first domain may comprise a “weather” domain based on the following ASR text data: “what is the weather.” Associated slot data may also be provided by the natural language understanding processing, such as location data associated with the intent (e.g., <intent:weather_inquiry>; <location_98005>). That is, the speech recognition processing can determine that the user wants a device in the environment, such as the device, to output an indication of the weather forecast for a zip code associated with the environment, and accordingly, the speech recognition system identifies the weather domain, the weather-inquiry intent, and location slot data to fulfill this request. The NLU system may also identify a named entity within the ASR text data, such as “today”. The named entity identified from the ASR text data may be one of a plurality of named entities associated with the weather domain (e.g., today, tomorrow, Saturday, etc.). As such, the named entity can be another type of slot data used by the domain to determine primary content (e.g., text, image, and/or audio data) outputted in response to the voice command. In response to identifying the user's request that the device output the expected weather for the day, the remote system may generate second audio data for sending back to the device. In some instances, the remote system determines the expected weather for the certain day and generates the second audio data to represent this expected weather. In other instances, the second audio data is separate from the indication of the actual weather. For instance, the remote system may generate second audio data configured to output “here is today's weather:” and then may instruct the device to obtain the primary content from another network resource. That is, the remote system may identify a network location (e.g., a uniform resource locator (URL) at which the device is able to acquire the day's weather. The remote system may then send the second audio data and the URL (or other network-location indication) to the device, which may obtain the primary content from the network location (using the URL), and output the second audio data and any additional audio data acquired from the network location. In either instance, whether the remote system generates the primary content (the weather forecast) or instead sends information for acquiring the primary content, the device, the device may output primary content such as “You can expect thunder and lightning today” or “Here is today's weather: it is expected to thunder and lightning today.” In addition to identifying the primary content to output on the device (or other device in the environment of the user) in response to receiving the user's voice command, the remote system may identify supplemental content to output by one or more accessory devices in the environment. For example, in response to receiving the request for the day's weather, the remote system may determine whether or not additional accessory devices reside in the environment of the device. To do so, the remote system may reference an identifier that accompanies (or is sent separately from) the request received from the device. This identifier may comprise a device identifier (e.g., MAC address, IP address, etc.), an account identifier (e.g., an account associated with the device, etc.), a customer identifier (e.g., an identifier of a particular user or user account), or the like. Using this identifier, the remote system may determine the account of the device at the remote system and may determine whether or not the account indicates that accessory devices reside within the environment of the device. If so, then the remote system may determine whether supplemental content is to be outputted along with the primary content (i.e., the weather). In one example, an accessory service monitors interactions between the device (and other devices) and the remote system to identify events there between. The accessory service then determines which events to respond to, having been preconfigured to respond in certain ways to certain events. In this example, the accessory service may determine that the remote system is going to instruct (or has instructed) the device to output “You can expect thunder and lightning”. The accessory service may determine that this forecast is associated with one or more pieces of supplemental content, such as audio content mimicking thunder, video content of lightning strikes, the flashing of lights, or the like. The accessory service may then identify which pieces of supplemental content to cause the accessory devices to output based on the accessory devices present in the environment. For example, the accessory service may cause a first accessory to output audio content of thunder and visual content of lightning flashing while determining to cause lights in the environment (example accessory devices) to flash off and on to mimic lightning. After identifying the supplemental content to output in the environment, the accessory service may determine how to send instructions to the accessory device(s) in the environment. To make this determination, the accessory service may determine a device type of each accessory device and may determine capabilities of each accessory device based on the device type. If, for instance, a first accessory device is WiFi-enabled, then the accessory service may send the instructions to cause the first accessory device to output the supplemental content over a network. If, however, a second device only communicates locally with the device or another device within the environment, the accessory service may send these instructions to the device (or other device), which may in turn relay the instructions via a short-range wireless connection. In another example, the accessory service may encode the instructions in audio data and/or visual data, which may be sent to the device or another device in the environment for output. In this example, the accessory service may send respective instructions to a first accessory device and a second accessory device (directly or via the device or another device) to cause the first accessory device to flash lightning on its display and output a thunder sound and to cause the second accessory device to flash its lights off and on. Furthermore, the output of the supplemental content may be coordinated with the output of the primary content. That is, the remote system may provide timing information to the device and/or the accessory devices such that the primary content and the information for acquiring/identifying supplemental content is output in a coordinated manner. Outputting the primary content and the information for acquiring/identifying the supplemental content in a coordinated manner may include outputting the audio data simultaneously, serially, in an interspersed manner, or in any other coordinated manner. For instance, sub-band coding techniques may be utilized to generate a single audio signal that includes the primary content corresponding to a first frequency range and the information for identifying/acquiring the supplemental content corresponding to a second audio range that is inaudible to a human user. Thus, the single audio signal may be output on the local device, resulting in simultaneous output of the primary content and the information for identifying/acquiring the supplemental content. In other instances, these audio signals partly or wholly serially. In some instances, the remote system sends an indication of a time at which to output the primary content and/or the supplemental content. For instance, the remote system may determine a first time at which to beginning outputting the primary content and a second time (before, after, or the same as the first time) at which to begin outputting the supplemental content. The remote service may then send the respective times to the device and the accessory devices. In another example, the remote system encodes an indication of an amount of time after some specified event at which to output content. For instance, the accessory service may indicate that the accessory device is to begin outputting the sound of thunder one hundred milliseconds after identifying the word “thunder” in the primary content. Therefore, upon generating an audio signal and performing ASR on the signal to identify the word “thunder”, the accessory device may begin its timer for 100 milliseconds and output the thunder sound upon expiration of the timer. Regardless of how the offset between the primary and supplemental content is specified, the primary and supplemental content may be output in a coordinated manner. For purposes of discussion, examples are used herein primarily for illustrative purposes. For example, the techniques described herein are often described with reference to playback of audio content on devices. However, it is to be appreciated that the techniques and systems described herein may be implemented with any suitable content and using any suitable devices (e.g., computers, laptops, tablets, wearables, phones, etc.). Where displays are employed, content can also comprise visual content, such as a movie, music video, graphics, animations, and so on. Accordingly, “content” as used herein can comprise any suitable type of content, including multimedia content. FIG. 1 is an illustration of an example system architecture 100 in which a user 102 utilizes a device 104 to control one or more accessory devices 106(1) and 106(2). FIG. 1 shows a first accessory device 106(1) in the form of a spherical toy and a second accessory device 106(2) in the form of a lamp. FIG. 1 is provided to aid in comprehension of the disclosed techniques and systems. As such, it should be understood that the discussion that follows is non-limiting. For instance, the accessory devices used herein may have any other form factors such as animatronic puppets, display devices, furniture, wearable computing devices, or the like. Further, the techniques may apply beyond the device 104. In other instances, the device 104 may be replaced with a mobile device, a television, a laptop computer, a desktop computer, or the like. Within FIG. 1, the user 102 may interact with one or more accessory devices (collectively 106) within an environment 108 by uttering voice commands that are directed to the device 104 in the environment 108. For instance, if the user 102 would like to have the accessory 106 “dance” and “sing” to music that is output via the device 104 and/or via the accessory 106, the user 102 may issue a voice command to the device 104 to “Tell Accessory_Device to sing and dance to Artist_Name.” Multiple other voice commands are possible, such as “Tell Accessory_Device to play a game,” or, in the case of multiple accessory devices 106 in the environment 108, “tell my Accessories to dance together to Artist_Name,” or the like. In each case, the device 104 may interact with a remote system, discussed below, to cause the accessory device 106 to perform the requested operation. For instance, the accessory device 106 may receive a stream of control information along with an instruction (or command) to begin processing the stream of control information at a time specified in the instruction. Processing of the control information by the accessory device 106 may cause the accessory device 106 to operate in a mode of operation among multiple available modes of operation, and/or cause operation of a component(s) of the accessory device 106, such as components including, without limitation, individual light sources of a plurality of light sources, a display, a movable member (e.g., a movable mouth or another appendage of an animatronic version of the accessory device 106, etc.), and the like. In a non-illustrated example, for instance, the user 102 may desire to have an accessory device “sing” and “dance” to music by operating light sources of the device (e.g., light emitting diodes (LEDs)) and presenting lip synch animations on a display of the accessory device. Accordingly, the user 102 could speak a natural language command, such as “Tell Accessory_Device to sing and dance to Artist_Name.” The sound waves corresponding to the natural language command 110 may be captured by one or more microphone(s) of the device 104. In some implementations, the device 104 may process the captured signal. In other implementations, some or all of the processing of the sound may be performed by additional computing devices (e.g. servers) connected to the device 104 over one or more networks. For instance, in some cases the device 104 is configured to identify a predefined “wake word” (i.e., a predefined utterance). Upon identifying the wake word, the device 104 may begin uploading an audio signal generated by the device to the remote servers for performing speech recognition thereon, as described in further detail below. While the user 102 may operate accessory devices directly via voice commands to the device 104, such as in the example instructing the accessory to sing and dance to a particular song, in other instances the accessory devices may output supplemental content that supplements content output by the device 104 or another device in the environment. In some instances, the accessory device(s) (such as devices 106(1) and 106(2)) may output supplemental content without receiving explicit instructions from the user 102 to do so. To provide an example, FIG. 1 illustrates that the user 102 may provide a voice command 110 asking the device 104, “what is the weather going to be like today?” In response to generating audio data based on sound captured by one or more microphones of the device 104, the device 104 may upload the audio data to a remote system 112 over a network 114. The network 114 may represent an array or wired networks, wireless networks (e.g., WiFi), or combinations thereof. The remote system 112 may generally refer to a network-accessible platform—or “cloud-based service”—implemented as a computing infrastructure of processors, storage, software, data access, and so forth that is maintained and accessible via the network 114, such as the Internet. Cloud-based services may not require end-user knowledge of the physical location and configuration of the system that delivers the services. Common expressions associated with cloud-based services, such as the remote system 112, include “on-demand computing”, “software as a service (SaaS)”, “platform computing”, “network accessible platform”, and so forth. As illustrated, the remote system 112 may comprise one or more network-accessible resources 116, such as servers. Multiple such resources 116 may be included in the system 112 for training ASR models, one server(s) for performing ASR, one resource/device 116 for performing NLU, etc. These resources 116 comprise one or more processors 118, which may include a central processing unit (CPU) for processing data and computer-readable instructions, and computer-readable storage media 120 storing the computer-readable instructions that are executable on the processors 118. The computer-readable media 120 may individually include volatile random access memory (RAM), non-volatile read only memory (ROM), non-volatile magnetoresistive (MRAM) and/or other types of memory, and may store an orchestration component 122 that includes a speech-recognition system 124 and a natural-language-understanding (NLU) component 126. The computer-readable media 120 may also store a customer registry 128 and an accessory component 130. The customer registry 128 may store a datastore indicating devices 132 that reside in the environment 108 (and potentially other user environments). It is noted that the computer-readable media 120 may individually include one or more non-volatile storage types such as magnetic storage, optical storage, solid-state storage, etc. The resources 116 may also be connected to removable or external non-volatile memory and/or storage (such as a removable memory card, memory key drive, networked storage, etc.) through respective input/output device interfaces. Computer instructions for operating the resource 116 and its various components may be executed by the processor(s) 118, using the computer-readable media 120 as temporary “working” douglas57@example.org. A resource's 116 computer instructions may be stored in a non-transitory manner in non-volatile memory, storage, or an external device(s), and computer-readable media 120 can represent some or all of these memory resources. Alternatively, some or all of the executable instructions may be embedded in hardware or firmware on the respective device in addition to or instead of software. Each resource 116 can include input/output device interfaces. A variety of components may be connected through the input/output device interfaces. Additionally, the resource(s) 116 may include an address/data bus for conveying data among components of the respective device. Each component within resource 116 may also be directly connected to other components in addition to (or instead of) being connected to other components across the bus. Upon the device 104 identifying the user 102 speaking the predefined wake word (in some instances), the device 104 may begin uploading audio data—the audio data representing sound captured by a microphone(s) of the device 104 within the environment 108—up to the remote system 112 over the network 114. In response to receiving this audio data, the speech-recognition system 124 (part of a speech recognition system) may begin performing ASR on the audio data to generate text data. The NLU component 126 may then use NLU to identify one or more user voice commands from the generated text data. Accordingly, upon receiving the audio data from the device 104, the speech-recognition system 124 may perform ASR on the audio data to generate text data. The text data may then be processed by the NLU component 126 to identify a domain(s) and an intent(s). In some instances, the text data generated from the audio data will indicate multiple intents and multiple corresponding domains. In the illustrated example, the speech-recognition system 124 performs ASR on the audio signal received from the device 104 to generate the text: “what is the weather going to be like today?” The NLU component 126 then determines, from analyzing this text, that the voice command 110 corresponds to a “weather” domain and that the intent of the command 110 is about determining the weather for the current day, which may comprise a named entity in the command 110. As such, other components of the speech platform associated with the weather domain and described in further detail below may determine primary content that is to be output by the device 104 in response to the voice command 110. For instance, the remote system 112 may determine the expected weather for the day and may either generate content to output on the device 104 (or another device in the environment 108) or may provide a network location at which to allow the device or other device to acquire the content. In this example, the remote system generates audio data corresponding to the day's expected weather and provides this audio data to the device 104 for output on one or more speakers of the device 104. As illustrated, the device 104 outputs an indication, such as: “you can expect thunder and lightning . . . .” In addition, the accessory component 130 may determine whether or not the interaction between the user 102 and the remote system 112 is one in which one or more accessory devices in the environment 108 should output supplemental content that supplements the primary content (i.e., the weather prediction). First, the accessory component 130 may determine whether the environment 108 includes or is likely to include any accessory devices 106. To do so, the accessory component 130 may analyze an identifier received from the device 104 to determine whether the account associated with the device 104 has been associated with any accessory devices. For example, the device 104 may upload, with or near-in-time to the audio data representing the voice command 110, a device identifier (e.g., a MAC address, IP address, serial number, etc.), a username, an account identifier, or the like, which the accessory component 130 may use to identify an account associated with the user 102 and/or the device 104. Using this information, the accessory component 130 may identify a set of one or more accessory devices 132 that have been registered to the user 102 and/or have been registered as residing with the environment 108 within the customer registry 128. In this example, the accessory component 130 may determine that the environment includes the accessory devices 106(1) and 106(2). In addition to determining that the environment includes one or more accessory devices 106, the accessory component 130 may determine whether supplemental content should be output based on the interaction between the user 102 and the remote system 112. To do so, the accessory component 130 may analyze the text generated by the speech-recognition system 124, the domain/intent determination made by the NLU component 126, the audio data to be output by the device 104, and/or any other information associated with the interaction to determine whether supplemental content should be output on one or more of the accessory devices in the environment 108. In this example, the accessory component 130 determines that supplemental content is to be output on both the accessory devices 106(1) and 106(2) in coordination with output of the primary content to be output on the device 104. First, the accessory component 130 may determine, based on a mapping between the primary content and supplemental content, that an accessory device with a display should output a picture or animation or a lightning bolt based on the weather predicting “lightning.” In addition, the accessory component 130 determines that an accessory device capable of outputting audio should output a thunder sound based on the primary content including the term “thunder”. In yet another example, the accessory component 130 determines that an accessory device that is capable of flashing lights should do so based on the primary content including the terms “thunder” and/or “lightning”. In still other instances, the accessory component 130 may be configured to determine that the example supplemental content is to be output in coordination with output of the primary content on the device 104—that is, at a particular offset relative to a position within the primary content. In this example, the accessory component determines that the picture of the lightning is to be output when the device 104 states the word “lightning” while the flashing lights and thunder sounds are to be output at a time corresponding to output of the word “thunder”. Therefore, the remote system 112 may send both the primary content (or information for acquiring/identifying the primary content) and the supplemental content (or information for acquiring/identifying the supplemental content) to devices in the environment 108. In instances where both an accessory device and the device 104 (or other primary device) is configured to communicate with the remote system 112 over the network 114, the remote system may send the respective data to each respective device. That is, the remote system 112 may send the primary content (or the information for acquiring/identifying the primary content) to the device 104, a portion of the supplemental content (or information for acquiring/identifying the portion supplemental content) to the accessory device 106(1) over the network 114 and another portion of the supplemental content (or information for acquiring/identifying the additional supplemental content) to the accessory device 106(2) over the network. In other instances, the remote system 112 may send the primary content (or information) and the supplemental content (or information) to the device 104, which may in turn send respective portions of the supplemental content (or information) to the respective accessory devices 106(1) and 106(2) over a local communication channel 134. The local communication channel 134 may include short-range wireless communication channels, such as WiFi direct, Bluetooth, Bluetooth Low-Energy (BLE), Zigbee, or the like. In yet another instance, the remote system 112 may encode the supplemental content (or information) into additional data and may provide this additional data for output by the device 104. For instance, the accessory component 130 may generate high-frequency audio data that utilizes FSK techniques for encoding a message into the audio data. The device 104 may then receive and output the high-frequency audio data. In some instances, while the audio data is in a frequency range that is inaudible to the user 102, microphone(s) of the accessory devices 106(1) and/or 106(2) may generate audio signals based on the high-frequency audio data and may decode instructions for outputting and/or acquiring supplemental data. In some instances, the high-frequency audio data instructs an accessory device to execute a local routing stored on the accessory device. That is, the encoded data may instruct the accessory device to output certain supplemental content that is stored on the accessory device. In other instances, the encoded data may specify a network location (e.g., a URL) at which the accessory device is to acquire the supplemental data. While the above examples describe different manners in which the remote system 112 may communicate with the devices of the environment 108, it is to be appreciated that the system 112 and the local devices may communicate in other ways or in combinations of ways. Regardless of the manner in which the instructions to output supplemental content reach the accessory devices, in some instances the instructions specify timing information for outputting the supplemental content. For example, the instructions may indicate a particular offset from a position of the primary content at which to output the supplemental content. In some instances, the instructions specify a time (e.g., based on a universal time clock (UTC)) at which to begin outputting the content. In another example, the instructions may instruct an accessory device to begin a timer at a particular UTC time and, at expiration of the timer, begin outputting the supplemental content. In another example, the instructions may instruct the accessory device to begin outputting the supplemental content after identifying a particular portion of the primary content being output by the device 104 or other primary device (e.g., the word “thunder”). Or, the instructions may instruct the accessory device to set a time for a particular amount of time after identifying the predefined portion of the primary content and to output the supplemental content at expiration of the timer. Of course, while a few examples have been provided, it is to be appreciated that the instructions may cause the accessory device(s) to output the supplemental content at the particular offset relative to the primary content in additional ways. In the illustrated example, in response to the user stating the voice command 110, the remote system 112 causes the device 104 to output audio data stating “You can expect thunder and lightning . . . .” Further, the remote system 112 causes the accessory device 106(1) to output thunder sound on its speaker(s) and lightning on its display(s). The remote system 112 also causes the accessory device 106(2) to flicker its lights off and on. In some of these instances, the remote system 112 may cause these accessory devices to perform these actions (i.e., output this supplemental content) at particular offset(s) relative to a position(s) of the primary content. For instance, upon the device 104 stating the word “thunder”, the accessory device 106(1) may output the thunder sound. Upon the device 104 outputting the term “lightning”, the accessory device 106(1) may display the lightning bolt on the display while the accessory device 106(2) may flicker its lights. FIG. 2 illustrates an example in the environment of FIG. 1 where a remote system causes the accessory devices to output the supplemental content by sending the supplemental content directly to the accessory devices. As illustrated, in this example the user 102 states the example voice command “what is the weather going to be like today?” At “202”, the device 104 generates first audio data based on the speech, as captured by one or more microphones of the device 104. At “204”, the device 104 sends the first audio data to the remote system 112 over the network 114. At “206”, the remote system receives the first audio data and, at “208”, performs ASR and NLU on the audio data and the text corresponding to the audio data, respectively, to identify primary content and supplemental content to output in the environment of the user 102. It is to be appreciated in this example, that the remote system 112 also determines that the environment of the user 102 includes the accessory devices 106(1) and 106(2). In this example, the remote system 112 determines that the accessory devices 106(1) and 106(2) in the environment are addressable over the network 114. Thus, at “210” the remote system sends the primary content (or a URL or the like for acquiring the primary content) to the device 104. At “212”, meanwhile, the remote system sends respective portions of the supplemental content (or information acquiring/identifying the supplemental content) directly to the accessory devices 106(1) and 106(2). At “214”, the device 104 receives and outputs the primary content. This may include acquiring the primary content in instances where the remote system 112 provides a URL, while it may include outputting received audio data in instances where the remote system 112 simply sends audio data as primary content for output by the device 104. At “216”, the accessory devices receive and output the respective portions of the supplemental content. Again, this may include outputting data received from the remote system 112, acquiring the supplemental content and then outputting it, mapping the instructions to locally stored data and then outputting the locally stored data, or the like. FIG. 3 illustrates an example in the environment of FIG. 1 where the remote system causes the accessory devices to output the supplemental content by sending the supplemental content to the device, which then sends the supplemental content to the accessory devices. As illustrated, in this example the user 102 again states the example voice command “what is the weather going to be like today?” At “302”, the device 104 generates first audio data based on the speech, as captured by one or more microphones of the device 104. At “304”, the device 104 sends the first audio data to the remote system 112 over the network 114. At “306”, the remote system receives the first audio data and, at “308”, performs ASR and NLU on the audio data and the text corresponding to the audio data, respectively, to identify primary content and supplemental content to output in the environment of the user 102. It is to be appreciated in this example, that the remote system 112 also determines that the environment of the user 102 includes the accessory devices 106(1) and 106(2). In this example, however, the remote system 112 determines that the accessory devices 106(1) and 106(2) in the environment are not addressable over the network 114. Thus, at “310” the remote system sends the primary content (or a URL or the like for acquiring the primary content) along with the supplemental content (or information for acquiring/identifying the supplemental content) to the device 104. At “312”, the device 104 receives and outputs the primary content. This may include acquiring the primary content in instances where the remote system 112 provides a URL, while it may include outputting received audio data in instances where the remote system 112 simply sends audio data as primary content for output by the device 104. At “314”, the device sends the supplemental content (or information) to the accessory devices over a local connection. At “316”, the accessory devices receive and output the respective portions of the supplemental content. Again, this may include outputting data received from the remote system 112, acquiring the supplemental content and then outputting it, mapping the instructions to locally stored data and then outputting the locally stored data, or the like. FIG. 4 illustrates an example in the environment of FIG. 1 where the remote system causes the accessory devices to output the supplemental content by sending high-frequency audio data to the device. Although this audio data may be inaudible to the user in the environment, it may encode instructions that cause the accessory devices to output the supplemental content in the environment. As illustrated, in this example the user 102 again states the example voice command “what is the weather going to be like today?” At “402”, the device 104 generates first audio data based on the speech, as captured by one or more microphones of the device 104. At “404”, the device 104 sends the first audio data to the remote system 112 over the network 114. At “406”, the remote system receives the first audio data and, at “408”, performs ASR and NLU on the audio data and the text corresponding to the audio data, respectively, to identify primary content and supplemental content to output in the environment of the user 102. It is to be appreciated in this example, that the remote system 112 also determines that the environment of the user 102 includes the accessory devices 106(1) and 106(2). In this example, the remote system 112 determines that the accessory devices 106(1) and 106(2) in the environment are not addressable over the network 114. Thus, at “410”, the remote system generates high-frequency audio data encoding the supplemental content (or information for acquiring/identifying the supplemental content). At “412” the remote system sends the primary content (or a URL or the like for acquiring the primary content) and the high-frequency audio data to the device 104. At “414”, the device 104 receives and outputs the primary content and also receives and outputs the high-frequency audio data. In some instances, the voice controlled device may output the primary content and the high-frequency audio data at a same time, while in other instances the device 104 may output them serially, partially overlapping, or the like. In some instances, the remote system 112 may in fact generate a signal audio file that includes both the primary content and the high-frequency data, such that the device 104 outputs both at a same time. At “416”, the accessory devices generate audio data based on sound captured by their respective microphones and analyze the audio data to identify the instructions to output the supplemental content. At “418”, the accessory devices output the supplemental content, which may include retrieving the content from a remote source, retrieving the appropriate content from local memory, or the like. FIG. 5 illustrates an example process 500 how an accessory device may output the supplemental content at a specified offset relative to a position of the primary content output by the device. At 502 and at a time T1, a device may begin outputting primary content 502, which may comprise audio data, visual data (e.g., images, animations, video, etc.), and/or the like. Continuing the example from above, the device 104 outputs the audio data “You can expect thunder and lightning . . . .” At 504 and at a time T2, meanwhile, an example accessory device 106(1) begins outputting supplemental content. That is, the accessory device may output the supplemental content at a specified offset relative to a position within the primary content. In some instances where the accessory device (or multiple accessory devices) output different portions of supplemental content, the different portions may be output at different offsets. At 506 and at a time T3, meanwhile, the device finishes and thus ceases outputting the primary content. At 508 and at a time T4, the accessory device ceases outputting the supplemental content. For instance, the lights may cease flashing, the thunder sounds may stop, and/or the like. FIG. 5, therefore, illustrates that both that the supplemental content may be output at one or more specified offsets relative to one or more positions of the primary content, but also that the outputting of the primary and supplemental content may, but need not, overlap in whole or in part. FIG. 6 is a conceptual diagram of components of the remote system 112 for determining when to cause an accessory device to output supplemental, identifying the supplemental output, and determining how to make the supplemental content available to the accessory device. As illustrated, FIG. 6 includes one or more primary devices 602, which may include devices, laptop computers, mobile phones, smart appliances, or any other type of electronic device. In addition, FIG. 6 includes one or more accessory devices 604. Again, the accessory devices may include any type of electronic device able to output audio content (e.g., music, tones, dialogue, etc.), visual content (e.g., images, videos, animations, lights, etc.), and/or the like. As shown, both the primary device(s) and the accessory device(s) may communicate, in whole or in part, with the orchestration component 122 of the remote system 112. The orchestration component 122 may include or otherwise couple to the speech-recognition system 124 and the NLU component 126. When the primary device 602 comprises a device, the device may upload audio data to the orchestration component 122, for generating text of the audio data by the speech-recognition system 124. The NLU component 126 may then determine a domain and an intent by analyzing the text and, based on this determination, route the request corresponding to the audio data to the appropriate domain speechlet, such as the illustrated domain speechlet 606. While FIG. 6 illustrates the speech-based components, the orchestration component 122 may also route, to the appropriate domain speechlet, non-audio requests received from other types of primary devices. In this example, the domain speechlet 606 receives the text associated with the audio data provided by the primary device 602 and determines how to respond to the request. In some instances, the domain speechlet 606 determines primary content to provide back to the requesting device or to another device, or determines a location at which the primary content is to be accessed (e.g., a URL). In addition, the domain speechlet may determine additional information to output on the requesting device or on another device, such as second audio data. For example, if the primary device sends a request for a particular song (e.g., “Play my oldies radio station”), the domain speechlet 606 may determine a URL to send back to the primary device 602 (for obtaining audio corresponding to the primary content, the requested radio station) as well as determine text for generating second audio data for output on the primary device, such as “Here is your requested station”. After the domain speechlet 606 determines a response to the received request, it provides this information back to the orchestration component 122, which in turns provides this information to a text-to-speech (TTS) engine 608. The TTS engine 608 then generates an actual audio file for outputting the second audio data determined by the domain speechlet 606 (e.g., “Here is your radio station”, or “You can expect thunder and lightning . . . .”). After generating the file (or “audio data”), the TTS engine 608 then provides this data back to the orchestration component 122. The orchestration component 122 may then publish (i.e., write) some or all of this information to an event bus 610. That is, the orchestration component 122 may provide information regarding the initial request (e.g., the speech, the text, the domain/intent, etc.), the response to be provided to the primary device 602 (e.g., the URL for the primary content, the primary content, the second audio data for output on the device, etc.), or any other information pertinent to the interaction between the primary device and the remote system 112 to the event bus 610. With the remote system 112, one or more components or services may subscribe to the event bus 610 so as to receive information regarding interactions between user devices and the remote system 112. In the illustrated example, for instance, the accessory component 130 may subscribe to the event bus 610 and, thus, may monitor information regarding these interactions. As illustrated, the accessory component 130 includes an event-identification module 612, an accessory-management module 614, an accessory-content module 616, and an
{'bibliographic_information': "{'country': 'US', 'doc-number': '16523188', 'kind': 'B1', 'date': '20190726', 'invention_title': 'Accessory for a voice-controlled device'}", 'source_file': './grant/2021/ipg211207.xml', 'source_data': 'USPTO-Grant'}