Data-stream sharing over communications networks with mode changing capabilities

FIELD

0001The subject matter described herein relates generally to a system and method for controlling and sharing data-streams over communications networks with the ability to change modes from a stream controller to a stream receiver and from a stream receiver to a stream controller.

BACKGROUND

0002Many social functions involve listening to music. Listening to music in some social settings may involve a live band or prerecorded music tracks playing and the use of equipment to amplify the audio signals and project them to the audience. As such, the audience may hear the amplified audio signals and enjoy the beat and melodies of the music. Since audio amplification and projection may result in loud volumes which are audible over distances, individuals in the vicinity of the event but not in the audience may hear the music even if they do not wish to, thus intruding on their peace. Other examples of useful implementations of the invention may include events such as political rallies or music festivals where numerous points of interest may exist in a localized area such as an arena, convention center, or fairground and where noise becomes a major issue and can interfere with each point of interest.

0003A “silent disco”, sometimes referred to as a “headphone event”, is a common name for a party, event, or other gathering where individuals may listen to multicast or broadcast music on wireless headphones. This allows individuals to hear the music and personally adjust the volume of the music based on the individuals own preferences. Use of headphones also helps to reduce the sound audible to individuals who are not tuning in to the broadcast and who may be disturbed by a loud audio projection of the broadcast. Silent disco events are sometimes popular in areas where local government has enacted noise curfews because they produce no loud audio signals. Silent disco events are also sometimes popular in mobile club gatherings or other flash mob type incidents.

0004Modernly, the concept of a silent disco is gaining popularity and has led to a greater demand for silent disco type events. In turn, this has led to a demand for broader and more varied applicability. Since many people now carry vast libraries of music around with them on a day-to-day basis using personal audio players, laptop computers, and other portable data storage devices they may wish to share music in-person with friends, family, coworkers, or other people and even be a disc jockey (“DJ”) master of ceremonies (“MC”), or other music coordinator or performer.

0005As such, improved methods and systems of audio sharing may be desirable.

SUMMARY

0006Provided herein are embodiments of a method and system of controlling and sharing data streams over networks. Typically a silent disco event consists of listeners tuning in to a broadcast by a single or small number of DJ's. In a typical silent disco event specialized hardware may be required in order to achieve the best synchronization of music streams to listeners and there is no opportunity for listeners to become broadcasters themselves using mobile devices which have become increasingly common.

0007Other systems, devices, methods, features and advantages of the subject matter described herein will be or will become apparent to one with skill in the art upon examination of the following figures and detailed description. It is intended that all such additional systems, devices, methods, features and advantages be included within this description, be within the scope of the subject matter described herein, and be protected by the accompanying claims. In no way should the features of the example embodiments be construed as limiting the appended claims, absent express recitation of those features in the claims.

BRIEF DESCRIPTION OF THE FIGURES

0008The details of the subject matter set forth herein, both as to its structure and operation, may be apparent by study of the accompanying figures, in which like reference numerals refer to like parts. The components in the figures are not necessarily to scale, emphasis instead being placed upon illustrating the principles of the subject matter. Moreover, all illustrations are intended to convey concepts, where relative sizes, shapes and other detailed attributes may be illustrated schematically rather than literally or precisely.

0009<figref idref="DRAWINGS">FIG. 1A</figref> is an example view of a basic network setup according to an embodiment of the present invention.

0010<figref idref="DRAWINGS">FIG. 1B</figref> is an example view of a network connected server system according to an embodiment of the present invention.

0011<figref idref="DRAWINGS">FIG. 1C</figref> is an example view of a user device according to an embodiment of the present invention.

0012<figref idref="DRAWINGS">FIG. 2</figref> is a block diagram depicting an example embodiment of a typical network structure and flow chart for data in a Wi-Fi network in accordance with the present invention.

0013<figref idref="DRAWINGS">FIG. 3</figref> is a sequence diagram depicting a 1D typical data sequence over a Wi-Fi network in accordance with the present invention.

0014<figref idref="DRAWINGS">FIG. 4</figref> is a block diagram depicting an example embodiment of a typical network structure and flow chart for data in a 3G network in accordance with the present invention.

0015<figref idref="DRAWINGS">FIG. 5</figref> is a sequence diagram depicting a typical data sequence over a 3G network in accordance with the present invention.

0016<figref idref="DRAWINGS">FIG. 6A</figref> is an example embodiment of a user interface of a mobile device in a stream controller mode in accordance with the present invention.

0017<figref idref="DRAWINGS">FIG. 6B</figref> is an example embodiment of a user interface of a mobile device in a listener/receiver mode in accordance with the present invention.

0018<figref idref="DRAWINGS">FIG. 6C</figref> is an example embodiment of a user interface of a mobile device in an audio stream access screen in accordance with the present invention.

DETAILED DESCRIPTION

0019Before the present subject matter is described in detail, it is to be understood that this disclosure is not limited to the particular embodiments described, as such may, of course, vary. It is also to be understood that the terminology used herein is for the purpose of describing particular embodiments only, and is not intended to be limiting, since the scope of the present disclosure will be limited only by the appended claims.

0020As used herein and in the appended claims, the singular forms “a”, “an”, and “the” include plural referents unless the context clearly dictates otherwise.

0021The publications discussed herein are provided solely for their disclosure prior to the filing date of the present application. Nothing herein is to be construed as an admission that the present disclosure is not entitled to antedate such publication by virtue of prior disclosure. Further, the dates of publication provided may be different from the actual publication dates which may need to be independently confirmed.

0022It should be noted that all features, elements, components, functions, and steps described with respect to any embodiment provided herein are intended to be freely combinable and substitutable with those from any other embodiment. If a certain feature, element, component, function, or step is described with respect to only one embodiment, then it should be understood that that feature, element, component, function, or step can be used with every other embodiment described herein unless explicitly stated otherwise. This paragraph therefore serves as antecedent basis and written support for the introduction of claims, at any time, that combine features, elements, components, functions, and steps from different embodiments, or that substitute features, elements, components, functions, and steps from one embodiment with those of another, even if the following description does not explicitly state, in a particular instance, that such combinations or substitutions are possible. It is explicitly acknowledged that express recitation of every possible combination and substitution is overly burdensome, especially given that the permissibility of each and every such combination and substitution will be readily recognized by those of ordinary skill in the art.

0023Although many of the examples below describe music embodiments it should be understood that embodiments are wide ranging and varied. For example, speech audio such as created during an educational lecture, political speech, walking tour, comedy act, language translation and others are contemplated. Likewise, audio accompanying television and other video feeds such as movies, and video clips are also contemplated. Additionally, live, recorded and delayed streams may be used in various embodiments. Embodiments are not limited to audio data. In some embodiments use and manipulation of video and other data are contemplated as well.

0024Turning to <figref idref="DRAWINGS">FIG. 1A</figref>, an example diagram of a basic network setup according to an embodiment of the present invention is shown.

0025In <figref idref="DRAWINGS">FIG. 1A</figref>, a system <b>1000</b> generally includes an audio-stream server system <b>1400</b> and a remote audio-stream database <b>1500</b>. Either audio-stream server system <b>1400</b> or remote audio-stream database <b>1500</b> may be distributed on one or more physical servers, each having one or more processors, memory, an operating system, input/output interfaces, and one or more network interfaces all known in the art. Also included are a plurality of end user devices <b>1200</b>, <b>1300</b>, <b>1600</b> coupled to a network <b>1100</b>, such as a public network (e.g., the Internet and/or a cellular-based wireless network) or a private network to which audio-stream server <b>1400</b> and remote audio-stream database <b>1500</b> may also be coupled. User devices include, for example, mobile device <b>1200</b> (e.g., phone, tablet, etc.), desktop or laptop devices <b>1300</b>, wearable device <b>1600</b><i>s </i>(e.g., watch, bracelet, glasses, audio headphone receivers), specialized media reception devices, other devices with computing capability and network interfaces, and so on. The remote audio-stream database <b>1500</b> includes, for example, audio files stored in memory and operable for accessing and playback. In some embodiments remote audio stream database <b>1500</b> and/or audio stream server <b>1400</b> may be dedicated third party platforms.

0026Turning to <figref idref="DRAWINGS">FIG. 1B</figref>, an example diagram of a network connected audio-stream server system according to an embodiment of the present invention is shown.

0027In <figref idref="DRAWINGS">FIG. 1B</figref>, a diagram of an audio-stream server system <b>1400</b> according to an embodiment is shown. An audio-stream server system <b>1400</b> includes a user device interface <b>1430</b> implemented with technology known in the art for communication with user devices <b>1200</b>, <b>1300</b>. Audio-stream server system <b>1400</b> also includes an audio-stream database interface <b>1440</b> implemented with technology known in the art for communication with audio-stream database <b>1500</b>. Audio-stream server system <b>1400</b> may further include an audio-stream server application program interface (API) <b>1420</b> that allows interaction between server based audio stream database <b>1410</b> and user devices <b>1200</b>, <b>1300</b>. Audio-stream server API <b>1420</b> is coupled to the server based audio-stream database <b>1410</b> to store and access audio-stream files as will be described below. Database <b>1410</b> may be implemented with technology known in the art, such as relational databases and/or object oriented databases.

0028Turning to <figref idref="DRAWINGS">FIG. 1C</figref>, an example diagram of a user device according to an embodiment of the present invention is shown.

0029In <figref idref="DRAWINGS">FIG. 1C</figref>, a diagram of a user mobile device <b>1200</b> according to an embodiment is shown. User mobile device <b>1200</b> includes a network connected data-stream application <b>1210</b> that is installed in, pushed to, or downloaded to the user mobile device <b>1200</b>. User mobile device may be any of a number of past, contemporary, and future user mobile devices including but not limited to smart-phones, media players, laptops, tablet computers, videogame consoles and others. These devices typically consist of displays showing graphical user interfaces to users; internal processors; internal memory; power sources such as rechargeable batteries; user input capabilities such as touchscreens, keyboards, joysticks, and others; and wireless connectivity hardware such as wireless transceivers. Often they have speakers and headphone jacks to plug in headphones.

0030Generally, a network connected data-stream application <b>1210</b> is installed in, pushed to, or downloaded to user mobile device <b>1200</b>. The user of data-stream application <b>1210</b> in some embodiments may be required to create a user account including a login name and password. In other embodiments no such account is required. Data-stream application <b>1210</b> may have at least two modes of operation that a user may select. One mode may be stream controller mode and one mode may be receiver mode. In many embodiments users of data-stream application may easily and quickly switch between modes.

0031In an example embodiment, a stream controller mode may control information sent in a communication network, particularly audio stream information. Information may be sent in communication networks via packets, sometimes called frames. Packets generally include two types of data, namely control data and payload data. Control data provides information that a communication network may use in order to deliver the packet to the correct location. Control data may include network addresses of the source and the destination, error detection codes, sequence information, time to live information, and others. Payload data typically is data a user wishes to transmit or receive. Payload data may be encrypted in some applications. Control data is typically located in portions of the packet called packet headers and packet trailers while payload data may be located in the between packet headers and packet trailers.

0032Turning to <figref idref="DRAWINGS">FIG. 2</figref>, a block diagram depicting an example embodiment of a typical network structure and flow chart for data in a Wi-Fi network in accordance with the present invention is shown.

0033In general, network structure and data flow <b>100</b> is shown. In the example embodiment, network structure includes stream controller <b>1220</b> receiving, accessing, or otherwise using audio streams <b>108</b> from remote audio sources <b>102</b>, internal/external audio input <b>104</b>, and/or media libraries <b>106</b>.

0034In some embodiments internal/external audio input <b>104</b> may include input from devices such as microphones, turntables, mixers, music players such as tape decks, record players, eight-track players, radios, personal media devices, televisions and/or others. In some embodiments media library <b>106</b><i>s </i>may include locally saved music files stored in libraries such as databases. Media libraries may be organized according to numerous different cataloging methods including grouping music by artist, title, genre, date of acquisition, and others.

0035Stream Controller <b>1220</b> is a mobile device <b>1200</b> with data-stream application <b>1210</b> installed and a stream controller mode active. Stream Controller <b>1220</b> is operable to control audio streams multicasts or broadcasts for other mobile device <b>1200</b><i>s </i>to tune into. Any mobile device <b>1200</b> with data-stream application <b>1210</b> may be transitioned from a listening/receiving mode to a stream controller mode (and thus into Stream Controller <b>1220</b>) using simple mode-change controls within data-stream application <b>1210</b>, as shown in <figref idref="DRAWINGS">FIG. 6B</figref>. Likewise, any Stream Controller <b>1220</b> may be transitioned from stream-controller mode into a listening/receiving mode (labeled generically as mobile device <b>1200</b><i>s</i>) using simple mode change controls within data-stream application <b>1210</b>, as shown in <figref idref="DRAWINGS">FIG. 6A</figref>. Although a single Stream Controller <b>1220</b> is shown in many figures in this application, multiple Stream Controller <b>1220</b><i>s </i>may exist on a single network and function similarly. This provides mobile device <b>1200</b><i>s </i>variability in selecting which Stream Controller <b>1220</b> to follow, tune-in, or listen when in listening/receiving mode. In some embodiments additional functionality may be provided such as linking multiple Stream Controller <b>1220</b><i>s</i>, toggling, or otherwise communicating between Stream Controller <b>1220</b><i>s. </i>

0036Remote audio sources <b>102</b> may be remote audio-stream databases <b>1500</b> or server based audio-stream database <b>1410</b><i>s</i>, among others. Remote audio source <b>102</b><i>s </i>may also include musical instruments, microphones, and other devices used to create audio streams for transmission over wired or wireless networks to Stream Controller <b>1220</b> and communicatively coupled to data transceivers. In some embodiments remote audio sources <b>102</b> may be third party audio source systems such as SoundCloud® by SoundCloud Limited, Spotify® by Spotify, Ltd., Pandora® by Pandora Media, Inc., or others. In some embodiments Stream Controller <b>1220</b> may access other mobile device <b>1200</b><i>s </i>storing audio as remote audio source <b>102</b><i>s. </i>

0037Media library <b>106</b> may be a library or other database of audio, visual and/or other data which is stored. In some embodiments media library <b>106</b> may be stored on portable storage media, such as on a USB flash drive or other memory stick; stored on locally connected equipment such as a laptop, computer, media player, or other device which may be wire-connected to Stream Controller <b>1220</b>; or stored on mobile device <b>1200</b> itself acting as Stream Controller <b>1220</b>. In some embodiments Stream Controller <b>1220</b> may access other wire-connected or wirelessly connected mobile device <b>1200</b><i>s </i>storing audio as media library <b>106</b><i>s. </i>

0038Internal/External Audio input <b>104</b> may include one or more audio player and/or manipulation devices. Examples of audio player and/or manipulation devices include turntables, sequencers, audio mixers, crossfaders, effects units, digital controller hardware, samplers, electronic musical keyboards, drum machines, guitars, basses, microphones, televisions, cable or satellite television receivers, Compact Disc (CD) players, Digital Video Disc (DVD) players, High Definition (HD) DVD players, Blu-ray™ players, Versatile Multilayer Disc players, EVD players, AM/FM radios, and other controllers, devices, and musical instruments. In some cases Internal/External Audio input <b>104</b> may receive audio stream <b>108</b><i>s </i>directly or indirectly from media library <b>106</b> and/or remote audio sources <b>102</b>. Depending on the type of internal/external audio input <b>104</b> device used, the audio stream <b>108</b> may be altered, modified, or otherwise changed before forwarding the audio stream <b>108</b> along to Stream Controller <b>1220</b>.

0039As a first example, if Internal/External Audio input <b>104</b> is an audio mixer equipped with a crossfader, a mobile device <b>1200</b> acting as Stream Controller <b>1220</b> may be able to smoothly transition from one song to another song using different audio stream <b>108</b><i>s</i>. As a second example, a user operating Stream Controller <b>1220</b> may use a microphone to talk or sing over audio tracks from audio stream <b>108</b><i>s </i>while they are playing so as to introduce songs to listeners operating mobile device <b>1200</b><i>s </i>in receiver mode. As another example, a guitarist may connect electric guitar as Internal/External Audio input <b>104</b> operatively coupled with Stream Controller <b>1220</b> in order to play the guitar over pre-recorded music tracks during a live guitar performance. Multiple Internal/External Audio input <b>104</b> devices may be used in various setups and a myriad of such combinations exist.

0040After activating stream controller mode to transition a mobile device <b>1200</b> into Stream Controller <b>1220</b>, Stream Controller <b>1220</b> may select a particular audio stream <b>108</b> from audio stream <b>108</b><i>s </i>it is receiving if more than one is being sent at a time. In some embodiments Stream Controller <b>1220</b> may access and receive audio stream <b>108</b><i>s </i>over a network (such as when remote audio sources <b>102</b> are selected). In an example embodiment a network is Wi-Fi network <b>116</b>. Stream Controller <b>1220</b> may then unicast the audio stream and ACK/Control (acknowledgement/control) signals <b>112</b> to or over Wi-Fi network <b>116</b>. In some embodiments Wi-Fi network <b>116</b> may be another private or semi-private network such as Bluetooth, or others. Alternatively, Wi-Fi network <b>116</b> may be replaced or supplemented by wired networks in some embodiments. Prior to, contemporaneous with, or subsequent to sending signals <b>112</b> to or over Wi-Fi network <b>116</b>, Stream Controller <b>1400</b> may advertise or otherwise broadcast Stream Controller <b>1220</b>'s presence <b>114</b> to or over Wi-Fi network <b>116</b>. Mobile device <b>1200</b><i>s </i>may receive audio stream <b>108</b><i>s </i>and audio control signals <b>118</b> from Wi-Fi network <b>116</b> and may process audio stream <b>108</b><i>s </i>and convert them into audio for listening using headphones, although speakers or other audio output equipment may also be used to play audio from audio stream <b>108</b><i>s. </i>

0041The system and methods described herein contemplate that many mobile device <b>1200</b><i>s </i>may switch modes based on user choice such as an operating mode change and become Stream Controller <b>1220</b><i>s</i>. The alternative is also true in that a Stream Controller <b>1220</b> has the functionality to become a listening mobile device <b>1200</b> upon a user choice such as an operating mode change.

0042Turning to <figref idref="DRAWINGS">FIG. 3</figref>, a sequence diagram depicting a typical data sequence over a Wi-Fi network <b>116</b> in accordance with the present invention is shown.

0043In general, <figref idref="DRAWINGS">FIG. 3</figref> shows a typical data sequence <b>200</b> over a Wi-Fi network <b>116</b>, particularly the interaction between remote audio source <b>102</b>, Stream Controller <b>1220</b>, Wi-Fi <b>116</b>, and mobile device <b>1200</b>.

0044In the example embodiment audio meta-info or metadata is first sent from remote audio source <b>102</b> to Stream Controller <b>1220</b>. Examples of meta-info may include copyright information, song information, song length, artist name, composer, beats per minute (bpm), musical key, or others.

0045Next, Stream Controller <b>1220</b> begins data broadcast loop <b>202</b>. Data broadcast loop <b>202</b> generally involves Stream Controller <b>1220</b> transmitting audio stream information (AudioStream info in the diagram) to a Wi-Fi router on Wi-Fi network <b>116</b>. In some embodiments this audio stream information includes an Internet Protocol (IP) address of Stream Controller <b>1220</b> and/or one or more remote audio source <b>102</b><i>s</i>. This information is useful for mobile device <b>1200</b><i>s </i>in order to make appropriate connections to receive the correct audio stream. Data broadcast loop <b>202</b> may continue perpetually until Stream Controller <b>1220</b> terminates it by ending the concert, event, or other activity. After audio stream information is transmitted by Stream Controller <b>1220</b> to Wi-Fi <b>116</b> it may be broadcasted by Wi-Fi <b>116</b> and received by mobile device <b>1200</b><i>s</i>. Inclusion of meta-info at earlier steps allows mobile device <b>1200</b><i>s </i>to display the meta-info in the audio stream application <b>1210</b> so that the user may view information about the audio stream <b>108</b> that Stream Controller <b>1220</b> is using.

0046Also included in this diagram is sync process loop <b>204</b> which may occur periodically or non-periodically as required by the particular network conditions. Sync process loop <b>204</b> includes mobile device <b>1200</b> sending SyncRequest (IP) signals to Stream Controller <b>1220</b>. This means that mobile device <b>1200</b> is requesting a status update of the AudioStream Info in order to ensure the current stream is being received. In response to SyncRequest (IP) signals, Stream Controller <b>1220</b> sends back SyncResponse (IP) signals to mobile device <b>1200</b>. In a typical embodiment, SyncResponse (IP) signal may include 8 bytes each of clientID data, clientTime data, serverID data, and serverTime data. ClientID data may be a copy of the received client ID from the SyncRequest, clientTime data may be a copy of the client clock time from the original SyncRequest, serverID data may be a unique ID for the server, and serverTime data may be a current server clock time.

0047After Stream Controller <b>1220</b> completes data broadcast loop <b>202</b>, a first segment or chunk of audio data N is sent to Stream Controller <b>1220</b>. Stream Controller <b>1220</b> may then send this first audio chunk N to mobile device <b>1200</b>, typically by broadcasting it via network <b>116</b>. The process repeats for a next audio chunk N+1 (Stream Controller <b>1220</b> receives it from audio source <b>102</b> and then sends it to mobile device <b>1200</b> via network <b>116</b>). Subsequent to receiving some or each audio chunk, mobile device <b>1200</b> may send Accept N which is an acknowledgement signal. For each audio packet with index N received by mobile device <b>1200</b>, mobile device <b>1200</b> will respond by sending an acknowledgement packet of index N. Mobile device <b>1200</b> may perform base checks on incoming packet or frame structure to determine whether data is valid or corrupt. If corrupt, the packet or frame may simply be skipped and no acknowledgment packet sent. Stream Controller <b>1220</b> may store information about acknowledgement data received from mobile device <b>1200</b><i>s</i>. In cases where acknowledgement packets are not received after a predetermined time threshold Stream Controller may resend the packet associated with the missing acknowledgement packet. Numerous error checking methods are known in the art and many may be appropriate in various embodiments herein.

0048Audiochunk data in a typical embodiment may include 8 bytes each of serverPlayingPosition and serverincrementationTime. ServerPlayingPosition may be a current server playing position such as the ID of an audio chunk that was played last. ServerincrementationTime may be a time when the last audio chunk was loaded to an AudioQueue or otherwise played. Time in this case does not necessarily mean current time in the real-world but may mean time that has passed from the last device boot in nanoseconds.

0049Each packet sent in the system may include a header with 2 bytes mHeader, 2 bytes mVersion, and 8 bytes mPacketID. MHeader may be a program identifier such as “LI”, mVersion may be a program version “0x02” and mPacketID may be a packet identifier.

0050It should be noted that additional steps may not be shown herein for brevity. For example, although Stream Controller <b>1220</b> and mobile device <b>1200</b> are shown as transmitting directly to each other in the diagram there may be actual steps of sending to a Wi-Fi router on Wi-Fi network <b>116</b> which are not shown in detail but would are understood by those in the art may occur.

0051Turning to <figref idref="DRAWINGS">FIG. 4</figref>, a block diagram depicting an example embodiment of a typical network structure and flow chart for data in a 3G network in accordance with the present invention is shown.

0052In the example embodiment typical network architecture and flow chart for data in a 3G network <b>300</b> includes Stream Controller <b>1220</b>, remote audio source <b>102</b><i>s</i>, mobile device <b>1200</b><i>s</i>, and synchronization server <b>1400</b><i>s. </i>

0053In the example embodiment, Stream Controller <b>1220</b> generally will access one or more remote audio source <b>102</b><i>s </i>over a 3G network. In some embodiments a 4G network may be used.

0054Stream Controller <b>1220</b> and mobile device <b>1200</b><i>s </i>are operable to receive audio streams and/or files from remote audio sources <b>102</b> over one or multiple 3G networks. In the example embodiment Stream Controller <b>1220</b> will first post a presence notification to synchronization servers <b>1400</b>. Simultaneously or subsequently, Stream Controller <b>1220</b> will begin transmitting current and/or next song information as well as playing position information to synchronization servers <b>1400</b>. Playing position information may also be periodically transmitted to synchronization servers <b>1400</b> in order to keep mobile unit <b>1200</b><i>s </i>current which are following the broadcast. Mobile device <b>1200</b><i>s </i>are able to communicate with synchronization servers <b>1400</b> to determine current and next song information and playing position information. Mobile Device <b>1200</b><i>s </i>are also operable to communicate or at least receive information from remote audio source <b>102</b><i>s </i>in the form of audio streams and/or files.

0055Although not shown in <figref idref="DRAWINGS">FIG. 4</figref>, other elements may also be included similar to <figref idref="DRAWINGS">FIG. 2</figref> such as Internal/External Audio Input <b>104</b><i>s </i>and media library <b>106</b><i>s </i>with similar functionality.

0056Turning to <figref idref="DRAWINGS">FIG. 5</figref>, a sequence diagram depicting a typical data sequence over a 3G network in accordance with the present invention is shown.

0057In the example embodiment data sequence over a 3G network <b>400</b> generally shows the interaction between Stream Controller <b>1220</b>, synchronization server <b>1400</b>, and mobile device <b>1200</b> including Stream Controller-Server sync process loop <b>402</b>, mobile device-Server sync process loop <b>404</b>, presence update via connection loop <b>406</b>, and presence update via polling loop <b>408</b>.

0058Stream Controller-Server sync process loop <b>402</b> generally includes Stream Controller <b>1220</b> sending a SyncRequest to synchronization server <b>1400</b> via the network similar to the description above. Upon receiving the SyncRequest from Stream Controller <b>1220</b>, synchronization server <b>1400</b> sends SyncResponse back to Stream Controller <b>1220</b> similar to that described. In some embodiments “pre-downloaded” data files may be used for playback. In some embodiments data files may be streamed directly from a server.

0059After SyncResponse is received from synchronization server <b>1400</b>, Stream Controller <b>1220</b> may begin playing an audio track. Stream Controller <b>1220</b> will then notify server of an updated presence such as what audio track is currently being played and/or what audio track is upcoming.

0060Mobile device-Server sync process loop <b>404</b> generally includes mobile device <b>1200</b> sending a SyncRequest to synchronization server <b>1400</b> via the network. Upon receiving the SyncRequest from mobile device <b>1200</b>, synchronization server <b>1400</b> sends SyncResponse to mobile device <b>1200</b> including information as previously described. The functionality over 3G and Wi-Fi is similar in this loop.

0061After mobile device-Server sync process loop <b>404</b>, mobile device <b>1200</b> may request a list of current Stream Controller <b>1220</b><i>s </i>from synchronization server <b>1400</b>. A list of current Stream Controller <b>1220</b><i>s </i>will typically include Stream Controller <b>1220</b><i>s </i>which have successfully completed Stream Controller-Server sync process loop <b>402</b>. Synchronization server <b>1400</b> may use additional criteria in some embodiments to determine a list of current Stream Controller <b>1220</b><i>s </i>such as determining which connected Stream Controller <b>1220</b><i>s </i>are actually playing audio tracks by evaluating whether Stream Controller <b>1220</b><i>s </i>have sent recent updates to synchronization server <b>1400</b>.

0062When synchronization server <b>1400</b> determines which Stream Controller <b>1220</b><i>s </i>are active it will respond to mobile device <b>1200</b> by sending a list. After receiving the list mobile device <b>1200</b> will notify the user by displaying the list and requesting user input in the form of choosing a Stream Controller <b>1220</b>. Once the user has chosen a Stream Controller <b>1220</b>, mobile device <b>1200</b> will notify synchronization server <b>1400</b> and synchronization server <b>1400</b> will respond by sending the appropriate stream from the chosen Stream Controller <b>1220</b>.

0063Presence update via connection loop <b>406</b> generally includes Stream Controller <b>1220</b> sending presence update information, such as current playing information, to synchronization server <b>1400</b> periodically via a network. In some embodiments this may mean sending presence update information when an audio track changes or when Stream Controller <b>1220</b> manipulates the audio track in some manner. In some embodiments this may mean sending presence update information when an audio stream changes. In some embodiments this may mean sending presence update information when an audio source changes. In some embodiments this may mean sending presence update information at regular time intervals or other times, such as thirty seconds before an audio track will end, or others. In the example embodiment synchronization server <b>1400</b> may update an internal register to track changes in presence update information. In the example embodiment synchronization server <b>1400</b> sends presence update information to mobile device <b>1200</b><i>s </i>via the network. Mobile device <b>1200</b><i>s </i>receive the presence update information, process it, and may then use it accordingly, such as to apply changes, play current audio, or otherwise update their internal information for upcoming audio tracks.

0064Presence update via polling loop <b>408</b> includes Stream Controller <b>1220</b> sending update presence signals to synchronization server <b>1400</b>, such as a currently playing item. Mobile device <b>1200</b><i>s </i>may then receive updated information on a current or multiple current Stream Controller <b>1220</b><i>s </i>by polling synchronization server <b>1400</b> about current Stream Controller <b>1220</b><i>s </i>presences. Based on the current presence, mobile device <b>1200</b><i>s </i>may update the currently playing item.

0065Presence update via connection loop <b>406</b> and presence update via polling loop <b>408</b> are generally alternative ways for mobile device <b>1200</b><i>s </i>to receive updated information although in some embodiments they may function in a complementary fashion.

0066Turning to <figref idref="DRAWINGS">FIG. 6A</figref>, an example embodiment of a user interface of a mobile device <b>1200</b> in Stream Controller mode <b>600</b> is shown. Numerous controls, buttons, and indicators are shown which allow a user to operate as Stream Controller <b>1220</b>.

0067Selecting Comment button <b>602</b> allows a user to provide comments to the system operator for improved system operability. Mode toggle button <b>604</b> allows users to toggle between stream controller mode and listener/receiver mode. In operation it changes user interface views from Stream Controller mode <b>600</b> to Listener/Receiver mode <b>620</b> shown in <figref idref="DRAWINGS">FIG. 6B</figref>. Currently track indicator <b>606</b> shows the user what track is currently selected and playing. Track listing <b>608</b> shows the user what tracks are currently set to play in the current playlist. Tracks may be removed from the current listing by swiping to the left. A trash icon may then appear on the song listing and the track may be removed by selecting the trash icon. Order change button <b>610</b><i>s </i>allow the user to drag and drop in order to change the track order (for instance, by swapping the position of tracks <b>2</b> and <b>3</b>). Audio meta-info <b>612</b> shows the user meta-info about the currently playing track such as time elapsed, total time, track title, and others in various embodiments. Operating mode indicator <b>614</b> shows a user that the device is currently an active Stream Controller <b>1220</b>. Current track position <b>616</b> shows a user where in the playlist the user is currently located. Audio stream addition button <b>618</b> allows users to add additional audio streams by displaying Audio stream access screen <b>630</b> shown in <figref idref="DRAWINGS">FIG. 6C</figref>.

0068Turning to <figref idref="DRAWINGS">FIG. 6B</figref>, an example embodiment of a stream controller selection user interface <b>620</b> for a user in Listener/Receiver mode is shown. Selecting Comment button <b>602</b> allows a user to provide comments to the system operator for improved system operability. Mode toggle button <b>604</b> allows users to toggle between stream controller mode and listener/receiver mode. In operation it changes user interface views from Listener/Receiver mode <b>620</b> Stream Controller mode <b>600</b> shown in <figref idref="DRAWINGS">FIG. 6A</figref>. Current Stream Controller list <b>622</b> will display Stream Controller <b>1220</b><i>s </i>within the user's selected network. Also included are distance marker <b>640</b><i>s </i>indicating an approximate and/or exact distance between the user's mobile device and each Stream Controller <b>1220</b>. Selecting a Stream Controller <b>1220</b> to tune may take a user to a tuned-in user interface screen <b>650</b> as shown in <figref idref="DRAWINGS">FIG. 6D</figref>.

0069Turning to <figref idref="DRAWINGS">FIG. 6C</figref>, an example embodiment of a user interface of Audio stream access screen <b>630</b> is shown. External access button <b>632</b> will provide users access to external audio connections. Remote audio source button <b>634</b><i>s </i>allow users to access third party sources in the example embodiment. In some instances third party sources may require login information that may be inputted directly into the system. In other instances third party sources may allow users to search and add audio tracks directly. Music library button <b>636</b> allows users to add music choices from the users own music library. In the example embodiment the music library is a music library stored locally on mobile device <b>1200</b>.

0070Turning to <figref idref="DRAWINGS">FIG. 6D</figref>, an example embodiment of a tuned-in user interface screen <b>650</b> is shown. In the example embodiment a user has selected a stream controller to receive data from. The stream controller title <b>654</b> shows the user the name of the current stream controller. Back button <b>652</b> may return the user to the previous screen, for instance a stream controller selection user interface <b>620</b> as shown in <figref idref="DRAWINGS">FIG. 6B</figref>. Status icon <b>656</b> may show a status of the current stream controller such as paused, playing, stopped, or others using different graphical or other indicators. In the example embodiment, headphones with wave pulses coming from the ear pieces may indicate that the stream controller is in play mode. Alternatively or additionally, status icon <b>656</b> may display whether data is being received from the stream controller.

0071Title <b>658</b> may display the title of a current data stream, such as the title of a current audio stream which is playing. Author <b>660</b> may indicate the author of a current data stream. In an example embodiment where music is being received, Author <b>660</b> may be an artist, composer, arranger, creator or other entity. Time elapsed indicator <b>662</b> may show the time elapsed since a data stream began or the time elapsed since a portion of a data stream began. Time remaining <b>666</b> may indicate the time remaining until a data stream expires or the time remaining until a portion of a data stream expires. Progress indicator <b>664</b> may show the progress of a current data stream or portion of a current data stream. For instance, in the example embodiment, a small percent of the data stream has elapsed and thus progress indicator <b>664</b> has an equivalent small percent shown of a full one-hundred percent. Stop button <b>668</b> may temporarily pause or permanently stop a current data stream from the currently selected stream controller.

0072Although audio data is the primary focus of the above description, it should be understood that the systems and methods described herein are not limited to audio data. In some instances video, gaming or other data may be shared, altered, controlled, and otherwise distributed according to the methods and systems described herein. Likewise, other processing, and/or data file-sharing, manipulation, management etc. may be accomplished using the methods and systems described herein.

0073In many instances entities are described herein as being coupled to other entities. It should be understood that the terms “coupled” and “connected” (or any of their forms) are used interchangeably herein and, in both cases, are generic to the direct coupling of two entities (without any non-negligible (e.g., parasitic) intervening entities) and the indirect coupling of two entities (with one or more non-negligible intervening entities). Where entities are shown as being directly coupled together, or described as coupled together without description of any intervening entity, it should be understood that those entities can be indirectly coupled together as well unless the context clearly dictates otherwise.

0074While the embodiments are susceptible to various modifications and alternative forms, specific examples thereof have been shown in the drawings and are herein described in detail. It should be understood, however, that these embodiments are not to be limited to the particular form disclosed, but to the contrary, these embodiments are to cover all modifications, equivalents, and alternatives falling within the spirit of the disclosure. Furthermore, any features, functions, steps, or elements of the embodiments may be recited in or added to the claims, as well as negative limitations that define the inventive scope of the claims by features, functions, steps, or elements that are not within that scope.