RadioReference on Facebook   RadioReference on Twitter   RadioReference Blog
 

Go Back   The RadioReference.com Forums > Computer Aided Monitoring and Programming > Streaming / Broadcasting / Audio Recording


Streaming / Broadcasting / Audio Recording - Interested in putting your scanner online for others to hear? Want to listen to other radios on the internet. This forum is here for you to discuss these topics related to streaming scanners online.

Reply
 
LinkBack Thread Tools Search this Thread Display Modes
  #81 (permalink)  
Old 04-30-2017, 3:35 PM
Member
  Audio Feed Provider
Audio Feed Provider
 
Join Date: Dec 2016
Location: Milpitas, CA
Posts: 298
Default

Quote:
Originally Posted by w9yrc View Post
JACK26, recently have been trying to get a local HAM repeater up and running on broadcastify myself and although I can't get the squelch correct, I also was experiencing the same buzz with what was being transmitted and added the -h & -Y options to the lame encoder and that seemed to help as well as configuring my highpass filter to --highpass .080
Hi w9yrc, What version of lame are you using? From what I can gather the -h option is for "high quality" and the -Y option is for ignoring noise. I'm not sure the version of lame I have installed has the -Y option as it doesn't show up in some version's docs and doesn't seem to make any difference in my case with the low freq buzz. I am thinking this buzz does have something to do with the lame mp3 encoder though and may be solved by installing a newer version.

I can play an audio file on the rpi and it sounds perfect with no buzzing. If I set squelch to zero the background static does not have the buzzing sound either which probably means the lame encoder is not working with only static. So probably the lame encoder is introducing the buzz when a signal is recognized. Nothing to do with the local utility power line fundamental AC frequency. Don't waste your time buying a USB battery as I suggested before.
Reply With Quote
Sponsored links
  #82 (permalink)  
Old 04-30-2017, 9:28 PM
Member
  Audio Feed Provider
Audio Feed Provider
 
Join Date: Dec 2016
Location: Milpitas, CA
Posts: 298
Default

Re-installed lame from the latest github archive and the hum seems to be lower. Working on replacing lame encoder.

Last edited by JACK26; 04-30-2017 at 9:38 PM..
Reply With Quote
  #83 (permalink)  
Old 05-02-2017, 6:25 PM
Member
  Audio Feed Provider
Audio Feed Provider
 
Join Date: Dec 2016
Location: Milpitas, CA
Posts: 298
Default

Update, I am back to blaming the low noise buzz to rtl_fm. I can tweak on the -g and -p ppm parameter and change the sound and level of the '60Hz' sounding background buzz. I don't think it has anything to do with lame or anything after rtl_fm.

Also, the easiest way to tell what rtl_fm version you are using is to enter the following command at a terminal prompt:
rtl_fm -version

If you don't see the -E pad option, then it's not the right version for padding dead air with 0's necessary to keep your feed alive on Broadcastify while squelched.

This is the feed again, rpi3 with USB sdr dongle and power supply only with a very strong received signal on narrow band fm:
http://www.broadcastify.com/listen/feed/23831

This is the startup script I'm using currently which seems to minimize the buzz but not eliminated yet:

sudo /usr/local/bin/rtl_fm -d 0 -M fm -f 482.862M -p 17 -l 82 -g 19 -t 10 -E pad -E dc -s 12k | \
> /usr/bin/lame -Y -h -r -X0 -s 12 --noreplaygain --scale 1.5 --resample 44.1 -m m -b 24 --cbr --lowpass 4 --highpass 0.03 - - | \
> sudo /usr/bin/ezstream -q -c /etc/ezstream_bcfy.xml

Not sure all that works because any parameters that are not recognized are just ignored. e.g. -E dc is not an option in my version rtl_fm so that probably does nothing.

Anyone who has comments on why the rtl_fm audio has this background buzz with sdr usb sticks is welcome. My opinion is this has nothing to do with hardware.

Last edited by JACK26; 05-02-2017 at 7:37 PM..
Reply With Quote
  #84 (permalink)  
Old 05-02-2017, 7:02 PM
blantonl's Avatar
Founder and CEO
  RadioReference Database Admininstrator
Database Admin
Audio Feed Provider
Audio Feed Provider
 
Join Date: Dec 2000
Location: Shavano Park, TX
Posts: 8,942
Default

Some thoughts here.

If you've got a 60 Hz hum on the feed, you've definitely got some kind of ground loop going on. I can't remember, but have you tried putting your Pi on wireless AND on a battery?

You'll need to try to remove any insertion of AC power interference and poor isolation - which could be anything from a powered USB Hub, to a power supply, to an ethernet connection that is ultimately connected to a hub that is powered by AC power.

60 Hz hum means A/C power is somewhere in the chain.

It's possible that the
__________________
Lindsay C. Blanton III
CEO - RadioReference.com / Broadcastify
Facebook: RadioReference | Broadcastify | Twitter: @RadioReference
Reply With Quote
  #85 (permalink)  
Old 05-02-2017, 7:14 PM
blantonl's Avatar
Founder and CEO
  RadioReference Database Admininstrator
Database Admin
Audio Feed Provider
Audio Feed Provider
 
Join Date: Dec 2000
Location: Shavano Park, TX
Posts: 8,942
Default

I recently moved both of my feeds from a server over to RPi2's. I'm running two feeds on two separate RPi2's.

Some notes and thoughts.

1) I've been unable to get even my own released Raspbian based image release to broadcast more than one darkice feed without all the attached sound cards broadcasting on all the darkice instances. My own produced image will broadcast 3 feeds using darkice with no problem, but will broadcast all three sound cards no matter how I configure alsamixer.

2) I've since moved to Ubuntu Mate for the RPi2, which provides a darkice package which is far easier to install than compiling. Both feeds are running great on this distribution. But I still cannot run two or more instances of darkice without all the audio being mixed together from every attached soundcard.

3) A RPi2 can easily stream 3+ darkice streams without a problem - provided the sound mixing issues are resolved.

4) I've checked and tried every single alsamixer configuration known to man. The behavior has been seen a few times from Google Fu results, but alas, no fixes have been seen.

I'm at a loss, so each stream I run has a separate RPi2 broadcasting. It works great. Food for thought.

If you have some feedback I'm welcome to it. A single RPi2 would have no problem broadcasting at least 3 streams if we (I) knew this soundcard bleed over problem.
__________________
Lindsay C. Blanton III
CEO - RadioReference.com / Broadcastify
Facebook: RadioReference | Broadcastify | Twitter: @RadioReference
Reply With Quote
Sponsored links
  #86 (permalink)  
Old 05-02-2017, 8:00 PM
Member
  Audio Feed Provider
Audio Feed Provider
 
Join Date: Dec 2016
Location: Milpitas, CA
Posts: 298
Default

Hi Lindsay and thanks for the reply!

The rpi3 is completely isolated and headless and uses wifi. It plays mp3 files perfectly. The only connection that is not isolated is the AC adapter which I replaced with a 20 watt power supply with no reduction in the "60Hz" sounding noise. I'm still convinced this an artifact of the rtl_fm software with usb sdr stick.

Also, the external USB sound card version of this is not a problem apparently. My thing is to get the SDR version without external USB sound card working. It is working and now I'm down to this annoying buzz.

I can affect the frequency of the buzz by manipulating tuner parameters and nothing else is affected by AC line freq. So I doubt that a battery USB supply will eliminate this problem but you are right that is the only way to know for sure. It would be nice if some one else would get involved who already has a big USB battery to test that .

Last edited by JACK26; 05-02-2017 at 8:14 PM..
Reply With Quote
  #87 (permalink)  
Old 05-02-2017, 8:09 PM
blantonl's Avatar
Founder and CEO
  RadioReference Database Admininstrator
Database Admin
Audio Feed Provider
Audio Feed Provider
 
Join Date: Dec 2000
Location: Shavano Park, TX
Posts: 8,942
Default

But... your power supply is connected to A/C power.

Put your rpi on a battery.... then see what happens.
__________________
Lindsay C. Blanton III
CEO - RadioReference.com / Broadcastify
Facebook: RadioReference | Broadcastify | Twitter: @RadioReference
Reply With Quote
  #88 (permalink)  
Old 05-02-2017, 8:38 PM
Member
  Audio Feed Provider
Audio Feed Provider
 
Join Date: Dec 2016
Location: Milpitas, CA
Posts: 298
Default

Ok, I will try that . I have a 12V lead acid car battery in the garage. I think all I need is one of those USB car adapters to hook up to the rpi.
Reply With Quote
  #89 (permalink)  
Old 05-02-2017, 8:42 PM
Member
  Audio Feed Provider
Audio Feed Provider
 
Join Date: Feb 2011
Location: Massachusetts
Posts: 985
Default

Quote:
Originally Posted by blantonl View Post

1) I've been unable to get even my own released Raspbian based image release to broadcast more than one darkice feed without all the attached sound cards broadcasting on all the darkice instances. My own produced image will broadcast 3 feeds using darkice with no problem, [I]but will broadcast all three sound cards no matter how I configure alsamixer[/I

3) A RPi2 can easily stream 3+ darkice streams without a problem - provided the sound mixing issues are resolved.

A single RPi2 would have no problem broadcasting at least 3 streams if we (I) knew this soundcard bleed over problem.

lindsay,

Several of us in the TwoToneDetect community run multiple sound cards on a raspberry pi serving intances of TTD as well as multiple Broadcastify streams. We are using pulseaudio to direct the audio from the sound cards to the appropriate stream. Refer to this post for a description of how Andy figured it out:

https://forums.radioreference.com/st...ml#post2127541

I think that I tried four streams from one pi at one time.

Thanks for your interest again in the rtl_fm discussion. I would love to be able to make that work but have just invested WAY too much time into it leading to dead ends wherever I went.

Have you tried using the darksnow gui for darkice on the pi? There is another thread on that in the Streaming/broadcasting... forum.

Jim
Reply With Quote
  #90 (permalink)  
Old 05-02-2017, 8:49 PM
Member
  Audio Feed Provider
Audio Feed Provider
 
Join Date: Feb 2011
Location: Massachusetts
Posts: 985
Default

Quote:
Originally Posted by DC31 View Post
lindsay,

Several of us in the TwoToneDetect community run multiple sound cards on a raspberry pi serving intances of TTD as well as multiple Broadcastify streams. We are using pulseaudio to direct the audio from the sound cards to the appropriate stream. Refer to this post for a description of how Andy figured it out:

https://forums.radioreference.com/st...ml#post2127541

I think that I tried four streams from one pi at one time.

Thanks for your interest again in the rtl_fm discussion. I would love to be able to make that work but have just invested WAY too much time into it leading to dead ends wherever I went.

Have you tried using the darksnow gui for darkice on the pi? There is another thread on that in the Streaming/broadcasting... forum.

Jim
Here is what the startup script for two streams as well as two two tags looks like from one pi:

ps auxw | grep darkice0feed | grep -v grep >> /dev/null



if [ $? != 0 ]

then
/bin/sleep 5

date >> /home/pi/launchfeed0.log

PULSE_SOURCE=alsa_input.usb-Solid_State_System_Co._Ltd._USB_PnP_Audio_Device-00-Device.analog-mono screen -dmS darkice0feed darkice -c /etc/darkice0.cfg & > /dev/null

fi
ps auxw | grep darkice1feed | grep -v grep >> /dev/null



if [ $? != 0 ]

then
/bin/sleep 5

date >> /home/pi/launchfeed1.log

PULSE_SOURCE=alsa_input.usb-Solid_State_System_Co._Ltd._USB_PnP_Audio_Device-00-Device_1.analog-mono screen -dmS darkice1feed darkice -c /etc/darkice1.cfg & > /dev/null

fi

ps auxw | grep tags0 | grep -v grep >> /dev/null

if [ $? != 0 ]

then
/bin/sleep 5

cd /home/pi

screen -dmS tags0 python metaPy.py
fi

ps auxw | grep tags1 | grep -v grep >> /dev/null

if [ $? != 0 ]

then
/bin/sleep 5

cd /home/pi

screen -dmS tags1 python metaPy1.py
fi
Reply With Quote
  #91 (permalink)  
Old 05-02-2017, 9:18 PM
Member
  Audio Feed Provider
Audio Feed Provider
 
Join Date: Dec 2016
Location: Milpitas, CA
Posts: 298
Default

Hi DC31, thanks for comments. Did you get that rtl_fm -E pad working yet? For some reason the -E pad parameter is not working for most people who try that the first time including me.

My rpi3 feed with narrow band fm:
http://www.broadcastify.com/listen/feed/23831/webflash

Last edited by JACK26; 05-02-2017 at 10:33 PM..
Reply With Quote
  #92 (permalink)  
Old 05-03-2017, 7:00 PM
Member
  Audio Feed Provider
Audio Feed Provider
 
Join Date: Dec 2016
Location: Milpitas, CA
Posts: 298
Default rtl_fm narrow band hum. no external usb sound stick

I looked closer at the hum I'm hearing from the narrow band rtl_fm function I'm experiencing. It is a pretty clean 160Hz sine wave with only a small amount of distortion. There is no 60Hz component that I can see with Audacity.

Also since no one seems to have this problem with an external USB sound stick and it doesn't affect the level or frequency of the sound with different AC adapters and playing back sample mp3 files sound perfect, I don't think it's coming from the AC mains but rather generated by the rtl_fm narrow band function. The period is about 6.2msec.

I posted the screen shots from Audacity with the sample .wav clip here:

Audacity Screen shot
https://tinyurl.com/kezwel8

Sample wav file:
https://tinyurl.com/mll8vvp

ps the files are named "180Hz" but I made a mistake in the original calc. It is 6.2 msec and not 5.5msec period. Not sure how accurate that is but nothing close to 60Hz line freq (16.67 msec).

The hum only appears when a mike is keyed up and transmitting. If I turn off squelch and listen to dead air with static, there is no hum.

on the 0 padding problem with squelch I think there must be something wrong with the original instructions (even when it was using the keenerd fork) and that multiple versions of rtl_fm are installed. The keenerd fork of rtl-sdr has the code to make the rtl_fm -E pad function work in the rtl-sdr folder whereas the osmocom fork of rtl-sdr and the version in librtlsdr folder does not have the rtl_fm -E pad function. When I first got this working I thought it was because I installed the osmocom fork which was not the fix but just a coincidence. The fix is to make sure your rpi is using the keenerd fork.

rtl_fm -version
should show what functions are available. If the -E pad option doesn't appear then it's the wrong rtl_fm version for padding 0's to Broadcastify.

For now my feed is back online with the windows version that has no hum so if you're wondering if I fixed the hum problem, not yet .

pps How do you post a screen shot directly to a forum like this one?

Last edited by JACK26; 05-03-2017 at 8:58 PM.. Reason: Clarification and typo corrections
Reply With Quote
  #93 (permalink)  
Old 05-07-2017, 3:53 AM
Member
   
Join Date: Sep 2002
Location: Toronto, Ontario
Posts: 4,784
Default

Quote:
Originally Posted by JACK26 View Post
I posted the screen shots from Audacity with the sample .wav clip here:
Your links are dead.


Quote:
How do you post a screen shot directly to a forum like this one?
Click on Manage Attachments.
Reply With Quote
  #94 (permalink)  
Old 05-09-2017, 10:04 PM
Member
  Audio Feed Provider
Audio Feed Provider
 
Join Date: Dec 2016
Location: Milpitas, CA
Posts: 298
Default rtl_fm sdr audio 150 Hz audio buzz

Hi slicerwizard

Thanks for the interest. My feed is back online with the rpi3 and rtl-sdr USB stick only. So far nothing works with sox filters. Any filter applied to the stream just drowns it out to static.

One thing that is interesting is that the higher the gain that the rtl-sdr USB stick is set to, the lower the relative amplitude of the 150Hz hum. That is the opposite of what you would expect if it was coming from the receiver. That means the noise is generated by the downstream hardware or software.

The same rtl-sdr stick sounds fine on a windows computer and the rpi3 plays .mp3 files with no noise.
I even shut down all the rpi3's other processes including the VRS and pixel desktop.

I finallly ended up minimizing the 150Hz noise with the following startup sequence:

sudo /usr/local/bin/rtl_fm -d 0 -M fm -f 482.863M -g 35 -p 19 -l 72 -t 10 -s 12k -E pad | \
/usr/bin/lame -r -s 12 --resample 22.05 -m m --cbr --lowpass 4 --highpass 0.241 - - | \
/usr/bin/ezstream -q -c /etc/ezstream_bcfy.xml

the parameters are still a little flaky as the gain is set to max to minimize the 150Hz hum.

Milpitas Police Dispatch
Reply With Quote
  #95 (permalink)  
Old 05-09-2017, 10:36 PM
Member
  Audio Feed Provider
Audio Feed Provider
 
Join Date: Dec 2016
Location: Milpitas, CA
Posts: 298
Default

So far I have not heard any feedback from anyone who has ever made this work before: i.e. rtl-sdr USB stick streaming audio using rtl_fm narrow band to broadcastify without using an external sound capture usb stick. So not sure if anyone else has run up against the 150 Hz problem.

I got this working with the above command sequence and would welcome feedback from anyone else who has the patience to get this working to this level to find out if this 150Hz buzz is a common unresolved problem .

Last edited by JACK26; 05-09-2017 at 10:42 PM..
Reply With Quote
  #96 (permalink)  
Old 05-11-2017, 11:23 PM
Member
  Audio Feed Provider
Audio Feed Provider
 
Join Date: Dec 2016
Location: Milpitas, CA
Posts: 298
Default rtl-sdr narrow band feeder update

To anyone still interested, I relocated the feeder to a 7 foot tall scratching post to get it off my desk and had to re-tweak the gain and squelch parameters for the best audio. The 150 Hz hum is minimized with the 250 Hz high pass lame filter.

As mentioned before, this is a powerful signal and I think the repeater I'm receiving is on top of the light pole that is only about 50 feet away. It has a wireless router that was originally installed by earthlink as an experiment in city wide wifi access back in the 90's. The wifi router was eventually taken over by the city and Google as an experiment. Someone eventually mounted a 10 foot pole on top of this same street light with a small dipole on the top which is probably the repeater I'm receiving and feeding to Broadcastify.

It would be nice to fix the 150Hz problem as using the high pass lame filter is not sharp and cuts out the lows a lot. Here is new temporary file storage links to the audio (without the high pass lame filter):
https://expirebox.com/download/41d63...1a1b12132.html

Audacity screen shots:
https://expirebox.com/download/aa0c8...cbe8a8b89.html

This is the startup code that works for me for now:

sudo /usr/local/bin/rtl_fm -d 0 -M fm -f 482.863M -g 20 -p 19 -l 74 -t 10 -s 12k -E pad | \
/usr/bin/lame -r -s 12 --resample 22.05 -m m --cbr --lowpass 4 --highpass 0.241 - - | \
/usr/bin/ezstream -q -c /etc/ezstream_bcfy.xml

The -g and -l parameters are critical to the setup and signal levels. It goes from not working at all to barely working well.

One thought on this 150Hz hum, it may have something to do with the private talk groups they use. Occasionally there is a distinct carrier that pops up in the exact middle of the operating frequency that sounds like some kind of trunk signal but the amplitude is barely above the background noise. It would be completely illegal for anyone else to transmit on this frequency in the area and would not be tolerated. So if it is a real transmitted signal it must be from the legal channel owners. I have no idea if that has anything to do with this persistent 150Hz hum but the fundamental audio frequency is very close but more complex with higher frequency components.

For some reason I don't hear the 150Hz hum with SDR# on a Windows computer, but I can hear the low level "trunk sounding" carrier signal when it pops above the background noise.

Last edited by JACK26; 05-11-2017 at 11:53 PM..
Reply With Quote
  #97 (permalink)  
Old 05-12-2017, 5:04 AM
Member
  Audio Feed Provider
Audio Feed Provider
 
Join Date: Feb 2011
Location: Massachusetts
Posts: 985
Default

[QUOTE=JACK26;2763287

This is the startup code that works for me for now:

sudo /usr/local/bin/rtl_fm -d 0 -M fm -f 482.863M -g 20 -p 19 -l 74 -t 10 -s 12k -E pad | \
/usr/bin/lame -r -s 12 --resample 22.05 -m m --cbr --lowpass 4 --highpass 0.241 - - | \
/usr/bin/ezstream -q -c /etc/ezstream_bcfy.xml

The -g and -l parameters are critical to the setup and signal levels. It goes from not working at all to barely working well.

[/QUOTE]

How does one determine his correct -g and -l parameters? Is it strictly trial and error? Do you have any suggestions on how to go about this? With two variables to change that is a lot of trials to hopefully find a sweet spot.
Reply With Quote
  #98 (permalink)  
Old 05-12-2017, 11:31 PM
Member
  Audio Feed Provider
Audio Feed Provider
 
Join Date: Dec 2016
Location: Milpitas, CA
Posts: 298
Default

Quote:
Originally Posted by DC31 View Post
How does one determine his correct -g and -l parameters? Is it strictly trial and error? Do you have any suggestions on how to go about this? With two variables to change that is a lot of trials to hopefully find a sweet spot.
There is a lot of trial and error to refine the end parameters for a given setup that mostly depends on signal strength. Easiest way to find a ball park -g -l figures is to use a graphics gui like sdr# to get an idea within +/-5-10 dBm gain setting for the specific rtl-sdr stick. Also -p clock offset. But after that it's several hours of tweaking to get the -g and -l parameters optimized. At least for me so far. agc doesn't work at all. No kidding, just moving the rpi and or antenna around and you're back to retweaking. It is worth getting this to work though because of the low cost and simplicity

ps: one thing to note is that in my case I was fighting to minimize the 150Hz background noise. This may not be a common experience and without that problem it's much easier to receive a quality signal. Not sure if this 150Hz hum is a common problem yet.

pps: Parallel thread on rtl-sdr website. Very little interest in this "rpi with rtl-sdr only" project so far but trying to motivate more interest
rtl-sdr.com • View topic - rtl_fm squelch and mp3 encoding

Original RR wiki on the build which is not perfect but a good place to start. If things don't work the first time don't give up and try to start over. Just figure out how to make it work some other way:
http://wiki.radioreference.com/index...R_Broadcastify

.

Last edited by JACK26; 05-13-2017 at 12:29 AM..
Reply With Quote
  #99 (permalink)  
Old 05-13-2017, 12:44 AM
Member
  Audio Feed Provider
Audio Feed Provider
 
Join Date: Dec 2016
Location: Milpitas, CA
Posts: 298
Default

In my case, I found that the wrong version of rtl-fm was invoked with the startup code. The problem with the original instructions was that 2 different versions of rtl-sdr was installed. Osmocom (original fork) and keenerd (updated with 0 padding for broadcastify requirements). After days of hacking the software and installing several different versions of rtl-sdr, I mistakenly thought that I'd fixed my zero padding problem by installing the Osmocom fork of rtl-sdr. That was not the case. The original instructions that pointed to the keenerd fork was correct. The "librtlsdr" folder still contains the osmocom version and I think that is what is messing up the original install instructions. The startup code is pulling up the rtl_fm version from "librtlsdr" instead or "rtl-sdr".

In other words, don't just keep trying to follow the original instructions. It took me so long to get here that I don't remember all the exact steps.

Also, make sure you use absolute paths as a super user to the file locations eg:
sudo /usr/local/bin/rtl_fm

And make sure that path contains the version of file you want (in this case the keenerd version).

Last edited by JACK26; 05-13-2017 at 12:53 AM..
Reply With Quote
  #100 (permalink)  
Old 05-14-2017, 12:10 AM
Member
  Audio Feed Provider
Audio Feed Provider
 
Join Date: Dec 2016
Location: Milpitas, CA
Posts: 298
Default

Update to those still interested, major problems with keeping the rpi reliably connected to broadcastify. Solved that problem by adding this startup code to the /etc/rc.local file and looping it back to a reboot with delay to allow time for network re connection. So far it works really well no matter how I abuse the rpi's connection. To incorporate, Insert the following code just before the "exit 0" line in the rc.local file as a super user:

#!/bin/bash
sleep 20

sudo /usr/local/bin/rtl_fm -d 0 -M fm -f 482.863M -g 20 -p 19 -l 75 -t 10 -s 12$
/usr/bin/lame -r -s 12 --resample 22.05 -m m --cbr --lowpass 4 --highpass 0.241$
/usr/bin/ezstream -q -c /etc/ezstream_bcfy.xml> sudo reboot &

The 3rd and 4th lines are unique to the frequency and signal strength you are receiving, it's the last line that streams it online and reboots if connection is lost. The sleep line allows time to re-establish a network connection. So far it seems to be bullet proof and restarts really well.

pps make sure your rc.local startup file has executable permission. i.e. at a command prompt type:

sudo chmod -x /etc/rc.local

If there is no feedback on errors, then it worked and rc.local should execute on reboots.

Last edited by JACK26; 05-14-2017 at 12:46 AM..
Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On



All times are GMT -5. The time now is 1:34 AM.


Powered by vBulletin® Version 3.8.2
Copyright ©2000 - 2018, vBulletin Solutions, Inc.
All information here is Copyright 2012 by RadioReference.com LLC and Lindsay C. Blanton III.Ad Management by RedTyger
Copyright 2015 by RadioReference.com LLC Privacy Policy  |  Terms and Conditions