Login at Kodi Home

CiNcH · (This post was last modified: 2017-10-08, 12:11 by CiNcH.)

Is it somehow possible to monitor the frequency of the audio resampler in Live TV? I am experiencing constant fluctuations in audio frequency. It is very audible on constant tones.

There are no visible frame drops/skips and also respective counters are not increased. So I assume clocks not to be that much off.

Any ideas? How can I debug it?

I am on a Sony Android TV (6.0.1) with MediaTek MT5890 (with a rather poor dual core ARM Cortex A17 @1GHz).

Further information:

Quote:I am providing a video of the test that I did with constant tone. What I did was putting a constant tone sample on my local server and imported the URL as PVR channel so that I could more easily test the resampling.

Kodi PVR resampling audio fluctuation (The effect is not as pronounced in the video due to phone recording and several format conversions. But it can still easily be spotted.)

Whenever rr changes are > 0.001, it is clearly audible. And that happens quite a lot, not just in the beginning. It can also clearly be spotted on conventional TV, especially for music/melodies. Audio clearly gets distorted, sounding quite funny at times.

My conclusion from this is that the resampling is hardly feasible for Android TV AudioTrack with its latency.

CiNcH · 2017-04-08, 08:15

I actually know this from the DVBViewer on PC, where DirectSound adjusts frequency according to the live clock, which is based on the PCR. Cheap audio hardware (like onboard chips) would only adjust in steps of 160Hz.

On Sony Android TV it sounds much worse than on the PC though. I assume steps to be even bigger than 160Hz which will require frequent up/down adjustments.

FernetMenta · 2017-04-09, 14:30

player debug infos show rr (resample ratio)

CiNcH · 2017-04-09, 17:26

As it is hard for me to interpret those values, I created a short video and uploaded it to YouTube, see here. Probably you can help me.

Depending on the content, permanent up/down frequency adjuments are clearly audible and very annoying. What's the resolution of the resampler? Judging from what I am hearing, it must be adjusting in the area of several hundred Hertz.

FernetMenta · 2017-04-09, 18:55

Audio engine synchronises the audio stream to the clock. In order to do so it slightly adjusts rr to compensate sync error. The problem with Android is that AudioTrack api is crap. If the audio sink returns crappy values for buffer level, resampler may overcompensate.
The behaviour can be improved by some not too advanced modifications to the AudioTrack sink. But this is the job of the Androis maintainers.

**fritsch** · 2017-04-09, 20:43

See: https://www.dropbox.com/s/ngg5zd6ou65bbo...d.png?dl=0

The green one is what the API returns. The red one is what I made of it.

Curious on the "not too advanced modifications". One might also say: Implement a better integral part in the resampling adjustment part. The current algorithm is way too dependend on a perfect world :-)

**fritsch** · (This post was last modified: 2017-04-09, 22:00 by fritsch.)

Please give this one a try: http://jenkins.kodi.tv/job/Android-ARM/11471/ - here it is logged what the rr adjustment part uses to compute its results.

Edit: Build http://mirrors.kodi.tv/test-builds/andro...bi-v7a.apk (wait until mirror syncs, please).

FernetMenta · 2017-04-10, 07:57

(2017-04-09, 20:43)fritsch Wrote: See: https://www.dropbox.com/s/ngg5zd6ou65bbo...d.png?dl=0

The green one is what the API returns. The red one is what I made of it.

Curious on the "not too advanced modifications". One might also say: Implement a better integral part in the resampling adjustment part. The current algorithm is way too dependend on a perfect world :-)

You can't adjust parameter to the most crappy conditions caused by AT. Why should more accurate platforms suffer from the poor work done by AT implementations. The controller is made to compensate sync errors not something else.

**fritsch** · 2017-04-10, 08:39

We will see. Input is the error, proportional and integral do a summed compensation. If the PI is not adjusting well enough as input fluctuates a D is missing ...

CiNcH · 2017-04-10, 14:53

LOG

Please consider that the logging eats up quite some CPU time, sometimes too much for smooth video playback on the slow CPU. I think that this is mainly due to the integration with logcat. Can this somehow be disabled?

**fritsch** · (This post was last modified: 2017-04-10, 18:25 by fritsch.)

Thanks. The input values look far too good to cause a hearable mess. But what we can clearly see the P is acting quite volatile, while the (fixed after some time) I does not what it should do, e.g. compensate the last "mile".

CiNcH · 2017-04-10, 18:36

Quote:The input values look far too good to cause a hearable mess.

What are the fluctuations in Hertz? Can you determine that from the log?

**fritsch** · (This post was last modified: 2017-04-10, 18:50 by fritsch.)

No. The PI should get errors in timely aequidistant manne, unit seconds or Millie, time based. What you see in the log is the p and I part. ret is the resulting adjustment value.

**fritsch** · 2017-04-10, 20:14

After shortly checking with fernet, you see that the P is fluctuating - BUT - it is everything far lower than in a 5 ms range. Only the third decimal place is altered. I highly doubt that this is in anyway hearable.

As you made a recording already, can you do another one with the audio also recorded? That in combination with the log might bring us further.

Btw. keep off the PlayerDebug

CiNcH · (This post was last modified: 2017-04-11, 11:10 by CiNcH.)

I'll try my best. Currently experimenting with test patterns (constant tone). I can inject a TransportStream from a file via DVBViewer Recording Service. It will limit datarate based on the PCR. I am reading it via DVBViewer PVR Add-on which declares the stream as realtime within Kodi...