The inventions below relate to the field of internet communications.
Recently, radiobroadcasters have begun transmitting their audio content over the internet, allowing consumers to listen to radio stations received over the internet and played through computer speakers. For a home user to receive radio station “netcasts” over the internet, the user must have a personal computer, an internet account, browser software such as Internet Explorer® or Netscape Navigator®, an audio processing software “plug-in” capable of processing audio information, and a radio simile graphical interface. An Internet Radio Receiver and Interface, described in our co-pending application U.S. application Ser. No. 09/334,846, hereinafter referred to as internet appliance, incorporates all of the necessary computer hardware and software needed to connect to the internet and communicate with various sources of audio information such as radiobroadcasters.
Audio files are typically large and if downloaded as a whole could take fifteen minutes of wait time for each one minute of audio played. A process called streaming audio allows the user to listen to the audio while it downloads to their internet appliance (as opposed to downloading a music file and playing the file after the download is complete). There are a number of streaming audio formats available. The common ones today include Real Networks G2 and G7, Microsoft Windows Media, Shoutcast MP3 and Icecast MP3.
When a user changes the internet radio station he is listening to, the internet appliance must (a) establish a data connection with the new internet radio station, (b) receive and store streaming audio data into a data buffer, and (c) start playing the streaming audio data from the head of the buffered data while adding new streaming audio data to the tail of the buffered data. Step (b) here is commonly called buffering or pre-buffering and may take on the order of several seconds to about 10 seconds or more depending on the user's connection quality to the network, network traffic, and the characteristics of the streaming audio to which the user is trying to connect. Currently, this dead air time is filled with silence and is visually represented (when the streaming media is received through a computer with a screen) with a small “progress bar” or message announces how much of the buffering has been completed. When the buffer level reaches 100% the user then starts to hear audio from the computer. Savvy internet radio listeners are accustomed to such delays in getting access to internet content. However, when one breaks the assumption that internet radio will always be listened to at a computer where the user is looking at some visual display, then the dead air time is annoying. Our internet radio appliances mimic the functionality of a traditional FM radio, allowing the user to listen to internet “radio stations” through an appliance that does not require a fully functional personal computer, and instead functions in a manner similar to a traditional radio or audio receiver. In the embodiment of our internet radio system, the dead air time is unacceptable and potentially confusing. The dead air time incident to buffering and pre-buffering, however, can be filled with audio content as desired.
To address and eliminate dead air time incident to negotiation, buffering and pre-buffering when connecting an internet appliance to an internet media server, the system and method described below identify the dead air time and provide alternate audio content during negotiation, buffering and pre-buffering. “Pre-rolls”, or short pieces of audio content, are stored in the internet appliance or a system management server and played during the dead air time. These pre-rolls are played during the time between the user selecting a new station and the start of the audio playing from the new station stream. Thus, the dead air time between changing internet radio stations has been eliminated.
a is a block diagram of storing IRQQ audio data into the play buffer and playing IRQQ audio data out from the play buffer.
b is a block diagram of storing IRKR audio data into the play buffer and playing pre-roll data out from the pre-roll storage.
c is a block diagram of storing IRKR audio data into the play buffer and playing IRKR audio data out from the play buffer.
The internet appliance 1 is the user interface whereby the user can select the desired internet radio station by simply tuning it in, just as you would a traditional radio. The internet appliance 1 is fully described in our co-pending application Internet Radio Receiver and Interface, U.S. application Ser. No. 09/334,846 and incorporated herein in its entirety. Internet Radio Receiver and Interface describes devices and method for receiving radio broadcasts (webcasts) over the internet in a device that resembles a typical radio receiver. The hardware is housed in a radio box separate from a personal computer, and the interface is a panel of physical radio knobs, buttons, FM and AM channel indicators, etc., on the radio housing. Inside the radio box, necessary computer components and software permit connection to the internet and communication with various sources of audio information. In one embodiment, the device is a completely stand-alone device that a consumer can plug into a telephone line, ISDN line, local area network, or cable line and select radio stations with the same type of controls as a typical radio. In another embodiment, the device is a box that communicates with the internet through the user's personal computer, which must then have an internet connection and internet software installed and operating and communicate with audio components, to play the audio content. In third and fourth embodiments, the internet appliance is either a personal computer or a web TV with the necessary browser software, audio processing software, and radio simile graphical interface.
The internet content database server such as internet radio database server 2 processes the user's request and is the primary interface to the internet appliance 1. The internet radio database server 2 maintains, in this example, internet radio station information, including a list of stations (audio content providers), their streaming media format, bit rate output, and associated URL. The internet radio database server 2 also maintains a list of “pre-rolls”, fully described below, for each of the internet radio stations. The internet radio database server 2 talks to the internet appliance 1 so that the server knows at what bit rate the user is connected to the internet (56K, ISDN, DLS for example) and what streaming media format the user's player requires (streaming MP3 for example).
Since audio data files are large, a process called streaming audio allows the user to listen to the audio while it downloads to their internet appliance. When the user selects an internet radio station, the internet appliance 1 sends a request to the internet radio database server 2. The internet radio database server responds with the URL of the internet radio station (the media content server) the user wants to play and also has instructions that tell what internet appliance audio processing software is required to play the requested audio content. The internet appliance, database server, and media content server negotiate to arrange the transmission of streaming audio content to the client. The requested audio content has, in most instances, been compressed and encoded. If the file was not compressed, the sound file would be too large and would be too long to send and be played with currently available internet connections. The requested audio content is transmitted in “packets” of compressed audio, and these packets are sent to a buffer on the internet appliance. Once the buffer is full, the internet appliance starts to play the audio. Thereafter, the streaming process provides an uninterrupted stream of audio content to the audio components of the client system. However, the negotiation and buffering take some several seconds, creating a long gap of time between selection of a station and eventual play of the station's audio content on the client's audio system.
To fill the gap, referred to by analogy as dead air time, short pieces of audio content are played during the time between the user selecting a new internet radio station and the start of audio playing from the new station stream. We refer to these short pieces of audio content as “pre-rolls” or “clips.” From the user's perspective, this eliminates the dead time when changing stations. There are a number of possible content alternatives for the pre-rolls. The pre-roll can contain verbal announcement, to announce to the user the station identification such as “This is IRQQ Cool Jazz from San Francisco”. There is the possibility of playing a musical clip from the station. Alternatively, a locally generated audio clip (from the user's ISP, for example) might be inserted also, for example, “You have new mail.” The station identification or other clips might be mixed with a musical background which is longer than the spoken text and may be looped to cover an extended buffer time. Naturally, the announcement could also indicate the progress and status “buffering fifty percent completed”.
The “pre-rolls” can be stored locally, in pre-roll storage 5, in the internet appliance playing the internet radio content as shown. Storage 5 may be any form of computer memory, including a computer hard disk, flash memory or the like. The pre-rolls do not require much storage if stored in a compressed format such as MP3. Locally generated audio content could also be generated by software either stitching together smaller audio pieces, a local synthesizer playing midi or a local software speech synthesizer.
Basically, any computer memory accessible to the client computer, either locally or through the internet, may be used to store any number of files of audio content suitable for use a pre-rolls. Pre-rolls could be stored on the system management server or on a separate a high performance server (not shown) which is in network terms on the internet, very close to the end user. This means that the expected jitter is low and the buffering for the pre-roll can be minimal. This network pre-roll could be combined with a local pre-roll on the local machine which might be only a second or two. This would allow more flexibility in the updating of the pre-rolls as they do not have to be sent to each end user's system.
The pre-rolls stored on the user's local system may be updated transparently to the user either when the system is idle or in the background when there is spare bandwidth. For example, user specific information (an announcement of waiting mail on the user's mail server) can be loaded into pre-roll storage during transmission of audio content. Pre-rolls for the user's favorite stations could be updated first and more often than those for stations infrequently used.
A clip could be stored from the last time the user listened to a particular internet radio station. One or more pre-rolls could be stored for each station in the database and the choice of which pre-roll is sent to a particular internet appliance could be on the basis of some user data such as language preference.
In the system shown in
Thus, while the preferred embodiments of the devices and methods have been described in reference to the environment in which they were developed, they are merely illustrative of the principles of the inventions. Other embodiments and configurations may be devised without departing from the spirit of the inventions and the scope of the appended claims.
This application is a continuation of U.S. patent application Ser. No. 09/570,837 filed on May 12, 2000 now abandoned.
Number | Name | Date | Kind |
---|---|---|---|
5014301 | Maltezos | May 1991 | A |
5142528 | Kobayashi | Aug 1992 | A |
5490275 | Sandvos | Feb 1996 | A |
5557541 | Schulhof et al. | Sep 1996 | A |
5572442 | Schulhof et al. | Nov 1996 | A |
5629867 | Goldman | May 1997 | A |
5721956 | Martin et al. | Feb 1998 | A |
5726909 | Krikorian | Mar 1998 | A |
5734119 | France et al. | Mar 1998 | A |
5790423 | Lau et al. | Aug 1998 | A |
5809246 | Goldman | Sep 1998 | A |
5815707 | Krause et al. | Sep 1998 | A |
5822537 | Katseff et al. | Oct 1998 | A |
5828839 | Moncreiff | Oct 1998 | A |
5841979 | Schulhof et al. | Nov 1998 | A |
5844158 | Butler et al. | Dec 1998 | A |
5892536 | Logan | Apr 1999 | A |
5922045 | Hanson | Jul 1999 | A |
5926624 | Katz | Jul 1999 | A |
5956681 | Yamakita | Sep 1999 | A |
6005563 | White et al. | Dec 1999 | A |
6012086 | Lowell | Jan 2000 | A |
6014569 | Bottum | Jan 2000 | A |
6047323 | Krause | Apr 2000 | A |
6163683 | Dunn et al. | Dec 2000 | A |
6222979 | Willis et al. | Apr 2001 | B1 |
6223292 | Dean et al. | Apr 2001 | B1 |
6226616 | You et al. | May 2001 | B1 |
6248946 | Dwek | Jun 2001 | B1 |
6249810 | Kiraly | Jun 2001 | B1 |
6269456 | Hodges et al. | Jul 2001 | B1 |
6289207 | Hudecek et al. | Sep 2001 | B1 |
6385212 | Baba et al. | May 2002 | B1 |
6405255 | Stoltz et al. | Jun 2002 | B1 |
6408315 | McManus et al. | Jun 2002 | B1 |
6430236 | Funakoshi | Aug 2002 | B1 |
6449260 | Sassin et al. | Sep 2002 | B1 |
6456601 | Kozdon et al. | Sep 2002 | B1 |
6493446 | Cherry | Dec 2002 | B1 |
6496205 | White et al. | Dec 2002 | B1 |
6526041 | Shaffer et al. | Feb 2003 | B1 |
6539417 | Stern | Mar 2003 | B2 |
6546427 | Ehrlich et al. | Apr 2003 | B1 |
6625656 | Goldhor et al. | Sep 2003 | B2 |
6654367 | Kaufman | Nov 2003 | B1 |
6662231 | Drosset et al. | Dec 2003 | B1 |
6678215 | Treyz et al. | Jan 2004 | B1 |
6721489 | Benyamin et al. | Apr 2004 | B1 |
6728763 | Chen | Apr 2004 | B1 |
6728776 | Colbath | Apr 2004 | B1 |
6766376 | Price | Jul 2004 | B2 |
6769027 | Gebhardt et al. | Jul 2004 | B1 |
6769028 | Sass et al. | Jul 2004 | B1 |
6823225 | Sass | Nov 2004 | B1 |
6836478 | Huang et al. | Dec 2004 | B1 |
6848002 | Detlef | Jan 2005 | B1 |
7136475 | Rogers et al. | Nov 2006 | B1 |
20020103919 | Hannaway | Aug 2002 | A1 |
20020133247 | Smith et al. | Sep 2002 | A1 |
20050165942 | McDowall et al. | Jul 2005 | A1 |
20060007923 | Boys | Jan 2006 | A1 |
Number | Date | Country | |
---|---|---|---|
20050165942 A1 | Jul 2005 | US |
Number | Date | Country | |
---|---|---|---|
Parent | 09570837 | May 2000 | US |
Child | 11041148 | US |