Re: [RDD] Carts take 5 seconds to start in Main log

[Lorne Tyndale]

Hi,

Is this only with ALSA, or have you also seen the same issue if you are
running audio through Jack?

Just wondering, I have not seen this issue myself.

I have run into issues with Apache taking time if for some reason
reverse DNS lookups are turned on.  Check your apache configuration and
maybe try adding:

HostnameLookups Off

Normally this should not be an issue as newer builds of apache default
to host name lookup being off, but if for some reason it is on this
could cause issues.

Also, make sure you've got a static IP address and set up your hosts
file with that IP and your host name.

Is /var/snd on a network share? Is it possible that there is latency on
that share?  This could cause delays in starting to play audio too.

Lorne Tyndale


> 
> 
> Hi Rich
> 
> Le 30/11/2020 à 17:22, Rich Gattie a écrit :
> > Greetings list..
> >
> > I just upgraded the machine I have been running 2.x on to the latest 
> > v3 of Rivendell. After an annoying issue with the NIC and driver no 
> > longer in the distro of CentOS 7, I got the machine up and running as 
> > it was before with one small exception.
> >
> > While testing the main log, (I use Aux Log 1 for a 24/7 stream), I add 
> > a cart, hit START, then it takes about 5 seconds to start playing. 
> > Segues go smoothly between carts, no delay.
> > There was no issue like this with 2.19.x, and no hardware changes have 
> > been made to the machine.
> 
> I've also hard time migrating a machine from 2.X to 3.X. My primary 
> tests on my dev machine were just fine, but when I tried on the target 
> machine, the CPU load was huge, and any operation took tens on 
> seconds... It looks like your issue.
> 
> I've spotted caed taking 100% of a core, on the target machine, compared 
> to ~30% of a core on my dev machine. The memory was fine, IOs were quiet 
> too. Since then, I'm digging into the source code of caed (mostly in 
> cae_alsa.cpp) to try to understand where CPU cycles are vanishing. Using 
> valgrind profiler, the mostly called function is AlsaPlayCallback, but 
> this is quite obvious and not giving so many clues on what is time 
> consuming in there.
> 
> Maybe you could verify you CPU load with the "top" oh "htop" commands in 
> a terminal in order to see if it points to caed also. What type of CPU 
> are you using ?
> 
> Until I find a solution to keep caed CPU consumption low on my atom 
> machines, I was forced to use a bigger one instead (any old Intel 
> Core-i3 I has were just perfect)
> 
> If anyone has an idea on why caed is taking so much on the CPU... I've 
> tried not to run rdvairplayd but it had no effect
> 
> Best regards
> 
> Florent
> 
> ___
> Rivendell-dev mailing list
> Rivendell-dev@lists.rivendellaudio.org
> http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev
___
Rivendell-dev mailing list
Rivendell-dev@lists.rivendellaudio.org
http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev

Re: [RDD] Touchscreen Monitor

[Florent Peyraud]

Hello

Le 23/11/2020 à 00:49, wa7skg a écrit :
Is anybody using touchscreens with Rivendell? Does it work well? Are 
there any economical touchscreens available these days? Is it really 
worth the extra expense? How is the touchscreen connection handled? 
They used to be via VGA and a serial port, but nothing has serial 
ports anymore. Is it via HDMI and USB?


I confirm VGA/DVI/HDMI + USB for the touch feedback

I used to propose touch screens with rivendell installations, but most 
of the time, it remained unused by people buying it. They prefer 
keyboard and mouse which are less prone to false pointing.


Worse : a customer called me once complaining about rdairplay switching 
to manual mode frequently, and mostly during weekends. After serarching 
the logs and all, there was no clue of any bug or crash. Then I 
remembered the type of touch screen they choose : it was an optical one 
with laser beams coming from screen corners and reflecting on screen 
sides. The good thing with them : they work when wearing gloves, so they 
are widely found in military vehicles. The bad thing : even a fly can 
trigger clicks...


I advised my customer to unplug USB from the screen and rdairplay never 
switched to manual mode "by itself" !


Touch screens remain useful when using rdairplay daily with sound panel.

Cheers

Florent

___
Rivendell-dev mailing list
Rivendell-dev@lists.rivendellaudio.org
http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev

Re: [RDD] Virtual Logs

[drew Roberts]

Lorne,

I decided to play with this today and got my first log loaded, playing, and
sound output streamed to icecast and heard on another machine running vlc!

Fantastic!

all the best,

drew

On Mon, Nov 23, 2020 at 11:47 AM Lorne Tyndale 
wrote:

> Drew,
>
> From reading the little bit of documentation on virtual logs that I can
> find, here is what I've been able to figure out:
>
> -For virtual logs to work, rdvairplayd needs to be running.  It normally
> is running/started as a part of the Rivendell service, but in my case
> for some reason it wasn't running.  Restarting the service fixed the
> issue for me.
>
> -Virtual logs are all controlled entirely by macros.  Any of the macros
> that have to do with controlling a log, for the machine number if you
> put in the number of the virtual log you want to manipulate, it works.
> For example, to load a log into virtual log 103 you'd use RML: LL 103
> [logname] [startline]!
>
> -In rdadmin --> Manage Hosts --> RDAirplay you can set the audio card
> output, startup control mode (automatic, manual, live assist), and
> whether you want a virtual log to start with a log loaded or not
>
> -Pypad instances can also handle virtual log data, see one of the pypad
> setups for examples
>
> -Unless I'm missing something, there does not seem to be a way to
> actually "see" on the screen an output of what the virtual log is doing
> as far as playout, the location in the log being played, or manipulate
> the log as you can with the Main or Aux 1 and 2 logs in RDAirplay.  It
> all has to be done with with macros.
>
> Virtual logs are definitely a neat feature - I can see a great benefit
> if you want to build a log in rdlogmanager or rdlogedit and then just
> let it play without any user interaction with it.  I could see it being
> useful if you're trying to run multiple unattended audio streams or
> something like that.
>
> Lorne Tyndale
>
>
> >
> >
> > Lorne,
> >
> > have you found some documentation that explains how this is supposed to
> > work? I would like to start playing/experimenting with the virtual log
> > stuff. Last time I looked, I could not find anything or get anything to
> > work.
> >
> > all the best,
> >
> > drew
> >
> > On Mon, Nov 23, 2020 at 1:36 AM Lorne Tyndale 
> > wrote:
> >
> > > Hi,
> > >
> > > Figured it out. For some reason my rdvairplayd had not started
> properly.
> > >  After I restarted my services the virtual logs and macros below
> started
> > > working.
> > >
> > > Lorne Tyndale
> > >
> > >
> > > >
> > > > Hi,
> > > >
> > > > I'm trying to figure out how virtual logs work, and running into some
> > > issues.
> > > >
> > > > I've set up a macro that is:
> > > >
> > > > LL 101 W_11_22_2020 -2!
> > > >
> > > >
> > > > I'd thought this would load a log into the virtual log 101 and start
> to
> > > play the first entry, but it doesn't seem to do anything, I don't get
> any
> > > audio.
> > > >
> > > > The same exact macro replacing the "101" with "1", "2", or "3" works
> -
> > > loads that log into the main or aux log in rdairplay and starts the
> playout.
> > > >
> > > > I tried doing a:
> > > > PN 101!
> > > >
> > > > macro after the LL command above and that did not work either.
> > > >
> > > > I also tried other virtual log machines, 102 and 103, but those did
> not
> > > work
> > > >
> > > > What am I missing?
> > > >
> > > > Lorne Tyndale
> > > ___
> > > Rivendell-dev mailing list
> > > Rivendell-dev@lists.rivendellaudio.org
> > > http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev
> > >
> >
> >
> > --
> > Enjoy the *Paradise Island Cam* playing
> > *Bahamian Or Nuttin* - https://www.paradiseislandcam.com/
>


-- 
Enjoy the *Paradise Island Cam* playing
*Bahamian Or Nuttin* - https://www.paradiseislandcam.com/
___
Rivendell-dev mailing list
Rivendell-dev@lists.rivendellaudio.org
http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev

Re: [RDD] Carts take 5 seconds to start in Main log

[Florent Peyraud]

Hi Rich

Le 30/11/2020 à 17:22, Rich Gattie a écrit :

Greetings list..

I just upgraded the machine I have been running 2.x on to the latest 
v3 of Rivendell. After an annoying issue with the NIC and driver no 
longer in the distro of CentOS 7, I got the machine up and running as 
it was before with one small exception.


While testing the main log, (I use Aux Log 1 for a 24/7 stream), I add 
a cart, hit START, then it takes about 5 seconds to start playing. 
Segues go smoothly between carts, no delay.
There was no issue like this with 2.19.x, and no hardware changes have 
been made to the machine.


I've also hard time migrating a machine from 2.X to 3.X. My primary 
tests on my dev machine were just fine, but when I tried on the target 
machine, the CPU load was huge, and any operation took tens on 
seconds... It looks like your issue.


I've spotted caed taking 100% of a core, on the target machine, compared 
to ~30% of a core on my dev machine. The memory was fine, IOs were quiet 
too. Since then, I'm digging into the source code of caed (mostly in 
cae_alsa.cpp) to try to understand where CPU cycles are vanishing. Using 
valgrind profiler, the mostly called function is AlsaPlayCallback, but 
this is quite obvious and not giving so many clues on what is time 
consuming in there.


Maybe you could verify you CPU load with the "top" oh "htop" commands in 
a terminal in order to see if it points to caed also. What type of CPU 
are you using ?


Until I find a solution to keep caed CPU consumption low on my atom 
machines, I was forced to use a bigger one instead (any old Intel 
Core-i3 I has were just perfect)


If anyone has an idea on why caed is taking so much on the CPU... I've 
tried not to run rdvairplayd but it had no effect


Best regards

Florent

___
Rivendell-dev mailing list
Rivendell-dev@lists.rivendellaudio.org
http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev

Re: [RDD] Rivendell-dev Digest, Vol 92, Issue 2

[Alan Peterson]

Gents, pardon me for asking; but I'm basically a glorified button-pusher
and not a programmer, and I am just curious to know.

Is there a distinct advantage to running RD on Ubuntu rather than CentOS?

AP
___
Rivendell-dev mailing list
Rivendell-dev@lists.rivendellaudio.org
http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev

Re: [RDD] Rivendell Future

[Florent Peyraud]

Hi Fred

Le 01/12/2020 à 17:11, Fred Gleason a écrit :



On Nov 30, 2020, at 14:12, Florent Peyraud > wrote:


As the packages are functional, but may require some more tuning to 
be considered as stable, they are in the UNRELEASED distribution.


In order to install a working instance, the procedure is :

wget -q -O -https://apt.rivendell-fr.org/release.asc  | sudo apt-key add -
echo "deb [ arch=amd64 ]https://apt.rivendell-fr.org/  UNRELEASED main"|sudo 
tee /etc/apt/sources.list.d/rivendell-fr.list
sudo apt-get update
sudo apt-get install mariadb-server
sudo apt-get install rivendell rivendell-server
This looks really cool. Is there a web page somewhere that contains 
this information? I’m thinking a link on the Rivendell wiki would be 
in order. (I could also simply put all this info into the wiki, but 
then we’ve potential issues with bit-rot when things inevitably change).
There is no such page as for today. I'll do it today or tomorrow and let 
you know, or even change the wiki by myself.



Any feedback is welcome to help releasing the official package ! The 
current version is 3.4.1int0. but the 3.4.1int5 is ready and I've a 
working process to package upstream releases quite fast, so I'll try 
to keep as close to latest release as possible.


FYI: those ‘int’ versions are interim test builds. By all means 
package them, but be aware that they shouldn’t be put into a ‘stable’ 
update stream as they have not been fully tested and could hence hand 
out unpleasant surprises on-air.


Thanks for the advice. I'm looking forward seeing a new stable tag on 
the github repo ;)


Cheers

Florent


___
Rivendell-dev mailing list
Rivendell-dev@lists.rivendellaudio.org
http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev

Re: [RDD] Rivendell Future

[Florent Peyraud]

Hi Rob

Le 03/12/2020 à 03:56, Rob Landry a écrit :

On Mon, 30 Nov 2020, Florent Peyraud wrote:


Some packages are not available anymore on Ubuntu 20.04.


That troubles me. Since Ubuntu is built on Debian Unstable, that means 
that we are probably no more than two Debian releases away from a time 
when it will no longer be possible to build Rivendell under Debian.


Debian used to be my platform of choice for Rivendell, but lately I've 
been using the CentOS installers. The one recent occasion I had to 
build Rivendell on Debian was on a Raspberry Pi 4, as an experiment. 
Rivendell 2.x would not compile, and while I did get Rivendell 3.x 
installed and running, the process was more complicated and there are 
a lot of new dependencies.


Do I understand correctly that just months after Fred completed the 
long process of porting Rivendell to Qt4, Ubuntu has dropped Qt4?


This is the case :(

Qt4 has been officially dropped in Ubuntu 20.04 LTS in order to 
"encourage" (understand "to force") developers to migrate to Qt6 [1][2]. 
Some PPA exist to install it anyway, but may conflict with some other 
packages. As I wanted to have a stable and maintainable platform with as 
few as possible hacks overriding obsolete packages, I sticked to Ubuntu 
18.04 which will be supported until 2028 (extended LTS). This should let 
us (well.. read "Fred Gleason" ;) ) the time to work on Qt6 migration 
before EoL of 18.04.


Nevertheless, there are also other packages missing, like libmp4v2 IIRC, 
maybe some more... As I needed a solution to upgrade my former customers 
still running 2.10.4 in a country where accentuated characters are so 
common, I focused on a stable transitional solution choosing 18.04. But 
I look forward migrating to 20.04+ ASAP !


Best regards

Florent

[1] 
https://www.phoronix.com/scan.php?page=news_item&px=Ubuntu-20.04-LTS-No-Qt4


[2] https://lists.ubuntu.com/archives/ubuntu-release/2019-August/004800.html

___
Rivendell-dev mailing list
Rivendell-dev@lists.rivendellaudio.org
http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev