Picochess 4.2.1 with Wi-Fi and Bluetooth menus are out for testing

[Johan Sjöblom]

Hi brave testers.

Trying to make installation easier, but this one requires more testing. I have tested the basic flows myself, but feedback is more than welcome.

If you want to test the 4.2.1 its now in this branch: 256-bluetooth-pairing

And here is the PR location with some explanations: https://github.com/JohanSjoblom/picochess/pull/258

You can now connect to a Wi-Fi when setting up a new Pi. If you want to be able to use quick-connect add your Mobile phone wifi hotspot info to your picochess.ini. You don't have to, you can also enter it in the settings page. Or you can enter any SSID and pass for any WiFi you have.

New optional picochess.ini settings:

hotspot-ssid = YourPhoneHotspotName
hotspot-pass = YourHotspotPassword

There is also an experimental Bluetooth pairing + PAN. In theory you could use your Raspberry Pi without any Wi-Fi network (PAN=Personal Area Network). You can pair your phone by chosing from the new Bluetooth menu, or from the setting page. Then you will see some instructions on the clock display. Put your phone to search for bluetooth devices, pair, and then enable Bluetooth tethering. Failing to setup a PAN, it will tell you to use WiFi hotspot. I could not yet get this flow to work on my Samsung Android phones... But some phones might work? Or someone might now how to fix the new scripts? Anyway, this Bluetooth part is very experimental. It does pair my phone, but my phone does not accept the PAN.

I have put all info in readme as best as I can. I have also updated all the picochess.ini.example.* files where you can see all the new settings for Wi-Fi and Bluetooth.

Main thing is that there is now a clock menu System -> Bluetooth. You can run the Fix_bluetooth script or pair your phone. On the new Wi-Fi menu you can connect to your mobile phone Wi-Fi hotspot.

-- Johan

[Johan Sjöblom]

Hi all.

After testing myself I realized that its difficult to test installation support features in a branch. I have now merged the 256-bluetooth-pairing branch. It means you will get this version 4.2.1 next time you do a normal upgrade.

For brave testers who want to test this, please report clean installation or upgrade problems. We now have a Wi-Fi and Bluetooth clock menu, and the same alternatives on the settings web page (from the cog wheel under the menu tab). You can now run Fix_bluetooth script from the menu, and you can connect to your Mobile Wi-Fi hotspot from the menu, or any Wi-Fi from the settings page. Hopefully this will make it easier as the new Pi Imager no longer allows you to pre-define a Wi-Fi. And yes, you can use an old version of the Pi Imager for a while.

All installations and setups are a little bit different, so setting up Wi-Fi and Bluetooth are never going to be fully automated, but lets see if things get a little bit easier now... If not, ideas are most welcome!

For headless installations: use ssh to run the new pair-phone script:

sudo ./pair-phone

If anyone knows why Mobile phones don't accept a PAN (Bluetooth personal area network with Bluetooth tethering) please check that pair-phone script. It does pair the mobile phone, and then it starts a PAN service after which Mobile Phone Bluetooth tethering should work, but my phones immediately reject it. I dont know why. My vision was to be able to use a Pi without Wi-Fi with Bluetooth only. And I was hoping to be able to install a headless Pi without any display or keyboard and to first get it into Bluetooth pairing with tethering and then from the Wi-Fi settings page connect it to your Wi-Fi. All in one flow, and no display needed, only ssh in and run sudo ./pair-phone. Unfortunately I did not get that part to work for me. The fallback to Wi-Fi hotspot does work. When the Wi-Fi hotspot connects, it will show the IP address on the clock display so that you know how to connect with your phone.

-- Johan

[RandyR]

Hi Johan,

Now that I can spend some time on PicoChess, after updating from 4.1.9 to 4.2.1 and switching to wayland I'm seeing a couple issues on my Pi5 with up-to-date Trixie (I ran the installer twice). First, the sound cuts out when announcing moves (e.g. you will hear "Knight" instead of "Knight f6", or sometimes the first part sort of fades in - as if coming out of suspend). I'm using the picochess.ini web example and have selected sox as the audio backend (native wasn't satisfactory either). Secondly, sometimes the kiosk web page does not initially open (just a grey screen). When I look at 'systemctl status picochess' I can see picochess service has started, and picochess.py is running, but nothing else. Eventually it starts. This doesn't happen every time, though.

I'm also seeing log entries like this:

2026-02-09 20:50:40.767   DEBUG     engine - stop: engine.stop called (thinking=False, waiting=True)
  File "/usr/lib/python3.13/asyncio/events.py", line 89, in _run
    self._context.run(self._callback, *self._args)
  File "/opt/picochess/picochess.py", line 4432, in process_main_events
    await self.state.picotutor.set_user_color(
  File "/opt/picochess/picotutor.py", line 489, in set_user_color
    await self._start_or_stop_as_needed()
  File "/opt/picochess/picotutor.py", line 686, in _start_or_stop_as_needed
    self.stop()
  File "/opt/picochess/picotutor.py", line 660, in stop
    self.best_engine.stop()
  File "/opt/picochess/uci/engine.py", line 1162, in stop
    "".join(traceback.format_stack(limit=6)),

2026-02-09 20:50:40.767   DEBUG     engine - stop: engine.stop called (thinking=False, waiting=True)
  File "/usr/lib/python3.13/asyncio/events.py", line 89, in _run
    self._context.run(self._callback, *self._args)
  File "/opt/picochess/picochess.py", line 4432, in process_main_events
    await self.state.picotutor.set_user_color(
  File "/opt/picochess/picotutor.py", line 489, in set_user_color
    await self._start_or_stop_as_needed()
  File "/opt/picochess/picotutor.py", line 686, in _start_or_stop_as_needed
    self.stop()
  File "/opt/picochess/picotutor.py", line 662, in stop
    self.obvious_engine.stop()
  File "/opt/picochess/uci/engine.py", line 1162, in stop
    "".join(traceback.format_stack(limit=6)),

It doesn't say ERROR so maybe it's just debug info for yourself.

I will do a fresh install tomorrow and see if things get sorted out.

Randy

[Johan Sjöblom]

Hi Randy.

Thanks for testing. I have not really done any changes to sox setting, that should work exactly as in V3. But of course, nothing is exactly the same. I definiteIy need to assemble my Pi5 when I get home (travelling now). I have only tested complete installs of 4.2 on Pi4. One Bookworm, and one Trixie. I will make the Pi5 a build environment so that I can debug if needed.

Meanwhile, here are some guesses on what to check:

1. My number one suspicion: the native setting is for good and bad made to fallback to sox if it does not work. That was maybe not a good design on my behalf. It could mean that you have something missing to make native work so it falls back to sox, which does not work either.
   • README lists this warning: Is some of these missing? "New Trixie might be missing audio libraries you need like pulseaudio, pulseaudio-utils, libpulse0, or even libasound2-plugins". If PipeWire is default and ALSA plugins aren’t present, SoX may not be talking to the right device reliably.
     • The install-picochess does NOT install these, I might need to fix that. If you can verify that they fixed native mode.
       
   • Do you have any of the following in your log:
     • native audio unavailable: ...
     • native audio requested but unavailable, falling back to SoX
     • native audio failed for
2. The audio device wakeup, or energy saving might do this. Could you try running some more sounds through the audio before starting the test to make sure its awake? This is a long shot....
3. Missing python dependencies for native sound support. Another long shot, I dont think its this one either.
   • numpy, sounddevice, soundfile, audiotsm, audiotsm.io.array
   • These are installed by requirements.txt 

 Of course I believe native is the way forward, but I am suprised that sox does not work... It _should_ be the same as V3.

BR, Johan

[Randy Reade]

Hi Johan,

I've just flashed the RPiOS image on that SD card so cannot check those issues any more, but I'll continue with a fresh install and see if there are any issues using a clean state with v4.2.1. Then, if still present, I'll use your notes to see if I can find anything. I know with PulseAudio I commented out the suspend-on-idle setting to help with the truncated audio but not sure what the equivalent is in PipeWire.

Randy

[Johan Sjöblom]

Courtesy ChatGPT this might give you some idea, but ideally a clean install should work out of the box. Let me know if it does not.

Good luck with the install.

Quoting ChatGPT 5.2:

On PipeWire, the “suspend‑on‑idle” equivalent is managed by WirePlumber (the default session manager on Trixie). You can disable device/node suspend by setting the suspend timeout to 0.
Common options (depends on WirePlumber version):
session.suspend-timeout-seconds = 0
This is typically set in a WirePlumber config override, e.g. under /etc/wireplumber/main.lua.d/ or /etc/wireplumber/conf.d/ depending on version.
You can also add a rule to force specific nodes (sinks/sources) to never suspend.

[Randy Reade]

I believe I tried something similar but it didn't help. If I recall, the path is /usr/share/wireplumber on RPiOS. Of course, that should only help if the first part of the sound is cut off, which wasn't always the case.

[RandyR]

With a clean setup using PipeWire and Wayland on a Pi5, I'm still seeing the audio issue (I'm using an HDMI monitor with sound). When PicoChess starts, I hear "PicoChess" normally, but the "Engine Setup" sounds more like "ngine Setup". Playing e4 with Stockfish 16, the audio response to Stockfish's Nf6 was "f6". So the first part of the sound (or actually, the knight.ogg file) is muted. This really does sound like the sound server is suspended. I'll look into the ChatGPT fix. Otherwise the clean install seems to work much better.

Also, the Dec 2025 release of Trixie has removed the option to switch from PipeWire to PulseAudio via raspi-config. I think we should attempt to stay with PipeWire.

[RandyR]

I made my next move, e5. SF16 responded with Nd5, but I only heard "Knight" this time, i.e. the first ogg file played but the next two didn't. I'll switch to debug and see if I can see anything in the log.

[RandyR]

Log files are normal for picotalker.

[Johan Sjöblom]

Good testing. I probably have to add more logs to find out what happens, but its probably not on the Python side (my guess), so logging might not help. Maybe I could construct a script that simulates a series of move sounds, so that we can test the system sound without any python involved, just system calls playing out those opening sounds and a few moves...

Certainly a reason for me to get my Pi5 assembled once I get back home so that I can check it myself.

-- Johan

[Randy Reade]

Hi Johan,

I actually tried something similar and was trying to figure out how the code was building the move sounds. When using Sox (which doesn’t help, btw) if you run ‘play knight.ogg f.ogg 6.ogg’ it sounds correct. In the code, are the sound files combined before playing or are they just separate calls (‘play knight.ogg’…’play f.ogg’…’play 6.ogg’)?

Randy

[Johan Sjöblom]

Hi.

Just came home from a 6 hour drive, but here's a quick small attempt to test a fix for native mode:

PR: https://github.com/JohanSjoblom/picochess/pull/261

Branch name: 260-sound-fix

And yes, the code first plays "Night", then "d" then "5" in a sequence. Now it plays 20ms of silence "pad" on start and end.

Test that branch if you have the possibility. This is a low risk change, but I made a branch so that we can keep trying different things until we find a fix.

-- Johan

[Randy Reade]

Thanks. I will check it when I get a chance.

[Johan Sjöblom]

This was the first test step, it adds 20ms at start and end of one move. So now there is 20ms + "Night" + "d" + "5" + 20ms.

If this improves the situation, but still misses some sound the next step I will try is to add that same 20ms also between the clips,  resulting in 20ms + "Night" + 20ms + "d" + 20ms + "5" + 20ms.

To really fix this I should compile all these separate clips into one, and then play 20ms + "Night d5" + 20ms. But lets see what test results we get first.

-- Johan

[Johan Sjöblom]

More info and just correcting myself:

• The audio-backend = native: Its totally Python sound, library: sounddevice with sd.play, soundfile to decode ogg, and audiotsm to get the time stretch that I failed with Mickey-Mouse sound half a year ago :-) 
• Sox is still playing using pulseaudio system calls, its there for backward compatibility with V3

And yes, audio-backend = native, which is now default in all example ini files, is what we are going for. It should be totally independent of which sound system you use (at least in theory). But lets make sure it works at least with pipewire.

[RandyR]

Back to native using the 260 branch. It seems like there's a small audible change. But the 2nd sound file either fades in (e.g. for c5 or d6, the 5 or 6 fades in) but for moves where the piece is specified I only hear the piece name (e.g., Nc6 plays "Knight", not "Knight c 6"). Note I'm only playing the first few moves then stopping play.

Randy

[RandyR]

Continuing the game, many 'second' sounds are barely heard (e.g. for a6, b5 - the 6 and 5 are muted or unheard). I'm only set for engine move announcements.

[RandyR]

Not just move sounds - "Abort Goodbye" has problems with the "Goodbye" audio.

[Johan Sjöblom]

Ok, step 2 implemented:

Now in addition to the 20ms pads before and after, there is now a gap between ogg sound clips. In addition there is also an extra wait at shutdown before emptying the sound queue. These can be adjusted in the rows 48-50 of picotalker.py

• NATIVE_PAD_MS = 20
• NATIVE_GAP_MS = 20
• SHUTDOWN_SOUND_WAIT_S = 2.0

pull the same branch, changes are still limited to picotalker.py only.

[RandyR]

Seems no better. Playing against SF18, I played e4, SF replied c6, but I only heard "c". Startup sounds were not right either - "PicoChess" played, "Engine Setup" faded in" and "OK" was barely audible. Of note, when I use Sox and enter 'play c.ogg && play 6.ogg' the issue is there (don't hear "6"). But the file is playing:

pi@picochess:/opt/picochess/talker/voices/en/christina $ play c.ogg && play 6.ogg
play WARN alsa: can't encode 0-bit Unknown or not applicable

c.ogg:

 File Size: 14.2k     Bit Rate: 180k
  Encoding: Vorbis        
  Channels: 1 @ 16-bit  
Samplerate: 44100Hz      
Track gain: +4.6dB      
  Duration: 00:00:00.63  

In:100%  00:00:00.63 [00:00:00.00] Out:27.8k [  ====|====  ]        Clip:0    
Done.
play WARN alsa: can't encode 0-bit Unknown or not applicable

6.ogg:

 File Size: 16.1k     Bit Rate: 175k
  Encoding: Vorbis        
  Channels: 1 @ 16-bit  
Samplerate: 44100Hz      
Track gain: +2.4dB      
  Duration: 00:00:00.74  

In:100%  00:00:00.74 [00:00:00.00] Out:32.5k [ -====|====- ]        Clip:0    
Done.

We can't be the only users seeing this issue. Time for some research.

Randy

[RandyR]

Interestingly, running 'alsamixer' on the Pi shows Card: vc4-hdmi-0 and Chip: is blank, whereas on my Linux Mint laptop alsamixer shows Card: PipeWire and Chip: PipeWire.

On Thursday, February 12, 2026 at 3:35:33 PM UTC-6 RandyR wrote:

Seems no better. 

[RandyR]

Apparently that's normal for the Pi.

[RandyR]

I decided to switch to the Pi4 with a clean install of Trixie and v4. Audio defaults to the 3.5 mm jack. I didn't have a speaker plugged in, just the monitor so did not hear initial startup sounds, BUT, when I hooked up a speaker the sound IS WORKING NORMALLY. I will switch to HDMI (using icon on Desktop since raspi-config no longer supports switching audio if using PipeWire/Wireplumber (!??) and will see if anything changes. If it still works fine, I will test a different Pi5 to make sure it isn't a hardware issue on the original Pi5.

Randy

On Tuesday, February 10, 2026 at 2:41:20 PM UTC-6 RandyR wrote:

[RandyR]

Rebooting the Pi4 after switching to HDMI resulted in the Kiosk browser not opening and no sounds heard. The LED on my ChessLink module is showing that the board is connected via BLE. Need to check the logs. Opening Web interface on my laptop works and shows PicoChess is running. Also, turning the still-connected speaker back on I hear the sound coming from it and not the monitor, even though HDMI is still selected in the Speaker icon at top right of desktop.

[RandyR]

Kiosk browser does not want to autostart on reboot but I can launch it manually via ssh 'DISPLAY=:0 /home/pi/kiosk.sh &>/dev/null &'. Surely it can't be related to the sound issue. It worked on initial reboot after installing using the command 'sudo ./install-picochess.sh pico lite kiosk'.

[Johan Sjöblom]

Okey, step 3 is implemented (last “easy” step). I removed the gap between clips and now concatenate the whole move (“Knight” + “d” + “5”) into one buffer and play it in a single call. This change only affects native mode. There is still a 20 ms silence pad before and after the entire concatenated clip (NATIVE_PAD_MS in picotalker.py). If clipping remains a problem, we can try to adjust that value upwards to 30–40 ms.

Your SoX test (play c.ogg && play 6.ogg) showing the second clip missing suggests the issue is start/stop latency, so playing the whole move in one go _should_ fix it. Yes I know, famous "last words" :-)
If this works for you, we’ve likely nailed it. If not, the next step is a persistent audio stream kept open. That is quite a much heavier change.

I did not catch if the kiosk autostart was an issue on Trixie Pi5 or Pi4. I dont see any connection between kiosk or autostart problems and the sound issues. Please let me know if this third attempt with concatenation fixed your issue.

BR, Johan

[Randy Reade]

Since sound works ok on my Pi4 on master branch (at least through the headphone jack - still trying to figure out why HDMI audio isn't working) I think this is a Trixie issue but still need to test a different Pi5. Kiosk not working is also a mystery unless an updated OS has changed how autostart works in Wayland. I need to sort out the Pi4 before returning to the sound issue on the Pi5. 

Randy

--
You received this message because you are subscribed to the Google Groups "PicoChess" group.
To unsubscribe from this group and stop receiving emails from it, send an email to picochess+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/picochess/5b9952de-7085-48fe-b315-6b1c3d6d92c6n%40googlegroups.com.

[RandyR]

To get sound to work on HDMI I had to use the following line in /boot/firmware/config.txt:

dtoverlay=vc4-kms-v3d-pi4,audio

as mentioned here.

I've never had to do anything like that before. But, this also allowed the kiosk browser to open!

However, the audio dropout is back like on the Pi5. :^(

Not happy with the implementation of Trixie by the RPiOS devs. I suppose it could be my monitor or the cable. It sounds more like PipeWire/WirePlumber is starting and stopping the sound server for each sound, as I can hear a faint pop before and after each sound segment. I will do some more testing.

Randy

[RandyR]

I tried a few things, mainly in config.txt, but the kiosk never worked again, even going back to the config.txt state where it worked. And, then I didn't hear any HDMI audio. I shut down, powered up and the audio was back (but no better) and the kiosk still didn't open. Very frustrating.

[RandyR]

Switching back to using a speaker attached to the Pi4 and the sound is OK so the issue is with the HDMI audio on both the Pi5 and Pi4. I believe the kiosk issue is a separate one. Sometimes (rarely on this Pi4) it starts. Usually it doesn't. Once it just flashed for a split second. Perhaps it isn't waiting long enough to detect PicoChess? Or the last Chromium update changed something? Running the script manually works fine.

I think the 260 branch can be removed, though. Sorry for wasting your time, Johan. I think these are all Trixie induced.

Randy

[RandyR]

Switching to X11 (on a whim) fixes the kiosk, and I'm able to switch audio properly using the speaker icon, but the sound cutout issue remains for HDMI. I think tomorrow I will attempt to remove PipeWire and Install PulseAudio.

[Johan Sjöblom]

Great trouble shooting Randy, and oh what a frustrating situation!... I was so tired yesterday but I started to think that you were onto something that its the Trixie-HDMI causing the audio issue, not Pi5. I realized that my test setup, currently only Debian laptop  and 2 x Pi4, the one Pi4 I have with HDMI is still bookworm, and the other one I have an integrated non-HDMI display. I realized I had missed that case HDMI-Trixie that you now have showed clearly.

Status now then?

--> We have a Trixie HDMI audio issue that seems to be hard to solve.

I also assume that the kiosk is another issue... 

I have to see if I can rig my Pi4 Trixie to use only HDMI and test the audio. And I would not consider the 260 branch wasted. Its low risk and it does improve playback by now concatenating one move into one sound play (Nd5, not N+d+5). So I will not yet throw it away. Its easy to adjust the extra padding to zero and only keep the concatenating.

I cant believe that Trixie has HDMI audio issues with pipewire... Isnt that supposed to be the main road forward?

-- Johan

[Johan Sjöblom]

If you have not given up on Pipewire yet, it would be interesting if the new 260 branch would work anyway, as the 20ms pads and concatenation in theory could fix the Trixie HDMI issue?

[Randy Reade]

I haven't yet removed Pipewire as a test. I wanted to confirm it wasn't a cable or monitor issue. I've moved to a different monitor and cable and started from scratch again on the Pi4. I flashed the latest image and the first thing I did was select HDMI using the speaker icon. I used the included speaker-test program to confirm I had sound using 'speaker-test -c2 - t wav' and I heard the looping test sound which appeared normal to me. I then ran the command 'speaker-test -c2 -l1 - t wav && speaker-test -c2 -l1 - t wav && speaker-test -c2 -l1 - t wav' to simulate 3 consecutive sound calls. There was no dropouts or fade-ins. I am now doing a full-upgrade and will test again. Then I will install PicoChess and see if it still works. If it does, I will move back to the original monitor setup and see if it still works.

Randy

[Johan Sjöblom]

... A lot of work.. If you do have the possibility to redo your earlier test, test this: single‑command SoX playback vs chained playback:

play knight.ogg d.ogg 5.ogg
vs
play knight.ogg && play d.ogg && play 5.ogg

This would establish the type of the problem to what I currently suspect. Its a suspend/idle power-save problem with pipewire.

[Johan Sjöblom]

I might be terribly wrong here, but Wireplumber could be the problem here... I asked chatgpt (who also could be terribly wrong) if we could override the global config file /etc/wireplumber/wireplumber.conf.d/ with something that prevents the suspend. This is what chatgpt proposes to add:

monitor.alsa.rules = [
  {
    matches = [{ node.name = "~alsa_output.*" }]
    actions = {
      update-props = {
        session.suspend-timeout-seconds = 0
        node.pause-on-idle = false
      }
    }
  }
]

[Randy Reade]

I believe I mentioned in an earlier post that I did that test. And 'play a b c' worked but 'play a && play b && play c' had issues over HDMI. I also tried many ways to disable any suspend on idle since there's no clear steps for RPi Trixie.

[Randy Reade]

I believe that was one of the things I tried, but I did it in a copy in ~/.config. 

--

You received this message because you are subscribed to the Google Groups "PicoChess" group.
To unsubscribe from this group and stop receiving emails from it, send an email to picochess+...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/picochess/8ffeebfc-b9e7-445e-9edc-5729eac5ec44n%40googlegroups.com.

[Johan Sjöblom]

I think our primary problem is that most applications use audio by keeping the audio open all the time. We play clip by clip. That puts us in a minority position... I have to investigate what it would mean to keep the audio open all the time... 

[Randy Reade]

But it's only an issue over HDMI for me.

To view this discussion visit https://groups.google.com/d/msgid/picochess/bbffb5f7-dd9a-41ba-ab1d-4f3b6af6d057n%40googlegroups.com.

[Johan Sjöblom]

I doubt its only you, you were just the first to hit this issue. We think pipewire is the mainstream on Pi going forward.

But yes, its "only" an HDMI issue right now. I myself mostly use audio-jack or bluetooth speakers.

I have now added a test branch, a parallell test to the previous 260. This branch name you can test is named 262-trixie-pipewire.

It attempts to keep the audio backend warm... A little bit experimental, but if it reduces the pipewire problems I will continue on it...

[Randy Reade]

It appears that it's PicoChess causing the issue. 😥

I ran the installer and before rebooting I tested both speaker-test and Sox using HDMI, both combined and consecutive and it was working. On reboot, no kiosk and no audio played. systemctl shows PicoChess running. picochess.ini is untouched (set to native). Playing audio manually also is not working, neither speaker-test nor Sox. RPiOS is unchanged (except for keyboard setting). So it's not the monitor. It's possible the new chromium is the issue as it doesn't open on boot - maybe it takes out the audio? I will disable it and reboot. 

[Randy Reade]

Yes. Kiosk is causing the issue. Sound works fine when kiosk.sh is renamed. Could be the edits for chromium. I'll check after lunch. 

[Etienne Chaffanjon]

Hi, FYI I am on pi 4 Trixie latest version 4.2 without pulsaudio (not native?) and hdmi sound is ok except the announcement at start that is cut. Kiosk is launching as well. Best regards, Etienne

Le 14 févr. 2026 à 18:35, Johan Sjöblom <messi...@gmail.com> a écrit :

I doubt its only you, you were just the first to hit this issue. We think pipewire is the mainstream on Pi going forward.

To view this discussion visit https://groups.google.com/d/msgid/picochess/55c31272-0f82-415f-b168-b6310b456df1n%40googlegroups.com.

[Randy Reade]

Hi Etienne,

I suspect something has changed since you installed v4. Also, the start sound should play normally on both HDMI and via a/v jack and both native and Sox.

[Johan Sjöblom]

Good catch again Randy. Could kiosk could be the problem here... There could be a timing issue that chromium is launched too soon after launch of picochess, and too soon for the OS to have the pipewire audio ready.

Could you try a sleep 5 in kiosk before launching chromium?

[Johan Sjöblom]

I suspect the error probability increased in this commit of Jan 6th, as it launches chromium under Wayland with less parameters:

https://github.com/JohanSjoblom/picochess/commit/94a04725b22fb81f10eb955f89b134fa67b94fac

or these touch flags I added Feb 3rd:

https://github.com/JohanSjoblom/picochess/commit/39e74e726cbcb12dbde0b73c1642ce643f309cab

[Etienne Chaffanjon]

I added a sleep in my auto start and then # to skip kiosk: in both case the picochess start announcement is cut…looks like Picochess starts too fast…

Le 14 févr. 2026 à 19:31, Johan Sjöblom <messi...@gmail.com> a écrit :

Good catch again Randy. Could kiosk could be the problem here... There could be a timing issue that chromium is launched too soon after launch of picochess, and too soon for the OS to have the pipewire audio ready.

--

You received this message because you are subscribed to the Google Groups "PicoChess" group.
To unsubscribe from this group and stop receiving emails from it, send an email to picochess+...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/picochess/e6dd8393-5ebc-4fe9-81bd-342e2aa021e4n%40googlegroups.com.

[Randy Reade]

This is discouraging - I moved my Pi back to the original monitor, leaving kiosk disabled and there is no sound over HDMI on boot, even manually. HDMI is still showing as selected in the speaker icon. If I connect a speaker to the a/v jack I hear both the speaker test and Sox.

[Randy Reade]

I just noticed that ~/.config/autostart is set to root:root. pico-kiosk.desktop is pi:pi.

[Randy Reade]

I fixed the permissions. I also deleted the .config/chromium and .config/pulse folders as well as the .local/state/wireplumber folder. I rebooted and heard the PicoChess startup sounds, but no kiosk. I checked the speaker icon and it was set to AV Jack!! I have no idea what's going on. Running speaker-test cuts out the start of the audio. Using Sox and the start of the sound is faded in (e.g. play knight.ogg f.ogg 6.ogg) and if playing consecutive clips I only hear "knight" and part of "6". I'd say it's definitely the sound server sleeping. I still don't know why or how the sound system got corrupted and have not been able to fix it. I'm tempted to reinstall RPiOS and start again, leaving out kiosk.

[Randy Reade]

Next reboot, after adding a 20 sec delay in kiosk.sh, the web page opened. But no audio played. Speaker icon still shows AV jack. Switched to HDMI. Still no sound. Rebooted again. Kiosk didn't open. Still no audio and speaker still showing HDMI.

[Randy Reade]

Interestingly, running kiosk.sh manually and I see this:

pi@picochess:~ $ kiosk.sh: X11 session detected
server does not have extension for -dpms option

and 'echo $XDG_SESSION_TYPE' shows 'wayland'.

[Randy Reade]

Sorry, disregard. I ran that via ssh. Running kiosk.sh on the Pi in a terminal correctly shows wayland detected.

[Randy Reade]

Ahh, but there is an error keeping chromium from running (actually it just flashed):

ERROR:third_party/crashpad/crashpad/snapshot/elf/elf_dynamic_array_reader.h:64] tag not found

[Johan Sjöblom]

Ok, it feels like it's challenging to pinpoint the failure, and the tests give different results on different boots? Could it be the touch screen flags, or wrong user running, or wrong rights messed up something?

Anyway, my 10 cents, before starting fresh, clear your chromium profile, in case the error was that chromium was started as root for some reason

Something like

mv ~/.config/chromium ~/.config/chromium.bak

mv ~/.cache/chromium ~/.cache/chromium.bak

--

You received this message because you are subscribed to the Google Groups "PicoChess" group.
To unsubscribe from this group and stop receiving emails from it, send an email to picochess+...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/picochess/CAE5WdusPQap3YUOzabMx%3D-Sam6bTAgE6F%2BFFTy1qfJ9GkbnrkA%40mail.gmail.com.

[Randy Reade]

Yes, I deleted the .config/chromium folder a few times. I forgot about the .cache/chromium folder. Unfortunately it didn't allow the kiosk to start. I think my system is sufficiently corrupted that I'll now have to reinstall. I'll keep an eye on the kiosk install and autostart folder.

[Randy Reade]

Without installing the kiosk, sound on HDMI is working, but the issue of fading in or cutting off is there. It's also there with speaker-test and sox. I suspect removing pipewire/wireplumber and installing pulseaudio would fix it. It's definitely being suspended between clips. But only on HDMI. Switching to AV jack, connecting a speaker and rebooting and there's no issue with the sound fading in or cutting out.

[Johan Sjöblom]

Yes, I agree that suspending between clips is now established as the problem. These two branches with different strategy could be tested.

260-sound-fix = concat Nd5 into one clip + pad (audio stream still opens close per clip).
262-trixie-pipewire = persistent audio stream

Both work well on my Debian Trixie Pipewire setup... So these need to be tested on a Pi5, Pi4. Which strategy is better, to concatenate clips, or to keep a persistent audio stream. I personally think that 262 is the way to go forward as it opens up the future possibility to use a mobile phone as a speaker. We can send the audio stream from the backend to a web page, so we could probably send the audio backend sound to the picochess main web page. That would require a persistent audio stream as well.

Next step for me is to assemble my Pi5, but I am starting a new day-job on Monday so it might take a while, lets see.

-- Johan

[RandyR]

Today I decided I better make a backup of my current v4 system. Before doing that I wanted to switch back to HDMI audio since that was where the issues present. However, switching back to HDMI using the speaker icon did not switch the audio! I think I mentioned this in a previous post. So, before continuing I wanted to solve this issue. The solution was to edit /boot/firmware/config.txt and change the dtparam=audio=on to =off (or comment out the line). I believe this is a bug in the latest RPiOS Trixie release (apt updates current as of today). I made a post on the Raspberry Pi forum. I can now return to HDMI audio testing.

Randy

[RandyR]

Johan,

I tested branch 262-trixie-pipewire using HDMI on the Pi4. It is better but there is still a small fade-in of the first audio clip. I'm currently using 'native'. I also tried solving the suspend issue but had no luck (again). 

On Sunday, February 15, 2026 at 2:30:36 AM UTC-6 messi...@gmail.com wrote:

[Johan Sjöblom]

With fade in I assumed you mean "picochess", "engine setup", and the "OK" initial sounds?

I added a warmup wait of 0.3s... Line 49 in picochess holds this initial waiting time:
NATIVE_STREAM_STARTUP_WAIT = 0.3

Or did you mean that we have fade on the first clip of every move, like "Night" in Nd5?

[Randy Reade]

By fade-in I mean the sound clip is muted at the start but increases quickly to normal volume. At the start, I hear "PicoChess" fade in, "Engine Setup" sounds ok (likely because the suspend doesn't happen since there's not enough idle time between the clips). Then, when the board is recognized, "OK" fades in. For moves, the first clip fades in, sometimes the next clip, if too short, isn't even heard.

Randy

[RandyR]

Turns out the program I was using to test sound ('speaker-test') does not pay any attention to what you select using the speaker icon. Once it decides on the default device (not sure how it does that but maybe it's whatever the system is set to when first run or a sound is first played?) then, unless you specify the output device it will keep using the same device. Note that this is only with PipeWire/Wireplumber. I tested on a Bookworm image running X11 and PulseAudio and speaker-test correctly followed the speaker icon setting.

So much time wasted...

[Johan Sjöblom]

OK, so what does that mean to us now?

More particularly: Do we still have a fade-in problem? The 262-trixie-pipewire branch does not play separate clips. It opens the audio and the only "start-of-clip" situation is "Picochess", the first clip. That branch never closes audio so it should behave like a "music player" and nothing should suspend? Of course there is not always something played, but I dont think the suspend is allowed to kick in as I keep the audio open, otherwise all sound applications would have problems on Trixie.

[Randy Reade]

The sound issue is still there. I've been trying to solve a related issue before getting back to PicoChess testing. Currently, on the Pi4, when the OS boots, the kernel assigns card numbers to audio hardware (if the drivers that support the hardware are loaded). But, I've noticed it isn't consistent on each boot. This is an issue because SoX and (I guess pygame) are using alsa. And the default card can change independent of the speaker icon selection (which I leave on HDMI since I have a monitor attached). On some reboots, no sound is heard from the monitor when PicoChess starts. If I use speaker-test or sox play, the programs run but no sound is heard. If I turn on the speaker attached to the AV jack I can hear the sound. This is even though HDMI is selected via the speaker icon. If I play a sound using the VLC player the sound plays through HDMI. This tells me that the VLC player on the desktop is using pipewire. But I'm no expert. You can select the default alsa device using the /etc/asound.conf file, but if the card numbers change on each boot it becomes useless. There is another file, /etc/modprobe.d/asound.conf, which is supposed to allow you to assign specific card numbers to the hardware you have, overriding what the kernel sets but I haven't been able to figure out the proper syntax. The fade-in sound issues are not unique to PicoChess.

Btw, the fix for kiosk was to use the --display=:0 flag when calling chromium.

[RandyR]

Note that the fade-in sound issue is only when using HDMI. On a Pi4 you can use an attached speaker with no issues. Not sure what would be the result of using a USB speaker on a Pi5. I'll eventually test that.

[Dirk]

USB speaker on a Pi5 (used headless with my Revelation II) is fine with my configuration.

Using a soundcard with a PI4 in my custom DGTPI does have the sound issue at the beginning of a sample.

Dirk 

Von meinem iPad gesendet

Am 18.02.2026 um 21:44 schrieb RandyR <randy...@gmail.com>:

Note that the fade-in sound issue is only when using HDMI. On a Pi4 you can use an attached speaker with no issues. Not sure what would be the result of using a USB speaker on a Pi5. I'll eventually test that.

On Wednesday, February 18, 2026 at 1:18:36 PM UTC-6 RandyR wrote:

The sound issue is still there. I've been trying to solve a related issue before getting back to PicoChess testing. Currently, on the Pi4, when the OS boots, the kernel assigns card numbers to audio hardware (if the drivers that support the hardware are loaded). But, I've noticed it isn't consistent on each boot. This is an issue because SoX and (I guess pygame) are using alsa. And the default card can change independent of the speaker icon selection (which I leave on HDMI since I have a monitor attached). On some reboots, no sound is heard from the monitor when PicoChess starts. If I use speaker-test or sox play, the programs run but no sound is heard. If I turn on the speaker attached to the AV jack I can hear the sound. This is even though HDMI is selected via the speaker icon. If I play a sound using the VLC player the sound plays through HDMI. This tells me that the VLC player on the desktop is using pipewire. But I'm no expert. You can select the default alsa device using the /etc/asound.conf file, but if the card numbers change on each boot it becomes useless. There is another file, /etc/modprobe.d/asound.conf, which is supposed to allow you to assign specific card numbers to the hardware you have, overriding what the kernel sets but I haven't been able to figure out the proper syntax. The fade-in sound issues are not unique to PicoChess.

Btw, the fix for kiosk was to use the --display=:0 flag when calling chromium.

--

You received this message because you are subscribed to the Google Groups "PicoChess" group.
To unsubscribe from this group and stop receiving emails from it, send an email to picochess+...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/picochess/580a2363-2646-47d4-a052-9158413714cfn%40googlegroups.com.

[Randy Reade]

Thanks for the info, Dirk.

[RandyR]

SOLVED! (I hope)

The fix was to install pipewire-alsa. Why this wasn't installed by default in Trixie is beyond me. What it does is route calls to ALSA through PipeWire. For those who don't know what ALSA is, you can read about it here. I would suggest we add it to the install-picochess.sh script, at least for now.

Here is the command for anyone to use. (NOTE: this is only required if using Pipewire and not PulseAudio - so latest Trixie or Bookworm RPiOS images).

To see if it is already installed: 'apt-cache policy pipewire-alsa'. To install: 'sudo apt install pipewire-alsa'.

You can confirm it is using PipeWire by using the command 'alsamixer' in a terminal:

This fixes the fade-in issue when using HDMI on my RPi4 using Master branch in PicoChess v4. I have HDMI selected in the speaker icon and am not using /etc/asound.conf to set the default ALSA card. Also, sound is still enabled in config.txt: 'dtparam=audio=on'. I suspect it will also fix the sound issue on the Pi5.

It also keeps sound working even though the ALSA Card indexes may change on reboot. I'm not sure what the results are when using the Lite RPiOS image as I haven't tested.

Randy

[RandyR]

Well, I spoke too soon. We still have the fade-in problem on some clips (using HDMI). But at least the sound is staying put.

[Johan Sjöblom]

O wow. You nailed it Randy!

The ALSA path must have been "cold" without this as the ALSA clients did not get routed via Pipewire.

I added pipewire-alsa to install-picochess. I also merged the 262-trixie-pipewire persistent audio into master as it will be useful for my next feature: allow the mobile phone browser to act as a speaker for backend sound.

The branch 262-trixie-pipewire no longer exists. Pull master instead.

-- Johan

[RandyR]

It seems to be a bit random. Sometimes the first clip fades in, sometimes not. Sometimes the second clip, sometimes not.

[RandyR]

Sometimes it sorts itself out and continues fine.

[Johan Sjöblom]

The best guess at this point is that it depends on how long the audio stream is silent between picotalker sounds. I mean, the difference in length of silence between sounds could be the source of randomness.

[Randy Reade]

Yes. But why only on HDMI? A connected speaker doesn't show the problem on my Pi4. Did I not test long enough? Also, maybe the suspend on idle edits will work now. I need some more testing, especially before announcing success. 🫣

--

You received this message because you are subscribed to the Google Groups "PicoChess" group.
To unsubscribe from this group and stop receiving emails from it, send an email to picochess+...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/picochess/88d48e75-dcef-41a7-b0bc-2c06c5f31f4an%40googlegroups.com.

[Johan Sjöblom]

Yes, quite, what is different with HDMI? Asking Chatgpt 5.3 I get the following proposals:

On Pi/Trixie, HDMI (vc4-hdmi-0 / vc4-hdmi-1) behaves differently from jack/Bluetooth in a few key ways:

• HDMI output often needs a short clock/stream lock when a stream starts. During that lock, first milliseconds can be muted.
• PipeWire/WirePlumber may suspend HDMI quickly on idle. Short clip playback then repeatedly wakes/suspends the sink, causing fade-in/truncation.
• HDMI ALSA devices are typically more exclusive (single PCM subdevice), so per-clip open/close is more visible.
• Some monitors/TVs apply their own unmute ramp/pop protection, which can swallow the start of short clips.

Why jack/Bluetooth look better:

• Audio jack path is usually “always ready” analog, with minimal wake delay.
• Bluetooth has larger buffering/continuous transport behavior, which can hide clip-start loss better.

So the root difference is: HDMI has stricter wake/lock/power behavior, and with short discrete clips that becomes audible.

-- Johan

[Johan Sjöblom]

Now that we do have a proper alsa-pipewire path, maybe now the session.suspend-timeout-seconds = 0 and node.pause_on_idle = false would work?

... Just a thought... Maybe thats why it did not work earlier...

[Randy Reade]

Makes sense what ChatGPT said. I'll continue investigating as time allows.

To view this discussion visit https://groups.google.com/d/msgid/picochess/95493595-87b2-4006-b796-48206ba5c536n%40googlegroups.com.

[Johan Sjöblom]

AND: now I have added the possibility to use the mobile phone browser as a speaker!! Picochess now behaves like a music station ;-)

With a DGT clock, or a small headless Pi, you do not need any Bluetooth speaker any more. This is great for travel and portability (and demos).

Due to mobile phone web browser rules, you have to make one user interaction (click anything) before the sound starts to play from the server.

PR: https://github.com/JohanSjoblom/picochess/pull/268

Branch to test: 267-mobile-phone-sounds

To test add this new setting to your picochess.ini:

web-audio-backend-remote = true

It will start the picochess music station :-)

[RandyR]

This is pretty cool, Johan. Thanks.