Playback Video - sound stuttering after March 5th Update

Help and Support Raspberry Pi
1

Hello,

As mentioned yesterday evening on the main page of the blog dealing with the OSMC’s March 5th update, after updating osmc and reboot, I have experienced sound stuttering when playing several videos (the image is fine, just the sound that stops for a second or two, sometimes less, and then comes back) . I have tried to rollback to previous version of OSMC, and then the problem disappears and everything works flawlessly.

I am using a RPi2b.

The complete log : here
The media info : here

I really hope this help you find and correct the issue.
Cheers

2

Your advancedsettings.xml contains this:

  <memorysize>0</memorysize>  <!-- number of bytes used for buffering streams in memory
   When set to 0 the cache will be written to disk instead of RAM -->

Writing video (and audio) cache to the SD card will (a) be slow and (b) wear out the card.

Change it to something like this:

<memorysize>104857600</memorysize>

then reboot.

3

Thank you for the suggestion. But still got the same issue.

4

You’re using the MMAL player, which is the default. I’d recommend you try changing to the OMX player (Settings > Player Settings).

1 Like
5

I have a similar problem after the February update on a Pi2 where video files come are shared via NFS (declared in /etc/fstab).

Audio can go out-of-sync sometimes (I skip to go back in sync). This happens with MMAL player and I don’t reproduce it with OMX. Before the last update, this problem did not happen and as far as I know, only MMAL was enabled then.

1 Like
6

I too have noticed small audio hiccups since the feb update. Fstab nfs shares and relatively low bitrate content playback on my pi3. MMAL default is checked. Will try OMX.

7

Dillthedog, thanks for the second suggestion. I cannot test it right now, but will do a.s.a.p. and let you know how it goes with OMX.

But to be fair I’ve been using MMAL for 2 years, making all the monthly updates in between, and never had a single issue before last February’s update.

8

So I have both OMX and MMAL switched on in the video settings. To be honnest I don’t really understand what it means to have both selected at the same time, I would have expected them to be mutually exclusive. Can someone explain?

Nevertheless, no more sound issue on my quick test. I’ll try on more videos this week end to confirm.
Thank you dillthedog.

9

I’d recommend you switch off MMAL. I agree, it doesn’t (seem to) make sense to have both enabled at the same time. Perhaps someone more knowledgeable can explain if/when having both enabled would be useful.

10

During video playback, on-screen display of technical information can be obtained, including the current player. The default keyboard shortcut is letter ‘o’.

11

Still that doesn’t clarify the meaning of being able to select both of them at the same time in the OSMC video settings. If someone knowledgeable knows, please tell us…

12

With both OMX and MMAL selected it uses OMX as default and i believe switches to using MMAL for anything the OMX can’t play for example using a2dp alsa streaming it uses MMAL and so forth.

I always use OMX as there is no jutter when navigating through menus with video playing.

If i’m reading the comments in this pull request correctly it looks like they will be dropping OMX player from v19 onwards. It would be a pity as it is great lightweight all round player, unless by v19 videoplayer (mmal) will have improved a great deal and that it doesn’t affect navigation performance that OMX will no longer be needed.

13

Same problem here! Popped up with either the March or the February update, not sure if I got two months in one go or not. Also running rpi2b. Issue seems to be related to MMAL, here are a few lines from mine that popped up during the stuttering:

17:48:31.583 T:1926199808   DEBUG: CMMALRenderer::RenderUpdate - vsync 71311 (+6)
17:48:31.873 T:1926199808   DEBUG: CMMALRenderer::RenderUpdate - vsync 71322 (+2)
17:48:31.879 T:1895908096   DEBUG: ActiveAE::SyncStream pll:0.00000 (act:1.00000 lim:0.00000) rr:0.96235 threshold:0.020 error:-74.857761
17:48:32.240 T:1926199808   DEBUG: CMMALRenderer::RenderUpdate - vsync 71328 (+5)
17:48:32.243 T:1453323008   DEBUG: CMMALVideo::SetDropState - bDrop(1)
17:48:32.332 T:1453323008   DEBUG: CMMALVideo::SetDropState - bDrop(0)
17:48:32.334 T:1453323008   DEBUG: OutputPicture - dropped in output
17:48:32.892 T:1895908096   DEBUG: Previous line repeats 6 times.

My shares are mounted with sshfs. Stuttering lasts just a fraction of a second, and occurs roughly once per minute or so.

OMX player does remedy the issue, but since it does not support ALSA spdif passthrough, it is of no use to me. I’ve had to downgrade to a previous backup for now.

1 Like
14

@Ronnick @FafaOSMC @buckley

What Audio Output Device do you have configured?

1 Like
15

I’ve tried with both HDMI, and ALSA hifiberry digi. Both experience the same issue.
Also, I tried running the nightly builds as well, problem only seem to get worse (more often) in the latest as of last night.

16

You mean Kodi 18?
Also have you tried to play the file locally so we exclude the network as a culprit?

17

I’ll have to double check when I get home but the default HDMI output I think. OMX does seem to fix the micro audio dropouts at the moment.

18

This might be one for @popcornmix to look in to.

Can anyone post a small sample that can reliably reproduce the problem?
It would also be interesting to know if the problem occurs with local playback from a USB thumb drive.

Sam

19

I have run the file locally, and I can confirm the nfs share is not the culprit.

20

I have previously run the same file from my SD internally, and got micro stutters there as well. A quick test now from USB however was smooth, whilst SSHFS share was not. I ran both for ~3-4 minutes.

kodi.log

I’ve attached the log file from a fresh boot with two plays of my show “tvshow.mkv”. The first run was with the USB (no issue this time!), and the second run is from the network share. You can clearly see something happening around 14:44:14.530, where the error value farthest to the right starts peaking in the negative direction - this is where the stutter was noticeable.