[RDD] Remote "Board Op" from within RDAirPlay

drew Roberts zotzbro at gmail.com
Sat Jun 3 22:26:48 EDT 2017


Cowboy,

On Sat, Jun 3, 2017 at 5:19 PM, Cowboy <curt at cwf1.com> wrote:

>
>  I'm gonna cut down some of the quotes of quotes of quotes...
>

~;-)

>
> On Saturday 03 June 2017 03:28:16 pm drew Roberts wrote:
> > Lorne,
> >
> > thanks for the input. Not sure we want to go this way, but I will comment
> > on my thinking for the future and for the benefit of any interested
> parties
> > anyway.
> >
> > On Sat, Jun 3, 2017 at 12:49 PM, Lorne Tyndale <ltyndale at tyndaleweb.com>
> > wrote:
>
> > > -Have your "remote" with the ability to VPN into your "station" network
> > > and see your Rivendell server
> > >
> >
> > This should be doable.
>
>  Easily do-able.
>  ssh tunnel, or if there's a firewall involved a reverse ssh tunnel.
>  VNC can be a wonderful tool, but it's only a tool.
>

Yes, this was not the doable I was referring to.

We are doing vnc over an ssh tunnel  for years. We are testing OpenOB over
a vpn. The OpenOB in the studio and the rdairplay machine in the studio may
not be on the same network when all is said and done.

>
> > > -Set up your "remote" rivendell machine with a full copy of Rivendell,
> > > but accessing the database on the main server.  For this to work, you
> > > might need to have a local copy of /var/snd - I've run into challenges
> > > getting a fast enough mount when at a remote location, but it might
> work
> > > via a mount too
>
> > I would not want to try a mount, but a local copy that was kept up to
> date
> > every night should be doable.
>
>  Depends on the bandwidth of the connection.
>  On a 10BaseT probably not. On a 100BaseTx maybe.
>  Across a public internet, no !
>
> > > -Set your "remote" machine to use the Core Audio Engine on the main
> > > server back at your station (rdadmin --> Manage Hosts --> Core Audio
> > > Engine).
>
> > Either all of my Rivendell systems are too old to have this setting or it
> > is not there in the chain.
>
>  Probably, your stuff is old, but again, consider the bandwidth of the
> link.
>  I have 14 ( virtual ) machines using 4 sound cards generating 14 streams.
>  It does work, but it's at bus speed.
>  Remote... uh... maybe. Probably not with today's tech.
>
> > The question is, where will it pull the wav file from? The studio's
> > /var/snd, or the local /var/snd.
>
>  The way it was outlined, the local sound file through the local airplay
>  using the remote sound card.
>

??? In my discussion, I hope I referred to the locations as remote and
studio.

In yours just above, is the local sound file and the local airplay at the
location where the remote is happening? And is the remote sound card in the
studio?

If so, is the pcm stream going/streaming over the vpn?


 Quite workable, we do it, but we're doing it across a gigabit network
>  through all of one ( count 'em... ONE ! ) gigabit switch.
>
> > > -when you want the jock to go "live" from the remote, you simply have
> to
> > > make RDAirplay stop (just as you would when in the studio) and turn on
> > > the remote mic.  The OpenOB Send will send your mic audio back down the
> > > pipe to your studio and out to your output (since it doesn't go through
> > > Rivendell at all it'll also have the added bonus of creating a
> > > mix-minux)
>
> > I will have to think this last bit all through very carefully.
>
>  And again, consider the bandwidth of the link, and the latency.
>
> > This is where we are with our thinking / testing so far:
> >
> > (I just thought of a problem arising from the fact that our "real"
> machine
> > has an ASI card while our "test" machine does not.)
>
>  I'm not sure that's necessarily a problem, unless you have an Livewire
>  ASI card ?
>

I thought of the problem with the ASI card, I did not elaborate on it. It
is not Livewire.

The problem is that in the test system, I have jack running on the sound
card that will be the parallel of the ASI card in the actual system where
jack is not running. Therefore, I will have to find another way to some of
the Jack Mixer mic muting and what not.

>
>
>
> > What we are trying to get smooth:
> >
> > As the song is fading down, the bed should fire low and fade up (with
> > overlap if we get it right.)
> >
> > We talk, talk, talk, as the bed plays.
> >
> > When we are done, we click on S:1 C1 R3 -> End Remote: Plays cart 050003
> >
> > What we are trying to get smooth:
> >
> > We want the bed to fade down and end and the next song in the log to fire
> > and fade in as the bed is fading down.
>
>  If I wanted to do this unattended, I would do it the way I've done it in
> the past,
>  which depends on an audio "processing" chain with a reasonably wide
>  dynamic range, and a fair amount of controllability.
>  If you can control the slew, and especially the slew rate, you're in
> heaven !
>

I am not trying to be as fancy as you seem to think by this comment. All I
am really trying to accomplish is for something that sounds like a segue
between the last song before going to remote and the music bed of the
remote and then another segue between the music bed and the first song
after the remote on coming out of the remote.

Your exposition does give me some ideas and something for us to ponder.


>  If you're doing mono, and you have processors available that will do true
>  dual mono, but also have a "linked stereo" mode, it gets really, really
> easy.
>  It's still do-able even if you don't.
>  The "trick" is understanding that if you have an AGC with a 40db input
> range,
>  you can play a bed at -30, feed mic at -10, the bed will be "faded down"
> 20db
>  by the following AGC transmitter processor.
>  When the announcer stops talking, the music is faded up 20.
>  Follow all this with a transmitter processor, so you get consistency at
> the
>  final output, and you'll like the results, provided you can tweek the
> attack and
>  decay times independently, else you'll get pumping.
>  You don't want it to pump if the announcer takes a breath.
>  Very fast attack, but very slow release. Exactly how fast, and how slow,
>  will take a little practice.
>
>  It's real do-able in mono.
>  You feed one source into L and another into R ( obviously enough ) but you
>  also mix the L+R output back to mono.
>  The linked stereo mode has the higher input level controlling the fade of
> both.
>  I ran WSLR this way for many years, and got nothing but compliments
>  on the way it sounded so "live" when it was most certainly automated.
>
>  Do keep in mind, like tweeking any audio processor, if you get one
> parameter
>  wrong, "train wreck" is an understatement.
>  If you want it to sound like a cat dying, I can tell you how to do that,
> too.
>  If someone accidentally leaves a mic open, well, see "train wreck" above.
>
>  Also, if you have all the pieces parts, AND you happen to be in the
> Caribbean,
>  and will pay expenses, I'll come show you for free !
>  ( see, I really *AM* easy to get along with ! )
>

~;-)


all the best,

drew


>
> --
> Cowboy
>
> http://cowboy.cwf1.com
>
> Absurdity, n.:
>         A statement or belief manifestly inconsistent with one's own
> opinion.
>                 -- Ambrose Bierce, "The Devil's Dictionary"
> _______________________________________________
> Rivendell-dev mailing list
> Rivendell-dev at lists.rivendellaudio.org
> http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev
>



-- 
Enjoy great *Bahamian Music* at:
Bahamain Or Nuttin - http://www.bahamianornuttin.com
<http://www.bahamianornuttin.com/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://caspian.paravelsystems.com/pipermail/rivendell-dev/attachments/20170603/695f72a1/attachment.html>


More information about the Rivendell-dev mailing list