Valley Free Radio | WXOJ-LP | 103.3 FM | Northampton, Massachusetts

Newsletter

Subscribe to the monthly VFR newsletter, coming soon! (p.s. we don’t share email addresses)

Email:

*

First Name:

Last Name:

In order to maintain the vitality of a radio station that can accommodate all those who want to participate, programming at Valley Free Radio is created by programming collectives. Each collective has the responsibility for training new applicants and allocating air time for all the programs produced within that collective. The structure of each programming collective is determined by its members. Collectives do not control the content of individual programming.

The Valley Free Radio board of directors has authority over VFR Website content, appearance, coding and practices. As an important public face and portal to VFR, Website content shall reflect and be in accordance with the VFR mission and vision statements and consistent with all VFR policies and procedures. The VFR website, design, content and files are property of Valley Free Radio. Audio content copyright resides with the show producers.

The Web committee shall operate the website on a day to day basis. The Website managing editor shall enforce board decisions and approve all content and content changes to site, directly accountable to the Board. The developer shall direct coding and maintenance of the site. The Web committee will operate in accordance with VFR committee structure.

Web code shall be consistent with web design best practices. The VFR website will strive towards coding and design that is inclusive and provides access to all, such as those with visual impairments and older/slower computers and computers with functional constraints such as in libraries. The site will strive be in compliance with ADA accessibility standards. VFR should always strive towards delivering valid and accessible code. Code should be validated against the standards established by the World Wide Web Consortium (W3C) and Section 508 of the US Rehabilitation Act.

In accordance with VFR’s mission, website software will prefer open-source and other non-commercial alternatives, and will not require users to use any propriety or fee-based software for access.

General Policies

The Website shall function as a broadcast medium consistent with and in accordance with all VFR policies, such as regarding profanity and commercial content, grievances, etc, and will comply with all applicable state, federal, and international laws.

Copyright

The VFR website shall operate in accordance with all copyright laws, including the Fair Use doctrine, and neither host nor link to prohibited content of any kind. Programmers linking to or hosting files at the VFR website are responsible for acting in accordance with copyright laws. Website content is protected under the Creative Common License — Attribution, Non-Commercial, and Non-Derivative. We encourage re-broadcasting and posting VFR content on your station or website, but this should conform to the conditions of the Creative Commons License, and we request that you let us know.

Links

The site shall include links to outside websites are related to VFR programming, LPFMs, media reform, and community radio approved by the Website Managing Editor accountable to the Board.

User generated content

User generated content such as comments and blog posts will be moderated by the Website Managing Editor consistent with VFR’s policies and accountable to the Board. Posts written by programmers are not a forum for commercial messages; repeated warnings from the managing editor or board may result in the revocation of blog posting privileges.

Committee Chairs

Committee chairs are responsible for keeping the website editor informed of committee scheduling and news, and providing minutes and other information vital to member access and transparency. Committee chairs are also responsible for notifying either (or both) the Programing Coordinators or Web site developer with meeting times to be posted on the online schedule.

Email/Email Lists

Anyone who volunteers for VFR for more than 3 months is entitled to a @valleyfreeradio.org email address. Also, any committee or collective is entitled to start their own email list to be used in their completion of Valley Free Radio business. Email lists will be hosted off-site, such as google or yahoo. Email and list use shall be consistent with VFR policies and practices and is subject to revocation at any time by Board determination.

Program Calendar

Programmers are responsible for keeping the Programming Coordinators and Collective Liasons up to date with program information.

February 2007

As a volunteer of Valley Free Radio, I make the following commitments regarding my interaction with other members, my use of station resources, and my representation of the organization in public:

1. I will support the Mission Statement and Guiding Vision of the station.
2. I will treat others with respect and tolerance.
3. I will work towards making the organization more inclusive and accessible.
4. I will contribute to a safe and welcoming environment at the station and in meetings.
5. I will communicate verbally and in writing (including electronically) with respect for the integrity of others; I will try to disagree in ways that are not insulting.
6. I will not wear products with fragrances in the studio or at VFR meetings, and when I invite people to the studio or to VFR meetings, I will ask them to do the same. I will not use unapproved chemical cleaners in the studio.
7. I will leave the station in better condition than I found it and use VFR equipment with care. I will take responsibility for the behavior of visitors I bring into the studio.
8. I will share power and opportunity for leadership and will support new members.
9. I will not promote commercial interests on VFR’s non-commercial airwaves.
10. I will provide constructive criticism and concrete alternatives to proposals or comments I object to.
11. I will listen to and consider criticism that is respectfully offered.
12. I will keep myself informed about and follow VFR guidelines and procedures, including volunteer requirements, and I will participate in fund drives.
13. If I can’t fulfill my volunteer hours, I will let the appropriate people know.
14. I have read and understand the following:

Behavior that is valued at VFR includes:

• expressing myself in meetings in a tone of verbal and physical respect, supporting the facilitators, listening to others
• helping to maintain the smooth running of the station by participating in fundraising efforts, keeping the station clean, and caring for its equipment
• thanking others for their contributions to the station
• encouraging new members to join

Behavior that will not be tolerated at VFR includes:

• drinking alcohol in the station (this will result in immediate dismissal)
• mistreating others
• intentionally violating FCC guidelines
• engaging in actions that undermine the reputation and health of the station

Welcome to the Valley Free Radio. You’ve come from one our Online Network affiliates, which is a good thing. We want to support the VFR programmers and other sites that are enthusiastic about non-profit community radio.

The VFR site is where we communicate with the world via the Internet. You can listen to our live webstreams, read our program schedule, and donate to community radio. All donations are tax deductable.

Thank you for taking time to visit valleyfreeradio.org.

Now we’re cooking with gas!

I am very happy to present a new tool for VFR programmers that maintain their own Websites: the Valley Free Radio Online Network. What does this mean? It means when you select one of the pieces of code below and paste it into the html code of your site, a VFR “badge” will be dynamically inserted onto your page. The graphic clearly identifies you as a member of the VFR family and provides a link back to the VFR site.

Why is this a big deal? Here are a few reasons: this extends the VFR brand image, identifying many sites that look different with a consistent mark. Also, for special events such as a fundraiser or pledge drive, we can insert special badges on your Website without any work from you–we take care of the images on the VFR Web server. Moreover, as people insert these badges on their sites we’ll start collecting better Web traffic statistics for you and VFR. Again, it’s good for you because work by you is unnecessary once you insert the code.

Which image to choose?

To begin I have created two different image sizes with each having a dark or light background version (that is, the background of your site is either light or dark). The images are either 100×75 pixels or 200×47 pixels. After choosing the image that will work best on your site, copy the appropriate code and paste it into your site code. I am suggesting that people include the code in their sidebar, or some other part of the site that is included with every page.

100×75 pixels with a dark background


<script type="text/javascript" src="http://www.valleyfreeradio.org/include/vfr-network/index.php?b=1"></script>


100×75 pixels with a light background


<script type="text/javascript" src="http://www.valleyfreeradio.org/include/vfr-network/index.php?b=2"></script>


200×47 pixels with a dark background


<script type="text/javascript" src="http://www.valleyfreeradio.org/include/vfr-network/index.php?b=3"></script>


200×47 pixels with a light background


<script type="text/javascript" src="http://www.valleyfreeradio.org/include/vfr-network/index.php?b=4"></script>


Please make use of this tool. As some people know, my number one gripe is either the lack of links back to VFR, or poor positioning of VFR promotion on programmer’s sites.

If you are having a problem with inserting the badge, and haven’t been able to figure it out, I will try to give you a hand (though please don’t abuse this offer, as I am still working on more features!) web [at] valleyfreeradio [dot] org

The following page will help you understand what RSS and podcasts are, and how to subscribe to them on the Valley Free Radio Website. The VFR Web feed (otherwise known as an RSS or XML feed) includes all updates to the site, not including the podcasts. The blog feed includes posts that may not appear under “Latest News” on the homepage, such as meeting minutes or agendas. Podcasts are kind of like RSS feeds, except that they include a link to a media file (in our case an audio file, but it can also include a link to a video file). If you are using the right program it will recognize the media file and automatically download it to your computer for your listening pleasure.

More details about subscribing to the VFR podcast and RSS feed follows.

Podcast

We offer two different links to our podcast: an iTunes short cut and a generic link you can copy to place in your podcast downloading application. Both links will give you the same podcast.

RSS Feeds

RSS (Really Simple Syndication) feeds are different from podcasts in that they do not normally include audio or video, though may include photos. A program like iTunes will not subscribe to an RSS feed (which only reads podcasts), but there are other programs that will process both podcasts and RSS feeds.

The VFR RSS feed can be copied and entered into a variety of programs, depending whether you are using a Mac, PC, or would like to be strictly Web based.

The Web Committee is happy to announce that VFR has a new email list system that both replaces the Topica list and expands services.

After searching for the least objectionable choice, given the desire for a low maintenance system, the always looming budget considerations, and our feature requirements (most notably the ability to moderate the lists), we have set-up two moderated lists on Google Groups. One list is for announcements (announcements for the VFR community without cross-talk), and the other list is for discussion (cross-talking).

As with the Topica list you can have the emails delivered to you in a variety of ways: no email (read posts on the Web), abridged email (summary of activity), daily digest (all emails), and all individual emails. Plus, if you know how to, you can subscribe to the groups with an RSS reader (which would be particularly useful in the case of the announcement list).

Both lists are moderated by Bill Childs, as agreed upon. What moderation means is that you submit either a new topic thread or respond to an existing post (in the case of the discussion list), and Bill receives an email telling him a post is waiting to be posted.

For more information about the establishment of these lists, please refer to the blog post announcing their creation.

Subscribe to Valley Free Radio Announcements

Email:

Browse Archives at groups.google.com

Subscribe to Valley Free Radio Discussion

Email:

Browse Archives at groups.google.com

1. ALL Expenditures require authorization.
2. All expenditures should be documented with an invoice, signed by an approved person [see #3 below], and must be submitted to the Treasurer or other Finance Committee member within three months of expenditure. As an alternative, authorization can be evidenced by email or signed note.
3. All expenditures below $100.00 must be authorized by a chairperson/coordinator of these listed committees or a board member:
• Programming
• Operations
• Site/Tech
• Fundraising
• Finance
• Publicity
• Website
4. Unless operating on a Board approved budget, expenditures of $100.00 and over must be directly approved by the Board of Directors.
5. Charge accounts may be created from time to time by the board or finance committee.
   Use of these accounts shall be limited in the same manner as expenditures outlined above. Purchases via charges must be duly authorized, with purpose of expense listed on invoices, and all charges signed.
6. All expenditures are subject to review by the Board of Directors.

This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available in our efforts to advance understanding of environmental, political, human rights, economic, democracy, scientific, and social justice issues, etc. We believe this constitutes a ‘fair use’ of any such copyrighted material as provided for in section 107 of the US Copyright Law. In accordance with Title 17 U.S.C. Section 107, the material on this site is distributed without profit to those who have expressed a prior interest in receiving the included information for research and educational purposes. For more information go to: http://www.law.cornell.edu/uscode/17/107.shtml. If you wish to use copyrighted material from this site for purposes of your own that go beyond ‘fair use’, you must obtain permission from the copyright owner.

We have some links that you might find useful.

Trackback (or pinging) allows two blogs to communicate with each other. Only blogging tools that support trackback can communicate using this technology. You can discover more about trackback from WikiPedia. Also, Jason Kottke has a very simple description of trackback.

You can access various VFR resources from this page.

The Grievance and Mediation Committee of Valley Free Radio

I. Welcoming Work Space Expectation

As a community radio station that has been and continues to be developed by its own membership, we strive to provide programs and a working environment that are free of racist or abusive behavior, hate speech and/or discrimination. Valley Free Radio as an organization has committed itself to working against all forms of oppression and therefore expects that all station workgroups/bodies also work against discrimination and bias in all its forms, and for respect for all people and communities. We are here to provide a safe and empowering space for those who can�t find it elsewhere, and in particular, to those who have been marginalized and underrepresented in the mass media.

II. Grievance & Mediation Committee

A. Purpose

The Grievance & Mediation Committee�s goal is to provide a safe space in which VFR members can bring forward their concerns regarding conflict within VFR generally,or within any of its workgroups or committees/collectives. Concerns may be based on the following: interpersonal conflicts, harassment, discrimination, unfair or arbitrary treatment of an individual or group, an individual or group’s failure to live by the mission statement or vision statement, under-representation, censorship, or misconduct. The GMC will attempt to provide a clear, compassionate, and binding solution to any issues that arise within the station. The GMC will strive towards impartiality and to impose effective, constructive solutions as quickly as possible. However, the Grievance and Mediation Committee is envisioned as a conflict resolution body, and not one tasked to enforce rules, provide a disciplinary process, or engage in the censorship of programs or programmers. If, in the process of mediating a conflict, it is apparent that disciplinary action is warranted, the GMC may decide to refer the issue to the board or other designated body.

B. Committee Composition

The Grievance & Mediation Committee is a subcommittee of the Board of Directors, appointed jointly by the Board and the Antidiscrimination Committee. The GMC will consist of 5 VFR members, serving for one-year terms. In the event one of the GMC members is a party involved in the process, the Board will appoint a different member for the duration of the hearing. Appeals go to the Board, or other Board- designated body.

C. General Procedure

1. Try to resolve the issue within the station body (e.g. committee, collective) in which the issue arose. Station members may seek advice from a committee coordinator, a collective liaison, an Antidiscrimination Committee member, or a Grievance and Mediation Committee member to suggest steps for dealing with the issue without a formal meeting of the GMC.
2. Before a formal grievance is filed, the parties may agree to an informal, nonbinding mediation with a VFR volunteer trained in mediation.
3. If the issue is not resolved, a request for a hearing, summarizing the nature of the complaint, should be submitted, in writing, to the GMC.
4. The GMC will review the request, notify the respondent of the nature of the complaint, and schedule a meeting to resolve the conflict. The meeting will be scheduled for a date no later than six weeks from the time the GMC received the request. At the meeting, the person requesting the hearing will have 20 minutes to present his/her case and the respondent will have 20 minutes to respond. The respondent should be prepared to justify the decisions or actions in question. There will also be a 20-minute period for the GMC to question both parties. The complainant and respondent will then leave the room as the GMC sets up a procedure appropriate to the complaint that will take no longer than sixty days for final resolution. If the GMC finds that the respondent has violated a VFR policy, which may warrant a suspension or loss of membership privileges, then the GMC will hand the case over to the Board, which will decide on the appropriate action. Both parties may bring to this meeting an advocate of their choice from within the station. All matters discussed within the meeting will remain confidential. The complaint, response, and steps taken will be recorded in the minutes of the meeting.

If a party is unsatisfied with the outcome, and the grievance is based on a complaint of sexual harassment or discrimination and/or the Board makes a decision that results in a loss of airtime, membership, or a leadership position, s/he may either request formal, outside, binding mediation or may petition the Board for an appeal.

I. Policy: The FCC and VFR

The Federal Communications Commission (FCC) is an independent federal agency created to regulate broadcast and non-broadcast spectrum use. The FCC is responsible for the regulation of licensing, technical operations, legal activities, and programming of all stations. Therefore, if VFR is to remain on the air, it is imperative that volunteers comply with FCC rules at all times. VFR on-air operators must comply with both FCC programming regulations and operating requirements as listed here.

Obscenity is never allowed on the air. Profanity is not allowed on air. This applies to Board operators, on-air guests, callers, and pre-recorded material.

Because the fine (per utterance) for FCC violations is $25,000—which could easily put VFR off the air—VFR does not distinguish between indecent and obscene material. That means we do not have a “safe harbor” time in which to broadcast indecent material; we simply do not broadcast it at all, not even late at night.

Program producers who intend to air material that is questionably or potentially indecent should clear such material at a Programming Committee meeting in advance. The committee will document the reason for clearing or rejecting the material.

All programmers must sign VFR’s “Memorandum of Understanding” which confirms their commitment to uphold VFR’s policy on FCC compliance.

II. Definitions

Material is obscene if it appeals to the prurient interest, depicts or describes sexual conduct in terms patently offensive, and taken as a whole, lacks serious literary, artistic, political, or scientific value. Material is indecent if it contains language or material that, in context, depicts or describes, in terms patently offensive as measured by contemporary community standards for the broadcast medium, sexual or excretory activities or organs.

Profanity refers to patently offensive words, including, but not limited to, the following words which the FCC has previously and specifically determined to be offensive: shi*, f*ck, piss, c*nt, co**sucker, motherf#*ker, t*ts.

III. Procedure

If you broadcast a violation: If the violation is in pre-recorded material, IMMEDIATELY fade out. Make a note of track on cd so it does not get aired again. Do not draw attention to the mistake by any on-air comments about it. Finally, log the infraction on
the comments section of the Daily Programming Log: log the time, the word and what corrective measures they took..i:e; “Pulled it off the air and made a note on the CD” and notify the—studio manager—of the infraction and corrective measures.

If you hear a violation: If you hear a violation of VFR policy on obscenity, profanity, and indecency, report to Programming Committee directly at a meeting or by contacting the Programming Committee Board Representative directly. Do NOT use Valley Free Radio’s listserves.

If your guest/caller violates regulations: If a guest or caller uses offensive language, the operator must cut that person off.

IV. VFR’s response

First Offense: Warning
A written warning will be given to the programmer. S/he must get in touch with the Programming Committee, via the Board Representative, to the committee in order to discuss the infraction. Do NOT use Valley Free Radio’s listserve to make these arrangements.

Second Offense: Three Month Suspension
The programmer will receive a written notice stating the time period for the suspension. S/he must get in touch with the Programming Committee Board Representative and her Collective Liaison in order to discuss the infraction and make arrangements for her /his show to be covered. Do NOT use Valley Free Radio’s listserves to make these arrangments.

Third Offense: Indefinite suspension of all membership privleges including on-air time. The programmer will receive a written notice of indefinite suspension. This notice will be approved by the Programming Committee.

The preferred method of listening to the Valley Free Radio web stream is just clicking on it!

This section exists because that doesn’t always work out. Let’s divide the readers here into windows and osx users. To both camps: please remember that VLC Media Player just works on windows, osx, linux, bsd.

“The power of the Web is in its universality. Access by everyone regardless of disability is an essential aspect.” — Tim Berners-Lee, W3C Director and inventor of the World Wide Web

This is the official Web accessibility statement for the Valley Free Radio Website. We have worked to make the Website accessible to all audiences, including those with visual impairments or other diabilities.

It is our goal to create a model of usable and accessible design for the elderly and the visually impaired, considerations which many web designers neglect.

Page Contents

• Guidelines
• Access Keys
• Visual Design
• Links and Images
• Accessibility References

Guidelines

1. Most pages on this site have passed the Cynthia Says web page accessibility test. This is always a judgement call; many accessibility features can be measured, but many can not. We have reviewed all the guidelines and believe that all these pages are in compliance.
2. Most pages on this site are WCAG AAA approved, complying wih all priority 1, 2, and 3 guidelines of the W3C Web Content Accessibility Guidelines. Again, this is a judgement call; many guidelines are intentionally vague and can not be tested automatically. We have reviewed all the guidelines and believe that all these pages are in compliance.
3. Most pages on this site are Section 508 approved, complying with all of the U.S. Federal Government Section 508 Guidelines. Again, this is a judgement call. We have reviewed all the guidelines and believe that all these pages are in compliance.

[Back to the contents]

Access keys

Most browsers support jumping to specific links by typing keys defined on the web site.
Windows users:

• Mozilla Firefox & Netscape: Press ALT + an access key.
• Microsoft Internet Explorer: Press ALT + an access key + ENTER

Macintosh users: press Control + an access key.
All pages on this site define the following access keys:

• Access key h - Home page
• Access key 4 - Search
• Access key 9 - Feedback
• Access key 0 - Accessibility statement

[Back to the contents]

Structural and Visual Design

1. We made one accessible version of a website, rather than two (or more) separate sites that need to be maintained. Studies show that users have learned not to trust secondary versions. They are too often left wanting.
2. This site uses cascading style sheets (CSS) to control the visual presentation and separate it from the content.
3. This site uses only relative font sizes, compatible with the user-specified “text size” option in visual browsers.
4. If your browser or browsing device does not support stylesheets at all, the content of each page is still readable, though may affect the functionality of the site.

[Back to the contents]

Links and Images

1. Many links have title attributes which describe the link in greater detail, unless the text of the link already fully describes the target (such as the headline of an article).
2. Links are written to make sense out of context.
3. All content images used in this site include descriptive ALT attributes. Purely decorative graphics include null ALT attributes.

[Back to the contents]

Accessibility References

1. W3 Auxiliary Benefits of Accessible Web Design.
2. W3 accessibility guidelines, which explains the reasons behind each guideline.
3. W3 accessibility techniques, which explains how to implement each guideline.
4. W3 accessibility checklist, a busy developer’s guide to accessibility.
5. U.S. Federal Government Section 508 accessibility guidelines.
6. WebAIM, a non-profit organization dedicated to improving accessibility to online learning materials.
7. WebXACT (formerly Bobby), a free service to analyze web pages for compliance to accessibility guidelines. A full-featured commercial version is also available.
8. HTML Validator, a free service for checking that web pages conform to published HTML standards.
9. Web Page Backward Compatibility Viewer, a tool for viewing your web pages without a variety of modern browser features.

[Back to the contents]

The web stream(s) is a downmixed version of the broadcast stream that is created in the on-air studio. The original stream is decoded, then re-encoded at a different quality and presented to the listening public. The software used at every stage of this process is Open Source Software (1).

Decoding the original stream

The server at valleyfreeradio.org listens to the original stream using the command `/usr/bin/ogg123 http://IP.OF.STUDIO/test.ogg -q -d raw -f -` (2) which translates more or less to “play this audio stream without header info, and dump the output to the screen instead of the soundcard.” The reason for the printing the raw audio data to the screen, or STDOUT as it is known, is so it can be in turn read by another program.

Encoding the new streams

The program reading the raw audio from the command line is called ices (3). The function of ices is to present audio wrapped in a package understandable by the icecast server (4). Ices is controlled through the xml configuration file listed here:

<?xml version="1.0"?>
<ices>
    <!– run in background  –>
    <background>0</background>
    <!– where logs go. –>
    <logpath>/var/lib/ices</logpath>
    <logfile>ices.log</logfile>
    <!– size in kilobytes –>
    <logsize>2048</logsize>
    <!– 1=error, 2=warn, 3=infoa ,4=debug –>
    <loglevel>4</loglevel>
    <!– logfile is ignored if this is set to 1 –>
    <consolelog>0</consolelog>
    <stream>
        <!– metadata used for stream listing –>
        <metadata>
            <name>Valley Free Radio</name>
            <genre>Free Speech</genre>
            <description>103.3 FM WXOJ-LP Northampton MA</description>
            <url>http://www.valleyfreeradio.org</url>
        </metadata>
        <!–    Input module.
            This example uses the ‘oss’ module. It takes input from the
            OSS audio device (e.g. line-in), and processes it for live encoding.  –>
<!–input>
            <module>stdinpcm</module>
            <param name=”rate”>44100</param>
            <param name=”channels”>2</param>
            <param name=”metadata”>1</param>
           <!–  <param name=”metadatafilename”>/usr/local/share/ices/metadata</param>–>
        </input>
 
      
<     <instance>          
            <hostname>66.249.31.180</hostname>
            <port>8000</port>
            <password>PASSWORD</password>
            <mount>/high.ogg</mount>
              <reconnectdelay>8</reconnectdelay>
                <reconnectattempts>-1</reconnectattempts>
                <maxquelength>80</maxquelength>
 
            <yp>1</yp>    allow stream to be advertised on YP, default 0 –>
 
            <!–    Live encoding/reencoding:
 
                channels and samplerate currently MUST match the channels
                and samplerate given in the parameters to the oss input
                module above or the remsaple/downmix section below.  –>
           <!– <encode>  
                <quality>4</quality>
                <samplerate>44100</samplerate>
                <channels>2</channels>
            </encode>
        </instance> –>
        <instance>
            <hostname>66.249.31.180</hostname>
            <port>8001</port>
            <password>PASSWORD</password>
            <mount>/mid.ogg</mount>
                <reconnectdelay>8</reconnectdelay>
                <reconnectattempts>-1</reconnectattempts>
 
        <!– stereo->mono downmixing, enabled by setting this to 1–>
          <!–  <downmix>1</downmix>–>
        <encode>
                <quality>6</quality>
                <samplerate>22050</samplerate>
                <channels>1</channels>
        </encode>
        <downmix>1</downmix>    
        <resample>
                <in-rate>44100</in-rate>
                <out-rate>22050</out-rate>
            </resample>
        </instance>
        <instance>
            <hostname>66.249.31.180</hostname>
            <port>8002</port>
            <password>PASSWORD</password>
            <mount>/low.ogg</mount>
               <reconnectdelay>8</reconnectdelay>
                <reconnectattempts>-1</reconnectattempts>
        <encode>
                <quality>2</quality>
                <samplerate>22050</samplerate>
                <channels>1</channels>
        </encode>
        <downmix>1</downmix>
        <resample>
                <in-rate>44100</in-rate>
                <out-rate>22050</out-rate>
        </resample>
        </instance>
    </stream>
</ices>

(note: the passwords aren’t really PASSWORD.)

Ices is configured to read raw audio from stdin, through a pipe. A pipe looks like this: ” | ” and is Linux/Unix/BSD for “take the output from the command before this and use it as the input for the command after this”. Because of the pipe, ices needs to executed in the same line as the ogg123 command from above.

It is probably hard to notice here, but the first stream instance in this configuration is commented out. In an editing session this would be very clear due to syntax highlighting. The commenting out was done because of bandwidth and cpu concerns, and will (hopefully) change in the future. To re-enable the ‘high.ogg’ just erase the “<!–” at the beginning and the “–>″ at the end of the section, and then type `killall ices icecast ogg123` a few times in the terminal, until it says “no process killed” for each of them. When a minute passes, a script will notice that the stream is dead and restart it, bringing the high.ogg back with it. That script will be discussed later on.

Making the streams accessible

The icecast server is what provides the links to the streams that we click on. Icecast server cannot be run as a normal user, so there is an ‘icecast’ user on the VPS. If there are streams present to serve up, icecast does so according to this xml configuration file:

<icecast>                      
   <limits>                    
        <sources>10</sources>  
        <clients>100</clients>  
        <threadpool>5</threadpool>
        <queue-size>102400</queue-size>
        <client-timeout>30</client-timeout>
        <source-timeout>30</source-timeout>
        <burst-on-connect>1</burst-on-connect>
        <burst-size>65536</burst-size>
    </limits>                  
    <authentication>            
        <source-password>PASSWORD</source-password>
        <relay-password>hackme</relay-password>
        <admin-user>admin</admin-user>
        <admin-password>ANOTHERPASSWORD</admin-password>
    </authentication>
    <hostname>66.249.31.180</hostname>
  
        <listen-socket>
                <port>8000</port>
        </listen-socket>
        
        <mount>
                <mount-name>/high.ogg</mount-name>
                <max-listeners>10</max-listeners>
        </mount>
<listen-socket>
        <port>8001</port>
</listen-socket>
        <mount>
                <mount-name>/mid.ogg</mount-name>
                <max-listeners>10</max-listeners>
        </mount>
<listen-socket>
        <port>8002</port>  
</listen-socket>    
        <mount>
                <mount-name>/low.ogg</mount-name>
                <max-listeners>15</max-listeners>
/>        </mount>        
 
<listen-socket>
        <port>8003</port>
</listen-socket>
        <mount>
                <mount-name>/wxoj.mp3</mount-name>
                <max-listeners>15</max-listeners>
        </mount>
   <fileserve>1</fileserve>
    <paths>
        <logdir>/var/lib/icecast</logdir>
        <webroot>/usr/local/share/icecast/web</webroot>
        <adminroot>/usr/local/share/icecast/admin</adminroot>
        <alias source=”/” dest=”/status.xsl”/>
    </paths>
    <logging>
        <accesslog>access.log</accesslog>
        <errorlog>error.log</errorlog>
        <loglevel>4</loglevel> <!– 4 Debug, 3 Info, 2 Warn, 1 Error –>
    </logging>
</icecast>

Well then, if all is going according to plan you will see the icecast server here.

Some xml things to notice: there is currently a configuration for “high.ogg” and “wxoj.mp3″ that are going unused. High.ogg was explained above, but wxoj.mp3 has been a major source of server slowdown in the past and as such was scrapped pending discovery of an efficient way to re-encode ogg to mp3 and serve it up. THIS ISSUE NEEDS ATTENTION. Politically favored or not, many people find ogg vorbis too inconvenient and want mp3.

The <source-password> is the password that ices uses to tell icecast it’s legit. The port numbers are arbitrary, but traditionally audio is served up around 8000. <mount-name> and <max-listeners> will probably be the only things you’d want to change here, short of adding more streams.

Keeping it all running

This stuff crashes a lot. In order to restart it all, two cron (5) scheduled Perl scripts run once every minute except for minute 59. The first one is /sbin/stream_watcher.pl and it goes a little something like:

#### stream_watcher.pl
my @proclist = ();
my $oggrunning = 0;
my $icesrunning = 0;
my $ezrunning = 0;
 
open BS,”ps -ef|” or die “can’t open the BS:$!\n”;
while (<BS>)
{
        my @fields = split /\s+/;
        push @proclist, $fields[7];
}
foreach (@proclist)
{
        if (/\/usr\/local\/bin\/ogg123*$/)
        {
                $oggrunning=1;
        }
        if (/\/usr\/local\/bin\/ices*$/)
        {
                $icesrunning= 1;
        }
        if (/\/usr\/local\/bin\/ezstream*$/)
        {
                $ezrunning=1;
        }
}
 
# we’ve checked to see if the stream looks ok. if not,
# we re-run the startup script  
 
if (($icesrunning == 0) || ($oggrunning == 0))
{
        exec ‘/etc/rc.local’;
}
 
#if ($ezrunning == 0)
#{
#       exec ‘/etc/rc.d/rc.mp3_0′;
#}

This script checks the output of the `ps` command for running instances of ices, ogg123, and ezstream. Ezstream was the ices-like program that was previously used to serve up an mp3 stream, but then nixed due to excessive processor usage. Any how, this stream executes `/etc/rc.local` if either no ogg123 or ices are found. The contents of rc.local are just:

/usr/local/bin/ogg123 http://IP.OF.STUDIO/test.ogg -q -d raw -f - | /usr/local/bin/ices /usr/local/share/ices/Aces-tentative.xml &

…which should make sense by now. The only new thing here is the ampersand, which forces a command to disappear into the background while running.

The other cron script is /sbin/icecast_watcher.pl and it does the same stuff as /sbin/stream_watcher.pl, except it does it for icecast. It looks like this:


#### icecast_watcher.pl
my @proclist = ();
my $running = 0;
open BS,”ps -ef|” or die “can’t open the BS:$!\n”;
while (<BS>)
{
  my @fields = split /\s+/;
  push @proclist, $fields[7];
}
foreach (@proclist)
{
  if (/\/usr\/local\/bin\/icecast*$/)
  {
    $running = 1;
  }
}
# we’ve checked to see if icecast is still coming in. if not,
# we re-run the startup script
if ($running == 0)
{
  print ” whoops…\nrestarting the icecast server.\n”;
  system(”su icecast -c /usr/local/share/icecast/doc/hello &”);
}

The system call right there might look a little strange. What it does is switch to the user “icecast” temporarily and run the command `/usr/local/share/icecast/doc/hello` in the background. the “hello” script is just an alias for

/usr/local/bin/icecast -c /usr/local/share/icecast/doc/icecast-min.xml

For whatever reason, ices can sometimes cease to provide a stream but not die. Other times the stream will degrade into an annoying clicking square wave kind of noise. This unfortunate situation seems to arise after a few hours of otherwise good behavior, and is no good for us. To deal with it. a third and final script is croned to run every 3 hours. The entire function of this script is to kill all of this junk, which in turn forces the other scripts to restart ices and ogg123 and icecast. It is called /sbin/pid_slap.pl and it goes:

### pid_slap.pl
# this perl script finds all the ogg123's and ices' and kills them dead. they make a nasty clicking noise if
# left alone too long.
my @oggs = split /\n/, `ps -axw|grep ogg123`;
my @icess = split /\n/, `ps -axw|grep ices`;
my @dummy = split /\//, $0;
my $SCRIPT_SHORT = $dummy[$#dummy];
my $oggsrunnin = 0;
my $icessrunnin =0;
my $PID = 0;
my @PIDs;
foreach (@oggs) {
   next if $_ =~ /grep ogg123/ or $_ =~ /$SCRIPT_SHORT $ARGV[0]/;
   $oggsrunnin++;
   $PID = $_;
   $PID += 0;
   push (@PIDs, $PID);
}
foreach (@icess) {
   next if $_ =~ /grep ices/ or $_ =~ /$SCRIPT_SHORT $ARGV[0]/;
   $icessrunnin++;
   $PID = $_;
   $PID += 0;
   push (@PIDs, $PID);
}
print “found $oggsrunnin oggs runnin ‘n $icessrunnin icess runnin…\n”;
foreach (@PIDs) {
   $killems = sprintf (”$killems %i”, $_);
}
print “killin ‘em\n”;
print `kill -9 $killems`;

What is happening here is a list is built containing the system process identification numbers, or PIDs, of the ogg123’s and ices’ that are running, and then the list is sent to the `kill` command. Blunt yet effective.

References

(1). http://www.opensource.org/

(2). http://linuxcommand.org/man_pages/ogg1231.html

(3). http://www.icecast.org/ices.php

(4). http://www.icecast.org/

(5). cron & crontab

This section is for documents pertaining to the technical runnings of Valley Free Radio.

This site is created with the Web publishing tool, WordPress, and was designed and programmed by Bill Hector Weye. The site is programmed to take advantage of the latest in Web accessibility technology. The following WordPress plugins are used to enhance the functionality of the site:
Fatal error: Call to undefined function displayPluginsAsList() in /home/.orji/vfr/valleyfreeradio.org/wp-content/plugins/exec-php/includes/runtime.php(42) : eval()'d code on line 5