[redec]

I recently built a new kodi machine on a raspberry pi 4 - raspbian buster with Kodi 18.7 kernel v5.4.51-v7l+ and now when resuming after pause/skip/whatever I'll often get 5+ seconds of lost audio.  It's a brand new install with nothing fancy or extra, just a straight vanilla raspbian install with a straight vanilla kodi install on top.  It's quite annoying - because of this issue the wife wants me to go back to my old install, which did not have this issue (openelec Krypton on a pi 3b)...but I really don't want to do that.  It happens a lot on 6-channel DTS, I'm pretty sure it also happens on dolby, I'm not sure about others...I can dig into that more if it's relevant.  I've tried changing the "keep audio device allowed" and "audio passthrough" settings, but they don't seem to have any effect on the issue.  Here's a log of it happening a few times http://paste.ubuntu.com/p/TFyDwbjgQp/ ...there's a really good example at the resume at 2020-07-25 20:30:18.261...didn't get audio for ~8 seconds after unpause.

I've installed Unpause Jumpback as kind of a workaround for this issue, but it really doesn't make it any less aggravating.  Anyone have any ideas?  Thx.

[FXB78]

This has always happened to me using passthrough on OpenELEC, LibreELEC & now CoreELEC. I thought that was just the way it was. Did you have it setup for passthrough on OpenELEC? I've definitely experienced this using OpenELEC in the past.

[roliverosc]

It happens to me too and it is not happening only in raspi. My system have windows 10.

https://forum.kodi.tv/showthread.php?tid=355855

[heysoundude]

You know the old joke about the person who goes to the doctor, complaining that it hurts when they do "this", and the doctor tells them "so don't do that"?  that solution might not be what you're looking for, but I guarantee it works 
(my initial response -that I didn't type- was a lot less charitable)
there is a lag while syncing 6-8 audio tracks to the picture?  I'm sure you'd rather it muted than some of the alternatives:
The host machine is seeking the files/appropriate place(s) in the file(s), doing any conversion/de-compression, lining it all up and checking that it's lined up "in the background" BEFORE it opens up the audio output.  Perhaps you'd prefer to see the clock/wheel while that all happens; it would mean a delay after pressing play

what are your buffers set at?  they could possibly be too large. 
The repository the host is calling the files from may be too slow (is it more than 50-60% full?)
The network may be busy
All of these possibilities may be true/occurring, compounding the issue

Further - Pi4 is fairly new, so OS and app/dependencies may not yet be optimized for it...immature code. Pushing the envelope often means waiting for everyone on the team to catch up first.  There's a huge difference between just working and working well/correctly/properly.

I have high hopes for v19 of kodi.  I just saw a github notification of v18.8 being released in the past 24h.  that has to get tweaked for release by the various maintainers/devs of the various platforms - OSMC, xbian, LibreELEC...

[redec]

You know the old joke about the person who goes to the doctor, complaining that it hurts when they do "this", and the doctor tells them "so don't do that"?  that solution might not be what you're looking for, but I guarantee it works 
(my initial response -that I didn't type- was a lot less charitable)
there is a lag while syncing 6-8 audio tracks to the picture?  I'm sure you'd rather it muted than some of the alternatives:
The host machine is seeking the files/appropriate place(s) in the file(s), doing any conversion/de-compression, lining it all up and checking that it's lined up "in the background" BEFORE it opens up the audio output.  Perhaps you'd prefer to see the clock/wheel while that all happens; it would mean a delay after pressing play

what are your buffers set at?  they could possibly be too large. 
The repository the host is calling the files from may be too slow (is it more than 50-60% full?)
The network may be busy
All of these possibilities may be true/occurring, compounding the issue

Further - Pi4 is fairly new, so OS and app/dependencies may not yet be optimized for it...immature code. Pushing the envelope often means waiting for everyone on the team to catch up first.  There's a huge difference between just working and working well/correctly/properly.

I have high hopes for v19 of kodi.  I just saw a github notification of v18.8 being released in the past 24h.  that has to get tweaked for release by the various maintainers/devs of the various platforms - OSMC, xbian, LibreELEC...

Hahah, I can picture telling my wife to just stop using pause/skip - I'd have to pick my raspi out of the garbage.  But yeah I understand there's a bunch of tracks to sync up, but at the same time I have (or have had) >10 other media players in this same environment, playing the same content off the same backend, none have this problem.  Currently I even have 2 older kodi's running on slower hardware, with slower network connections which do not have this problem....so yeah, I'm hoping it's just something with the "new" platform which will eventually get patched/fixed.  I don't know about the buffers...they're set at whatever the default is, I'll maybe dig into that a bit to see if that makes any difference, thanks!

And yeah, actually, a spinner would be way better than the video playing with no audio.  I'll have to look to see if I can find an extension that maybe does that...probably a long shot, but hey...maybe

[heysoundude]

You know the old joke about the person who goes to the doctor, complaining that it hurts when they do "this", and the doctor tells them "so don't do that"?  that solution might not be what you're looking for, but I guarantee it works 
(my initial response -that I didn't type- was a lot less charitable)
there is a lag while syncing 6-8 audio tracks to the picture?  I'm sure you'd rather it muted than some of the alternatives:
The host machine is seeking the files/appropriate place(s) in the file(s), doing any conversion/de-compression, lining it all up and checking that it's lined up "in the background" BEFORE it opens up the audio output.  Perhaps you'd prefer to see the clock/wheel while that all happens; it would mean a delay after pressing play

what are your buffers set at?  they could possibly be too large. 
The repository the host is calling the files from may be too slow (is it more than 50-60% full?)
The network may be busy
All of these possibilities may be true/occurring, compounding the issue

Further - Pi4 is fairly new, so OS and app/dependencies may not yet be optimized for it...immature code. Pushing the envelope often means waiting for everyone on the team to catch up first.  There's a huge difference between just working and working well/correctly/properly.

I have high hopes for v19 of kodi.  I just saw a github notification of v18.8 being released in the past 24h.  that has to get tweaked for release by the various maintainers/devs of the various platforms - OSMC, xbian, LibreELEC...

Hahah, I can picture telling my wife to just stop using pause/skip - I'd have to pick my raspi out of the garbage.  But yeah I understand there's a bunch of tracks to sync up, but at the same time I have (or have had) >10 other media players in this same environment, playing the same content off the same backend, none have this problem.  Currently I even have 2 older kodi's running on slower hardware, with slower network connections which do not have this problem....so yeah, I'm hoping it's just something with the "new" platform which will eventually get patched/fixed.  I don't know about the buffers...they're set at whatever the default is, I'll maybe dig into that a bit to see if that makes any difference, thanks!

And yeah, actually, a spinner would be way better than the video playing with no audio.  I'll have to look to see if I can find an extension that maybe does that...probably a long shot, but hey...maybe

2 other kodis running on the same network with no issues strongly indicates a settings or software issue on this newest one...check/optimize configs on the new Pi first.  Took me a few days to get my head around that and straighten my settings/config out

[redec]

what are your buffers set at?  they could possibly be too large. 

Which buffers are you referring to specifically here?  I tried playing around with the <cache> buffer settings but they had no impact...they only affect the network buffer anyways tho which isn't the problem (since I have video the content has been successfully retrieved from the network).  It seems the ability to tweak any audio-specific buffers was removed way back in like v13.

[popcornmix]

Might be worth a test with a Kodi 19 build on a spare sdcard.
The audio drivers are completely different (driven by kernel driver on arm, rather than firmware driver).

[heysoundude]

what are your buffers set at?  they could possibly be too large. 

Which buffers are you referring to specifically here?  I tried playing around with the <cache> buffer settings but they had no impact...they only affect the network buffer anyways tho which isn't the problem (since I have video the content has been successfully retrieved from the network).  It seems the ability to tweak any audio-specific buffers was removed way back in like v13.

If memory serves correctly (and I'll have to rely on that since my system and I are fairly distant from each other at the moment), there were a few additions/modifications I needed to make in config.txt.  The bookmarks to the webpages I used as a guide are also at that location, so I can't help that way either.
warm up your google-fu and get down to it.  Then again, if one of the main devs of v19 is suggesting you give their recent work a shot, that may just prove to be the easiest/best solution
Good luck!  please keep us posted