Kodi Community Forum

Full Version: Audio glitch on pause when bitstreaming DTS/DD over S/PDIF
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2 3 4 5
First off, thanks for the work that has been done on VAAPI VC-1 acceleration in the latest builds! The segfaults are now gone. Also, XBMC is now finally running at ~23.976Hz (so goodbye to skipped frames/occasional judder).

However, there is an issue which has been consistent with the recent builds in the Fernetmenta-Master branch (latest build tested: 14.0~git20140402.0500-7783cfd): a ~0.5-1 sec audio glitch (like a 'pop', sometimes more than one) occurs every time a stream is paused when bitstreaming the audio over S/PDIF. If XBMC is re-encoding the stream (i.e, when using FLAC5.1 over S/PDIF, converted to a DD 640kbps stream), it works fine. But for all standard 'unprocessed' DTS5.1 (DTS core) or Dolby Digital 5.1 streams a brief pop/'stutter' occurs, as if to clear the audio buffer. When reverting to an older build (pre-14), the audio is handled correctly. It seems this might be caused by the new functionality which keeps the sink alive?

I am not running PulseAudio, btw. Debug log is here: http://pastebin.com/hUenXzE7
Re-ran the test with the latest FernetMenta-Master build from Apr 6th.

Debug log is here (tried to trim off as much as I could, left details about the system in the header though + other info I thought might be useful):
Forgot the version string, it was 14.0~git20140406.0501-1fb475d.

All acceleration (VAAPI) is disabled during this test, and the audio (& video) is perfect apart from the 1/2 sec. stutter when pausing. There are no (visible) dropped frames or audio dropouts/distortions apart from this (I watched the whole movie in full to make sure ~2h45m)

The stutter is reproducible each time, and only occurs with the newer 14-alpha1 builds. When changing the audio device keepalive settings to off (from 1 min), the audio artifacts are worse, which was why I initially suspected this as being the culprit.

I also notice that the audio sync delay has to be changed with ActiveAE (seem to remember seeing something about this as well). Normally I'd use a 175ms delay, but it is not needed for DTS streams with Gotham. FLAC 5.1 streams, however, need the 175ms delay set.
(On Frodo the 175ms setting worked for all media (DD TrueHD, DTS HD MA + PCM / FLAC etc.)
Quote:The stutter is reproducible each time, and only occurs with the newer 14-alpha1 builds. When changing the audio device keepalive settings to off (from 1 min), the audio artifacts are worse, which was why I initially suspected this as being the culprit.

Ah! Btw. if you pause, do you do something else? e.g. switching to another window? e.g. xbmc looses focus?

Edit: Can you do one without fast forward please?
Edit2: 22:00:06 T:140393128163200 WARNING: CSettingsManager: unable to read value of setting "audiooutput.streamsilence"

Did you run "make install"? It seems your local files are out of date.
I see a lot of vblanks missed (driver?) and also disconts before that - are you sure the machine is fast enough to playback 1080p on one core without vaapi?
The machine is fast enough–guaranteed. There are no playback issues. I saw the discontinuity messages as well. XBMC only uses ~25-30% CPU when running w/o acceleration on this i3-3225. Again, I watched the whole movie in full without having dropped frames/judder/sync issues. It was perfect 23.97Hz throughout. No skips in video, audio or other a/v glitches. And believe me, I am _extremely_ susceptible to jerky video or other things having an impact on viewing.

The reason for the fast-forward was simply because XBMC did not do forward chapter skips unless one skipped to the beginning first.

The stream was re-started from the beginning and skipped a couple of chapters into the feature in order to do a more proper test (audio is silent during the beginning)

Regarding the local files: where should I run the make install? XBMC was installed via .deb from @wsnipex' repo. btw. I saw the audiooutput.streamsilence message too, hopefully the problem is related to this.
can you try with a fresh guisettings.xml?
You mean delete it, and it gets auto-generated the next time XBMC starts? (Or if not, where do I find a minimal guisettings.xml?)
As you seem capable to compile, then try to bisect. The offending commit needs to be found. You can bisect start before fernet's rebases on top and then make your way until head.

Curious what will be coming out: http://git-scm.com/book/en/Git-Tools-Debugging-with-Git
Yes, deleting it will recreate on startup with default settings. All settings will be reset.
@Kib, thanks, I'll try that later today then.

@fritsch, I can certainly compile, and also try to bisect with git. However, I've not done the latter before so I would need some pointers (where to start, what to look for), etc. (I did look at the provided link)
Also, regarding your previous comment about window focus -- XBMC is always focused on the second display (HDMI2). Nothing special happens when it gets paused.
Then again, the issue is not apparent when XBMC is processing/re-encoding the stream (i.e, Dolby TrueHD or FLAC5.1 streams), only when using passthrough.
Please post a short video of what you see and hear when pressing pause. The title of this thread is already confusing. How does audio manage it to stutter when being paused? I am sure that everybody reading this has a different interpretation of this issue.
Maybe 'stutter' is not the best word to describe it. There is a slight audio glitch (like a pop, one or more) when the stream is paused, as if to clear a buffer. When outputting the audio (uninterrupted), the audio is ok. The audio is also ok when resuming the movie (i.e, it does not have a similar 'pop' when it starts back up again.)
I'll try to see if I can capture this later today.
There is no difference in how AE handles passthrough an pcm when the stream is paused. Maybe some receivers like yours have problems in receiving an incomplete packet which is the case when we flush the engine on pause.
Sounds pretty much exactly like what is happening. Although I've never had issues with any other sources on this receiver-ranging from cable set-top boxes, PS3s, various DVD and Blu-Ray players, etc.–nor previous versions of XBMC running on Linux or OSX.

But there has to be a difference in how ActiveAE handles incomplete packets when doing transcoding of FLAC5.1 or TrueHD; as these streams (when converted into Dolby Digital 640kbps) do not have an issue when pausing the stream.

What about making sure an incomplete packet isn't sent for encoded formats like DTS & Dolby ? (i.e, mimic the behaviour of the 'old' audio engine, pre-Gotham?)
Pages: 1 2 3 4 5