On Saturday 08 December 2012 08:04:25 pm James Harrison wrote:
> That said, unless you have good reason to use 44100Hz... :-)
>
Every CD in the world is 44.1 seems a valid reason.
--
Cowboy
http://cowboy.cwf1.com
Expense Accounts, n.:
Corporate food stamps.
_
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
OpenOB at no point is even aware of the sample rate it's running at
(well, GStreamer under the hood is, but the app isn't). It'll just use
your sound card/JACK sample rate by default. If your sound card is
running at 44100Hz, it'll use that.
That said
Hello Folks!
Everything is working as I need by now but it is running at 48khz, is there
a way t change the sample rate of OpenOB?
Regards.
Atenciosamente,
** **
*Fernando Della Torre*
Tecnologia da Informação
(: +55 16 8137-1240
(: +55 16 9137-2886
*: *f...@vdit.com.br*
V.D
Hi, the answers go down,.
Thank you so much for helping,
Cheers,
2012/11/30
> Hi,
>
> How much memory is in your desktops? If they're low on memory (512MB or
> less) it could be something as simple as a resource / memory issue,
> especially if there is something running in the background e
Hi,
How much memory is in your desktops? If they're low on memory (512MB or
less) it could be something as simple as a resource / memory issue,
especially if there is something running in the background eating up cpu
/ memory.
Are your onboard sound cards based on the Intel audio chipset? I've
Hello again James,
Thank you so much for your reply and such helpfull information!
I'll read all the info on these links you suplied, than you again!
Atenciosamente,
** **
*Fernando Della Torre*
Tecnologia da Informação
(: +55 16 8137-1240
(: +55 16 9137-2886
*: *f...@vdit.com.b
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Couple of things can affect delay. Sound cards is one thing - the
jitter buffer in OpenOB is the other. By default this is 150ms,
suitable for decent Internet links, and is tweaked with the -j option
on the transmitter. -j 5 should be fine on fast ethe
Hello James,
This is my very first time experience with OpenOB.
I have set up 2 old IBM P4 HT 3Ghz desktops running Wheezy and installed
OpenOB on both.
They are running OpenOB on the onboard sound cards through ALSA over a
100Mbit fast ethernet.
Using 96kbps Opus I get 390ms of delay, and using
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Technically OpenVPN can run in TCP or UDP modes, but UDP is the default.
Cheers,
James Harrison
On 27/10/2012 23:03, Rob Landry wrote:
>
>
> On Fri, 26 Oct 2012, James Harrison wrote:
>
>> Unfortunately, SSH is a TCP based protocol. RTP is a UDP b
On Fri, 26 Oct 2012, James Harrison wrote:
> Unfortunately, SSH is a TCP based protocol. RTP is a UDP based protocol
> and with good reason - packet loss is fine and expected (Opus has packet
> loss concealment and forward error correction, both of which are made
> use of for OpenOB). So you nee
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I absolutely agree on all counts. Cheers for the feedback, all!
Cheers,
James Harrison
On 26/10/2012 18:12, Cowboy wrote:
> On Friday 26 October 2012 12:33:19 pm Fred Gleason wrote:
>> I think it'd be sufficient to make OpenOB do network audio
>> tra
On Friday 26 October 2012 12:33:19 pm Fred Gleason wrote:
> I think it'd be sufficient to make OpenOB do network audio transmission well.
> Packet encryption/tunneling/whatever are not properly within its scope.
> There are lots of other packages that can provide those functionalities in a
> l
On Oct 26, 2012, at 09:41 50, James Harrison wrote:
> I'd rather have this outboard on something like a Mikrotik Routerboard (which
> can
> handle the IP routing and encryption and all that jazz).
That's certainly the Un*x philosophy: a tool that does one thing well, rather
than huge monster m
On Friday 26 October 2012 09:41:50 am James Harrison wrote:
> and it might be easier to
> just design OpenOB with the assumption
Of course it would be easier !!
It would be easier to just assume it will always be run
across a Microsoft VPN, too, and let Microsoft worry about
how or whether it
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Well, -w just plugs SSH into tun devices, and I'm relatively certain
that it'll result in packet fragmentation (which will happen with most
tunneling protocols, but that's something I need to check). Plus the
overhead of encryption and decryption is
He is right, James. I might add that if you get things working on the
command line there is a config file that you can setup the ports you want
to connect every time you ssh into a host. That means you don't have to
remember a long commplicated command a mile long.
Frederick
On Thu, 25 Oct
> You don't even need a static IP, but you do need a domain name
> that can track dynamic DNS in that case.
>
A domain names can be spoofed, fire walling by ip is safer.
Cheers
Gary.
___
Rivendell-dev mailing list
Rivendell-dev@lists.rivendellaudio
On Friday 26 October 2012 04:06:18 am James Harrison wrote:
> So you need a UDP based tunnel,
See the -w option in man ssh.
There are a number of ways to accomplish UDP via SSH.
--
Cowboy
http://cowboy.cwf1.com
"You've got to think about tomorrow!"
"TOMORROW! I haven't even prepared for *
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Unfortunately, SSH is a TCP based protocol. RTP is a UDP based protocol
and with good reason - packet loss is fine and expected (Opus has packet
loss concealment and forward error correction, both of which are made
use of for OpenOB). So you need a U
On Tuesday 23 October 2012 04:10:10 am James Harrison wrote:
> Since most outside broadcasts want talkback functionality anyway, I want
> to implement firewall/NAT tunneling to get around the same problem on
> the transmitter end (because you need an audio link from RX to TX for
> talkback), whi
Its fairly simple to set up too.
-Original Message-
From: rivendell-dev-boun...@lists.rivendellaudio.org on behalf of
ltynd...@tyndaleweb.com
Sent: Wed 24/10/2012 16:22
To: rivendell-dev@lists.rivendellaudio.org
Subject: Re: [RDD] OpenOB 2.3 release
Hi,
Instead of trying to incorpor
On Wed, 2012-10-24 at 17:29 -0200, Daniel Roviriego wrote:
> The talkback option would be a must!
> Thanks for sharing James!
I was (some years back) playing with an add in to CAED that appeared as
a switcher for accepting audio over IP in various forms, you set up an
entry as a URL and could to t
The talkback option would be a must!
Thanks for sharing James!
cheers
2012/10/24 James Harrison
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> This is very much where I want to get OpenOB to. Lots of my work
> (dabbling at weekends) has been in modularizing the code; next comes the
> e
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
apt-X is actually inferior to Opus from what I've heard. Opus is the
maturation of the CELT and SILK codecs, is patent-unencumbered and open,
and is an IETF standard: http://www.opus-codec.org/ and
http://tools.ietf.org/html/rfc6716 - it's also damn
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
This is very much where I want to get OpenOB to. Lots of my work
(dabbling at weekends) has been in modularizing the code; next comes the
extraction of the user interface (mostly there now) so the backend can
be dropped into a PyGTK app with friendly
Hi,
Instead of trying to incorporate a silence detection into something like
OpenOB, why not just set up something like SilentJack on the receiving
end to do that? This would seem fairly trivial to set up, you could
probably even pipe your receiving end of OpenOB through Jack and have
Silentjack
Hello,
It looks really interesting, and we'll have a look into that ! We
currently use our own-flavored Gstreamer application, with CELT encoded
RTP packets, hooked into JACK on both ends, for our live presentations
outside of the studio, and it works quite well. But as it is made so
far, it requi
...Opus codec? That's a new one to me.
How does it compare with AAC, Ogg, and MPEG?
I'd love to see apt-X become available some day. The patents must be
running out one of these days.
Rob
On Mon, 22 Oct 2012, James Harrison wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I know a
> Being a little security conscious you should be firewalling the hell out of
> the transmitter which leaves you with 3 obvious routes:
>
> 1. Set up a site to site VPN (doable but introduces latency and processing
> cost)
> 2. Open the ports on the transmitter firewall (which to my mind is a
Original Message-
From: rivendell-dev-boun...@lists.rivendellaudio.org on behalf of Wayne Merricks
Sent: Wed 24/10/2012 01:55
To: User discussion about the Rivendell Radio Automation System
Subject: RE: [RDD] OpenOB 2.3 release
Use case wise, we farm out our transmission to WRN in London (they take
ndell-dev@lists.rivendellaudio.org
Subject: Re: [RDD] OpenOB 2.3 release
Since most outside broadcasts want talkback functionality anyway, I want
to implement firewall/NAT tunneling to get around the same problem on
the transmitter end (because you need an audio link from RX to TX for
tal
Maybe it could be optional. You could provide the option to run a
script when the internet is down, and another script when your online
again. Anyway, I will test this software, as it looks promising.
/Morten
2012/10/23 James Harrison :
> My gut feeling is that OpenOB shouldn't be responsible for
My gut feeling is that OpenOB shouldn't be responsible for this - you
should have a silence detector outboard of the PC in any transmission
system with a standalone hardware audio player for reliability.
Cheers,
James Harrison
On 23/10/12 15:31, Morten Krarup Nielsen wrote:
> This looks very i
This looks very interesting.
This could be a cool new feature, if you use it for STL, and the
internet connection is lost: What about adding a silence detector
function, where the receiver plays MP3 files, until the connection to
the studio is reestablished?
Kind regards,
Morten
2012/10/22 Jame
I just came off a three-hour remote connecting New Mexico with Arlington, VA.
on Friday, using AudioTX Communicator. I didn't get to use it for very long,
but it got my attention for sure.
http://www.audiotx.com/communicator.html
And its about half the price of a dedicated IP codec cuz (presuma
me off list to save spamming RD (if necessary).
Regards,
Wayne
-Original Message-
From: rivendell-dev-boun...@lists.rivendellaudio.org on behalf of James Harrison
Sent: Mon 22/10/2012 22:27
To: User discussion about the Rivendell Radio Automation System
Subject: [RDD] OpenOB 2.3 release
2/10/2012 22:27
> To: User discussion about the Rivendell Radio Automation System
> Subject: [RDD] OpenOB 2.3 release
>
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> I know a few Rivendellers have used the earlier (beta) versions of
> OpenOB in the past so here's
ellaudio.org on behalf of James Harrison
Sent: Mon 22/10/2012 22:27
To: User discussion about the Rivendell Radio Automation System
Subject: [RDD] OpenOB 2.3 release
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I know a few Rivendellers have used the earlier (beta) versions of
OpenOB in the past so
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I know a few Rivendellers have used the earlier (beta) versions of
OpenOB in the past so here's a quick notice to all that OpenOB 2.3 is
out, with stable support for the Opus codec recently standarized by the
IETF, which supports bitrates as low as 1
39 matches
Mail list logo
