Systems and methods for providing a media playback in a networked environment

FIELD OF THE INVENTION

The present invention relates to systems and methods for providing media playback in a networked environment. Embodiments of the invention have been particularly developed to allow a wireless web enabled portable device (such as an MP3 player, cellular telephone, or the like) to interface with one or more networked media playback devices without the need to install special software on the portable device. While some embodiments will be described herein with particular reference to that application, it will be appreciated that the invention is not limited to such a field of use, and is applicable in broader contexts.

BACKGROUND

A networked media playback device (such as a networked speaker device) typically includes a central processing unit coupled to a memory unit, a networking interface and output hardware (such as an amplifier and one or more speaker cones in the case of a speaker). The central processing unit provides a media rendering functionality whereby data indicative of audio received via the networking interface is processed to provide a corresponding audible output via the audio output hardware. In the case of a wireless media playback device, the networking interface typically implements a wireless networking standard such as the IEEE 802.11 standard.

Control of a networked media playback device is typically achieved by way of either a purpose-built control device, or by way of another computational platform that runs a software application for allowing control functionality. For example, a common approach is to provide a software-based media player application on a networked PC.

Digital media files might reside at various locations on a network. These locations might include various PCs, networked storage devices, and networked personal media playback devices. The Universal Plug and Play Audio and Video (UPnP AV) standard, supervised by the Digital Living Network Alliance (DLNA), provides a useful framework for allowing playback of digital media files residing at such locations. In particular, the UPnP AV standard regards such locations as “media servers”, and provides a framework whereby a “media renderer” (a playback device) obtains media for playback front those locations. Under such a framework, it is necessary to have three components: a media server for maintaining the media, a media renderer for playing back the media, and a control device for providing instructions.

It is known to install software on portable devices to allow those devices to take on roles within a UPnP AV arrangement, for example as control devices. However, it is not always possible, practical, and/or preferable to install such software on those devices.

SUMMARY

Described herein are devices, systems and methods for providing media playback in a wireless speaker devices and/or wireless audio systems. However, although wireless speaker devices and wireless audio systems are considered as a primary example, various embodiments are equally applicable to other audio systems, particularly other networked audio systems, and networked digital media playback systems generally.

One embodiment provides a method, in a networked media playback device, for allowing a wireless web enabled device to provide media playback control signals for the networked media playback device or a networked media playback system, the method including the steps of <ul id="ul0001" list-style="none"><li id="ul0001-0001" num="0000"><ul id="ul0002" list-style="none"><li id="ul0002-0001" num="0008">(i) providing a local web server for delivering data indicative of a browser-renderable control interface for the networked media playback device or networked media playback system;</li><li id="ul0002-0002" num="0009">(ii) being responsive to a predetermined request from a wireless web enabled device for delivering data indicative of the control interface for rendering in a web browser of the wireless web enabled device;</li><li id="ul0002-0003" num="0010">(iii) being responsive to utilization of the control interface as rendered in the web browser application for defining one or more playback control commands; and</li><li id="ul0002-0004" num="0011">(iv) implementing the one or more playback control commands in the networked media playback device or networked media playback system.</li></ul></li></ul>

One embodiment provides a method wherein step (ii) includes: <ul id="ul0003" list-style="none"><li id="ul0003-0001" num="0000"><ul id="ul0004" list-style="none"><li id="ul0004-0001" num="0013">(iia) receiving data indicative of a browser navigation request from the wireless web enabled device, the browser navigation request being indicative of a predetermined URI;</li><li id="ul0004-0002" num="0014">(iib) being responsive to the browser navigation for resolving the URI to the local web server such that the data indicative of the control interface is delivered in response to the browser navigation request.</li></ul></li></ul>

One embodiment provides a method wherein the networked media playback device provides a local domain name server for allowing resolution of the predetermined URI.

One embodiment provides a method wherein the networked media playback device or networked media playback system is controllable in accordance with the UPnP protocol.

One embodiment provides a method wherein the wireless web enabled device includes a memory unit that maintains one or more media files, and the one or more playback commands includes an instruction to render a selected one or more of the media files via the networked media playback device or networked media playback system.

One embodiment provides a method including the steps of: <ul id="ul0005" list-style="none"><li id="ul0005-0001" num="0000"><ul id="ul0006" list-style="none"><li id="ul0006-0001" num="0019">connecting to a wireless network;</li><li id="ul0006-0002" num="0020">identifying one or more other networked media playback devices on the network;</li><li id="ul0006-0003" num="0021">determining whether or not to provide the local web server based on analysis of the one or more other networked media playback devices on the network, such that only a single control interface is provided on the network.</li></ul></li></ul>

One embodiment provides a method wherein the control interface is for a networked media playback system haying a master networked media playback device, and the step of implementing the one or more playback control commands includes providing the one or more playback control commands to the master networked media playback device.

One embodiment provides a computer program product for performing a method as described herein.

One embodiment provides a one or more processors cause the one or more processors to carry out a method as described herein.

One embodiment provides a computer system including one or more processors configured to carry out a method as described herein.

One embodiment provides a media playback unit including: <ul id="ul0007" list-style="none"><li id="ul0007-0001" num="0000"><ul id="ul0008" list-style="none"><li id="ul0008-0001" num="0027">a networking interface for connecting to a computer network;</li><li id="ul0008-0002" num="0028">a memory module for maintaining data indicative of a browser renderable playback control interface;</li><li id="ul0008-0003" num="0029">a processor for providing a web server for delivering the data indicative of the browser renderable playback control interface to a wireless web enabled device, thereby to allow the device to control the media playback unit and/or a media playback system including the media playback unit.</li></ul></li></ul>

One embodiment provides a media playback unit wherein the networking interface includes a radio interface and wherein the computer network is a wireless network.

Reference throughout this specification to “one embodiment”, “some embodiments” or “an embodiment” means that a particular feature, structure or characteristic described in connection with the embodiment is included in at least one embodiment of the present invention. Thus, appearances of the phrases “in one embodiment”, “in some embodiments” or “an embodiment” in various places throughout this specification are not necessarily all referring to the same embodiment, but may. Furthermore, the particular features, structures or characteristics may be combined in any suitable manner, as would be apparent to one of ordinary skill in the art from this disclosure, in one or more embodiments.

Particular embodiments may provide all, some, or none of these aspects, features, or advantages. Particular embodiments may provide one or mere other aspects, features, or advantages, one or more of which may be readily apparent to a person skilled in the art from the drawings, descriptions, and claims herein.

BRIEF DESCRIPTION OF THE DRAWINGS

<figref idref="DRAWINGS">FIG. 1</figref> shows a networked media system according to one embodiment.

<figref idref="DRAWINGS">FIG. 2A</figref> shows a networked media system according to one embodiment.

<figref idref="DRAWINGS">FIG. 2B</figref> shows a networked media system according to one embodiment.

<figref idref="DRAWINGS">FIG. 2C</figref> shows a networked media system according to one embodiment.

<figref idref="DRAWINGS">FIG. 3A</figref> shows a method performed by a wireless web-enabled device according to one embodiment and a method performed by a wireless speaker according to one embodiment.

<figref idref="DRAWINGS">FIG. 3B</figref> shows a method performed by a wireless web-enabled device according to one embodiment, a method performed by a wireless speaker according to one embodiment, and a method performed by a remote server according to one embodiment.

<figref idref="DRAWINGS">FIG. 4A</figref> shows an exemplary screenshot according to one embodiment.

<figref idref="DRAWINGS">FIG. 4B</figref> shows an exemplary screenshot according to one embodiment.

<figref idref="DRAWINGS">FIG. 5</figref> shows a flowchart of one method embodiment for providing a wireless audio system.

<figref idref="DRAWINGS">FIG. 6</figref> schematically illustrates a wireless audio system embodiment including a plurality of wireless speaker subsystems.

<figref idref="DRAWINGS">FIG. 7</figref> shows a flowchart of an embodiment of a method performed by a wireless speaker subsystem.

<figref idref="DRAWINGS">FIG. 8</figref> shows a flowchart of an embodiment of a further method performed by a wireless speaker subsystem.

<figref idref="DRAWINGS">FIG. 9</figref> shows a flowchart of an embodiment of a further method performed by a wireless speaker subsystem.

<figref idref="DRAWINGS">FIG. 10</figref> shows a flowchart of an embodiment of a further method performed by a wireless speaker subsystem.

<figref idref="DRAWINGS">FIG. 11</figref> schematically illustrates data flow in a wireless audio system according to one or more aspects of the present invention.

<figref idref="DRAWINGS">FIG. 12</figref> shows a flowchart of an embodiment of a further method performed by a wireless speaker subsystem.

<figref idref="DRAWINGS">FIG. 13</figref> schematically illustrates a wireless audio system embodiment including a plurality of wireless speaker subsystems.

<figref idref="DRAWINGS">FIG. 14</figref> schematically illustrates an embodiment of a wireless speaker subsystem.

<figref idref="DRAWINGS">FIG. 15</figref> shows a flowchart of an embodiment of a further method performed by a wireless speaker subsystem.

<figref idref="DRAWINGS">FIG. 16</figref> schematically illustrates data flow in a wireless audio system embodiment.

<figref idref="DRAWINGS">FIG. 17</figref> is a plan view of a location having a plurality of wireless audio system embodiments.

DETAILED DESCRIPTION OF EMBODIMENTS

Described herein are systems and methods for providing media playback in a networked environment. In one embodiment, a networked media playback device is configured to provide a web server for delivering data indicative of a browser-renderable control interface for the networked media playback device, or for a related networked media playback system. In overview, the user of a networked device, such as a wireless web enabled device, is able to render the control interface in a web browser, and in this manner control playback of digital media via the networked media playback device or networked media playback system.

Some embodiments of the invention described herein are applicable to networked media playback devices. A networked media playback device is a hardware device capable of rendering digital media delivered to it via a computer network. In much of the description herein, wireless speakers are used as an example of networked digital media playback device. Those of ordinary skill in the art would readily be able to modify the description provided herein that is for wireless speakers and apply the methods arid apparatuses to other discrete media devices. The description is provided in terms of wireless speakers in order to keep the description simple and not obscure various significant concepts. Wireless speakers are also referred to by terms such as “wireless speaker devices” and “wireless speaker subsystem units”.

Some embodiments of the invention described herein are applicable to networked media playback systems. A networked media playback system is a system that allows one or more networked media playback devices connected via a computer network to render digital media. In much of the description herein, a wireless audio system is used as an example of a networked media playback system. Those of ordinary skill in the art would readily be able to modify the description provided herein that is for a wireless audio system and apply the methods and apparatuses to other digital media playback systems. The description is provided in terms of a wireless audio system in order to keep the description simple and not obscure various significant concepts.

<figref idref="DRAWINGS">FIG. 1</figref> illustrates a basic digital media playback system <b>100</b>. System <b>100</b> includes two wireless speaker devices, in the form of wireless speakers <b>101</b>a and <b>101</b>b. These wireless speakers are controllable individually, or collectively as a speaker set <b>101</b>c. Speakers <b>101</b>a and <b>101</b>b connect to a wireless network <b>102</b> by way of an access point <b>103</b>, in the present circumstances being a wireless network in accordance with the IEEE 802.11 standard. In some embodiments access point <b>103</b> is integrated with one of the wireless speakers.

Also connected to network <b>102</b> is a personal computer (PC) <b>104</b>. PC <b>104</b> includes a memory module for maintaining software instructions indicative of a software application for coordinating playback of media via wireless speakers <b>101</b>a and <b>101</b>b, as well as via speaker set <b>101</b>c. In the present example, this software application is identified as playback control software application <b>105</b>. Also stored in the memory of PC <b>104</b> is data indicative of a plurality of media items, such as audio tracks (e.g. WAV, MP3 and other digital audio files). In this manner, PC <b>104</b> effectively provides the functionality of a media server <b>106</b>.

In the present example, a distributed media server <b>107</b> is also connected to network <b>102</b>. This media server, in some embodiments, includes a portable media playback device (such as an MP3 player) mounted in a networked cradle device, thereby to allow playback over the network of media items stored on the portable device.

A wireless web enabled device <b>108</b> is also connected to the network. The term “wireless web enabled device” refers to substantially any device having a web-browser application and the ability to communicate over a wireless network (such as a 802.11 type network). Common examples include personal digital music players, cellular telephones, PDAs, and the like. It will be appreciated that many consumer electronic devices adopt a plurality of these roles. Prime examples of wireless web enabled devices include the iPhone and iPod Touch, distributed by Apple Inc, which make use of the Safari web browser. As discussed further below, device <b>108</b> is used to control speakers <b>102</b>a and/or <b>101</b>b (and/or speaker set <b>101</b>c).

Trademarks, product names, and business names used herein are provided for the sake of illustration only, and should not imply any permission, affiliation, or the like.

Each wireless speaker <b>101</b>a and <b>101</b>b includes a network interface <b>112</b> for connecting to network <b>102</b>, in the present example via access point <b>102</b>. Data indicative of command signals is received via this network, along with data indicative of digital media for playback. A central processing unit (CPU) <b>113</b> operates in conjunction with memory <b>114</b>, and is responsible for rendering content, processing command signals, and the like. Memory <b>114</b> includes software instructions <b>115</b>, which, among other functions, allow wireless speakers <b>101</b>a and <b>101</b>b to perform various methods, including methods described herein. It is noted that not all instructions required for performing these methods need be in memory <b>104</b> at a given time. Wireless speakers <b>101</b>a and <b>101</b>b additionally include respective audio outputs <b>117</b> (which in some embodiments includes one or more speaker cones, of other analogue outputs such as audio jacks), for allowing playback of rendered digital media as audio.

Wireless speaker set <b>101</b>c does not have a discrete hardware manifestation. Rather, in the present example, wireless speaker set <b>101</b>c is a virtual device embedded on (i.e. advertised by and controllable via) speaker <b>101</b>a, which adopts the role of a lead speaker in the context of the set, with the speaker set operating as a stereo pair (i.e. one speaker renders and plays back a left channel signal, the other a right channel signal). This functionality is described in more detail further below. However, for the time being, it is sufficient to note that speaker set <b>101</b>c provides a location to which playback instructions are able to be provided so as to affect playback of audio tracks via the speaker set.

It will be appreciated that system <b>100</b> is illustrated for the sake of example only, primarily to illustrate various components relevant to embodiments discussed herein. However, it will be appreciated that the present disclosure is equally applicable to arrangements having a greater or lesser deal of complexity as compared with system <b>100</b>. For example, in further embodiments there are a larger number of wireless speakers, which might include a plurality of individual wireless speaker sets. For the sake of the present disclosure, the following terminology is used: <ul id="ul0009" list-style="none"><li id="ul0009-0001" num="0000"><ul id="ul0010" list-style="none"><li id="ul0010-0001" num="0065">Wireless speaker. This is an individual wireless speaker (also refereed to as a “wireless speaker device” or “wireless speaker subsystem unit”), being an individually discoverable and controllable device that receives digital audio streamed over a network, and renders that data to provide an analogue output. In some cases the analogue output is provided via one or more speaker cones, and in other cases via an audio output jack or the like.</li><li id="ul0010-0002" num="0066">Wireless speaker group. A wireless speaker group (or “group”) includes a plurality of wireless speakers (although in some embodiments a wireless speaker group may be defined to include only a single wireless speaker). In some embodiments a wireless speaker group presents a single virtual device interface for receiving playback/control commands directed to the group as a whole (e.g. commands are provided to that interface which resides on one of the physical speakers, and those commands are processed for appropriate implementation amongst the individual speakers). Generally speaking, a wireless speaker group is defined for a set of wireless speakers that are, in practical terms, intended to operate as a collective. Common examples include stereo pairs, or multi channel surround sound arrangements (such as 5.1 channel surround sound).</li><li id="ul0010-0003" num="0067">Wireless speaker zone. A wireless speaker zone (or “zone”) includes at least one wireless speaker group, in combination with one or more further wireless speakers and/or wireless speaker groups. In the present embodiments, zones are defined for the sake of convenience, rather than practical necessity. For example, zones are generally defined to allow synchronous playback of audio across a region, such as a floor of a house, or a house as a whole. In some embodiments a wireless speaker zone presents a virtual device interface for receiving playback/control commands directed to the zone as a whole. The constituent groups and/or speakers also provide respective virtual interfaces, for example to allow volume individual control across portions of the zone.</li></ul></li></ul>

In general, detailed considerations in respect of the operation and interoperation of speakers, groups and zones falls beyond the scope of the present disclosure, which requires only a general understanding of the meaning of these terms.

<figref idref="DRAWINGS">FIG. 2A</figref> provides a schematic representation showing a wireless web-enabled device <b>201</b> and a wireless speaker device <b>202</b>. In overview, device <b>201</b> is used to control wireless speaker <b>202</b>, for instance in the manner described below by reference to methods <b>300</b> and <b>310</b> of <figref idref="DRAWINGS">FIG. 3</figref>.

Device <b>201</b> includes a processor <b>210</b> coupled to a memory module <b>211</b>, this mentors module maintaining software instructions <b>212</b>. Software instructions <b>212</b> allow processor <b>210</b> to execute a web browser application <b>213</b>, schematically shown as a GUI on a display screen <b>214</b>. Various web browser applications executable on portable devices are known, these generally including similar functionalities (for example the ability to render HTML content). Device <b>201</b> also includes an 802.11 type network interface <b>215</b>.

Wireless speaker <b>202</b> includes generally the same components as wireless speaker <b>101</b>a, and these ore afforded corresponding reference numerals. Speaker <b>202</b> additionally provides a web-server <b>220</b> and, in some embodiments, a domain name server <b>221</b>, It will be appreciated that these are effectively processes provided by way of software instructions <b>113</b> executing on processor <b>113</b>. Web server <b>220</b> makes available data indicative of a browser renderable control interface <b>222</b>, including HTML data for allowing the rendering of one or more web pages by way of browser application <b>213</b>.

As noted, the provision of a domain name server is optional. In some embodiments the wireless speaker provides the only domain name server on the network. However, in many cases there will be an existing domain name server on the network. Often, it is often preferable to avoid the introduction of a further domain name server. However, some embodiments described herein make use of a domain name server in the speaker itself to allow resolution of a predetermined control URI to the control interface provided by way of the speaker's web server. Other embodiments make use of a remote server arrangement to achieve a similar goal.

In the present embodiment, wireless speaker <b>202</b> provides access point functionality. For example, wireless speaker <b>202</b> advertises a wireless networldnetwork having its own SSID, allowing other components to connect to that network (referred to herein as the “speaker network”). This allows other components on the network (such as control devices, other wireless speakers, and in the present example device <b>201</b>) to connect to that network. In some embodiments, connection to the speaker network requires a degree of authentication/authorization.

In other embodiments a third patty access point is used. In some such embodiments, speaker <b>202</b> provides a virtual access point, and leverages the existing third party access point.

<figref idref="DRAWINGS">FIG. 3A</figref> illustrates methods <b>300</b> and <b>310</b>, performed respectively by speaker <b>202</b> and device <b>201</b>. These methods are described to assist in understanding the approach implemented according to the present embodiments for allowing device <b>201</b> to provide control commands to speaker <b>202</b> without the need for special software.

Dealing initially with method <b>310</b>, at step <b>311</b> device <b>201</b> connects to the speaker network. For example, using software supplied to manage the operation of wireless network interface <b>215</b>, the speaker network is selected by way of its SSID from a list of available networks. At step <b>312</b> the web browser application is launched (it will be appreciated that, in some cases, this may precede step <b>311</b>). At step <b>312</b> the browser is used to navigate to a predetermined control URL. For example, the predetermined control URL is inputted into an address bar of the web application, or a link is clicked. In some embodiments, upon connecting to the speaker network, navigation to the predetermined control URL is automatic upon each launching of the browser application.

In the example of <figref idref="DRAWINGS">FIG. 3A</figref>, the predetermined control URL is a simple web address inherently descriptive of the functionality under consideration, such as www.speakercontrol.com. To allow the use of such a web address, a local domain server is used to resolve the URI. In the present example, domain name server process <b>221</b> allows speaker <b>220</b> to resolve this URI. In this manner, the user is directed to the local control interface for the speaker network to which device <b>201</b> is connected.

Step <b>314</b> includes loading the control interface, or one page thereof, in the web browser application, for example by rendering HTML and/or other web page data. This control interface allows for browser-based control of either a single wireless speaker, or a wireless audio system (in some embodiments a user is able to select between speaker control or system control).

Step <b>315</b> includes utilizing the control interface. This step of “utlizing” varies in nature between implementations, dependent to a greater extent on the content and complexity of the control interface. Numerous approaches to providing a browser-based control interface are known in the art, and the present disclosure should not be limited to any single such approach. For example, combinations of any of HTML, DHTML, ActiveX controls, Flash objects, JavaScript, and the like are used in various embodiments.

In some embodiments, noting the application to portable devices, the control interface is relatively rudimentary to account for the simple nature of many portable web browser applications. For example, in some embodiments, HTML-based buttons and the like are provided, and manipulation of these results in data being transmitted from the browser to the web server. In one simple embodiment, the control interface provides a display showing current operational characteristics of the speaker (playback status, volume, etc), and allows a user to enter modified operational characteristics. Subject to a postback event, the modified operational characteristics are transmitted to the web server to allow implementation of those modified operational characteristics. The control interface is, in some cases, then re-rendered to display the modified operational characteristics as current operational characteristics.

Dealing now with method <b>300</b>, step <b>301</b> includes providing a wireless access point. This is, in the present embodiment, performed at the time speaker <b>202</b> is initialized. Step <b>302</b> includes providing a local web server. This includes commencing a web server process based on locally stored software instructions.

The term “local web server” generally describes a process that runs on the wireless speaker and listens for requests to deliver browser renderable content (for example when a user of a web-browser navigates to a web page deliverable by the local web server). The wireless speaker also maintains web page data (such as HTML and/or other data) indicative of one or more web pages that are deliverable by the web browser. One or more of these pages provides a browser-renderable control interface for the wireless speaker or wider wireless speaker group/zone. The term “browser-renderable control interface” generally describes one or more web pages that are renderable in a web browser application. The page or pages provide control features, which allow a user to apply operational changes to the wireless speaker of to the wireless speaker group/zone (for example, these operational changes might be used to control playback of audio via the speaker or speakers).

Step <b>303</b> includes receiving data indicative of a request to navigate to the control URL, this being triggered by step <b>313</b>. Step <b>304</b> includes delivering data indicative of the control interface for rendering in the web browser. In some embodiments, this step includes dynamically generating HTML for one or more web pages. For example, in some embodiments the HTML is dynamically generated based an analysis of current operational characteristics for the speaker/system.

Step <b>305</b> includes defining control commands corresponding to utilization of the control interface. Step <b>305</b> also includes delivering further data indicative of the control interface. For example, utilization of the interface may result in navigation to other pages, or require the updating/re-rendering of the current page (or one or more page elements thereof).

The defining of control commands, in some embodiments, includes the speaker adopting a role as a control device (for example a control device in accordance with the UPnP framework). Generally speaking, a translation protocol is established such that data received front utilization of the control interface is able to be converted into UPnP commands. For example, upward modification of a volume value in the control interface is translated into a UPnP command to increase volume. This is particularly advantageous where other devices (i.e. other than speaker <b>202</b>) are affected by the utilization of the control interface.

A particularly important category of command is a playback command, which is indicative of an instruction to commence/cease playback of a particular audio track. In some embodiments, the control interface only allows simple commands such as “play” and “stop”. However, in other embodiments the control interface additionally allows a user to select one or more tracks (in the case of multiple tracks, these may define a playlist) for playback. Some examples along these lines are considered below. <ul id="ul0011" list-style="none"><li id="ul0011-0001" num="0000"><ul id="ul0012" list-style="none"><li id="ul0012-0001" num="0087">In one embodiment, the control interface allows the user to browse media stored at UPnP media servers on the speaker network. Where device <b>201</b> maintains UPnP media server software, this may include locally stored media.</li><li id="ul0012-0002" num="0088">In one embodiment, speaker <b>202</b> scans the memory of device <b>201</b> and defines a list of available media files. These files are advertised by speaker <b>202</b> in the capacity of a media server. Where a playback command is received in respect of one of those files, speaker <b>202</b> obtains and uploads the relevant file, such that streaming can commence from speaker <b>202</b>. In some cases streaming commences prior to the completion of upload. In this manner, device <b>201</b> is effectively able to operate as a media server, although media server software is not installed.</li><li id="ul0012-0003" num="0089">In one embodiment, the control interface allows the user to browse locally stored media (i.e. media stored on the memory of device <b>201</b>). This might include either or both of individual media files and/or playlists. Assuming device <b>201</b> does not support streaming of media files over a wireless network, the selected files are uploaded to speaker <b>202</b> for playback, which takes on a role as a UPnP media server for those files. In some cases the uploading of such files is temporary only, such that copies are not permanently retained. In some embodiments, rather than uploading the files to speaker <b>202</b>, they are uploaded to another device on the speaker network (such as to a distributed media server).</li></ul></li></ul>

It will be appreciated that the final example is simpler where device <b>201</b> implements a conventional file system, given that a relatively rudimentary browse/upload interface is able to be used in such cases. However, in some embodiments, media storage on device <b>201</b> is maintained in a non-conventional file system. In some such cases, the control interface varies depending on the make/model/etc of device <b>201</b>. In some cases the control interface includes an initial page that prompts the user to identify the device being used to facilitate determination of appropriate subsequent pages.

Step <b>306</b> includes implementing the control commands in the wireless speaker, or in a wireless audio system. In the case of the latter, and as shown in <figref idref="DRAWINGS">FIG. 2B</figref>, speaker <b>202</b> operates as a master speaker in conjunction with a plurality of slave speakers. The web server is provided by the master speaker, and commands received at the master speaker are applied across the master speaker and slave speakers.

In another embodiment, the web server is provided by a slave speaker of a wireless audio system, and a control command received by the web server is provided in accordance with the UPnP interface to the master speaker, such that the master speaker implements the command.

Generally speaking, only a single one of the speakers on a given speaker network should provide a web server as discussed herein. To this end, where multiple speakers are connected to a network, those speakers in some embodiments self arrange to determine which should provide the web server (i.e. a master/slave determination). In some cases only one of the speakers is configured from a hardware perspective to provide an access point, and in such cases determination is relatively straightforward (as that device is inherently configured to provide the web server). However, in other embodiments alternate approaches are used. Additional discussion of wireless speaker systems, virtual devices representative of those systems, and arbitration between master/slave speaker devices, is provided further below, particularly by reference to sub-process <b>502</b> of <figref idref="DRAWINGS">FIG. 5</figref>.

<figref idref="DRAWINGS">FIG. 3B</figref> illustrates a variation on the methods of <figref idref="DRAWINGS">FIG. 3A</figref>. In the example of <figref idref="DRAWINGS">FIG. 3A</figref>, a local domain server is used to resolve a URI inherently descriptive of control functionality. In the example of <figref idref="DRAWINGS">FIG. 3B</figref>, an alternate approach is used, generally involving the use of a remote server which associates user data with speaker addresses. This is described in more detail below.

A general arrangement underlying <figref idref="DRAWINGS">FIG. 3B</figref> is shown in <figref idref="DRAWINGS">FIG. 2C</figref>. In overview, a remote server <b>250</b> communicates with either or both of device <b>201</b> and speaker <b>202</b> over the Internet. For example, in some embodiments this is made possible by a DSL modem or other form of Internet connection available on the speaker network. Server <b>250</b> maintains a database <b>251</b> which correlates user data with wireless speaker IP addresses.

In one embodiment, during the configuration of wireless speaker <b>202</b>, a user defines user data for that speaker, which may take the term of a username/password combination. These are in some cases wholly or partially predefined. The username is used to uniquely identify wireless speaker <b>202</b>. Wireless speaker <b>202</b> transmits data indicative of its username to remote server <b>250</b>, along with data indicative of its IP address. The data is re-transmitted periodically, for example upon alteration of the IP address. It will be appreciated that the speaker's IP address might change over time, in some cases under the influence a DHCP.

Server <b>250</b> provides a website whereby a user is able to log on by way of the user data (for example by providing a username/password), and by doing so receive the IP address for speaker <b>202</b>. In particular, a user navigates by way of a web browser running on device <b>201</b> to a URL such as www.speakercontrol.com, which is resolved to access the website provided by server <b>250</b>. The user then provides the relevant user data, and is provided a link indicative of the IP address for speaker <b>202</b>. In other embodiments the browser is automatically redirected to that IP address. In this manner, device <b>201</b> provides the “predetermined request” in response to which the speaker begins delivering data indicative of the control interface. This allows resolution of a local speaker address based on a generic URL, although without a need to perform local resource resolution.

In the context of <figref idref="DRAWINGS">FIG. 3B</figref>, method <b>300</b> remains generally unchanged. However, method <b>310</b> includes additional steps <b>318</b> and <b>319</b>. Step <b>318</b> includes navigating to a first predetermined control URL, such as www.speakercontrol.com, and providing a logon (for example in terms of a username/password combination). In response, assuming logon is successful, device <b>201</b> receives from server <b>250</b> data indicative of a local control address. In this instance, step <b>313</b> includes navigating to this second control address, and step <b>303</b> correspondingly includes receiving data indicative of a request to navigate to the local control address.

<figref idref="DRAWINGS">FIG. 3B</figref> also illustrates a method <b>320</b> performed by server <b>250</b>. Method <b>320</b> includes, at step <b>321</b>, processing a logon, and identifying a local control address. This is achieved by querying database <b>251</b>. Step <b>322</b> includes providing data indicative of the local control address to the browser responsible for the logon (i.e. device <b>201</b>).

In some embodiments server <b>250</b> maintains additional data regarding the configuration of speakers on the speaker network. In this manner, server <b>250</b> is able to provide links to control addresses for individual speakers, groups and/or zones defined on the local speaker network. These are identified by reference to descriptive names defined locally. For example, in one embodiment navigates to www.speakercontrol.com, performs a logon, and is provided links to the likes of “bedroom speaker system”, “lounge room surround system”, and so on. This allows the user to select which speaker or speakers are to be controlled by way of device <b>201</b>. An example of speaker arrangements within a house is described further below by reference to <figref idref="DRAWINGS">FIG. 17</figref>.

<figref idref="DRAWINGS">FIG. 4A</figref> illustrates an exemplary screenshot of a control interface according to one embodiment, as rendered in a web browser. This screenshot, along with others provided herein, is schematic only and should not be regarded as necessarily limiting in any way. That is, screenshots provided are illustrative of relatively rudimentary interfaces, substantively simplified to facilitate convenient understanding of significant features and functionalities. Those skilled in the art will appreciate how interfaces having varied appearances might be implemented in practice, whilst preserving such features and functionalities.

The present screenshot shows a region <b>401</b> for containing standard browser controls, such as an address toolbar, menu toolbars, navigation toolbars, and the like. Region <b>402</b> displays data indicative of current operational characteristic, such as the volume at which the speaker/system is set, playback status (in terms of play/stop, and track/playlist), and the like. Region <b>403</b> provides general playback control buttons, such as play, stop, next track, and so on. Region <b>404</b> provides other control, which vary between implementations.

<figref idref="DRAWINGS">FIG. 4B</figref> illustrates a screenshot from a more complex control interface. In this example, a playlist display region <b>410</b> is shown for providing a graphical representation of media that is designated for playback, much in the same way as a conventional software based media player. Additionally, region <b>411</b> allows a user to select between one or more available groups, zones and/or individual speakers to control. In overview, the control interface under consideration is able to be used to control a plurality of speakers/groups/zones, a by way of region <b>411</b> the user is able to select which of those is to be controlled at a given time.

The web pages that when rendered provide control interfaces are, in some embodiments, dynamically generated based on up-to-date information received over the network. For example, a repository of page data maintains various objects and the like which are able to be dynamically built to form appropriate web pages (e.g. using DHTML) as is common in the field. For example, in one embodiment at runtime a page generation engine is responsive to current data (such as data indicative of available speakers/groups/zones) for building an appropriate web page for rendering n a browser as a control interface.

The method by whish commands provided via the web pages are converted into playback control commands varies between embodiments. For example, in some cases data received from a web page is translated to provide a standard control signal (such as a standard UPnP control signal).

As further context, <figref idref="DRAWINGS">FIG. 5</figref> is a flowchart that illustrates a method for providing a multimedia system in the form of a wireless audio system. In overview, several individual wireless speaker subsystems are activated, each wireless speaker subsystem including a wireless network interface for allowing connection to a wireless network, e.g., a wireless local area network (WLAN) conforming to the IEEE 802.11 standard. These wireless speaker subsystems connect to a common wireless network—for example by association to an open access point.

The method of <figref idref="DRAWINGS">FIG. 5</figref> is described by reference to a number of sub-processes. It will be appreciated that in various embodiments these sub-processes are performed in parallel or series. Sub-process ordering and particular examples should not be regarded as limiting.

Sub-process <b>501</b> represents a discovery sub-process where the wireless speaker subsystems are discovered by one another and by other devices on the network. In practical terms, discovery is a process whereby networked devices—including the wireless speaker subsystems and other devices—share data indicative of themselves and advertise their respective capabilities. For example, a wireless speaker subsystem advertises capabilities including wireless audio playback. A significant result taken from sub-process <b>501</b> is that the wireless speaker subsystems discover one another. Sub-process <b>501</b> is discussed in greater detail further below by reference to a specific example.

At sub-process <b>503</b> a virtual device is defined. A virtual device is a device which presents a single proxy interface to a collection of networked media devices to allow for a single control interface to these devices. Furthermore, a virtual device is a networked device that does not have a conventional hardware manifestation. Both the terms “group” and “zone” as used in this disclosure are virtual devices. In the example described herein, the virtual device is referred to as a “group” because it represents a plurality of networked multimedia devices (the wireless audio system).

In the present embodiment, a virtual device (a group or a zone) does not have a conventional hardware manifestation in the sense that the wireless audio system includes several individual wireless speaker subsystems. Virtual devices are discoverable on a network in the same way as physical devices. Physical devices communicate with virtual devices as they would with other physical devices. In the present embodiment a virtual device has its own IP address. In other embodiments however a virtual device does not have IP addresses, for example as a result of a lower-level protocol running atop that virtual device. In some embodiments a virtual device includes one or more virtual sub-devices, and the virtual device has an IP address whilst the virtual sub-devices may or may not have respective IP addresses.

At sub-process <b>504</b> a system control interface is provided via the group. This interface is enabled or receiving a system control signal indicative of an operational change to the wireless audio system. In particular, a signal or message provided to the group (for example by using the IP address of that device) is received by the system control interface. The term “operational change” should be read broadly to include substantially any change in state of any device either physical or virtual. For example: in the present context operational changes might include wireless speaker subsystem volume adjustment, other audio amplification settings, media playback control, and so on.

Providing the system control interface in some embodiments includes advertising on the network the group—for example in accordance with one or more open or other proprietary networking protocols. The group advertises the capability of a wireless audio system, and this capability is discoverable and controllable on the network. A user wishing to apply an operational change across the wireless audio system—such as a volume adjustment—provides a system control signal indicative of this change to the group. This is dealt with at sub-process <b>505</b>.

At sub process <b>505</b>, a system control signal is received. In response to the system control signal, corresponding device control signals are provided to each of the wireless speaker subsystems to implement the operational change across the wireless audio system.

The term “system control signal” refers to a signal, message or data packet that is directed to the group for applying an operational change across the wireless audio system. A device control signal is a signal, message or data packet that is directed to an individual wireless speaker subsystem for applying an operational change to that particular wireless speaker subsystem. In some embodiments a single device control signal is concurrently provided to a plurality of individual wireless speaker subsystems, such as by way of message broadcast.

In the present embodiment, one of the wireless speaker subsystems is responsible for implementing sub processes <b>503</b> to <b>505</b>. That is, one of the wireless speaker subsystems defines the group representative of the wireless audio system, provides the system control interface, and is responsive to system control signals for implementing the desired operational changes across the system. Achieving this includes the step of identifying among the wireless speaker subsystems a wireless speaker subsystem, also called a leader wireless speaker subsystem. More specifically, in the present embodiment between sub-processes <b>501</b> and <b>503</b> there is an arbitration sub process <b>502</b> where each speaker subsystem autonomously decides whether it is to be the leader speaker subsystem based on a predefined comparison protocol. In one embodiment this is performed on the basis that all speaker subsystems on the network are aware of each other.

Various comparison protocols are used among embodiments. For example, in some embodiments each speaker subsystem includes a unique hierarchical identifier, and periodically broadcasts this identifier for reception by other speaker subsystems. In this way each speaker subsystem is able to compile a list of speaker subsystems on the network and their corresponding hierarchical identifiers, and as such make an autonomous decision as to whether or not it is to become the leader. Some further comparison protocols used in other embodiments are discussed further below.

Wireless speaker subsystems that do not determine that they are leader wireless speaker subsystems inherently become slave wireless speaker subsystems, also called member wireless speaker subsystems, and as such do not implement sub processes <b>503</b> to <b>505</b>. As new wireless speaker subsystems connect to or otherwise appear on the network they scan the network for existing devices, and under certain conditions join existing wireless audio systems. Where a wireless speaker subsystem is not a leader wireless speaker subsystem, that wireless speaker subsystem implements a join sub-process in <b>506</b> to confirm its place in a wireless audio system. Join sub process <b>506</b> is not shown in <figref idref="DRAWINGS">FIG. 5</figref> for the sake of simplicity, however it will be appreciated that it is performed following sub-process <b>502</b> by a wireless speaker subsystem that determines itself not to be a leader wireless speaker subsystem. An example of sub-process <b>506</b> is found in <figref idref="DRAWINGS">FIG. 12</figref>.

<figref idref="DRAWINGS">FIG. 6</figref> shows a wireless audio configuration including five wireless speaker subsystems <b>601</b> to <b>605</b>. These wireless speaker subsystems are activated and automatically connect to a wireless network <b>606</b>. Network <b>606</b> is provided by an open access point <b>607</b>, and in connecting to network <b>606</b> each of the wireless speaker subsystems associate to access point <b>607</b>. Access point <b>607</b> is “open” in the sense that wireless speaker subsystems <b>601</b> to <b>605</b> are able to associate without the need to grant in advance special permissions. In some embodiments such permissions are required. A method in line with that disclosed in <figref idref="DRAWINGS">FIG. 5</figref> is carried out to provide a wireless audio system <b>610</b> including wireless speaker subsystems <b>601</b> to <b>605</b>. In particular, a group <b>608</b> is defined, this device being representative of wireless audio system <b>610</b>. Group <b>608</b> provides a system control interface <b>609</b> which receives system control signals for implementing operations changes across system <b>610</b>.

From a terminology point of view, group <b>608</b> describes a discoverable group on network <b>606</b> that provides a capability in the form of a wireless audio system. System <b>601</b> describes the hardware making up the wireless audio system—including individual wireless speaker subsystems <b>601</b> to <b>605</b>.

Although in <figref idref="DRAWINGS">FIG. 6</figref> group <b>608</b> is shown as being separate from the leader wireless speaker subsystem, it will be appreciated that in a practical sense the group exists within and shares the hardware of the leader wireless speaker subsystem. Whilst messages are sent directly to the group, in a physical sense those messages are received by the network interface of the leader wireless speaker subsystem. This network interface may be a physical device such as a network interface, or alternately a logical interface.

Wireless speaker subsystems <b>601</b> to <b>605</b> have not been pre-configured to act as a group. They are off-the-shelf wireless speaker subsystems that, as discussed below, implement instructions to substantially autonomously arrange themselves to provide a wireless audio system such as system <b>610</b>.

In the present embodiment wireless speaker subsystems <b>601</b> to <b>605</b> are provided by a single manufacturer, and as such implement generally the same protocols and procedures. They are of the same or a similar model—similar in that they may differ in details such as color, appearance, in size or speaker cone configuration. Each wireless speaker subsystem is uniquely identifiable electronically by one or more respective identifying features, such as unique MAC addresses. In other embodiments several different makes of wireless speaker subsystem are used.

Once activated, wireless speaker subsystems <b>601</b> to <b>605</b> undergo a discovery process in sub-process <b>501</b>. There are a number of known discovery protocols that manage precisely how discovery takes place. In various embodiments of this invention discovery protocols such as Universal Plug and Play (UPnP) Bonjour and Jini are used, as well as proprietary discovery protocols. Bonjour is a general method to discover services on a local area network, and was formerly called Rendezvous. It is Apple's trade name for its implementation of the Zeroconf specification framework. For Jini, see www.jini.org.

The discovery process used in the present embodiment is shown in <figref idref="DRAWINGS">FIG. 7</figref>, and described below by reference to wireless speaker subsystem <b>601</b>. It will be appreciated that this is provided as an example only, and in other embodiments other discovery processes are used.

Wireless speaker subsystem <b>601</b> connects to network <b>606</b> at step <b>701</b> in sub-process <b>501</b>. Wireless speaker subsystem <b>601</b> implements Dynamic Host Configuration Protocol (DHCP) client, which searches for a DHCP server at step <b>702</b>. Such a server is generally responsible for the assignment of IP addresses across a network, such as network <b>606</b>. If, at decision <b>703</b>, no DHCP server is available, wireless speaker subsystem <b>601</b> self-assigns an IP address at step <b>704</b>. Otherwise, an available DHCP server assigns an IP address to wireless speaker subsystem <b>601</b> at step <b>705</b>. In either case, the LP address assigned is used by wireless speaker subsystem <b>601</b> in subsequent network operations.

Once an IP address is assigned, the wireless speaker subsystem <b>601</b> advertises itself across network <b>606</b> at step <b>706</b>. In particular, wireless speaker subsystem <b>601</b> provides a discovery message that communicates to wireless speaker subsystems <b>602</b> to <b>605</b> and other devices on network <b>606</b> a relatively small data packet indicative of wireless speaker subsystem <b>601</b>. For example: data indicative of a type or identifier, and a URL indicative of a location from which more detailed information is available. In the present embodiment the data packet includes the wireless speaker subsystem's MAC address.

Although the present embodiment is described by reference to the use of IP addresses, that should not be regarded as limiting. For example, in one embodiment layer two encapsulated packets are used, optionally in conjunction with a proprietary discovery protocol adapted to make use of such packets. In one such embodiment only MAC layer access is required, as opposed to higher layer access such as IP layer access.

Step <b>707</b> includes conducting a discovery search across network <b>606</b> for devices of interest—such as other wireless speaker subsystems or groups representative of wireless audio systems. The discovery search includes the provision of a probe frame, and in response to this probe frame a similar discovery message to that mentioned above is provided by each complementarily discoverable device on network <b>606</b> to wireless speaker subsystem <b>601</b>. This includes wireless speaker subsystems <b>602</b> to <b>606</b>.

It will be appreciated that, following this discovery process, each wireless speaker subsystem <b>601</b> to <b>605</b> discovers the other wireless speaker subsystems regardless of the order in which the wireless speaker subsystems connect to network <b>606</b>. For instance, the first wireless speaker subsystem to connect discovers the other wireless speaker subsystems as they connect and advertise themselves. The last wireless speaker subsystem to connect discovers the other wireless speaker subsystems following a discovery search.

This completes sub-process <b>501</b>. In the present embodiment each wireless speaker subsystem waits for a predetermined time before progressing to the arbitration sub-process <b>502</b>. In one embodiment this predetermined time is ten seconds without discovery of a wireless speaker subsystem. That is, if a given wireless speaker subsystem is idle for ten seconds without discovering another wireless speaker subsystem, that wireless speaker subsystem progresses to the arbitration sub-process. In other embodiments alternate time periods are used. In some embodiments alternate rules determine when a wireless speaker subsystem progresses to the arbitration sub-process.

<figref idref="DRAWINGS">FIG. 8</figref> shows the arbitration sub-process <b>502</b> of the present embodiment. Sub process <b>502</b> commences at decision <b>801</b> where wireless speaker subsystem <b>601</b> decides whether an existing device having a wireless audio system capability has been discovered. For example, whether an existing group <b>608</b> has been discovered. If one has been discovered, the method progresses to sub-process <b>506</b>. Otherwise the method progresses to decision <b>802</b>.

At decision <b>802</b> wireless speaker subsystem <b>601</b> determines whether it is the leader device. As foreshadowed, in this sub-process each wireless speaker subsystem inherently adopts a leader or member role. In the present embodiment, use is made of device MAC addresses, and as foreshadowed MAC addresses are shared during the discovery sub-process. The MAC address for each wireless speaker subsystem is embedded with a hierarchical identifier, such as the numerical value of the final bit in the address. In overview, the wireless speaker subsystems inherently self assign leader and member roles based on comparison protocol that takes into account a comparison of these identifiers. In some embodiments other factors are also used in addition. Given the relative nature of the present comparison protocol, in one implementation a particular wireless speaker subsystem might be leader whilst in another implementation that same wireless speaker subsystem might be a member.

The use of MAC addresses for leader/member assignment should not be regarded as limiting. In other embodiments alternate approaches or combinations of approaches are adopted. Some alternate approaches include, for example: <ul id="ul0013" list-style="none"><li id="ul0013-0001" num="0000"><ul id="ul0014" list-style="none"><li id="ul0014-0001" num="0134">Assessment of physical factors. For example, in a system having a first wireless speaker subsystem having an input for receiving a SPDIF signal and a second wireless speaker subsystem that does not accept SPDIF signal, the first wireless speaker subsystem can be inherently designed to act as a leader.</li><li id="ul0014-0002" num="0135">The use of a unique hierarchy identifier as part of a discovery message. That is, a wireless speaker subsystem advertises itself in a manner indicative of a hierarchy identifier, and another wireless speaker subsystem recognizes that device as a relative leader or member based on a comparison of the discovered device's hierarchy identifier and its own hierarchy identifier. This is similar to the MAC address approach, but uses another number which may or may not be pre-existing for other networking purposes.</li></ul></li></ul>

A connection time based protocol where the time at which a wireless speaker subsystem associated to access point <b>607</b> determines whether it is the leader. For example, the leader is in one embodiment the first wireless speaker subsystem to associate to access point <b>607</b>.

If, based on an assessment of the MAC addresses of discovered wireless speaker subsystems, wireless speaker subsystem <b>601</b> determines that it is the leader, the method progresses to sub-process <b>503</b>. Otherwise the method loops to decision <b>801</b>, and it will be appreciated that this repeats until a group <b>608</b> is found. In some embodiments a timeout function is implemented to contain such looping with predefined restraints.

In some embodiments the present arbitration is extended to determine whether a given device is a master or slave from a control interface perspective, with a master of that sort providing a web server for delivering a browser renderable control interface.

Sub-processes <b>503</b> and <b>504</b> of the present embodiment are shown in <figref idref="DRAWINGS">FIG. 9</figref>. As noted above, these sub-processes are only carried out by wireless speaker subsystem <b>601</b> where that wireless speaker subsystem determines it is the leader wireless speaker subsystem. At step <b>901</b> wireless speaker subsystem <b>601</b> assesses the wireless speaker subsystems that have been discovered—specifically wireless speaker subsystems <b>602</b> to <b>605</b>—in terms of type and number. In some embodiments each wireless speaker subsystem is indicative of a location in a surround sound configuration, such as a “front-left” wireless speaker subsystem. In one embodiment each wireless speaker subsystem includes a physical or digital switch that is progressed between a plurality of positions to allow such identification. Based on the assessment at step <b>901</b>, wireless speaker subsystem <b>601</b> defines group <b>608</b> at step <b>902</b>. This definition step includes providing a discoverable description indicative of system <b>610</b>, and assigning an IP address to device <b>608</b>. For example, in the present embodiment the description might be of a “five wireless speaker subsystem wireless audio system”. In embodiments where surround sound is enabled the description might be of a “five channel surround wireless audio system”. This description is in some embodiments modified over time as a result of changes in hardware, such as the addition or removal of wireless speaker subsystems, or as a result of user interaction.

Sub-process <b>504</b> commences at step <b>903</b> with the definition of interface <b>609</b>. This is in one embodiment performed based on instructions contained in the memory unit of wireless speaker subsystem <b>601</b>. That is, wireless speaker subsystem <b>601</b> contains instructions indicative of how to define interface <b>609</b> based on the wireless speaker subsystems discovered. At step <b>904</b> interface <b>609</b> is provided, which includes making the interface available on network <b>606</b>. In the present embodiment this in turn includes advertising device <b>608</b>. As such, a user or other device on network <b>606</b> is able to discover device <b>608</b> and by way of interface <b>609</b> take control of system <b>610</b>.

In the present embodiment group <b>608</b> is advertised in accordance with the UPnP open networking protocol. As part of this, device <b>608</b> provides some additional information itself. Specifically, group <b>608</b> provides in its discovery messages URLs to allow access to this additional information. The additional information for each device includes a UPnP description expressed in XML. This description includes a wide range of information, such as:

The availability of a wireless audio system capability, along with the number of wireless speaker subsystems and so on. <ul id="ul0015" list-style="none"><li id="ul0015-0001" num="0000"><ul id="ul0016" list-style="none"><li id="ul0016-0001" num="0143">Details regarding how to take control of the wireless audio system capability. For example: command formats, how the system responds, parameters, variables rules and so on. Generally speaking, whatever information is required to allow a control unit to actually take meaningful control.</li><li id="ul0016-0002" num="0144">A control URL for the system control interface. A system control signal is in some embodiments provided to the control URL to make an operational change to the wireless audio system.</li></ul></li></ul>

In some cases information can be provided by URL link within the XML description, as opposed to being entirely contained within the description.

In the present embodiment interface <b>609</b> is accessible as a graphical user interface via a personal computer on network <b>606</b> through a web browser and/or a standalone program executable on a client terminal. A user of the personal computer is able to make complex changes to group <b>608</b> in this way—for example configuring surround sound, removing wireless speaker subsystems, setting up groups composed of one or more physical wireless speaker subsystems, zones composed of groups, which are in turn composed of physical wireless speaker subsystems, and so on.

<figref idref="DRAWINGS">FIG. 10</figref> illustrates sub-process <b>505</b> in greater detail, again in the context of wireless speaker subsystem <b>601</b>. This assumes that wireless speaker subsystem <b>601</b> is the leader wireless speaker subsystem, and that sub-processes <b>503</b> and <b>504</b> have completed. Sub-process <b>505</b> commences at step <b>1001</b> with the receipt of a system control signal by system control interface <b>609</b>. Interface <b>609</b> (in physical terms wireless speaker subsystem <b>601</b>) is enabled to be responsive to the system control signals for assessing the sought operational change at step <b>1002</b> and defining one or more corresponding device control signals at <b>1003</b>. In one embodiment the interface <b>609</b> receives commands in the same format each of wireless speaker subsystems <b>601</b> to <b>605</b> would individually receive control signals, and as such device control signals are the same as the system control signals. In other embodiments the system control signals are different to the device control signals.

Device control signals are provided by interface <b>609</b> to each of wireless speaker subsystems <b>601</b> to <b>606</b> to implement the operational change across those wireless speaker subsystems at step <b>1004</b>. In the present embodiment this is performed using a custom network protocol based on a one way UDP broadcast message over IP from the leader wireless speaker subsystem (wireless speaker subsystem <b>601</b>), coupled with a reliable TCP acknowledgement back to the leader from every other wireless speaker subsystem in system <b>610</b>. This combination enables control signals to be received in a timely manner by all wireless speaker subsystems at a similar time, and also provides an asynchronous fail safe for wireless speaker subsystems that may not have received the message. At decision <b>1005</b> interface <b>609</b> determines whether acknowledgements have been received from each wireless speaker subsystem within a predetermined time period. If all acknowledgements are received, the method progresses to step <b>1001</b>. Otherwise, if a wireless speaker subsystem fails to acknowledge a control message within a given time, interface <b>609</b> will, via a TCP message, instruct the failing wireless speaker subsystem to reset itself to a predefined state and progress to sub-process <b>506</b>. This message is provided at step <b>1006</b>.

In another embodiment device control signals are unicast to the individual wireless speaker subsystems, as opposed to using a one way UDP broadcast message. This alternate approach better provides for individual control of the wireless speaker subsystems.

In some embodiments a device control signal includes data indicative of an execution time. For example, a device control signal is indicative of “apply operational change X at time Y”. This allows for synchronisation of command execution such that, in the example of volume control, the wireless speaker subsystems each alter their volume at the same time. It will be appreciated that achieving such synchronisation in some embodiments requires for synchronisation of internal clocks in the individual wireless speaker subsystems. In one embodiment such synchronisation of internal clocks is carried out for the related purpose of ensuring synchronised media playback. In some embodiments the execution time is expressed as an offset of a known time.

<figref idref="DRAWINGS">FIG. 11</figref> schematically illustrates data flow during sub process <b>505</b>, and the numerical conventions of <figref idref="DRAWINGS">FIG. 6</figref> are adopted. In overview, a control device <b>1101</b> provides a system control signal <b>1102</b>, and subsequently corresponding device control signals <b>1103</b> are received by wireless speaker subsystems <b>601</b> to <b>605</b>.

It will be appreciated that the above approach involves some redundancy in the sense that interface <b>609</b> provides signals to wireless speaker subsystem <b>601</b> over network <b>606</b> irrespective of the fact that interface <b>609</b> is provided by wireless speaker subsystem <b>601</b>. This redundancy balances with simplicity. In other embodiments wireless speaker subsystem <b>601</b> implements the operational change without the need for a device control signal to be sent from device <b>608</b> to wireless speaker subsystem <b>601</b>.

There are two general categories of operational changes that affect system <b>610</b>. The first of these is a global change that affects every wireless speaker subsystem in the same way. For example: a global increase in volume. In such a case the system control signal is the same as the device control signals, and effectively wireless speaker subsystem <b>601</b> is simply responsible for distributing the system control signal as a device control signal to each of the wireless speaker subsystems. The second category is a complex change that affects different wireless speaker subsystems in a different way. For example: where system <b>610</b> has been configured to provide a five-channel surround sound configuration, and the operational change affects only a selection of the wireless speaker subsystems. In one example a system control signal is provided to reduce the volume on the front left wireless speaker subsystem, which in this embodiment is wireless speaker subsystem <b>602</b>. In such a case wireless speaker subsystem <b>601</b> is responsible for assessing the system control signal, and defining device specific device control signals. In the present example a single device control signal is defined, this signal being uniquely intended for and provided to wireless speaker subsystem <b>602</b>, instructing wireless speaker subsystem <b>602</b> to reduce its output volume.

It will be appreciated that configuring wireless speaker subsystems <b>601</b> to <b>606</b> to adopt roles in a complex configuration may involve additional steps and manual intervention. For example, if a 5-channel surround system is desired, it is necessary to identify which wireless speaker subsystem is physically located in which position. Device <b>608</b> in some embodiments provides a user interface accessible via a personal computer to assist in such a task.

It is worth noting that the ability of wireless speaker subsystem <b>601</b> to control wireless speaker subsystems <b>602</b> to <b>606</b> hinges on wireless speaker subsystem <b>601</b> being privy to information detailing the manner in which those wireless speaker subsystems are controlled. This information is in some embodiments maintained by wireless speaker subsystem <b>601</b>, or in other embodiments obtained during the discovery sub-process, or in other embodiments even obtained from a remote data source such as the Internet when required. Assuming such information can be obtained, wireless speaker subsystem <b>601</b> is able to provide a wireless audio system including wireless speaker subsystems from alternate manufactures. For example, wireless speaker subsystem <b>601</b> is able to include substantially any UPnP wireless speaker subsystem in a wireless audio system.

Effectively, wireless speaker subsystem <b>601</b> provides by way of device <b>608</b> and interface <b>609</b> a centralized location for receiving system control signals that effect system <b>610</b> as a whole. For example, if there is a desire to increase the volume on all of wireless speaker subsystems <b>601</b> to <b>605</b>, a signal indicative of that operational change is provided to device <b>608</b>. This circumvents the need for a user to manually provide a signal to each individual wireless speaker subsystem.

In some embodiments device <b>608</b> is responsive to the discovery of other controllable devices on network <b>606</b> for selectively defining additional groups. For example, a particular wireless speaker subsystem may provide a microphone input, allowing a virtual hands-free telephone device to be created. Group logic maintained on wireless speaker subsystem <b>501</b> is able to interrogate devices on the network, determine their capabilities and present a list of possible groups to create given the resources available.

<figref idref="DRAWINGS">FIG. 12</figref> illustrates sub process <b>506</b> in greater detail. Given that the above disclosure describes sub-processes <b>503</b> to <b>505</b> in terms of wireless speaker subsystem <b>601</b>, this sub process is described by reference to wireless speaker subsystem <b>602</b>—which determines during sub-process <b>502</b> that it is not the leader. At step <b>1201</b> wireless speaker subsystem <b>602</b> provides a message to interface <b>609</b> indicative of its willingness to participate in system <b>610</b>. Interface <b>609</b> is responsive to such as message for providing an acceptance or rejection, and this is received at decision <b>1202</b>. In one instance, in the case of rejection, wireless speaker subsystem <b>602</b> may return to sub-process <b>501</b> to ensure a consistent system state. In the case of acceptance, the acceptance message is indicative of an operational state provided by device <b>608</b> that should be adopted by wireless speaker subsystem <b>602</b>. The rationale is for device <b>608</b> to know the state of each wireless speaker subsystem in system <b>610</b>. In some embodiments device <b>608</b> periodically interrogates each wireless speaker subsystem to obtain data indicative of their respective operative states. At step <b>1203</b> wireless speaker subsystem <b>602</b> adopts the state identified by the acceptance message, and provides a TCP acknowledgement to device <b>608</b>.

In some embodiments a group which references other groups may be created. A set of groups may be referred to as a zone while a set of physical devices could be referred to as a group. A zone would be created to address the need for multi-room media playback where multiple groups would be required to act on identical media and commonly process commands relating to media playback. A group composed of groups would address the same issues of command and media stream routing between groups as would be required in an embodiment where a group routs commands to physical devices.

As noted above, in the embodiment of <figref idref="DRAWINGS">FIG. 6</figref> wireless speaker subsystems <b>601</b> to <b>605</b> associate to an existing access point <b>607</b>. In some instances no access point is provided, and one of the wireless speaker subsystems inherently provides an access point. Such an embodiment is shown in <figref idref="DRAWINGS">FIG. 13</figref>, which adopts the same numbering conventions as <figref idref="DRAWINGS">FIG. 6</figref>. In this embodiment each wireless speaker subsystem scans for an available access point for a predetermined period of time, and if no beacon or probe response frames are received, establishes itself as an open access point. In a similar manner to the leader/member (master/slave) determination technique discussed above, MAC addresses are often used to assist this process. Specifically, in one embodiment, each wireless speaker subsystem scans for a period of time related to the final byte in its MAC address—in some embodiments between about five to ten seconds multiplied by the value of that final byte. If no access point is found within that time, the wireless speaker subsystem initiates its own open access point. It will be appreciated that by such an approach only one of the wireless speaker subsystems need initiate an access point, and the remaining wireless speaker subsystems will associate to that access point. In one embodiment the wireless speaker subsystem providing the access point becomes the leader device, reducing the complexity of sub-process <b>502</b>.

In some embodiments the wireless speaker subsystems first associate to an open access point, and subsequently self arrange themselves into an internal private network.

<figref idref="DRAWINGS">FIG. 14</figref> shows a wireless speaker subsystem <b>1401</b> in more detail. This wireless speaker subsystem is appropriate for use in the above embodiments. For example, in some embodiments wireless speaker subsystem <b>601</b> is interchangeable with wireless speaker subsystem <b>1401</b>.

Wireless speaker subsystem <b>1401</b> includes an input array <b>1402</b> for receiving audio signals. Array <b>1402</b> includes a SPDIF input, along with various other standard and proprietary digital audio inputs. In some instances array <b>1402</b> includes one or more analogue audio inputs, in which case wireless speaker subsystem <b>1401</b> includes an analogue to digital converter for converting analogue audio signals into digital form. Once received (and where necessary digitized) the audio signals are processed by a processing unit, e.g., a central processing unit (CPU) <b>1403</b>, which operates in conjunction with memory <b>1404</b>. Memory <b>1404</b> includes software instructions <b>1405</b> which, among other functions, allow wireless speaker subsystem <b>1401</b> to perform methods described herein. It is noted that not all instructions required for performing these methods need be in memory <b>1404</b> at a given time.

Wireless speaker subsystem <b>1401</b>, given that it presents the virtual interface for system <b>610</b>, also becomes responsible for fetching media from a server, or in the case of an SPDIF stream, partially recovering that stream from a digital input. Data indicative of this media or stream is then distributed to the other devices in the group. CPU <b>1403</b> is responsible for administering playback of a received audio signal. In a broad sense, this includes two distinct tasks. Firstly, using a wireless network interface <b>1406</b>, providing instructions to other wireless speaker subsystems to play respective components of the audio signal. Secondly, using an audio output <b>1407</b> (which in some embodiments includes one or more speaker cones), playing back the intended center wireless speaker subsystem component of the audio signal. There are, of course, detailed issues of rendering and synchronization, and these fall beyond the scope of the present disclosure.

Wireless speaker subsystem <b>1401</b> also includes an infrared port <b>1410</b>. This infrared port receives infrared control signals from a compatible infrared remote controller <b>1411</b>. Where wireless speaker subsystem <b>1401</b> acts as an individual wireless speaker subsystem, such a signal is a device control signal. However, when wireless speaker subsystem <b>1401</b> is part of a wireless audio system, such a signal is recognized as a system control signal. A system control signal received by infrared port <b>1410</b> is provided by a TCP message to the group. This is discussed further in by reference to <figref idref="DRAWINGS">FIG. 15</figref> and <figref idref="DRAWINGS">FIG. 16</figref>.

In other embodiments alternate remote controls are used, such as Bluetooth remotes, 802.11 type networked remotes, and radio frequency remotes.

In other embodiments a control signal received by infrared port <b>1410</b> is provided to the group by means other than TCP message—for example by a layer two encapsulated message or other proprietary message.

<figref idref="DRAWINGS">FIG. 15</figref> shows a method for processing a system control signal received by infrared. This method is described by reference to the example of <figref idref="DRAWINGS">FIG. 6</figref>. The signal is received at step <b>1501</b>, and provided in a TCP message to interface <b>609</b> of device <b>608</b> at stop <b>1502</b>. Device <b>608</b> then progresses to sub-process <b>505</b>, and the relevant operational change is implemented across the system.

In overview, there are multiple one-way external interfaces that must propagate received commands to group <b>608</b>. Because this is a unidirectional message, it is accomplished using a TCP connection from the wireless speaker subsystem receiving the infrared signal back to the group. Upon being received at the group, the received commands are aggregated to remove duplicate commands. Duplicates cart occur because the same infrared command might be received concurrently at more than one infrared port. Obviously, though, only one action is desirable per button press on remote <b>1411</b>. After aggregation then, the resulting single change in state is then distributed to all of the wireless speaker subsystems as discussed in relation to sub process <b>505</b>.

In one embodiment, messages provided at step <b>1502</b> are timestamped. In that embodiment, aggregating the received commands to remove duplicate commands includes analysis of those timestamps. In particular, when a command is received via infrared at step <b>1501</b>, a timestamp is defined to identify the time at which the infrared command was received. The group, upon receipt of timestamped messages, compare the timestamps to determine whether received commands are unique or duplicates. In one embodiment the timestamp is a global timestamp derived from a global clock. In another embodiment the timestamp is derived from a device clock maintained by a particular wireless speaker subsystem, and all device clocks in the system are synchronised in accordance with a synchronisation protocol.

By this approach, a user can, by way of remote <b>1411</b>, control system <b>610</b> by physically pointing the remote substantially in the direction Of any of the wireless speaker subsystems and pressing one or more buttons enabled to cause operational changes.

<figref idref="DRAWINGS">FIG. 16</figref> shows the data paths for infrared signals in a manner similar to the example of <figref idref="DRAWINGS">FIG. 11</figref>. In overview, remote <b>1411</b> provides a system control signal <b>1601</b>, and this signal is received by to wireless speaker subsystems <b>603</b> and <b>604</b>. These wireless speaker subsystems provide identical system control signals <b>1602</b> to device <b>608</b>, and wireless speaker subsystems <b>601</b> to <b>605</b> subsequently receive corresponding device control signals <b>1604</b>.

Similar infrared approaches are in some embodiments applied in situations where a group is not used. For example, where the leader wireless speaker subsystem advertises itself as a leader wireless speaker subsystem. In that case data indicative of the infrared signal is provided using a TCP connection from the wireless speaker subsystem receiving the infrared signal back to the leader wireless speaker subsystem.

In some embodiments multiple wireless audio systems are defined on a common network. For example, a building is split into areas where a different wireless audio system serves each area, although a single network serves all of the areas in combination. This is shown in the example of <figref idref="DRAWINGS">FIG. 17</figref>, which provides a plan view of a residential house <b>1701</b>. There are three wireless audio systems defined: <ul id="ul0017" list-style="none"><li id="ul0017-0001" num="0000"><ul id="ul0018" list-style="none"><li id="ul0018-0001" num="0175">Lounge DVD surround system <b>1702</b>, including wireless speaker subsystems <b>1703</b> to <b>1707</b>.</li><li id="ul0018-0002" num="0176">Bedroom stereo system <b>1708</b>, including wireless speaker subsystems <b>1709</b> and <b>1710</b>.</li><li id="ul0018-0003" num="0177">House ambiance system <b>1711</b>, including wireless speaker subsystems <b>1712</b> to <b>1718</b>.</li><li id="ul0018-0004" num="0178">House leader system <b>1719</b>, including all of the above wireless speaker subsystems.</li></ul></li></ul>

Where multiple systems exist on a common network, the groups representative of these systems determine which is to become the parent system (also referred to as the zone leader). This is largely dependent on the situation and the circumstances in which the systems were created. In some embodiments, one system is explicitly added to an existing system as a child system. In this ease, system <b>1712</b> is the parent system and a group representing this system presents a system control interface for controlling all wireless speaker subsystems in the zone. This interface is used to apply an operational change across the whole zone—for example simultaneously muting all wireless speaker subsystems in the house. Each child system (systems <b>1702</b>, <b>1708</b> and <b>1711</b>) is represented by a respective group having its own control interface. To apply an operational change in a child system, a system control signal is provided to the group representative of that child system. To apply an operational change to the parent system, a system control signal is provided to the group representative of the parent system. In some embodiments the zones representative of all parent and child systems are provided by a common leader wireless speaker subsystem, regardless of whether that wireless speaker subsystem is included in each and every child system.

Although embodiments are described herein by reference to wireless speaker subsystems, it will be appreciated that in other embodiments other wireless media renderers are used. For example, wireless video units that receive over a wireless network data indicative of video and provide that video via a video output such as an LCD screen or an analogue or digital connection port.

Additionally, although the above embodiments have been described by reference to wireless networking, in some embodiments alternate networking arrangements are used such as wire-based Ethernet networks and power line networks. It will be appreciated that embodiments of the invention described by reference to wireless networking are equally applicable to these other networking arrangements.

It should be appreciated that although the invention has been described in the context of the IEEE 802.11 standard, the invention is not limited to such contexts and may be utilized in various other applications and systems, for example in other systems that use OFDM. OFDM is one example of a multicarrier system in which the signal for transmission is split into a set of subcarriers. The invention may also be applicable to other wireless receivers that use multicarriers.

In keeping with common industry terminology, the terms “base station”, “access point”, and “AP” may be used interchangeably herein to describe an electronic device that may communicate wirelessly and substantially simultaneously with multiple other electronic devices, while the terms “client,” “mobile device” and “STA” may be used interchangeably to describe any of those multiple other electronic devices, which may have the capability to be moved and still communicate, though movement is not a requirement. However, the scope of the invention is not limited to devices that are labeled with those terms.

While an embodiment has been described for operation in an OFDM receiver with RF frequencies in the 5 GHz range and 2.4 GHz range (the 802.11a and 802.11g variants of the IEEE 802.11 standard), the invention may be embodied in receivers and transceivers operating in other RF frequency ranges. Furthermore, while a transceiver embodiment for operation conforming to the IEEE 802.11 OFDM standards has been described, the invention may be embodied in transceivers conforming to other standards and for other applications, including, for example other WLAN standards and other wireless standards. Applications that can be accommodated include IEEE 802.11a COFDM wireless LANs and links, wireless Ethernet, HIPERLAN 2, European Technical Standards Institute (ETSI) broadband radio access network (BRAN), and multimedia mobile access communication (MMAC) systems, wireless local area networks, local multipoint distribution service (LMDS) IF strips, wireless digital video, wireless USB links, wireless IEEE 1394 links, TDMA packet radios, low-cost point-to-point links, voice-over-IP portable “cell phones” (wireless Internet telephones), etc.

In the context of this document, the term “wireless” and its derivatives may be used to describe circuits, devices, systems, methods, techniques, communications channels, etc., that may communicate data through the use of modulated electromagnetic radiation through a non-solid medium. The term does not imply that the associated devices do not contain any wires, although in some embodiments they might not.

Unless specifically stated otherwise, as apparent from the following discussions, it is appreciated that throughout the specification discussions utilizing terms such as “processing,” “computing,” “calculating,” “determining” or the like, refer to the action and/or processes of a computer or computing system, or similar electronic computing device, that manipulate and/or transform data represented as physical, such as electronic, quantities into other data similarly represented as physical quantities.

In a similar manner, the term “processor” may refer to any device or portion of a device that processes electronic data, e.g., from registers and/or memory to transform that electronic data into other electronic data that, e.g., may be stored in registers and/or memory. A “computer” or a “computing machine” or a “computing platform” may include one or more processors.

The methodologies described herein are, in one embodiment, performable by one or more processors that accept computer-readable (also called machine-readable) code containing a set of instructions that when executed by one or more of the processors carry out at least one of the methods described herein. Any processor capable of executing a set of instructions (sequential or otherwise) that specify actions to be taken are included. Thus, one example is a typical processing system that includes one or more processors. Each processor may include one or more of a CPU, a graphics processing unit, and a programmable DSP unit. The processing system further may include a memory subsystem including main RAM and/or a static RAM, and/or ROM. A bus subsystem may be included for communicating between the components. The processing system further may be a distributed processing system with processors coupled by a network. If the processing system requires a display, such a display may be included, e.g., a liquid crystal display (LCD) or a cathode ray tube (CRT) display. If manual data entry is required, the processing system also includes an input device such as one or more of an alphanumeric input unit such as a keyboard, a pointing control device such as a mouse, and so forth. The term memory unit as used herein, if clear from the context and unless explicitly stated otherwise, also encompasses a storage system such as a disk drive unit. The processing system in some configurations may include a sound output device, and a network interface device. The memory subsystem thus includes a computer-readable medium that carries computer-readable code (e.g., software) including a set of instructions to cause performing, when executed by one or more processors, one of more of the methods described herein. Note that when the method includes several elements, e.g., several steps, no ordering of such elements is implied, unless specifically stated. The software may reside in the hard disk, or may also reside, completely or at least partially, within the RAM and/or within the processor during execution thereof by the computer system. Thus, the memory and the processor also constitute computer-readable medium encoded with computer-executable code.

Furthermore, a computer-readable medium may form, or be includes in a computer program product.

In alternative embodiments, the one or more processors operate as a standalone device or may be connected, e.g., networked to other processor(s), in a networked deployment, the one or more processors may operate in the capacity of a server or a client machine in server-client network environment, or as a peer machine in a peer-to-peer or distributed network environment. The one or more processors may form a personal computer (PC), a tablet PC, a set-top box (STB), a Personal Digital Assistant (PDA), a cellular telephone, a web appliance, a network router, switch or bridge, or any machine capable of executing a set of instructions (sequential or otherwise) that specify actions to be taken by that machine.

Note that while some diagram(s) only show(s) a single processor and a single memory that carries the computer-readable code, those in the art will understand that many of the components described above are included, but not explicitly shown or described in order not to obscure the inventive aspect. For example, while only a single machine is illustrated, the term “machine” shall also be taken to include any collection of machines that individually or jointly execute a set (or multiple sets) of instructions to perform any one or more of the methodologies discussed herein.

Thus, one embodiment of each of the methods described herein is in the form of a computer-readable medium encoded with a set of instructions, e.g., a computer program that are for execution on one or more processors, e.g., one or more processors that are part of a wireless speaker device or other wireless media rendering device. Thus, as will be appreciated by those skilled in the art, embodiments of the present invention may be embodied as a method, an apparatus such as a special purpose apparatus, an apparatus such as a data processing system, or a computer-readable medium, e.g., a computer program product. The computer-readable medium carries computer readable code including a set of instructions that when executed on one or more processors cause the processor or processors to implement a method. Accordingly, aspects of the present invention may take the form of a method, an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore. the present invention may take the form of computer-readable medium (e.g., a computer program product on a computer-readable storage medium) encoded with computer-readable program code embodied in the medium.

The software may further be transmitted or received over a network via a network interface device. While the computer-readable medium is shown in an exemplary embodiment to be a single medium, the term “computer-readable medium” should be taken to include a single medium or multiple media (e.g., a centralized or distributed database, and/or associated caches and servers) that store the one or more sets of instructions. The term “computer-readable medium” shall also be taken to include any medium that is capable of storing, encoding or carrying a set of instructions for execution by one or more of the processors and that cause the one or more processors to perform any one or more of the methodologies of the present invention. A computer-readable medium may take many forms, including but not limited to, non-volatile media, volatile media, and transmission media. Non-volatile media includes, for example, optical, magnetic disks, and magneto-optical disks. Volatile media includes dynamic memory, such as main memory. Transmission media includes coaxial cables, copper wire and fiber optics, including the wires that comprise a bus subsystem. Transmission media also may also take the form of acoustic or light waves, such as those generated during radio wave and infrared data communications. For example, the term “computer-readable medium” shall accordingly be taken to included, but not be limited to, solid-state memories, a computer product embodied in optical and magnetic media, a medium bearing a propagated signal detectable by at least one processor of one or more processors and representing a set of instructions that when executed implement a method, a carrier wave bearing a propagated signal detectable by at least one processor of the one or more processors and representing the set of instructions a propagated signal and representing the set of instructions, and a transmission medium in a network bearing a propagated signal detectable by at least one processor of the one or more processors and representing the set of instructions.

It will be understood that the steps of methods discussed are performed in one embodiment by an appropriate processor (or processors) of a processing (i.e., computer) system executing instructions (computer-readable code) stored in storage. It will also be understood that the invention is not limited to any particular implementation or programming technique and that the invention may be implemented using any appropriate techniques for implementing the functionality described herein. The invention is not limited to any particular programming language or operating system.

Reference throughout this specification to “one embodiment” or “an embodiment” means that a particular feature, structure or characteristic described in connection with the embodiment is included in at least one embodiment of the present invention. Thus, appearances of the phrases “in one embodiment” or “in an embodiment” in various places throughout this specification are not necessarily all referring to the same embodiment, but may. Furthermore, the particular features, structures or characteristics may be combined in any suitable manner, as would be apparent to one of ordinary skill in the art from this disclosure, in one or more embodiments.

Similarly it should be appreciated that in the above description of exemplary embodiments of the invention, various features of invention are sometimes grouped together in a single embodiment, figure, or description thereof for the purpose of streamlining the disclosure and aiding in the understanding of one or more of the various inventive aspects. This method of disclosure, however, is not to be interpreted as reflecting an intention that the claimed invention requires more features than are expressly recited in each claim. Rather, as the following claims reflect, inventive aspects lie in less than all features of a single foregoing disclosed embodiment. Thus, the claims following the Detailed Description are hereby expressly incorporated into this Detailed Description, with each claim standing on its own as a separate embodiment of this invention.

Furthermore, while some embodiments described herein include some but not other features included in other embodiments, combinations of features of different embodiments are meant to be within the scope of the invention, and form different embodiments, as would be understood by those in the art. For example, in the following claims, any of the claimed embodiments can be used in any combination.

Furthermore, some of the embodiments are described herein as a method or combination of elements of a method that can be implemented by a processor of a computer system or by other means of carrying out the function. Thus, a processor with the necessary instructions for carrying out such a method or element of a method forms a means for carrying out the method or element of a method. Furthermore, an element described herein of an apparatus embodiment is an example of a means for carrying out the function performed by the element for the purpose of carrying out the invention.

In the description provided herein, numerous specific details are set forth. However, it is understood that embodiments of the invention may be practiced without these specific details. In other instances, well-known methods, structures and techniques have not been shown in detail in order not to obscure an understanding of this description.

As used herein, unless otherwise specified the use of the ordinal adjectives “first”, “second”, “third”, etc., to describe a common object, merely indicate that different instances of like objects are being referred to, and are not intended to imply that the objects so described must be in a given sequence, either temporally, spatially, in ranking, or in any other mariner.

“Variants of the IEEE 802.11 standard” as used herein means the variants and proposed variants of the IEEE 802.11 standard. Variants are versions defined in clauses of the standard and proposed amendments of the standard.

It should be appreciated that although the invention has been described in the context of variants of the IEEE 802.11 standard, the invention is not limited to such contexts and may be utilized in various wireless and non-wireless network applications and systems.

In one embodiment the SPDIF enabled device becomes the leader. In some embodiments, the group and the media source will not be implicitly linked together, so it may be possible for one device to have the SPDIF input and another to provide the streaming source from SPDIF.

A networked digital media device may be connected through any form of computer network including networks with wired and wireless physical layers and networks consisting of multiple physical layers. The network through which the digital media device is connected does not affect the operation of the group other than to partially vary the extent to which synchronous playback is possible.

While in most of the description above, a set of wireless speakers is used as an example of a networked digital media player, the invention is not limited to wireless speakers. Those in the art would readily be able to modify the description provided herein for wireless speakers and apply the methods and apparatuses to other discrete media devices. Thus while in one embodiments, some of the media devices include a radio interface and the network includes a wireless network, in general, the invention is applicable to media devices that can connect to a computer network. The description is provided in terms of wireless speakers in order to keep the description simple and not obscure the inventive concepts.

Furthermore, in most of the description above, a wireless audio system is used as an example of a networked digital media playback system—i.e., as an example of a system that allows one or more devices connected via a computer network to render digital media, the invention is not limited to a wireless audio system. Those of ordinary skill in the art would readily be able to modify the description provided for wireless audio systems herein and apply the methods and apparatuses to other digital media playback systems. The description is provided in terms of wireless speakers and a wireless audio system in order to keep the description simple and not obscure the inventive concepts.

All publications, patents, and patent applications cited herein are hereby incorporated by reference.

Any discussion of prior art in this specification should in no way be considered an admission that such prior art is widely known, is publicly known, or forms part of the general knowledge in the field.

In the claims below and the description herein, any one of the terms comprising, comprised of or which comprises is an open term that means including at least the elements/features that follow, but not excluding others. Thus, the term comprising, when used in the claims, should not be interpreted as being limitative to the means or elements or steps listed thereafter. For example, the scope of the expression a device comprising A and B should not be limited to devices consisting only of elements A and B. Any one of the terms including or which includes or that includes as used herein is also an open term that also means including at least the elements/features that follow the term, but not excluding others. Thus, including is synonymous with and means comprising.

Similarly, it is to be noticed that the term coupled, when used in the claims, should not be interpreted as being limitative to direct connections only. The terms “coupled” and “connected,” along with their derivatives, may be used. It should be understood that these terms are not intended as synonyms for each other. Thus, the scope of the expression a device A coupled to a device B should not be limited to devices or systems wherein an output of device A is directly connected to an input of device B. It means that there exists a path between an output of A and an input of B which may be a path including other devices or means. “Coupled” may mean that two or more elements are either in direct physical or electrical contact, or that two or more elements are not in direct contact with each other but yet still co-operate or interact with each other.

Thus, while there has been described what are believed to be the preferred embodiments Of the invention, those skilled in the art will recognize that other and further modifications may be made thereto without departing from the spirit of the invention, and it is intended to claim all such changes and modifications as fall within the scope of the invention. For example, any formulas given above are merely representative of procedures that may be used. Functionality may be added or deleted from the block diagrams and operations may be interchanged among functional blocks. Steps may be added or deleted to methods described within the scope of the present invention.