This disclosure relates to audio systems and related devices and methods, and, particularly, to establishing a connection between a computer hosting a digital media server and an audio playback device when a firewall running on the computer blocks in-bound communications from the audio playback device.
All examples and features mentioned below can be combined in any technically possible way.
One aspect features a method that includes receiving via an audio playback device a first multicast transmission (e.g., an SSDP(HTTP)/Bonjour(DNS) presence announcement) from a computer hosting a digital media server. The first multicast transmission provides an indication of the presence of the digital media server (e.g., DLNA music server) on a network (e.g., a LAN). The audio playback will attempt to make a unicast connection with the digital media server by transmitting a request for a unicast connection (e.g., a connection to a particular IP address and port). If the audio playback device fails to establish the connection, it will send a second multicast transmission which includes information that allows the digital media server to establish a connection with the audio playback device to facilitate transmission of a unicast request for content from the audio playback device to the digital media server.
Implementations may include one of the following features, or any combination thereof.
In some implementations, the information includes an indication that the audio playback device is capable of reverse communication, an identification of a port on the audio playback device through which the connection is to be established, and/or a location (e.g., IP address) of the audio playback device.
In certain implementations, the method includes transmitting a unicast request for content after the digital media server establishes a connection with the audio playback device.
In some examples, in the absence of a response to the request for a unicast connection, a third multicast transmission (e.g., a Bonjour/DNS-based presence announcement) is transmitted via the audio playback device.
The third multicast transmission may be transmitted substantially simultaneously with the second multicast transmission.
In certain examples, the second multicast transmission is transmitted via a first discovery protocol and the third multicast transmission is transmitted via a second discovery protocol.
In some cases, the first multicast transmission is transmitted via the first discovery protocol or the second discovery protocol.
In certain cases, the first discovery protocol uses HTTP messages, and the second discovery protocol uses DNS messages.
In some implementations, a multicast discovery request is transmitted via the audio playback device; and the first multicast transmission is transmitted via the digital media server as a response to the discovery request.
In certain implementations, the computer hosting the digital media server includes a firewall application which inhibits in-bound unicast communications from the audio playback device from reaching the digital media server unless and until the digital media server establishes the connection with the audio playback device.
Another aspect provides a method that includes receiving via a digital media server a first multicast transmission transmitted via an audio playback device, and, in response to the first multicast transmission, establishing communication with the audio playback device based on information included in the first multicast transmission. The information included in the first multicast transmission includes an identification of a port on the audio playback device through which the communication is established.
Implementations may include one of the above and/or below features, or any combination thereof.
In some implementations, the method includes blocking a first unicast communication from the audio playback device via a firewall application running on a computer that hosts the digital media server.
In another aspect, an audio playback device is configured to operably connect to a plurality of digital audio sources. The audio playback device includes (i) a digital-to-analog converter configured to receive a digital representation of content from the digital audio sources and convert to analog form; (ii) an electro-acoustic transducer; (iii) a communication interface; (iv) a processor coupled to the digital-to-analog converter, the electro-acoustic transducer, and the communication interface; and (v) instructions stored on a non-transitory computer-readable media. The instructions, when executed, cause the processor to: (a) receive via the communication interface a first multicast transmission (e.g., an SSDP(HTTP)/Bonjour(DNS) presence announcement) from a computing hosting a digital media server, the first multicast transmission indicating the presence of the digital media server (DLNA music server) on a network (e.g., a LAN); (b) transmit via the communication interface a request for a unicast connection to the digital media server; and (c) in the absence of a response to the request for a uncast connection, transmit via the communication interface a second multicast transmission. The second multicast transmission includes information that allows the digital media server to establish a connection with the audio playback device to facilitate transmission of a unicast request for content.
Implementations may include one of the above and/or below features, or any combination thereof.
In some implementations, the audio playback device includes a set of user-selectable preset indicators. Each indicator in the set of preset indicators is configured to have assigned to it an entity associated with the plurality of digital audio sources.
Another aspect features a non-transitory computer readable storage medium that includes a set of instructions for execution by a processor. The set of instructions, when executed, cause the processor to: (i) receive via an audio playback device a first multicast transmission (e.g., an SSDP(HTTP)/Bonjour(DNS) presence announcement) from a computer hosting a digital media server, the first multicast transmission indicating the presence of the digital media server (DLNA music server) on a network (e.g., a LAN); (ii) transmit via the audio playback device a request for a unicast connection to the digital media server; and (iii) in the absence of a response to the request for a unicast connection, transmit via the audio playback device a second multicast transmission. The second multicast transmission includes information that allows the digital media server to establish a connection with the audio playback device to facilitate transmission of a unicast request for content.
Another aspect provides a non-transitory computer readable storage medium that includes a set of instructions for execution by a processor. The set of instructions, when executed, causes the processor to receive via a digital media server a first multicast transmission transmitted via an audio playback device, and, in response to the first multicast transmission, establish communication with the audio playback device based on information included in the first multicast transmission. The information included in the first (multicast) communication includes an identification of a port on the audio playback device through which the communication is established.
This disclosure is based, at least in part, on the realization that it can be beneficial to establish a method through which a computer hosting a digital media server can establish a connection with an audio playback device when a firewall running on the computer otherwise blocks in-bound communications from the audio playback device. This approach could also work if the firewall is running on another computer (i.e., other than the one hosting the digital media server).
System Overview
Referring to
The audio playback devices 110 are electronic devices which are capable of rendering audio content. These devices can access stored audio content (e.g., remotely stored audio content) and stream it for playback. In some cases, the audio playback devices 110 may also be capable of playing locally stored content. These devices render audio with the help of audio codecs and digital signal processors (DSPs) available within.
The audio playback devices 110 can communicate with each other. For example, each audio playback device 100 can communicate with the other audio playback devices 110 within the audio system 100 for synchronization. This can be a synchronization of device settings, such as synchronization of preset assignments, or, for synchronization of playback (e.g., such that all or a subset of the audio playback devices 110 play the same content simultaneously and synchronously).
The digital audio sources 120 are devices and/or services that provide access to one or more associated entities for supplying content (e.g., audio streams) to the audio playback devices 110, and which can be located remotely from the audio playback devices 110. An “entity,” as used herein, refers to a grouping or collection of content for playback. Exemplary entities include Internet radio stations and user defined playlists. “Content” is data (e.g., an audio track) for playback. “Associated entity” refers to an entity that is associated with a particular audio source. For example, if the digital audio source 120 is an Internet music service such as Pandora®, an example associated entity would be a radio station provided by Pandora®.
For the purposes of the audio system 100, audio streams are considered to be data. They are processed as digital information that is converted to analog before presentation. Data streaming is the method by which data is moved from an audio source 120 to an audio playback device 110. Typically, there are two models for this data movement, push and pull. The audio system 100 is capable of managing this audio (data) streaming in both fashions; descriptions of these processes are as follows.
In a push model, the digital audio source 120 will move the data to the audio playback device 110 at a pace that it desires. The recipient (e.g., one of the audio playback devices 110) of the data will acknowledge the data and the digital audio source 120 will provide more data. This model requires the digital audio source 120 to be managing the throughput characteristics of the audio system 100. In a pull model, the audio playback device 110 will request data from the digital audio source 120 at a rate it desires. This allows the audio playback device 110 to read ahead if data is available.
The digital audio sources 120 each maintain a repository of audio content which can be chosen by the user to play. The digital audio sources 120 can be based on the Digital Living Network Alliance® (DLNA) or other Web based protocols similar to the Hypertext Transfer Protocol (HTTP). Some of the devices and services in this category include Internet based music services 120a such as Pandora®, Spotify®, and vTuner®; network-attached storage (NAS) devices 120b, and a media server daemon 120c (e.g., provided as a component of a computer-based controller).
The digital audio sources 120 include user defined playlists of digital music files available from network audio sources such as network-attached storage (NAS) devices 120b, and a digital music server 120c (DLNA® music server), which may be accessible to the audio playback devices 110 over a local area network such as a wireless (Wi-Fi) or wired (Ethernet) home network 150, as well as Internet radio sites 120a such as Pandora®, vTuner®, Spotify®, etc., which are accessible to the audio playback devices 110 over a wide area network 160 such as the Internet.
The controllers 130 are responsible for controlling the audio playback devices 110 and for browsing the audio sources 120 in the audio system 100. Some of the devices in this category include desktop computers, laptop computers, and mobile devices such as smart phones and tablets. These devices control the audio playback devices 110 via a wireless communication interface (e.g., IEEE 802.11 b g, Bluetooth LE, infrared, etc.). The controllers 130 serve as an online management tool for a user's network enabled audio playback devices 110. The controllers 130 provide interfaces which enable to the user to perform one or more of the following: setup a connection to a Wi-Fi network; create an audio system account for the user, sign into a user's audio system account and retrieve information; add or remove an audio playback device 110 on a user's audio system account; edit an audio playback device's name, and update software; access the audio sources (via the audio playback devices 110); assign an entity (e.g., a playlist or radio station) associated with one of the audio sources 120 to a preset indicator; browse and select recents, where “recents” refers to recently accessed entities; use transport controls (play/pause, next/skip, previous), view “Now Playing” (i.e., content currently playing on an audio playback device 110) and album art; and adjust volume levels.
In some cases, the controllers 130 may include network controllers 130a, 130b and auxiliary controllers 130c. The network controllers 130a, 130b are controllers that communicate with the audio playback devices 110 over a wireless (Wi-Fi) network connection. The network controllers can include primary network controllers 130a and secondary network controllers 130b. The primary network controllers 130a can be utilized for: connecting an audio playback device 110 to a Wi-Fi network; creating a system account for the user; setting up music services; browsing of content for playback; setting preset assignments on the audio playback devices 110; transport control (e.g., play/pause, fast forward/rewind, etc.) for the audio playback devices 110; and selecting audio playback devices 110 for content playback (e.g., single room playback or synchronized multi-room playback). Devices in the primary network controller category can include desktop and laptop computers.
The secondary network controllers 130b may offer some, but not all, of the functions of the primary network controllers 130a. For example, the secondary network controllers 130b may not provide for all of the account setup and account management functions that are offered by the primary network controllers 130a. The secondary network controllers 130b may be used for: music services setup; browsing of content; setting preset assignments on the audio playback devices; transport control of the audio playback devices; and selecting audio playback devices 110 for content playback: single room or synchronized multi-room playback. Devices in the secondary network controller category can include mobile devices such as smart phones and tablets.
The auxiliary controllers 130c communicate wirelessly (e.g., via Bluetooth low energy (BTLE) or IR) with an associated (e.g., paired) one of the audio playback devices (item 110,
The remote server 140 is a cloud-based server which contains (e.g., within an account database) information related to a user's audio system account. This includes user account information such as the list of the audio playback devices 110 within the system 100, device diagnostic information, preset assignments, etc. The remote server 140 will be connected to by the audio playback devices 110 and by the controllers 130 (e.g., by primary network controllers) for the purpose of preset management, as well as management of audio sources 120 and management of the user's audio system account. Generally, the controllers 130 (e.g., network controllers 130a, 130b) will login to the remote server 140 with a user's login details and ‘sync down’ the required information to work with.
The audio playback devices 110 and one or more of the controllers 130 are coupled to a local area network (LAN) 150. Other devices such as one or more of the digital audio sources (e.g., a network-attached storage (NAS) device 120b) may also be coupled to the LAN 150. The LAN 150 may be a wired network, a wireless network, or a combination thereof. In one example, the devices (e.g., audio playback devices 110 and controllers 130 (e.g., primary and secondary controllers 130a, 130b)) within the LAN 150 are wirelessly coupled to the LAN 150 based on an industry standard such as IEEE 802.11 b/g. The LAN 150 may represent a network within a home, an office, or a vehicle. In the case of a residential home, the audio playback devices 110 may be arranged in different rooms (e.g., kitchen, dining room, basement, etc.) within the home. The devices within the LAN 150 connect to a user supplied access point 170 (e.g., a router) and subsequently to a wide area network (WAN) 160 (e.g., the Internet) for communication with the other digital audio sources 120 (Internet based music services 120a) and the remote server 140.
Notably, the audio system 100 can provide for the management of presets (a/k/a preset assignments). Presets are a set of (e.g., six) user-defined shortcuts to content, intended to provide quick access to entities associated with the digital music sources 120 from (1 of 6) preset indicators present on each of the audio playback devices 110. In some cases, the preset indicators can be hardware buttons. Alternatively, the preset indicators may be virtual buttons defined by regions on a touch sensitive display. The individual preset indicators can be denoted with numerical identifiers.
The preset indicators on the audio playback devices 110 provide access to their respectively assigned entities irrespective of the associated digital audio source. More specifically, the preset indicators can provide for single press access to the respectively assigned entities, irrespective of the digital audio source. That is, a single press of a preset indicator will start the streaming and rendering of content from an entity assigned to that preset indicator regardless of the audio source providing that entity. In that regard, the presets are said to be source agnostic in that they behave in the same manner regardless of the audio source. In some cases, the single press access can be facilitated with the distribution of tokens for accessing account based audio sources which normally require a user to login with account credentials.
The presets can be global or local at the user's option. The user can select the global or local option, e.g., during set up of the user's system account. If the user's account is set to provide for global presets, the preset assignments will be synchronized on all the audio playback devices 110 across the audio system 100 such that preset assignments on any one of the audio playback devices correspond to respective preset assignments on each of the other audio playback devices (e.g., such that preset indicator “1” on a first one of the audio playback devices is assigned to the same entity as preset indicator “1” on all of the other audio playback devices 110 in the audio system 100), and, such that, if one of the preset assignments is changed on one of the audio playback devices 110, each of the other audio playback devices 110 is automatically updated such that a corresponding change is made to a corresponding preset assignment on each of the other audio playback devices. The synchronization of the preset assignments is managed through a combination of communications between the audio playback devices 110 with the remote server 140, and communications among the audio playback devices 110 themselves. A copy of the global preset assignments is stored locally on each audio playback device 110 associated with the user's account, and a copy of the global preset assignments is also maintained on the remote server 140. Additional details regarding the synchronization of presets among devices is provided in U.S. patent application Ser. No. 13/833,394, the complete disclosure of which is incorporated herein by reference.
As mentioned above, there is a digital media server 120c (e.g., a DLNA® server daemon) that runs on the primary controller 130a (a/k/a computer 130a). The digital media server 120c serves music from the user's computer (e.g., iTunes, Windows Media Player, or files in a folder) to audio playback devices 110. The digital media server 120c is installed as a system service and always runs when the computer 130a is booted. The digital media server 120c can provide the user with the options for enabling and disabling the serving of the selected music library.
The audio playback devices 110 discover the digital media server 120c through a discovery protocol (e.g., Simple Service Discovery Protocol (SSDP) or Bonjour), and can then expose a catalog of content on the digital media server 120c to the user (e.g., via a user interface on one of the controllers 130) to allow the user to navigate through the content and select content from the digital media server 120c for playback via the audio playback device(s) 110. Communication occurs between the controller 130 and the audio playback device 130, and between the audio playback device 110 and the digital media server 120c, such that the audio playback device 110 is the network device that actually retrieves/requests the content from the digital media server 120c.
Generally, the way that the discovery protocol works is as each audio playback device 110 is added to the LAN 150 it will announce itself by transmitting a presence announcement, and it will also transmit a discovery request (e.g., an HTTP UDP discovery request). The presence announcement is a multicast transmission that is transmitted to a multicast port on the other devices on the LAN 150 so that the other network devices know that the transmitting device is on the network. The discovery request is another multicast transmission that is transmitted to a multicast port on the other devices on the LAN to help the transmitting device identify the other devices (e.g., other audio playback devices 130 and the computer/controller 130a hosting the digital media server 120c) on the LAN.
Alternatively or additionally, the computer/controller 130a hosting the digital media server 120c may periodically transmit a presence announcement to allow the other devices on the LAN to know that it is present on the LAN and that it offers a digital media server 120c as a service.
Once the audio playback devices 110 discover the digital media server 120c, the audio playback devices 110 can then attempt to establish a unicast connection to the digital media server 120c so that it can send content requests (e.g., HTTP requests) to the digital media server 120c to retrieve content from the digital media server 120c. These content requests are unicast transmissions addressed only to the digital media server 120c, and may include, inter alia, request for a file (e.g., an xml file) that describes the capabilities of the digital media server 120c, navigation requests to navigate through a menu hierarchy of the digital media server 120c, or requests for audio content.
An interesting problem may occur in configurations in which the computer 130a that hosts the digital media server 120c also hosts a firewall. In such configurations, the firewall generally will not block the multicast transmissions, so the audio playback devices 110 will be able to discover the computer 130a hosting the digital media server 120c and vice-versa. The firewall may, however, block the subsequent attempts to establish a unicast connection coming in from the audio playback devices 110. This is because firewalls typically do not block in-coming transmissions on dedicated multicast ports, but they do often block transmissions coming in on other ports, e.g., to prevent malicious software from accessing the host device over those other ports.
One solution to this problem is to configure the firewall so that it allows incoming communications intended for the digital music server 120c. However, that solution may be beyond the skill of a typical user and it may be difficult to implement automatically (e.g., via software) in a scalable manner since many different firewalls exist and new firewalls may yet be developed and each firewall may require a different configuration. Another solution to this problem would be to deactivate the computer's firewall altogether; however, that could leave the computer 130a vulnerable to the types of attacks that the firewall is designed to prevent.
The process outlined in
Referring to
A first audio playback device (i.e., a first one of the audio playback devices 110,
At step 228, the request for a unicast connection is blocked via a firewall running on the computer 130a that is hosting the digital media server 120c. In general, firewalls will not block in-coming communications on a dedicated multicast channel/port; so, the discovery requests and other multicast announcements will pass through. However, the subsequent request to establish a unicast connection may be blocked by the firewall.
After a pre-determined period of no response from the digital music server 120c, the request for a unicast connection will timeout (step 230). When this occurs, the first audio playback device 110 will then transmit a multicast presence announcement and include with the transmission an indication that the first audio playback device 110 is capable of reverse communication along with an identification of a port number for communication (step 232).
The computer 130a will receive the multicast presence announcement from the first audio playback device 110 (step 234) and, based on the additional information provided in the transmission, will conclude that the first audio playback device 110 attempted to reach the digital media server 120c and will then use that additional information to establish a connection to the first audio playback 110 via the port number identified in the presence announcement. That is, the digital media server application will initiate a connection using the host computer's networking stack. In that regard, the digital media server 120c will send a request to establish a unicast connection via the port number identified in the presence announcement (step 236). That request will get through the firewall, and, at step 237, the first audio playback device 110 will receive the request from the digital media server 120c via the identified port number and a unicast connection will be established. This essentially establishes a line of communication between the first audio playback device 110 and the digital media server 120c which will not be blocked by the host computer's firewall.
Once the connection is established with the digital media server 120c, the first audio playback device 110 can transmit a unicast request for content (a/k/a “content request”) to the digital media server 120c over the newly established unicast connection (step 238). This unicast request for content may be a request to download a file (e.g., an .xml file) that describes what the digital media server name is, who owns it, who developed it, and what music server capabilities it has. Alternatively or additionally, the request may include a request to navigate into a menu on the server 120c, or a request to play a particular song in a particular server location (e.g., by URL). The unicast request may be prompted by input received from the user either through one of the controllers 130, or directly though a user interface on the first audio playback device 110 itself, such as will occur when the user presses a preset indicator that is associated with content on the digital media server 120c. The request will be received by the digital media server 120c without being blocked by the host computer's firewall (step 240). The digital media server 120c can then send the requested content (step 242) to the first audio playback device 110, and the first audio playback device 110 will receive the requested content via the unicast connection (step 243).
In some cases, when the first audio playback device 110 fails to reach the digital media server 120c and, as a result, transmits a multicast presence announcement with the information necessary for the computer 130c to establish reverse communication with the first audio playback device 110, the other audio playback devices 110 on the network will also receive the multicast transmission from the first audio playback device 110 (step 244), and, in response, will each transmit their own respective multicast presence announcement with information that will allow the computer 130a to also connect to each of the other audio playback devices 110 (step 246). This will establish unicast connections between the digital media server 120c and each of those other audio playback devices 110 so that subsequent unicast content requests from those other audio playback devices 110 will not be blocked by the firewall running on the computer 130a.
In some instances, the first audio playback device 110 can be configured to transmit multiple multicast presence announcements substantially simultaneously (e.g., one after the other). For example, Microsoft Windows devices have a tendency to be SSDP centric, whereas Apple devices have a tendency to utilize Bonjour—a DNS based service discovery. With Apple devices, the above described reversal mechanism may not work with SSDP/HTTP-based announcements because Apple devices sometimes block the SSDP ports. For this reason, the first audio playback device 110 may be configured such that, when a request for a unicast connection to the digital media server 120c times out, the first audio playback device 110 not only transmits an SSDP/HTTP-based presence announcement (step 232) with the above mentioned additional information, but also transmits a corresponding Bonjour/DNS-based presence announcement (step 248) with the additional information substantially simultaneously so that, even if the SSDP ports are blocked, e.g., by an Apple device hosting the digital media server 120c, the multicast presence announcement may still reach the computer 130a via the Bonjour protocol. Likewise, the other audio playback devices 110 can also be configured such that, when they see a multicast presence announcement with the reverse communication information from the first audio playback device 110, they too transmit their own respective multicast presence announcements via both discovery protocols as well (steps 246 and 250), and the digital media server 120c may similarly send requests to establish unicast connections via respective ports on each of the other audio playback devices.
Audio Playback Devices
An exemplary audio playback device 110 will now be described in greater detail with reference to
The assigned entities can be associated with different ones of the digital audio sources (items 120a, 120b, 120c,
Notably, the preset indicators 318 operate in the same manner, at least from the user's perspective, regardless of which entities are assigned and which of the digital audio sources provide the assigned entities. That is, each preset indicator 318 can provide for single press access to its assigned entity whether that entity is a user-defined playlist of digital music provided by an NAS device or an Internet radio station provided by an Internet music service.
With reference to
The network interface 320 provides for communication between the audio playback device 110 and the controller (e.g., items 130a-c,
In some cases, the network interface 320 may also include a network media processor 334 for supporting Apple AirPlay® (a proprietary protocol stack/suite developed by Apple Inc., with headquarters in Cupertino, Calif., that allows wireless streaming of audio, video, and photos, together with related metadata between devices). For example, if a user connects an AirPlay® enabled device, such as an iPhone or iPad device, to the LAN 150, the user can then stream music to the network connected audio playback devices 110 via Apple AirPlay®. A suitable network media processor is the DM870 processor available from SMSC of Hauppauge, N.Y. The network media processor 334 provides network access (i.e., the Wi-Fi network and/or Ethernet connection can be provided through the network media processor 334) and AirPlay® audio. AirPlay® audio signals are passed to the processor 322, using the I2S protocol (an electrical serial bus interface standard used for connecting digital audio devices), for downstream processing and playback. Notably, the audio playback device 110 can support audio-streaming via AirPlay® and/or DLNA's UPnP protocols, and all integrated within one device.
All other digital audio coming from network packets comes straight from the network media processor 334 through a USB bridge 336 to the processor 322 and runs into the decoders, DSP, and eventually is played back (rendered) via the electro-acoustic transducer(s) 315.
The network interface 310 can also include a Bluetooth low energy (BTLE) system-on-chip (SoC) 338 for Bluetooth low energy applications (e.g., for wireless communication with a Bluetooth enabled controller (item 130c,
Streamed data pass from the network interface 320 to the processor 322. The processor 322 can execute instructions within the audio playback device (e.g., for performing, among other things, digital signal processing, decoding, and equalization functions), including instructions stored in the memory 328. The processor 322 may be implemented as a chipset of chips that include separate and multiple analog and digital processors. The processor 322 may provide, for example, for coordination of other components of the audio playback device 110, such as control of user interfaces, applications run by the audio playback device 110. A suitable processor is the DA921 available from Texas Instruments.
The processor 322 provides a processed digital audio signal to the audio hardware 324 which includes one or more digital-to-analog (D/A) converters for converting the digital audio signal to an analog audio signal. The audio hardware 324 also includes one or more amplifiers which provide amplified analog audio signals to the electroacoustic transducer(s) 315 for playback. In addition, the audio hardware 324 may include circuitry for processing analog input signals to provide digital audio signals for sharing with other devices in the acoustic system 100.
The memory 328 may include, for example, flash memory and/or non-volatile random access memory (NVRAM). In some implementations, instructions (e.g., software) are stored in MEMORY 328. The instructions, when executed by one or more processing devices (e.g., the processor 322), perform one or more processes, such as those described above (e.g., with respect to
The instructions may also include instructions for enabling certain “browsing” functionality. That is, at least in some cases, the controllers (items 130a-c,
Computer/Controller
Referring to
The processor 400 can execute instructions (e.g., software) within the controller 130, including instructions stored in the memory 410 or in a secondary storage device (e.g., mass storage device 418). The processor 400 may be implemented as a chipset of chips that include separate and multiple analog and digital processors. The processor 400 may provide, for example, for coordination of other components of the controller 130a, such as control of user interfaces, applications run by the controller 130, and network communication by the controller 130. The processor 400 may communication with a user through the display 412 and the user input interface 414.
The processor 400 may communicate with the user through a display interface 420 coupled to the display 412. The display 412 may include an LCD monitor, or a touch sensitive display (e.g., in the case of a mobile device). The display interface 420 may comprise appropriate circuitry for driving the display 412 to preset graphical and other information to the user.
The user input interface 414 may include one or more user input devices such as a keyboard, a pointer device such as a mouse, and/or a touch sensitive display. In some cases, the same device (e.g., a touch sensitive display) may be utilized to provide the functions of the display 412 and the user input interface 414.
The network interface 416 facilitates wireless communication (e.g., Wi-Fi, Bluetooth, IR, etc.) with one or more of the audio playback devices (item 110,
The memory 410 stores information within the controller 130a. In some implementations, the memory 410 is a volatile memory unit or units. In some implementations, the memory 410 is a non-volatile memory unit or units. The memory 410 may also be another form of computer-readable medium, such as magnetic or optical disk.
The mass storage device 418 is capable of providing mass storage for the controller 130a. In some implementations, the mass storage device 418 may be or contain a computer readable medium, such as a floppy disk device, a hard disk device, an optical disk device, or a tape device, a flash memory or other similar solid state memory device, or an array of devices.
Instructions (e.g., software) can be stored in an information carrier. The instructions, when executed by one or more processing devices (e.g., the processor 400), perform one or more processes, such as those described above (e.g., with reference to
Implementations of the systems and methods described above comprise computer components and computer-implemented steps that will be apparent to those skilled in the art. For example, it should be understood by one of skill in the art that the computer-implemented steps may be stored as computer-executable instructions on a computer-readable medium such as, for example, floppy disks, hard disks, optical disks, Flash ROMS, nonvolatile ROM, and RAM. Furthermore, it should be understood by one of skill in the art that the computer-executable instructions may be executed on a variety of processors such as, for example, microprocessors, digital signal processors, gate arrays, etc. For ease of exposition, not every step or element of the systems and methods described above is described herein as part of a computer system, but those skilled in the art will recognize that each step or element may have a corresponding computer system or software component. Such computer system and/or software components are therefore enabled by describing their corresponding steps or elements (that is, their functionality), and are within the scope of the disclosure.
A number of implementations have been described. Nevertheless, it will be understood that additional modifications may be made without departing from the scope of the inventive concepts described herein, and, accordingly, other implementations are within the scope of the following claims.
Number | Name | Date | Kind |
---|---|---|---|
5087980 | Staffer | Feb 1992 | A |
5530859 | Tobias, II et al. | Jun 1996 | A |
5655144 | Milne et al. | Aug 1997 | A |
5951690 | Baron et al. | Sep 1999 | A |
5987106 | Kitamura | Nov 1999 | A |
6134379 | LaMacchia | Oct 2000 | A |
6285405 | Binford, Jr. et al. | Sep 2001 | B1 |
6469633 | Wachter | Oct 2002 | B1 |
6631410 | Kowalski et al. | Oct 2003 | B1 |
7023833 | Aiello et al. | Apr 2006 | B1 |
7085814 | Gandhi | Aug 2006 | B1 |
7165107 | Pouyoul | Jan 2007 | B2 |
7391791 | Balassanian et al. | Jun 2008 | B2 |
7483538 | McCarty et al. | Jan 2009 | B2 |
7643894 | Braithwaite et al. | Jan 2010 | B2 |
7769865 | Parker | Aug 2010 | B1 |
7917082 | Goldberg et al. | Mar 2011 | B2 |
8234395 | Millington | Jul 2012 | B2 |
8588949 | Lambourne et al. | Nov 2013 | B2 |
8942252 | Balassanian et al. | Jan 2015 | B2 |
9100424 | Thomas | Aug 2015 | B1 |
9154534 | Gayles | Oct 2015 | B1 |
9195258 | Millington | Nov 2015 | B2 |
9213357 | Millington | Dec 2015 | B2 |
9838353 | Roskind | Dec 2017 | B2 |
9923725 | Watsen | Mar 2018 | B2 |
20020031196 | Muller et al. | Mar 2002 | A1 |
20020067909 | Iivonen | Jun 2002 | A1 |
20020131398 | Taylor | Sep 2002 | A1 |
20020143855 | Traversat | Oct 2002 | A1 |
20030050989 | Marinescu et al. | Mar 2003 | A1 |
20030101294 | Saint-Hilaire | May 2003 | A1 |
20040008661 | Myles et al. | Jan 2004 | A1 |
20040136375 | Koguchi | Jul 2004 | A1 |
20040267937 | Klemets | Dec 2004 | A1 |
20050005014 | Holmes | Jan 2005 | A1 |
20050240758 | Lord | Oct 2005 | A1 |
20060013208 | Rietschel et al. | Jan 2006 | A1 |
20060182100 | Li | Aug 2006 | A1 |
20060215684 | Capone | Sep 2006 | A1 |
20070142944 | Goldberg et al. | Jun 2007 | A1 |
20070150570 | Eastham | Jun 2007 | A1 |
20070153812 | Kemp | Jul 2007 | A1 |
20070160034 | Koretsky | Jul 2007 | A1 |
20070169115 | Ko | Jul 2007 | A1 |
20070180485 | Dua | Aug 2007 | A1 |
20070180512 | Chaudhuri | Aug 2007 | A1 |
20070226360 | Gupta | Sep 2007 | A1 |
20070233879 | Woods | Oct 2007 | A1 |
20080215669 | Gaddy | Sep 2008 | A1 |
20090006648 | Gopalakrishnan | Jan 2009 | A1 |
20090059952 | Kalofonos | Mar 2009 | A1 |
20090094317 | Venkitaraman | Apr 2009 | A1 |
20090125609 | Wood | May 2009 | A1 |
20090125633 | Watsen | May 2009 | A1 |
20090300721 | Schneider | Dec 2009 | A1 |
20090323632 | Nix | Dec 2009 | A1 |
20090327244 | Rizal | Dec 2009 | A1 |
20090327521 | Huotari | Dec 2009 | A1 |
20100014529 | Takechi | Jan 2010 | A1 |
20100115119 | Gallo et al. | May 2010 | A1 |
20100146126 | Lin | Jun 2010 | A1 |
20100205309 | Skog | Aug 2010 | A1 |
20100268832 | Lucas | Oct 2010 | A1 |
20100325248 | Camarillo Gonzalez | Dec 2010 | A1 |
20110082922 | Ahn | Apr 2011 | A1 |
20110131518 | Ohashi | Jun 2011 | A1 |
20110150432 | Paul | Jun 2011 | A1 |
20110216753 | Kneckt | Sep 2011 | A1 |
20110219123 | Yang | Sep 2011 | A1 |
20110295974 | Kashef | Dec 2011 | A1 |
20120087302 | Chaturvedi | Apr 2012 | A1 |
20120136944 | Stewart | May 2012 | A1 |
20120281852 | Beckmann | Nov 2012 | A1 |
20130089026 | Piper | Apr 2013 | A1 |
20130124735 | Shin | May 2013 | A1 |
20130346564 | Warrick | Dec 2013 | A1 |
20140052770 | Gran | Feb 2014 | A1 |
20140055554 | Du | Feb 2014 | A1 |
20140178052 | Kim | Jun 2014 | A1 |
20140280938 | Kadaba | Sep 2014 | A1 |
20140366105 | Bradley | Dec 2014 | A1 |
20150012646 | Yang | Jan 2015 | A1 |
20150019759 | Tran | Jan 2015 | A1 |
20150052235 | Tokunaga | Feb 2015 | A1 |
20150054947 | Dawes | Feb 2015 | A1 |
20150058431 | Srikanth | Feb 2015 | A1 |
20150058634 | Watsen | Feb 2015 | A1 |
20150089025 | Liang | Mar 2015 | A1 |
20150127853 | Roskind | May 2015 | A1 |
20150135265 | Bagrin | May 2015 | A1 |
20150244808 | Wulfsohn | Aug 2015 | A1 |
20150280986 | Abuan | Oct 2015 | A1 |
20150326332 | Chen | Nov 2015 | A1 |
20150365457 | Dvir | Dec 2015 | A1 |
20160142259 | Rajagopala-Rao | May 2016 | A1 |
20160164933 | Kafle | Jun 2016 | A1 |
20160173659 | Sheu | Jun 2016 | A1 |
20160191461 | Wang | Jun 2016 | A1 |
20160234320 | Chang | Aug 2016 | A1 |
20160295296 | Zhu | Oct 2016 | A1 |
20170039372 | Koval | Feb 2017 | A1 |
20170047066 | Liu | Feb 2017 | A1 |
20170099153 | Watsen | Apr 2017 | A1 |
20170134422 | Shieh | May 2017 | A1 |
20170163691 | Alon | Jun 2017 | A1 |
20170302703 | Buruganahalli | Oct 2017 | A1 |
20180019890 | Dawes | Jan 2018 | A1 |
Number | Date | Country |
---|---|---|
1966692 | Sep 2008 | EP |
1996001540 | Jan 1996 | WO |
9856135 | Dec 1998 | WO |
2000076272 | Dec 2000 | WO |
0108366 | Feb 2001 | WO |
2003058830 | Jul 2003 | WO |
2007077633 | Jul 2007 | WO |
Entry |
---|
Chesire, et al. “Multicast DNS,” 2013, IETF RFC 6762. |
“Bonjour Overview,” 2013, Apple Inc. |
Srisuresh, et al. “State of Peer-to-Peer (P2P) Communication across Network Address Translators (NATs),” 2008, IETF RFC 5128. |
International Search Report and Written Opinion dated Jun. 30, 2016 for International Application No. PCT/US2016/024947. |
Yahun Y Goland Ting Cai Paul Leach Ye Gu Microsoft Corporation Shivaun Albright Hewlett-Packard Company: “Simple Service Discovery Protocol/1.0 Operating without an Arbiter; draft-cai-ssdp-vl-3.txt”, 5. JCT-VC Meeting; 96. MPEG Meeting; Mar. 16, 2011-Mar. 23, 2011; Geneva; (Joint Collaborative Team on Video Coding of ISO/IEC JTC1/SC29/WG11 and ITU-T SG.16); URL: http://wftp3.itu.int/av-arch/jctvc-site/, Internet Engineering Task Ford, IETF, CH, No. 3, Oct. 28, 1999. |
Fireball DVD and Music Manager DVDM-100, Installation and User's Guide, Escient Manual No. M22003-01A3, Revision 1.2, Jul. 2004, 361 pages. |
Escient Fireball E2 User's Manual, P/N: M22004-01A3, copyright 2004, 369 pages. |
Escient Fireball AVX & MX Series User's Manual, P/N: M42001-02A1, copyright 2006, 136 pages. |
Avega Uses Wireless, UPnP to Network Home Speakers, by Joseph Palenchar, Jan. 5, 2006, https://www.twice.com/product/avega-uses-wireless-upnp-network-home-speakers-2973, 3 pages, retrieved Dec. 18, 2017. |
Avega: Wireless Is More, CES 2006, by Wes Phillips, Jan. 4, 2006, https://www.stereophile.com/ces2006/010406avega/index.html, 4 pages, retrieved Dec. 18, 2017. |
Avega's Oyster Is a Pearl, by Mike Kobrin, Jan. 6, 2006, https://www.pcmag.com/article2/0,2817,1908704,00.asp, 2 pages, retrieved Dec. 18, 2017. |
Escient Fireball DVDM-100 Review, by Nathaniel Wilkins, Dec. 14, 2004, https://www.cnet.com/products/escient-fireball-dvdm-100/review/, 4 pages, retrieved Dec. 18, 2017. |
Escient Fireball DVDM-100 Review & Rating, by Bill Howard, Mar. 16, 2004, https://www.pcmag.com/article2/0,2817,1549587,00.asp, 5 pages, retrieved Dec. 18, 2017. |
Escient Fireball E2 Digital Music Server Review, by Nathaniel Wilkins, Jun. 14, 2006, https://www.cnet.com/products/escient-fireball-e2-400-400gb/review/, 4 pages, retrieved Dec. 18, 2017. |
Escient Fireball E-40 Digital Music Manager Review, by Nathaniel Wilkins, Oct. 12, 2003, https://www.cnet.com/products/escient-fireball-e-40-digital-music-manager/review/, 9 pages, retrieved Jan. 23, 2018. |
Escient Fireball SE-80 Digital Music Manager, by Michael Antonoff, Oct. 4, 2005, https://www.soundandvision.com/content/escient-fireball-se-80-digital-music-manager, 5 pages, retrieved Dec. 18, 2017. |
Universal Plug and Play, Wikipedia, https://en.wikipedia.org/wiki/Universal_Plug_and_Play, 10 pages, retrieved Jan. 10, 2018. |
Wi-Fi Pearl to be Found in Oyster Speakers?, by Digital Trends Staff, Jan. 2, 2006, https://www.digitaltrends.com/home-theater/wi-fi-pearl-to-be-found-in-oyster-speakers/, 4 pages, retrieved Dec. 18, 2017. |
Number | Date | Country | |
---|---|---|---|
20160294884 A1 | Oct 2016 | US |