[fritsch]

Are you sure the PLLs of this anthem cinema device are fully correct?

[steo86]

I have no openend a seperate thread regarding sox as resampler. So we don´t mix the Topics here.
This thread here should only handle the stuttering without resampling (sync Playback to display)

[steo86]

ok have to mention that the "Anthem Cinema device" is a virtual soundcard defined via asound.conf.
The audiostream will then passed to Shell-script, which will apply some room correction filters via brutefir and then pass the Signal to the Marian Card.

Sorry please help me what are PLLs and how can I define it?

Code:

pcm.anthemresamplecinema
{
     type file
     slave {
             pcm null
     }
     format "raw"
     file "| /etc/brutecfg/convolving.sh %c %b %r %f resample AnthemTC linearphase cinema"
     hint {
        show on
        description "AnthemTC Resampling Cinema"
    }
}

[fritsch]

I see that from your log :-) and that's why I asked.

If you use the NVIDIA HDMI for audio output, can you see the same issues?

[steo86]

ok tried over NVIDIA hdmi and there the problem doesnt exist:
https://pastebin.com/RZPH1KMe

Switched back to my virtual card and I will get the errors again.

Code:

13:30:43.581 T:140104039790336   DEBUG: CDVDClock::ErrorAdjust - CVideoPlayerAudio::OutputPacket - error:-28446.500682, adjusted:-41708.333333
13:30:45.607 T:140104039790336   DEBUG: CDVDClock::ErrorAdjust - CVideoPlayerAudio::OutputPacket - error:30185.650143, adjusted:41708.333333
13:31:59.207 T:140104039790336   DEBUG: CDVDClock::ErrorAdjust - CVideoPlayerAudio::OutputPacket - error:-28538.641195, adjusted:-41708.333333
13:32:00.231 T:140104039790336   DEBUG: CDVDClock::ErrorAdjust - CVideoPlayerAudio::OutputPacket - error:20055.278024, adjusted:41708.333333
13:32:32.935 T:140104039790336   DEBUG: CDVDClock::ErrorAdjust - CVideoPlayerAudio::OutputPacket - error:-29331.784765, adjusted:-41708.333333
13:32:34.962 T:140104039790336   DEBUG: CDVDClock::ErrorAdjust - CVideoPlayerAudio::OutputPacket - error:42085.263828, adjusted:41708.333333

https://pastebin.com/ZLMpnAQq

So whats the difference for kodi between this cards?

[fritsch]

Yeah - now you understand WHY we want a Debug Log?

[steo86]

yes of course! No problem for me to provide the logfile.

[fritsch]

The problem is as follows. The problem is: the soundcard you use, does clock differently than your vsync does. In short it means: 48 khz are not 48 khz. We can easily measure that with our internal hostcounter with much more accuracy. This sums up per packet and after a certain time, we correct. We could at least hope it is constant skew. Second is, you pipe the stuff into a convolution script, that does whatever it wants and eats whatever data it gets, it has its own buffers and therefore ALSA cannot reliably determin the delay, which is the reason kodi adjusts very frequently.

What does your convolution script do? How many buffers does it need? What are the ALSA delay values you receive? How exact are they?

Kodi measures all those things and compares with internal buffer processing and the result is: your side is off :-)

[steo86]

ok heres the convolving-script I am using (in real it´s bigger but to keep it simple I have now reduced it to the minimum). My asound.con I have already posted.
In general it´s just taking the input audio stream and passing it to brutefir. If mode "resample" is set it will first pass it to sox and then to brutefir.
In the brutefir-config file the real output-device ("plughw S8,0") is defined. Brutefir is running with 4096/16 partitions. There is no buffer defined (couldnt find a parameter in brutefir for that).
I found out that the "CDVDClock::ErrorAdjust - CVideoPlayerAudio::OutputPacket" erros will be less if disable resampling in the script and directly pass it to brutefir and skip sox.
But the error is still there even without resampling. I think it will occur about 3-5 times in two hours. So please ignore the sox part in the script and lets concentrate on the brutefir-part without sox.
So in general without sox it will just execute:

$BRUTEFIR_CMD > $BRUTEFIR_LOGFILE 2>&1

The brutefir_CMD will get generated (see script) depending on the input-stream and defined config in asound.conf
So for each situation I have a dedicated brutefir.conf-File.

So what can I do to completely remove the "CDVDClock::ErrorAdjust - CVideoPlayerAudio::OutputPacket" error?
Any improvment/suggestion?

Code:

#!/bin/sh
# convolving script

CHANNELS="$1"          # Number of channels of input stream.
BITS="$2"                  # Bitrate of input stream f.e. 16,24,32
RATE="$3"               # Sampling rate of input stream f.e. 44100,48000
TYPE="$4"           # Type for exaple FLOAT_LE, S24_LE etc.
MODE="$5"              # resample/noresample --> Resample to 192khz with Sox?
TARGETCURVE="$6"   # %CurveName% --> Define TargetCurve filters.
FILTERTYPE="$7"        # filter_tpye linearphase or minimum phase
LAYOUT="$8"               # Layout for example cinema/music

if [ "$MODE" = "resample" ]
then
    # SOX Variables
    SOX_OUTPUT_BITS="32"
    # Decoding format. possible values:
    # signed-integer, unsigned-integer, floating-point
    SOX_OUTPUT_FORMAT="floating-point"
    SOX_PARAMS="-v -I -b 99.7 -a"
    SOX_OUTPUTRATE="48000"
    BRUTERATE="$SOX_OUTPUTRATE"
else
    BRUTERATE="$RATE"
fi

# Brutefir Variables
BRUTEFIR_CONFIGFILE="/home/steffen/bruteconfig_"$TARGETCURVE"_"$BRUTERATE"_"$CHANNELS"_"$FILTERTYPE"_"$LAYOUT
BRUTEFIR_LOGFILE="/home/steffen/brutefir.log"

# sox resample command.
SOX_CMD="sox -q -t raw -c $CHANNELS -b $BITS -r $RATE -e floating-point - -t raw -b $SOX_OUTPUT_BITS -c $CHANNELS -e $SOX_OUTPUT_FORMAT - rate $SOX_PARAMS $SOX_OUTPUTRATE"

# brutefir command / -daemon?
BRUTEFIR_CMD="brutefir -nodefault $BRUTEFIR_CONFIGFILE"

# Execute sox/brutefir
if [ "$MODE" = "resample" ] && [ "$RATE" -ne "$SOX_OUTPUTRATE" ]
then
    $SOX_CMD|$BRUTEFIR_CMD > $BRUTEFIR_LOGFILE 2>&1
else
    $BRUTEFIR_CMD > $BRUTEFIR_LOGFILE 2>&1
fi;

[fritsch]

I'd build Kodi from scratch and change it to use sox directly.

[steo86]

ok. that sounds great. Do you know what to change in the source code?

[fritsch]

Yes.

[FernetMenta]

Yes.

[steo86]

ok. that means you know it but you are not interessted to do it?
I would do it but I don´t have the skills to do that.

[fritsch]

ok. that means you know it but you are not interessted to do it?
I would do it but I don´t have the skills to do that.

I answered to your question, which was: bool doYouKnowIt(); - the return value was true / yes.

Code:

From 20ba506289a42571658461e175e7f8f59c2927f6 Mon Sep 17 00:00:00 2001
From: fritsch <[email protected]>
Date: Sat, 29 Jul 2017 09:50:47 +0200
Subject: [PATCH] Resampler: Use soxr

---
xbmc/cores/AudioEngine/Engines/ActiveAE/ActiveAEResampleFFMPEG.cpp | 4 ++++
1 file changed, 4 insertions(+)

diff --git a/xbmc/cores/AudioEngine/Engines/ActiveAE/ActiveAEResampleFFMPEG.cpp b/xbmc/cores/AudioEngine/Engines/ActiveAE/ActiveAEResampleFFMPEG.cpp
index af5bf93..e23b895 100644
--- a/xbmc/cores/AudioEngine/Engines/ActiveAE/ActiveAEResampleFFMPEG.cpp
+++ b/xbmc/cores/AudioEngine/Engines/ActiveAE/ActiveAEResampleFFMPEG.cpp
@@ -74,6 +74,10 @@ bool CActiveAEResampleFFMPEG::Init(uint64_t dst_chan_layout, int dst_channels, i
     return false;
   }

+  // use soxr engine
+  if (av_opt_set_int(m_pContext, "resampler", SWR_ENGINE_SOXR, 0) >= 0)
+    CLog::Log(LOGDEBUG, "Setting SOXR resampler");
+
   if(quality == AE_QUALITY_HIGH)
   {
     av_opt_set_double(m_pContext, "cutoff", 1.0, 0);
--
2.7.4

That will silently be skipped if ffmpeg has no SOXR build in. ffmpeg will fallback to swr then. Above code sets it for everything (low, mid, high).

Edit: As I need to get the plane in two hours I won't be able to finally fix it before that. To run the above change, make sure to disable swr_set_compensation in the code above. As with soxr the fltp intermediate is not constructed automatically.