Put in a second sound "card" (USB on a laptop) and assign Audition to it. Did that with Audition 3.0 & Scott TLC on the same machines.
-
Get involved.
We want your input!
Apply for Membership and join the conversations about everything related to broadcasting.
After we receive your registration, a moderator will review it. After your registration is approved, you will be permitted to post.
If you use a disposable or false email address, your registration will be rejected.
After your membership is approved, please take a minute to tell us a little bit about yourself.
https://www.radiodiscussions.com/forums/introduce-yourself.1088/
Thanks in advance and have fun!
RadioDiscussions Administrators
SKYPE FOR REMOTES
- Thread starter Steve Eberhart
- Start date
OMG!!! Fantastic idea!!! Then take the audio from both cards and run it through a y-cable into the board/router so you don't lose an input. Or not. If you have the space, use two inputs. This could certainly un-knot a lot of Calvins in my plant.boiseengineer said:
TomT said:
<zoinks!>It'd be impossible, period. Why is anyone taking calls without a profanity delay?
And even if calls were not being taken, and the delay was bypassed, there's still too much delay in all our digital doo-dads these days to do anything without IFB. Observe the audio path from a remote, through to the listener's ears:
- analog to digital conversion in the sound card or USB headset.
- Skype codec processing at the remote.
- ISP, cellular network, and the internet itself.
- network gadget delay in the rack room: firewall, router, etc.
- Skype codec processing at studio end.
- sound card processing in studio PC.
- DSP processing in the console.
- DSP processing in the audio router.
- DSP processing in the air chain.
- profanity delay if calls are being taken.
- DSP & transmission delay in the STL.
- DSP in the dynamic range management at the transmitter. (Omnia, Orban, etc.)
- HD processing delay.
- transmission time through the air to the listener's radio.
- DSP in the radio if it's got anything like DSP-based EQ.
- and then of course the sound passing through the air from the speakers to the ears, but I'd never split hairs like that... ;-)
Even back in the day when I first started doing remotes and *everything* was still analog, there was still a delay that could be heard as an audible echo at the remote.
And then there are all the alternative paths like translators, satellite networks, and XM, and the gobs of DSP involved in those.
And just as a cranky side-note, I'd like to stomp my foot and swear, and say all that DSP has *destroyed* audio quality the world over! >=-|
Ok, off my soap box now. =-)
That's almost how one of our shows works: the host is in studio, the co-host is on Skype from three time zones away, and it's all mixed in the control room with no delay issues at all.shreveville said:
R
RolfTaylor
Guest
Tom, with all due respect...
You have either failed to say what you mean, or are incorrect.
There absolutely is an end to end delay on codecs, including cell phones. There are a number of reasons, and there are more causes for delay in an IP system versus a synchronous system.
For each talker it is the round trip delay figure that matters, which is why broadcasters frequently mix algorithms in the two directions (e.g. use a low delay lower-quality algorithm in the IFB direction).
This ability to mix algorithms is useful and is not present in systems not intended for broadcast use.
Here is a clear and concise explanation courtesy of the Telos Xstream manual:
<begin quote>
Phones and Remotes
To save money and hassle, callers are usually received at the studio, rather than at the remote site. In this situation, phones need to be fed to the remote talent, so that they can hear and respond to callers. Moreover, the phone callers need to hear the talent. In many cases, the remotes are sufficiently distant that the station cannot be monitored for the caller feed. Even if it could, the profanity delay would be a problem, since the talent needs to hear the phone pre-delay.
The talent hears callers via the return path. As before, this return is fed with mix-minus: a mix of everything on the program bus minus the remote audio.
As for the second half of the equation, the callers hear the talent because the remote feed is added to the telephone mix-minus buss. No problem if you have a set-up that permits selective assignment to the phone mix-minus.
The most common problem with this arrangement is a result of a phone hybrid with too much leakage combined with the system delay. If the hybrid isn't doing a good job of preventing the send audio from leaking to its output, the special remote send mix-minus is corrupted.
Remember, if any of the announcer audio from the remote site is returned via the monitor feed, it will be delayed by the codec link, causing an echo effect. Problem. The answer is to make sure you have the best possible hybrid with the maximum trans-hybrid loss, such as a system that uses ISDN lines. If it has variable override (caller ducking), you could increase the amount when these remotes are in progress (or, on some hybrids, you would decrease the setting of the "duplex" control).
Some users place a downward expander, carefully adjusted to gate the leakage, in the caller audio path.
Another issue worth considering is the round trip delay. The apparent on-air response time of the talent to callers’ comments will be the sum of studio-to-remote delay + remote-to-studio delay + talent’s thinking time. For this reason the studio-to-remote path will generally use the G.722 mode, which sacrifices fidelity for delay (after all, the callers need not be in high fidelity). This round trip delay issue will also affect your choice of remote-to-studio coding. If the show will be 90% talk with just a small amount of music then delay can be minimized by using a mono mode for this path rather than using one of the slower stereo modes.
Here is where Zephyr Xstream’s AAC-LD encoding really shines. It gives you high quality announcer audio with the lowest delay possible. In addition, the reduced delay time will serve make any leakage less distracting (for more on this see Section 6 & 8 - Audio Coding Reference).
Another trick is to use a POTS call (call mode = Phone) for the studio-to-remote link, which will make the delay in that direction very small. Other intermediate tradeoffs are possible, and will be dependent on your format. Talent thinking time can be significantly reduced by drinking a strong cup of coffee!
For information on the tradeoff between audio quality and delay, refer to manual Section 6 (Audio Coding Reference)
<end quote> Provided courtesy of Telos Systems
Of course the same end-to-end delay issue is true when you have "local" and "remote" talent.
While it is up to each broadcaster to determine their own tradeoffs, the above issues are perfect examples where buying broadcast specific products, and better grade hybrids, can provide real benefits to broadcasters.
You have either failed to say what you mean, or are incorrect.
There absolutely is an end to end delay on codecs, including cell phones. There are a number of reasons, and there are more causes for delay in an IP system versus a synchronous system.
For each talker it is the round trip delay figure that matters, which is why broadcasters frequently mix algorithms in the two directions (e.g. use a low delay lower-quality algorithm in the IFB direction).
This ability to mix algorithms is useful and is not present in systems not intended for broadcast use.
Here is a clear and concise explanation courtesy of the Telos Xstream manual:
<begin quote>
Phones and Remotes
To save money and hassle, callers are usually received at the studio, rather than at the remote site. In this situation, phones need to be fed to the remote talent, so that they can hear and respond to callers. Moreover, the phone callers need to hear the talent. In many cases, the remotes are sufficiently distant that the station cannot be monitored for the caller feed. Even if it could, the profanity delay would be a problem, since the talent needs to hear the phone pre-delay.
The talent hears callers via the return path. As before, this return is fed with mix-minus: a mix of everything on the program bus minus the remote audio.
As for the second half of the equation, the callers hear the talent because the remote feed is added to the telephone mix-minus buss. No problem if you have a set-up that permits selective assignment to the phone mix-minus.
The most common problem with this arrangement is a result of a phone hybrid with too much leakage combined with the system delay. If the hybrid isn't doing a good job of preventing the send audio from leaking to its output, the special remote send mix-minus is corrupted.
Remember, if any of the announcer audio from the remote site is returned via the monitor feed, it will be delayed by the codec link, causing an echo effect. Problem. The answer is to make sure you have the best possible hybrid with the maximum trans-hybrid loss, such as a system that uses ISDN lines. If it has variable override (caller ducking), you could increase the amount when these remotes are in progress (or, on some hybrids, you would decrease the setting of the "duplex" control).
Some users place a downward expander, carefully adjusted to gate the leakage, in the caller audio path.
Another issue worth considering is the round trip delay. The apparent on-air response time of the talent to callers’ comments will be the sum of studio-to-remote delay + remote-to-studio delay + talent’s thinking time. For this reason the studio-to-remote path will generally use the G.722 mode, which sacrifices fidelity for delay (after all, the callers need not be in high fidelity). This round trip delay issue will also affect your choice of remote-to-studio coding. If the show will be 90% talk with just a small amount of music then delay can be minimized by using a mono mode for this path rather than using one of the slower stereo modes.
Here is where Zephyr Xstream’s AAC-LD encoding really shines. It gives you high quality announcer audio with the lowest delay possible. In addition, the reduced delay time will serve make any leakage less distracting (for more on this see Section 6 & 8 - Audio Coding Reference).
Another trick is to use a POTS call (call mode = Phone) for the studio-to-remote link, which will make the delay in that direction very small. Other intermediate tradeoffs are possible, and will be dependent on your format. Talent thinking time can be significantly reduced by drinking a strong cup of coffee!
For information on the tradeoff between audio quality and delay, refer to manual Section 6 (Audio Coding Reference)
<end quote> Provided courtesy of Telos Systems
Of course the same end-to-end delay issue is true when you have "local" and "remote" talent.
While it is up to each broadcaster to determine their own tradeoffs, the above issues are perfect examples where buying broadcast specific products, and better grade hybrids, can provide real benefits to broadcasters.
TomT said:
No delay! Wow. But we are talking about out in the field remotes. Just had a remote that no matter what we tried, the jitter was so bad the buffer delay was 2 seconds! The ol' 450 Marti shot & an FM subcarrier for IFB (no delay there!) saved the day.
Srsly? What was it on, a dial-up connection? =-)
@spin If he's using a mobile broadband card, the answer is "yes." Just this past evening we had a terrible time with our Verizon card keeping a decent connection with our Access, with is designed to optimize the connection and reconnect ASAP automatically. Wireless broadand is "best efforts." This means you are subject to the variability of the network. Almost every other time from this location, we never have a problem. But last night, 3G was unavailable and we limped along on just slightly better than dial-up speeds. It happens, even where you least expect it.
DudeFan said:
I've noticed widely varying performance so far with wireless 3G and Access on high school football games. Seems like no matter what my setup parameters are, I will always get a brief loss of audio every so often.
There was one location that I noticed the issues were worse at halftime. Must have been everyone making phone calls at the half and clogging the network.
Hmmm... It'd be interesting to do some bandwidth tests. And throttling software. Or perhaps mess with the ethernet connection and simulate a bottleneck.
The mind wanders...
One could take an ethernet cable, hack it in half, and do two things: 1) make it a crossover, and 2) place some pots inline and slowly increase the resistance so framing errors also increase due to the attenuated signal. Then crank up Skype and the bandwidth software and see what happens.
One issue I've been wondering about it if/how Skype varies the compression rate and/or codec to adapt to the headroom at hand.
The mind wanders...
One could take an ethernet cable, hack it in half, and do two things: 1) make it a crossover, and 2) place some pots inline and slowly increase the resistance so framing errors also increase due to the attenuated signal. Then crank up Skype and the bandwidth software and see what happens.
One issue I've been wondering about it if/how Skype varies the compression rate and/or codec to adapt to the headroom at hand.
Just curious what kind of settings everyone is using for Skype on both the remote and host ends? I'm trying to iron out the audio settings and I haven't really been able to nail down what I need to set things at. I would expect it would be best to turn off the Automatic level settings for the microphone, but I wanted to see what everyone else has been doing. Also, are you using a broadcast quality soundcard, such as a Lynx, at the host end? Any input is appreciated. Looks like we're going to use this more and more.
the_scoop said:
We've been using all the default settings and the motherboard audio with a Henry Matchbox. Works perfectly.
The show has now been going on for at least three months, with the host in DC and the co-host in Seattle. Since the Skype was first set up to do this, we've had but one single problem, which was traced to the mix-minus not being set for that fader. Skype was hearing itself, and the codec got grumpy.
Don't knitpick over the audio quality too much. First, you're doing radio, not the next Celine Dion CD. Also 99% of your listeners have crappy radios and are half deaf anyways, and the ones that aren't are probably not audiophiles. Second it's a remote, and any remote gear will mash the audio. And with the proliferation of digitization & data-compression, every time audio passes through a "hop" it gets mashed more.
You've got your Skype, then the sound card on the PC, then the console, and/or a digital console/router if you have one, then the radio audio chain & processing, delay, STL, HD (MP3), transmitter, ISDN to satellite uplink/downlink & whole other studio audio chains, and last but not least crappy radio in the listeners' cars, crappy speakers, crappy room acoustics, and swaths of shattered cochlear cilia from listening too loud to this kind of crappy for too many years.
In essence, good enough is good enough. Aside from not having a damn clue about audio, most regular listeners know that remotes sound funny and it's part of the flavor. =-)
LibertyNT said:
That's because there probably is none. The OEM's buy all the same codec chipsets from the same chinese chip manufacturers. One might argue differences in sample rates, oversampling rates, and filter capacitors, and possibly DSP if they program their own TI chips, but the calculus mathematics is the same all over. Fourier Transforms are Fourier Transforms. In the end, the biggest difference is the marketing spin. People feel better buying a $999.99 Digigram card instead of a $9.99 generic card from the sale bin at the computer superstore. But I'll bet you dinner & beer if you plugged them both in to a car stereo that no one - not you, not me, and especially not the listeners could tell the difference. =-)
spinjector said:
Well, that's a BIT of an oversimplification.
The "pro" cards (Digigram, Audioscience et. al) do come with hardware and drivers that provide MUCH more functionality than the el-scuzzo $10 cards do (i.e. on-board MP3 decoding, on-the-fly time compression/expansion, etc.) and the analog components are generally of a MUCH higher quality than those cheapie cards. So it's not all "marketing spin".
As for your comparison assertion - on a typical car stereo, you're probably right.
Meh. Time compression? Get a TARDIS for that! ;-)
SRP said:
That's a little misleading too. Most Digigram cards don't do sample rate conversion or mp3 decoding in the DSP. That is usually passed on to the CPU, but none of us should be using compression anyway, right?
chriscollins said:
Actually, that's not misleading at all. The PCX cards and the Mixart all have on-board compression hardware and that's the majority of Digigram's product line. The VX cards (their semi-pro line) do not, however have hardware compression functionality.
Whether or not to use compression is a topic for another thread.
- Status