Globalizing Community Outreach with Streaming Media 

When a new Portland, Oregon-based radio station sought experts in the field of education to interview for a new series of programs exploring strategies to help students be successful in school, the faculty members of the College of Education at the University of Oregon was were considered an obvious choices.  The faculty of our nationally-ranked college represent over 30 years of research expertise. (is this collective experience or “calendar year” experience?)  Their research has been the subject of National Education Association documentaries and articles in Education Week.  (citations would be helpful here)

From the college’s perspective, this community outreach opportunity provided an excellent platform to inform education professionals, alumni, potential students, parents and the general public about our research and outreach activities ranging from dealing with destructive behavior to improving early reading performance.  But Oregon is a very large, rural state with 248 school districts scattered over almost 100,000 square miles. Furthermore, the discussions could be of interest to educators in other states and countries.  Although Portland is the largest city in Oregon, the radio station’s broadcast range was extended less than 75 miles from the metropolitan area. So, we explored the use of streaming media to extend the programs to a global audience. (Was this the goal: to go global? Or was it to reach a larger audience in Oregon? If the latter, then you could say that a secondary benefit of streaming media was the creation of a global audience.)

Streaming is a relatively new method (not in Internet time J it’s been around for a few years now) of delivering multimedia content over a network. Unlike linking to a standard audio or video file which requires the browser to download the entire file before it can be loaded into the appropriate player and played, streaming uses both client and server software working together to transmit and receive data simultaneously to produce uninterrupted sound or video. The client side buffers a few seconds of multimedia data before it starts sending it to the speakers (or video decoder), which that compensates for momentary delays in packet delivery.  This makes it possible for the listener/viewer to begin listening/viewing the content after only a few seconds (broadband) to a few minutes (modem speeds) after the file begins to download.

There are a number of different streaming formats available.  The most familiar are Real Player (http://www.realaudio.com/), Quicktime (http://www.apple.com/quicktime/), and Windows Media Player (http://www.microsoft.com/windows/windowsmedia/EN/default.asp).  As we began to consider our options to provide streaming content, KPAM AM860 (http://www.radiofreeoregon.com/ ), the station involved in the project, explained that they currently stream their broadcasts through a  service offered by StreamAudio (http://www.streamaudio.com/).  A growing list of iInternet service providers (ISPs) offer radio broadcast streaming (http://www.microsoft.com/windows/windowsmedia/en/service_provider/service/default.asp#Radio).  However, unlike many ISPs, StreamAudio provides the service at no charge to the radio station because their software incorporates clickable advertising to generate revenue from streaming activity.  StreamAudio provides a 450 Mhz Pentium class encoding computer to the radio station that is connected to the radio station’s broadcast console. The encoding software developed by StreamAudio incorporates Microsoft’s Windows Media Player technology to create an active streaming format (.asf) file.  The file is then transmitted to Stream Audio’s high capacity streaming servers and linked to the radio station’s web page.  The file encoding and serving processes occur in real time so listeners can actually call in with questions during the course of streamed programs.  This appeared to be ideal for our purposes.  StreamAudio even graciously agreed to serve archive files of the interviews for us following the broadcasts at no charge. The radio station also generously agreed to provide us with tapes of the interviews and permission to copy and redistribute the tapes for the cost of materials and handling and copies of the streaming files on CD. Every base seemed to be covered. 

To promote the upcoming event, I created a web page to explain how to prepare to view the broadcasts by installing the appropriate Media Player for a client’s particular computer system (http://interact.uoregon.edu/broadcastprep.html).  I created a web page with pictures of the faculty members and links to articles related to their discussion topics that would be updated each week with a link to an archive file of the interview (http://interact.uoregon.edu/coeonline.html).  Then I prepared successive home page modifications to feature a teaser about the upcoming interviews to generate interest from students, faculty, staff and other visitors to our website. Sample:

http://interact.uoregon.edu/index1013.html

The university public relations office released a Portland-area announcement about the upcoming broadcasts and a statewide news item.  Brochures were mailed to alumni and school districts around the state. I was surprised to read about the print advertising … then I realized that you’ve been describing a SERIES of broadcasts. So I think it would be helpful to introduce the series concept early on so that readers will understand why the public relations effort was more significant than they might expect.

I have learned over the years to be a little skeptical of technology vendors’ claims, so before the broadcast date, I installed Media Player on a number of different platforms to test streaming performance in different environments.  Unfortunately, as I had feared, problems began to crop up.  The first problem we encountered was a file naming convention problem that caused playback of the broadcast file to fail on MacIntosh clients.  Stream Audio's technical support recognized the problem right away when I reported it and modified the file name and resolved this problem.

The next problem we encountered after the interview series, “Kids and Schools – What Works!”, began to air  and the radio station began creating the archive files was the inability for Macs, Win95, and Windows NT stations running Media Player 6.x (Media Player 7 was not yet available for these operating systems) to play the archive files.  I contacted StreamAudio who agreed to try to find a solution to the problem.  They admitted they were new to the technology themselves and had little experience with MacIntosh clients.  (This is a rather troubling anecdote, given your earlier positive comments about StreamAudio’s marketing to radio stations. Had they not run across this problem in their other installations? It might be helpful in the earlier section to tell a little bit more about StreamAudio: how many stations they serve, how many listeners use their services, etc.) In my efforts to assist them with troubleshooting this problem, I delved into the extensive Microsoft Knowledgebase on Media Player development.  I found references to the need to create a text metafile for each media file and refer to this metafile in the web page link instead of linking directly to the media file. Microsoft’s Knowledgebase explained that when linking directly to streaming files using a standard <a href> tag, the browser simply downloads it like any other document, which defeats the purpose of streaming. With a metafile however, Windows Media Player opens the metafile and interprets the scripting, then uses the URL to locate the content and stream the content.  A sample metafile looks like this (where path is the path to the media file):

<ASX version="3.0">

   <Entry>

      <ref HREF="Path"/>

   </Entry>

</ASX>

I noticed that the radio station link referred directly to the media file so I thought this might solve the problem.  I created a simple .asx metafile and replaced my link reference.  But Media Player would then report that the file was corrupt.  I conferred with StreamAudio’s technical support and was told that StreamAudio combines streams of Flash content and javascript into their file during the file creation process to generate the clickable advertising and collect listener demographic data.  They speculated that perhaps this material modified the file header enough that the file appeared to be corrupted when opened directly in Media Player instead of through the StreamAudio proprietary client interface which that automatically launches when accessed by a Media Player 7 client.  Of course, at the time, Media Player 7 was not available for Macs, Windows 95 or NT 4 operating systems, a particular problem for an education environment with large numbers of these clients. (I think this is too much explanation for the readers here. If you are instructing readers about how to code their own streaming files, then this would be ok. But I think you’re describing how you helped to troubleshoot the use of someone’s proprietary technology with more common media players. Since most readers won’t be using StreamAudio services (you said that their services were marketed to radio stations), I don’t think this much detail is warranted. You may want to approach this as a small case study of why proprietary technology is difficult to use on a large scale.

We also tested their file remotely on slow modem lines.  We found we encountered severe choppiness of the file streaming at slower modem speeds (<56k). Unfortunately, this problem could also not be resolved by StreamAudio.  The software they had developed for producing the archive files apparently encoded the file at a transmission rate that was too high for low bandwidth connections.  

Fortunately, I had asked KPAM to produce conventional audio tapes of the interviews.  My colleague Terry Kneen, Instructional Systems Coordinator for the college, digitized the audio and created small, compressed streaming files with Quicktime 4 and a digital media utility named Media Cleaner (http://www.mediacleaner.com/) that could be streamed at speeds as slow as 26,400 baud.  He installed a version 3 beta Quicktime Streaming Server running the OS X operating system to deliver the files. 

We are now in the process of replacing the links to the StreamAudio archive files with these compressed Quicktime files.  (See: http://interact.uoregon.edu/destructive.html).  These files are playable by both PCs and Macs and can be streamed without a pause on slow modems. 

So, with some effort, we eventually accomplished our task, although, because the original broadcast files could not be streamed properly, this prevented audiences at home (except in the rare case of a user with a higher speed DSL connection – very rare in Oregon outside of limited metropolitan areas) from listening to or interacting with the interviewees during the broadcast itself. We were pleased to note that our web server logs showed page access from international locations as well as local and national access.  Despite our difficulties, I am excited about the potential use for this technology to share our research and scholarly activities with a global audience.

 

(So you wound up NOT using the StreamAudio service, correct? If that’s the case, then I think that the whole discussion about the problems of using StreamAudio can be taken down into about a paragraph. The real message in this article is about how your faculty members were able to develop an outreach program using both radio broadcasts and streaming media. I take it that your web site now has the video archives posted, correct? So I would ask what are your future plans for similar work, what other uses of streaming media are you contemplating, and how have faculty accepted the technology as being supportive of their research efforts?)