Slice4s

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).

1. 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.
2. 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.
3. 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.
4. 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 clock

If 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.

1. SSH into your LibreELEC box.
2. Create or edit the file /storage/.kodi/userdata/advancedsettings.xml.

3. Add the following content:

   Code

   <advancedsettings>
     <audio>
       <samplerate>44100</samplerate>
     </audio>
   </advancedsettings>

4. 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.

1. Open your driver source file: sound/soc/bcm/slice.c.
2. Navigate to the slice_hw_params function.
3. 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);

1. Recompile your driver and the kernel, create the new image, and deploy it.
2. (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.

Please give this slice-drivers branch a try: https://github.com/HiassofT/slice…/kernel-5.10%2B

And here's an LE13 branch that pulls in the driver for RPi2 (you'll need to adjust the RPi4 options for your CM4s): https://github.com/HiassofT/LibreELEC.tv/tree/le13-slice

A few years ago I tried to clean up the slice (soundcard) driver, I dug out the branch again and noticed a couple more fixes are required now and added those today (I also ran into the distorted sound issue).

The RPi2 LE13 build worked fine on my Slice with CM3 with just dtoverlay=slice added to config.txt (this enables audio, IR and the RTC), analog audio out sounds fine now.

Note: SPDIF out doesn't work since a change to the cs4265 upstream driver some years ago, I haven't looked at that.

I also didn't care about the dt-blob.bin files from the slice-firmware repo, using the blobs from old Slice images works fine to get USB/ethernet working - you may need to create your own dt-blob for CM4s.

so long,

Hias

Thanks a lot for reporting back, and glad to hear it's working for you, too!

You can safely ignore (and actually should dtop) the ancient Linux patches, they are no longer needed nowadays.

The mmc patch dates back long before we switched to reference the flash and system partitions by UUID, when the EMMC/SD card device ordering still mattered - with UUIDs it doesn't matter if the EMMC is /dev/mmc0 or /dev/mmc1.

The cs4265 patch also predates changes to the upstream cs4265 driver and isn't needed anymore.

And the alsa card conf was only needed for kodi so it recognises an IEC958/SPDIF capable device to allow AC3/DTS passthrough via Toslink(SPDIF. A few years ago I looked into improving the (incomplete) SPDIF support but realized a lot of important bits were missing in the cs4265 driver to transmit proper channel status information - then gave up and shortly afterwards SPDIF got broken again in the cs4265 driver due to changes in the upstream code. So better use HDMI if you need/want to pass through AC3/DTS/..., receivers with only SPDIF input are also quite rare today.

so long,

Hias