Grok provides a few clues - and perhaps not all of them are pure nonsense:
Diagnose via Logs and ALSA Status (Quick Root Cause Identification):
- Run dmesg | grep -iE 'snd|alsa|audio|codec|i2s|underrun|overrun|error' and check your Kodi log (grep -i audio elegant-marmot.log).
- Enable xrun debug: echo 1 > /proc/asound/card0/pcm0p/xrun_debug, play audio, then cat /proc/asound/card0/pcm0p/xrun_debug to confirm underruns (common for periodic glitches).
- Test basic playback: speaker-test -c2 -r48000 -fS16_LE -Dhw:0,0—note if glitches align with 4s intervals or CPU spikes (top in parallel).
- Verify and Adjust ALSA Devices/Volumes (Fix Mismatches):
- List devices: aplay -l (ensure your Slice card shows up).
- Use alsamixer -c0 to unmute/adjust volumes (e.g., DAC controls); test formats/rates with speaker-test variants (e.g., -r44100 if 48kHz distorts).
- In Kodi settings: Set audio device to "ALSA: hw:0,0" and disable passthrough if enabled.
- Tweak Boot Config and Reload Driver (Address Hardware/Timing):
- Edit /flash/config.txt (remount rw): Add dtparam=i2s=on, hdmi_force_edid_audio=1 (if HDMI-related), and your overlay (dtoverlay=slice-audio or from repo).
- Reload module: rmmod <your_module e.g. snd_soc_slice> && modprobe <your_module>.
- Reboot and retest; if periodic, add audio_pwm_mode=0 to config.txt for PWM cleanup.
- Increase Buffers in Driver Source (Target Underruns/Periodic Glitches):
- In your driver code (slice-drivers/sound/soc/...), bump snd_pcm_hardware values: Set buffer_bytes_max = 256 * 1024; and period_bytes_min = 8192;.
- Recompile/install the module, reload, and test playback. Add debug prints in hw_params to log rates/channels via pr_info.
- If clock-related, update DT overlay clocks (e.g., clock-frequency = 12288000; for 48kHz), recompile DTBO, apply.
- Hardware/Power Check and Fallback Test (Rule Out Environmentals):
- Monitor voltage: vcgencmd measure_volts during playback—ensure stable 5V; swap PSU if dips.
- Test on kernel 5.x stock image to isolate v6 porting bugs; if persists, probe I2S pins if hardware access allows.
If these don't resolve, the issue may need kernel rebuild with SND_DEBUG_VERBOSE or forum help with logs/code snippets.
but wait, chatGPT has its opinion as well 
1. Quick confirm: xrun / underrun check
# as root echo 1 > /proc/asound/card0/pcm0p/xrun_debug
# reproduce the glitch, then: cat /proc/asound/card0/pcm0p/xrun_debug
dmesg | grep -iE 'snd|alsa|audio|i2s|underrun|xrun|error' If xruns or pointer/avail errors show → underrun / pointer problem (go to step 3). If nothing shows → skip to step 4 (clocks).
2. Quick behavior probe: speaker-test with bigger buffers
speaker-test -c2 -r48000 -fS16_LE -D hw:0,0 # default
speaker-test -c2 -r48000 -fS16_LE -D hw:0,0 -p 8 -n 4 # larger periods/buffer
speaker-test -c2 -r44100 -fS16_LE -D hw:0,0 # try 44.1k If large buffers remove the glitch → it's an underrun/period-size alignment issue. Proceed to step 3.
3. Fast driver fixes that often cure periodic glitches
- Increase safe defaults in struct snd_pcm_hardware (temporary test):
.buffer_bytes_max = 256*1024,
.period_bytes_min = 8192,
.period_bytes_max = 64*1024,
.periods_min = 2,
.periods_max = 8,- Force period alignment to frame size when computing period bytes:
/* ensure period_bytes is multiple of bytes_per_frame */
period_bytes = frames * bytes_per_frame;
period_bytes = ALIGN(period_bytes, bytes_per_frame);Rebuild & test. If fixed, reduce sizes until minimal stable values.
4. If xruns NOT present — verify clocks / DT overlay
- Inspect device tree and confirm MCLK / clock-frequency exists for the codec.
# inspect DT
grep -R "sound" -n /proc/device-tree || true
dtc -I fs -o - /proc/device-tree | less
dmesg | grep -i clockIf MCLK or clock-frequency is wrong/missing → fix overlay to supply correct clock phandle/rate (e.g. 12.288 MHz for 48k×256 or the codec’s expected MCLK).
5. Instrument pointer & hw_params for precise diagnosis
Insert compact logs in hw_params() and pointer():
pr_info("slice: hw_params rate=%u ch=%u frame=%u buf=%lu per=%lu\n",
params_rate(r), params_channels(r), bytes_per_frame,
r->buffer_size, r->period_size);
pr_info("slice: pointer dma_pos=%llu\n", (unsigned long long)dma_hw_ptr);Rebuild, run, and watch dmesg for pointer jumps or negative avail — that points to DMA position read / 64-bit type bug.
6. Search/patch common porting gotchas (aarch64 / kernel-6)
- Make sure DMA position and counters use u64/dma_addr_t properly (no implicit 32-bit truncation).
- Use proper register reads (readl() / ioread32() as appropriate).
- If codec probe fails for clocks, return -EPROBE_DEFER rather than continuing.
7. If still failing — rapid triage steps
- Try older kernel (5.x) image to confirm regression from kernel-6 port.
- Paste pointer(), trigger(), and hw_params() here and I’ll mark exact lines to change.
Short diagnosis summary
If large buffer sizes fix it → underrun/period alignment; if no xruns and logging shows pointer discontinuities → DMA pointer / 64-bit type bug; if no pointer issues but glitch remains → clock/MCLK.
and here comes the Gemini 
The root cause of the regular 4-second audio glitch is a hardcoded Master Clock (MCLK) in your driver. It's correctly configured for audio at $44.1 \, \text{kHz}$ but is incorrect for the very common $48 \, \text{kHz}$ rate, causing a predictable clock drift that the system violently corrects every few seconds.
Here's the direct path to fixing it.
Step 1: Confirm the Diagnosis (2-Minute Test)
Force Kodi to resample all audio to the one rate your driver handles correctly: $44.1 \, \text{kHz}$. This requires no recompiling.
- SSH into your LibreELEC box.
- Create or edit the file /storage/.kodi/userdata/advancedsettings.xml.
Add the following content:
Code<advancedsettings> <audio> <samplerate>44100</samplerate> </audio> </advancedsettings>- Reboot the system (reboot).
Play some audio, especially UI sounds or video files that are likely $48 \, \text{kHz}$. If the distortion and periodic glitches are gone, this confirms the MCLK is the problem. You can now proceed to the permanent fix.
Step 2: Implement the Permanent Fix (Code Change) ✅
Modify the driver to calculate the MCLK dynamically based on the requested sample rate instead of using a hardcoded value.
- Open your driver source file: sound/soc/bcm/slice.c.
- Navigate to the slice_hw_params function.
- Replace the hardcoded MCLK logic with a dynamic calculation.
Change this section:
/* Set the codec system clock */
err = snd_soc_dai_set_sysclk(codec_dai, WM5102_SYSCLK_MCLK1,
MCLK_RATE, SND_SOC_CLOCK_IN);To this:
unsigned int mclk_rate;
/*
* Dynamically calculate the MCLK based on the requested sample rate (fs).
* The WM5102 codec works well with an MCLK of 256 * fs.
*/
mclk_rate = params_rate(params) * 256;
/* Set the codec system clock */
err = snd_soc_dai_set_sysclk(codec_dai, WM5102_SYSCLK_MCLK1,
mclk_rate, SND_SOC_CLOCK_IN);- Recompile your driver and the kernel, create the new image, and deploy it.
- (Optional but recommended) Remove the advancedsettings.xml file you created in Step 1.
This code change has a very high probability of permanently resolving the audio issue for all standard sample rates.
:
:
