On the adaptation of Lucy’s original work you’re using, I’ve never seen that layout be necessary, so it might be worth testing both Core22 and Core24 without it.
Otherwise, let us know the Java error
If you go back to Lucy’s original above, then I’d add it back in. But the spin off you’re using has never needed it because it only exists in the domain of fixing ALSA → Pulse(+Pipe implicitly), not fixing direct userland ALSA access like Lucy’s.
Sorry about the missing java error @James-Carroll, here it is.
SEVERE [global]
java.lang.IllegalArgumentException: No line matching interface Clip supporting format PCM_SIGNED unknown sample rate, 16 bit, stereo, 4 bytes/frame, big-endian is supported.
at java.desktop/javax.sound.sampled.AudioSystem.getLine(Unknown Source)
at java.desktop/javax.sound.sampled.AudioSystem.getClip(Unknown Source)
at se.trixon.yaya.dice.data.sound.Sound.lambda$load$3(Sound.java:88)
at java.base/java.util.concurrent.ConcurrentHashMap.computeIfAbsent(Unknown Source)
at se.trixon.yaya.dice.data.sound.Sound.load(Sound.java:82)
at se.trixon.yaya.dice.data.sound.Sound.<init>(Sound.java:43)
at se.trixon.yaya.dice.Die$RollThread.rollOut(Die.java:362)
[catch] at se.trixon.yaya.dice.Die$RollThread.run(Die.java:317)
Removing the layout section on core22 did not seem to brake anything.
Removing it on core24 did not fix the problem.
Regarding the generated snap size, is it supposed to be so much larger ?
Im shipping a custom java runtime image but the error is there when I use a classic JRE too.
I noticed that libasound2-plugins in core24 results in the extra 60MB compared with core22 and that by removing libasound2-plugins from the core22 snap I got the same error as with the core24.
To me it looks like libasound2-plugins is not configured correctly in my core24 snap, but I have no idea how to fix that.
snap run --shell yaya
> aplay $SNAP_REAL_HOME/example.mp3
(You might need to bundle this but I think you’d already have it from the other staged ALSA bits).
It’d be helpful for identifying whether this is a problem with the libraries and general environment config, or, should you get audio playing, it’d imply the problem relates more to Java or your app itself. Unfortunately Googling, this error doesn’t seem to be amazingly common outside of snaps without Pulseaudio workarounds; but one post on Stack overflow did suggest that this can also happen if the underlying resources aren’t cleaned up in the JVM properly and others suggested it can even come down to the size of the audio file itself. I’ve no idea to what extent that’s true unfortunately.
Do you happen to know which JVM is in the app and where it’s from? Your snapcraft.yaml doesn’t have it so I suppose it’s bundled in the .zip for yaya itself, which might contribute to problems itself if e.g., the Java ABI isn’t compatible. It could be worth shipping default-jre (Java 17 in Core24, though you can also use Java 21) and using a repo provided Java just as another source of reference.
FWIW, I think you might be able to save space by just shipping libasound2-plugins specifically without libasound2 itself, letting Apt deal with getting the bare minimum needed, there’s a decent chance libasound2 grabs more of the ALSA stuff than you need given all we’re doing is trying to avoid it in the first place.
libpxbackend-1.0.so: cannot open shared object file: No such file or directory
Failed to load module: /home/pata/snap/yaya/common/.cache/gio-modules/libgiolibproxy.so
and then
aplay: error while loading shared libraries: libOSSlib.so: cannot open shared object file: No such file or directory
bash-5.2$ aplay -L
aplay: symbol lookup error: aplay: undefined symbol: snd_pcm_get_chmap, version ALSA_0.9
bash-5.2$ alsamixer
alsamixer: symbol lookup error: alsamixer: undefined symbol: snd_mixer_selem_set_playback_dB, version ALSA_0.9
bash-5.2$ aplay
aplay: symbol lookup error: aplay: undefined symbol: snd_pcm_get_chmap, version ALSA_0.9
Perhaps the java point is not relevant by now but I created a custom runtime with jlink based off azul zulu jdk 23 and bundled that with the application.
I’d agree, it’s unlikely to be Java if aplay itself isn’t working so it makes sense to treat it as an environment error for now.
It’s an odd one though, I can’t recall if I’ve done any Core24 snaps with Audio and the workaround yet but I’ll give it a go my end and see if anything stands out.
I’ve just tried this locally, working from your current devel@HEAD
Swapped the base to Core24
Removed the layout: bit
added alsa-utils into stage-packages testing with aplay (I’d not recommend this for an actual release, we’re trying to avoid ALSA not get it closer to functional)
Removed architecture [amd64] so snapcraft stops moaning about it being the old syntax for now
Swapped the version string just to make it build
What I did realise then, was I didn’t actually have the .zip itself, so I also then changed the source to point at your latest release from Github to cheat just stealing a presumably known good binary rather than have to setup the JDK stuff myself since the actual build is done outside of snapcraft.
When I’ve run this below, I don’t appear to have any problems, could you let us know how this works on your end just for curiosity?
name: yaya
title: Yaya
base: core24
version: '1'
summary: Yet Another Yahtzee-esque Application
description: |
Enjoy classic family dice games with up to 8 players.
If you know your way around games like Yahtzee, Yatzy, Yacht and Crag you will do fine.
Ready, Set, Roll!
grade: stable
confinement: strict
icon: snap/gui/yaya.png
license: Apache-2.0
compression: lzo
apps:
yaya:
command: yaya/bin/yaya
extensions: [gnome]
plugs:
- audio-playback
environment:
ALSA_CONFIG_PATH: $SNAP/etc/asound.conf
parts:
yaya:
plugin: dump
source: https://github.com/trixon/yaya/releases/download/v24.12/Yaya-24.12-linux.zip
source-type: zip
stage-packages:
- alsa-utils
- libasound2
- libasound2-plugins
config:
after:
- yaya
plugin: nil
override-prime: |
craftctl default
sed -i 's/${HOME}\/.${APPNAME}/${SNAP_USER_COMMON}\/.yaya/' /root/prime/yaya/bin/yaya
sed -i 's/${HOME}\/.cache\/${APPNAME}/${SNAP_USER_COMMON}\/.cache\/yaya/' /root/prime/yaya/bin/yaya
alsa-pulseaudio:
plugin: dump
source: .
override-pull: |
mkdir etc -p
cat > etc/asound.conf <<EOF
pcm.!default {
type pulse
fallback "sysdefault"
hint {
show on
description "Default ALSA Output (currently PulseAudio Sound Server)"
}
}
ctl.!default {
type pulse
fallback "sysdefault"
}
EOF
lint:
ignore: [library]
On my end, aplay works without errors. Unfortunately and maybe at the risk of sounding a bit dim, I’ve no clue how to play Yahtzee and can’t make the game itself play any audio because I can’t figure it out lol, but I’d presume if I could be a professional enough gamer to get to a “you lost!” screen I might get some some game over music or such since aplay isn’t having issues for me.
As an update, I found the die sneaking in the bottom right corner and can confirm on my end, this has sound with nothing more than libasound2-plugins, you can remove alsa-utils and libasound2 entirely, along with the layout. Technically you can even remove the audio-playback interface, it’s default with the Gnome extension.
Assuming then that works the same on yours as mine, the only real difference is the source of the .zip file. JLink itself can be problematic from time to time but practically the simplest solution for yourself here seems to be to just re-use your existing binaries on Github and leave snap as just a deployment tool, otherwise my recommendation would ultimately probably be “build Yaya in snapcraft itself and avoid the dump plugin”, for possibly little benefit to yourself.
I’d assume if you were to build JLink in Snapcraft the problem goes away, since what I’m imagining happening is wherever this JLink’d binary was originally created is in an environment that’s not compatible with Ubuntu 24.04 and might even suggest you have this problem elsewhere outside snaps with it (but probably only with Linux, with the way things are, I imagine JLink doesn’t have issues here with Windows/MacOS)
name: yaya
title: Yaya
base: core24
version: 'FILL-ME'
summary: Yet Another Yahtzee-esque Application
description: |
Enjoy classic family dice games with up to 8 players.
If you know your way around games like Yahtzee, Yatzy, Yacht and Crag you will do fine.
Ready, Set, Roll!
grade: stable
confinement: strict
icon: snap/gui/yaya.png
license: Apache-2.0
compression: lzo
apps:
yaya:
command: yaya/bin/yaya
extensions: [gnome]
environment:
ALSA_CONFIG_PATH: $SNAP/etc/asound.conf
parts:
yaya:
plugin: dump
source: https://github.com/trixon/yaya/releases/download/v24.12/Yaya-24.12-linux.zip
stage-packages:
- libasound2-plugins
config:
after:
- yaya
plugin: nil
override-prime: |
craftctl default
sed -i 's/${HOME}\/.${APPNAME}/${SNAP_USER_COMMON}\/.yaya/' /root/prime/yaya/bin/yaya
sed -i 's/${HOME}\/.cache\/${APPNAME}/${SNAP_USER_COMMON}\/.cache\/yaya/' /root/prime/yaya/bin/yaya
alsa-pulseaudio:
plugin: dump
source: .
override-pull: |
mkdir etc -p
cat > etc/asound.conf <<EOF
pcm.!default {
type pulse
fallback "sysdefault"
hint {
show on
description "Default ALSA Output (currently PulseAudio Sound Server)"
}
}
ctl.!default {
type pulse
fallback "sysdefault"
}
EOF
lint:
ignore: [library]
Thank your for your time and effort.
This is a bit confusing though.
Yesterday I could not get your changes to work, I still got the same problem.
Since I’m mostly a Fedora user I installed Ubuntu last night to get a clean reference environment. Just to realize that the problem remained.
This morning however, after some DDG-ing and some minor changes to the yaml and snapcraft clean along with deleting related lxd instances, your version that did not work yesterday works just fine today.
Not sure why, but thanks!
My local zip and the one released on github is pretty much the same, and they are both working for me now. IIRC I used to prefer using local files when I started out with snap due to the download performance and many many retries with snapcraft clean etc. Today I use the local zip in order to be able to have the snapcraft.yaml part of the actual release tag.
I used to run jlink in my snapcraft.yaml a couple of years ago. Since the I wanted to streamline the buildning of netbean platform applications so I wrote a “packager” for that along with a gui for jlink called CRIC.
Certainly a weird one. Fundamentally I don’t see a reason for the original YAML to have not worked, so it might be worth keeping an eye on to see if it reoccurs because at this point it’s sounding like some weird business in the snapcraft tooling domain but also one of those that’s unfortunately as easy to reproduce as Panda Bears. The errors would have basically implied that the base snap and the app snap weren’t designed for each other, how that would happen I’m clueless, and hearing it’s just sorted itself out as if by magic, now I’m more clueless ,
I’m on a 27" 1440P screen, the scoreboard sits firmly in the middle of the display even when maximised. I was reading the help and kept seeing “bottom right” but didn’t interpret the skeumorphic design of the table as valid because visually all the elements were firmly central, so kept looking at the bottom right of the scoreboard. Something that draws attention to the table itself might help, whether it’s a little border around where the mouse can interact with the dice, or maybe something like this that animates/jiggles a little until you click it the first time and get into the game
There’ll be some natural growth overtime due to the compilers adding more functionality but having inspected the snap I’ve made myself, it seems to have a load of libraries that probably aren’t needed and I’m not sure why. My guess is the Gnome extension might be adding them implicitly because a lot of them are in the domain of the Gnome extension (sound stuff, image codecs, video codecs, etc).
Add this to your .YAML and see if it helps reduce the size, effectively it compares files in the Gnome extension with the files in your snap, where the paths match they can be assumed to be functionally equivilent and then get deleted from your snap so there’s only one copy rather than two, especially since only one copy will get used anyway so in most cases the duplication is just legitimately wasteful, and you’d rather the Gnome ones for the quicker downloads and fact they can be updated independantly of your main snap.
parts:
cleanup:
plugin: nil
build-snaps:
- core24
- gnome-46-2404
- mesa-2404
override-prime: |
set -eux
for snap in "core24" "gnome-46-2404" "mesa-2404"; do
cd "/snap/$snap/current" && find . -type f,l -exec rm -f "$SNAPCRAFT_PRIME/{}" \;
done
after: [yaya]
Edit:
AI, what kind of die is this?!
, it has two 5’s and a “7”!
, it has two 5’s and a “7”!