[bobo1on1]

It returns how much audio is buffered in the soundcard, so you can calculate when an audio packet will play, otherwise you can't keep correct a/v sync if the soundcard buffers a lot.

It should not be close to 0 after unpause, because that would mean a bunch of audio is dropped.

[TheSwissKnife]

It returns how much audio is buffered in the soundcard, so you can calculate when an audio packet will play, otherwise you can't keep correct a/v sync if the soundcard buffers a lot.

It should not be close to 0 after unpause, because that would mean a bunch of audio is dropped.

So a pause event can actually pause data already sent to soundcard? Well don't you hear missing sound data when doing pause/un-pause, because I do?

[bobo1on1]

It depends on the soundcard as far as I know, some cards can pause playback, others can't, then on resume we send some zero bytes to prefill the buffers.

[TheSwissKnife]

It depends on the soundcard as far as I know, some cards can pause playback, others can't, then on resume we send some zero bytes to prefill the buffers.

ok I will assume mine is of the non-pause variety then...not that it really matters as long as I know that GetDelay() is to be trusted.

[TheSwissKnife]

I have a reasonable working solution for this now (ie keeping audio/video sync after speed change event without using audio clock discontinuity, having a stable and more accurate a/v sync info value, and using interpolated clock)...but I would like to improve it further.

I seem to get issues with seeks (which I also get with trunk untouched but the clock discontinuity code resolves)...so now I need to find where /why the seek is often completely wrong (ie video and audio don't match by a large margin). I also get the buffering... message intermittently after seek and don't yet know what is the root cause of that either.

I would also like to improve the sync to partial audio packets for AC3 (32ms) - the question there is, is it possible to insert shorter than frame duration fillers (silences) to reposition the audio to closer than +/-16ms?

Finally (for now) I need to ascertain what causes these nasty ALSA broken pipe errors that return from GetDelay() and GetSpace() (related to buffer levels after seeks).

As always, any pointers much appreciated.


EDIT: and I also intermittently see the WaitMSec call in video ref clock ::Wait take much longer (eg extra 50ms) than the number of milliseconds passed to it (ie when the vblank is also missed). What can cause this to occur? Would it be better to just use a 1 ms sleep loop?

[TheSwissKnife]

The statters caused by intermittent system delays are showing up in vmstat as with "blocks in" and "wait" being non-zero, when generally they are zero throughout (though not always), but it is clear that these two values change in these cases. I don't yet know what is the root cause as nothing other than xbmc playing is supposed to be happening on the system. Here the vmstat lines that seems to correspond to the xbmc freeze events (over the course or more than 2 hours with almost no other lines where both bi and wa non-zero).

Code:

procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa
...
0  2    804  56608   5876 1749244    0    0     4  4968 4717 7766 12  6 80  2
...
1  0    804  89628   7876 1714296    0    0     4  5848 4150 6470 10  7 81  2

...
2  0    804  56160   7344 1733080    0    0     4  5880 4799 7429 10  7 76  6

I don't seem to see these events without xbmc running, and I have tried putting /usr/lib/xbmc/ all in ramfs so I think I can be sure it isn't anything in the main program...so possibly one of the libraries?

[bobo1on1]

Check if you have anything in dmesg when that happens.

[TheSwissKnife]

Check if you have anything in dmesg when that happens.

Already checked that - and nada. It is quite possibly some unpleasant behaviour from writing to the filesystem (ie logging) and the resulting pressure that places on VM system...I will look into that first anyway.

..just got to work out why debug appears permanently enabled in trunk regardless of loglevel setting...

[bobo1on1]

Debug logging is always enabled for a debug build.

[TheSwissKnife]

Debug logging is always enabled for a debug build.

Is there no way to disable it without recompiling without debug or changing m_logLevel ?

For now I have simply adjusted xbmc.cpp to keep the loglevel at default with debug build.

[TheSwissKnife]

Well it does seem to be simply the result of the extra logging - at unpredictable intervals the system becomes unresponsive due to paging. Now I will get back to my discontinuity tweaks - seems like ages now since xmas so I need to remember exactly where I was...

I know I had adjusted the code so that after any speed change event I first get the current video frame to be well positioned (with respect to vblank) then I set the dvd clock to a preferred start point (half a frame off current video pts) then I had the audio doing drop/dupe/silence for the first few packets to bring it in sync with dvd clock, and only after that do I let the clock discontinuity code kick in if it is still required (which it typically isn't). This I thinks works well to ensure that video does not stutter. And I have added counters for audio drop and dupe, and clock discontinuity count, and video drop and dupe inside renderer...I think subtitle startup was causing issues, and ff/rw still very erratic...will report back soon

[TheSwissKnife]

I have started with the subtitle issue. What I see so far is the first subtitle to be rendered takes around 100ms in the code CGUIWindowFullScreen::RenderTTFSubtitles, specifically in the call to RenderOutline(). This creates a stutter as this ties up the application (render) thread.

Would it be possible to generate a fake and preferably invisible subtitle at start of play to get whatever is required instantiated? Maybe a whole blank video frame with a black subtitle should be rendered before playback?

[Buckster]

I upgraded from my 9400m on-board (Ion) to a 5670 last night, and the movement is noticeably smoother - YMMV

I always seemed to get occasional micro stutters with the on-board, and also horizontal pans weren't kind to the verticals (which seemed to lag - is prob best word)

PQ is improved with the 5670 too

and its woring perfectly with XBMC and DXVA2

[ezechiel1917]

I have started with the subtitle issue. What I see so far is the first subtitle to be rendered takes around 100ms in the code CGUIWindowFullScreen::RenderTTFSubtitles, specifically in the call to RenderOutline(). This creates a stutter as this ties up the application (render) thread.

Would it be possible to generate a fake and preferably invisible subtitle at start of play to get whatever is required instantiated? Maybe a whole blank video frame with a black subtitle should be rendered before playback?

I'm having also similar problem. xbmc-live dharma @ ion2. I watch movies with Czech subtitles, there is lot of accented characters used. There is a regular video stutter when subtitles first appear, then another one when first bold/italics subtitles appear. Plus sometimes I have a feeling there is a also stutter when there are lot of new (previously not rendered) accented characters.

I remember definitely not having this problem few months ago.
Can this be solved somehow please? It's becoming really annoying.

[Will_away]

Hey. I'm having identical problem when i'm watching movies with polish subtitles. In Xbmc 9.11 there were no problems with that.


Regards,
Will_away