Playback Video - sound stuttering after March 5th Update

Is there a way to role back to the previous OSMC 2018.08-1 update? Will be there a solution to our problem or out of options?

I have a spare rp3 b+. Would it be a possible solution if I use the spare rpi with rasbian to run the transmission daemon with the HDD and share the media over smb or nfs. If so smb or nfs would be a better solution.

Thanks in advance!

We are still looking in to this.
You can install the previous kernel, but we can’t provide support for this.


Sounds good!

I have a spare rp3 b+. Would it be a possible solution if I use the spare rpi with rasbian to run the transmission daemon with the HDD and share the media over smb or nfs. If so smb or nfs would be a better solution?

Thank you!

Yes, would be possible and nfs on linux is always the better (more performant) solution

Personally, i am very happy with this latest release.
Finally I can watch my movie library without having to use an old kernel version :wink:.

Everything seems to be stable.

Thank you for your support.

1 Like

Just tried the latest update and obviously the problem is back as read it had to be rolled back. Will continue to run the older kernel for time being. As long as there is a work around, it is what it is. :slight_smile:

1 Like

Same here … By the way, I have HifiBerry DAC. Problem occurs also with HDMI sound, but just in case … it seems that some don’t have this issue. Wonder if it may be related to a HifiBerry installed?

Currently Kodi is unusable for me. I have installed kernel 4.9 again because the patched kernel 4.14 does not longer install (???). I consider trying libreELEC or so, though. If only few have this issue (with standard hardware …) it will probably very difficult to sort this out.


Sorry, but I must review my last evaluation.
In fact, there is still some “micro” sound stuttering.
And I say “micro” because it is very subtle.
But it still happens, but only when watching a movie and making a download with transmission at the same time.

In Opposition to previous kernel versions, when transmission stops downloading, the stuttering disappears (in previous versions, for stuttering to disappear we needed to reboot the system).

Downgrading kernel back to 4.9.29, fixes this too.

About logs:
Nothing to report during the video playback in journal.
But I’ve noticed the following in kodi.log:

18:41:32.237 T:1885336320 NOTICE: CAESinkPi:AddPackets Underrun (delay:0.00 frames:2400)


An additional update:

Yesterday I was waching a tvheadend tv program previoualy recorded in an external hdd.
at the same time, another program was being recorded by tvheadend.

Sound stuttering was present like once per minute.
When the recording endend, the playback stuttering stopped.
This happened with the current kernel version.

Downgrading kernel to 4.9.29 also fixed this.

Will the October release with new kernel and raspberry firmware improve this situation? I’m still on the February release due to the audio stuttering problem.

Try it. It should do.

That seems to have done the trick – thumbs up :+1:

1 Like

Good stuff.

It seems to be solved with the current (October 2018) kernel.

Thank you :blush:


Running a couple days now with no issues. Thank you for all your hard work.

I’ve used the October release since the upgrade, and in most cases it works fine. However, I’ve found a couple of TV recordings (HD) that give constantly crackling sound. I’m using the analogue audio output.

I’ve installed the February release on another (larger, but slower) SD-card, and on that release, there is no crackling in the sound.

In both cases, the video file is played back from an NFS server on the local network. The network has Gigabit switches.

Would a small extract from the video file help in diagnosing this problem?

Does “audio_pwm_mode=0” added to config.txt avoid this issue?

Sorry for the late reply; been busy and lost my extra SDHC micro card…

Bought a new card now and installed the latest release on it (2018-12), and the crackling is still present (working perfectly with the 2018-02 release). I’ve added the suggested audio_pwm_mode=0 setting and rebooted, and the crackling is gone.

This seems to be a working configuration again – thanks!

I’ll stay on this version and will report back if audio-problems appear.

Sorry to jump on the end of this thread. I am a very experienced OSMC user, recently had to install 2 more Rpi’s built the same as all the others. Using the latest release just a few days ago. All media is on a central NAS, MySQL for Libraries and there are 9 clients sharing it. 6 Rpi’s OSMC and 2 Fire TV Sticks running Kodi 1 Linux.

I have sound stuttering on the 2 new Rpi’s. Reading through this thread seemed to point to network issues. Have tried wifi connection, wired connection. Bypass any local switches and wired into the main switch (the one that the NAS is on) into the main switch. Nothing seems to make a difference.

I tried rebuilding the pi’s from scratch. These 2 seem to be noticeably slower than the previous ones. Menu refresh etc. They are Model B 3+ units.

Had previous items in the same network ports that worked fine no sound dropouts. All other clients work fine and are responsive and play media perfectly.

All units update automatically so should all be running latest versions. Is there a particular log file you need to look at. Excerpt below with full debugging enabled and component logging for audio I could not see anything obvious.

12:59:48.511 T:1330123520 DEBUG: GetMovieId (smb://USERNAME:PASSWORD@TWHGNAS/TV/Banshee/Season 2/Banshee.S02E06.SD.TV-Armies of One.mp4), query = select idMovie from movie where idFile=10596
12:59:48.527 T:1330123520 DEBUG: GetEpisodeId (smb://USERNAME:PASSWORD@TWHGNAS/TV/Banshee/Season 2/Banshee.S02E06.SD.TV-Armies of One.mp4), query = select idEpisode from episode where idFile=10596
12:59:48.569 T:1886384896 DEBUG: CAESinkPi:Drain delay:99ms now:0ms
12:59:48.569 T:1886384896 DEBUG: CAESinkPi:Deinitialize
12:59:48.570 T:1886384896 DEBUG: CAESinkPi:SetAudioProps hdmi_stream_channels 0 hdmi_channel_map 00000000
12:59:48.575 T:1886384896 DEBUG: COMXCoreComponent::Deinitialize : OMX.broadcom.audio_render handle 0x5cb4b4d8
12:59:48.576 T:1886384896 DEBUG: CActiveAESink::OpenSink - trying to open device PI:HDMI
12:59:48.576 T:1886384896 DEBUG: CAESinkPi:Initialize Format:24 Channels:2 Samplerate:48000 framesize:8 bufsize:19200 bytes/s=384000.00 dest=PI:HDMI
12:59:48.576 T:1886384896 DEBUG: CAESinkPi:SetAudioProps hdmi_stream_channels 0 hdmi_channel_map 00000008
12:59:48.577 T:1886384896 DEBUG: COMXCoreComponent::Initialize OMX.broadcom.audio_render input port 100 output port 100 m_handle 0x5cb4b4d8
12:59:48.578 T:1886384896 DEBUG: COMXCoreComponent::AllocInputBuffers component(OMX.broadcom.audio_render) - port(100), nBufferCountMin(1), nBufferCountActual(2), nBufferSize(19200), nBufferAlignmen(16)
12:59:48.579 T:1886384896 DEBUG: CActiveAESink::OpenSink - SinkPi Initialized:
12:59:48.579 T:1886384896 DEBUG: Output Device : HDMI
12:59:48.579 T:1886384896 DEBUG: Sample Rate : 48000
12:59:48.579 T:1886384896 DEBUG: Sample Format : AE_FMT_FLOATP
12:59:48.579 T:1886384896 DEBUG: Channel Count : 2
12:59:48.579 T:1886384896 DEBUG: Channel Layout: FL,FR
12:59:48.579 T:1886384896 DEBUG: Frames : 2400
12:59:48.579 T:1886384896 DEBUG: Frame Size : 8
12:59:48.582 T:1895908096 DEBUG: CActiveAE::ClearDiscardedBuffers - buffer pool deleted
12:59:48.587 T:1355289344 DEBUG: Previous line repeats 1 times.
12:59:48.587 T:1355289344 DEBUG: CVideoPlayer::HandleMessages - player started 1
12:59:48.587 T:1355289344 DEBUG: CVideoPlayer::SetCaching - caching state 3
12:59:48.587 T:1355289344 DEBUG: CDVDClock::SetSpeedAdjust - adjusted:0.000000
12:59:48.587 T:1355289344 DEBUG: CVideoPlayer::SetCaching - caching state 0
12:59:48.587 T:1355289344 DEBUG: CDVDClock::SetSpeedAdjust - adjusted:0.000000
12:59:48.588 T:1355289344 DEBUG: VideoPlayer::Sync - Audio - pts: 554090666.000000, cache: 261333.353067, totalcache: 500000.000000
12:59:48.588 T:1355289344 DEBUG: VideoPlayer::Sync - Video - pts: 553970083.000000, cache: 50000.000000, totalcache: 100000.000000
12:59:48.588 T:1403073280 DEBUG: CVideoPlayerAudio - CDVDMsg::GENERAL_RESYNC(553829332.646933)
12:59:48.588 T:1403073280 DEBUG: CDVDAudio::Resume - resume audio stream
12:59:48.588 T:1895908096 DEBUG: ActiveAE - start sync of audio stream
12:59:48.732 T:1895908096 DEBUG: ActiveAE::SyncStream - average error of -45.288418, start adjusting
12:59:48.732 T:1895908096 DEBUG: ActiveAE::SyncStream - average error -0.288418 below threshold of 30.000000
12:59:48.976 T:1411461888 DEBUG: CVideoPlayerVideo - CDVDMsg::GENERAL_RESYNC(553829332.646933)
12:59:49.738 T:1403073280 DEBUG: CDVDClock::ErrorAdjust - CVideoPlayerAudio::OutputPacket - error:-30246.947806, adjusted:-30246.947806
12:59:53.592 T:1411461888 DEBUG: CPullupCorrection: detected pattern of length 1: 41708.33, frameduration: 41708.333333
12:59:57.026 T:1925638656 INFO: CheckIdle - Closing session to (easy=0x6fd0c038, multi=0x5cb4f6c8)

While stuttering no error or other anomaly detected in the log.

Any help appreciated.

Current config.txt modified after reading through other posts maxing out the Freqs.



Does “audio_pwm_mode=0” added to config.txt avoid this issue?

well, it definitely solves the issue (rpi/3, Dec.18 update) by bringing another: very loud hissing. Any ideas?..