BUG RDAirPlay sometimes chops off the end of carts during a segue

[vizubeat]

v4.1.0: Occasionally I hear the end of carts being chopped off too early during a segue from Cart A to Cart B - as if the segue point on a cut within Cart A has been set too early. However on checking the segue point, it's in the correct place. Queueing up Cart A and Cart B and letting them play naturally will sometimes produce the same 'early finish' of Cart A, sometimes it will play as expected. Difficult to reliably reproduce, but others have reported the issue in the Rivendell Facebook group: https://www.facebook.com/groups/1739406449620107

[dklann]

Experiencing this on Rivendell 4.1.0 also. Configuration:

• single Rivendell workstation
• local database
• local audio file storage (in /var/snd)
• audio via ALSA (not JACK)
• audio adapter: Focusrite Scarlett 4i4 (USB), also the on-board audio device on Intel-based motherboard

I thought it might be related to the Manual Segue and Forced Segue and Default Trans. Type settings in RDAdmin > Manage Hosts > hostname > RDAirPlay, but tweaking, and disabling (setting values to Zero) did not affect the behavior.

[alexolivan]

I Noticed that already quite time ago in my testing VM (Debian bullseye, bleeding edge snapshot packaging), Although I'm using jackd all the time. So quite an 'unorthodox' testing platform.

I noticed that, not only segues behave oddly, but also that the overall internal audio routing/mixing engine behaves oddly in general (at least at jackd level): audio leaks, low or wrong levels... my thought is that, if segueing is achieved by the usage of that same 'internal mixing/routing' engine, odd segueing could be expected. My guess is that, for ASI card driven systems (ASI cards are just awesome), where rivendel may use the ASI internal PCM mixing/routing engine to handle the audio, this problems may be completelly unnoticed.

I see that Fred is working in a caed rework branch, so probably he's very aware of something amiss there :-)

Cheers!

[lowlevelm]

Experiencing the same issue upon testing rd4.1. Rocky Linux 8, running inside a proxmox vm, jack, stereotool, and glasscoder. So far this is the only issue I have found in rd4 👍

[ElvishArtisan]

Confirmed here, and fixed in c9953bf. Everyone is encouraged test this as throughly as possible as the fix involves some fairly fundamental changes to the CAE command channel.

[dklann]

First couple of log transitions ("play" and "segue") working as expected here with c9953bf. Continuing testing ...

[alexolivan]

At first glance, what I've noticed is that my hourly GTS pips (played from RDCatch events) do play out at correct level again... so definitely something changed for good. I've only listened to a few segues but they were not enough long mixes to notice how well it mixes two songs. However, no chops, spikes or weird things.

I'm gonna have a listen for a while this morning to be sure...but probably it is fixed.

EDIT: being a while listening for segues and I heard no longer weird mixes.

[ElvishArtisan]

I'm going to close this for now. Please feel free to repon if testing turns up anything wonky.

[vizubeat]

I'm afraid I'm still seeing this on a fresh installation of 4.1.2 on Jammy (with imported database and audio).

Just heard it on the segue between a dry sponsor tag and music - the last 0.5s of the sponsor tag was chopped off. This meant the sponsor tag's words "musical events" became "musical ev", and it sounds very clunky.

Re-cueued the same cars three times with no issue, the glitch / early finish happened again on the fourth re-cue.

I adjusted the segue marker for the sponsor tag and re-saved, but the same problem appears.

I'm happy to send over any other information you might find useful, just let me know. But nothing seen in the logs so far.

Thanks.