How do you test this? GNOME does not seem to have any sound theme. In g-c-c there is a Alert sound choice but it does not seem to make any sound when changed. And it only seems to make a symlink from ~/.local/share/sounds/__custom/bell-window-system.ogg to a file in g-c-c package.

How do you test this? GNOME does not seem to have any sound theme. In g-c-c there is a Alert sound choice but it does not seem to make any sound when changed. And it only seems to make a symlink from ~/.local/share/sounds/__custom/bell-window-system.ogg to a file in g-c-c package.

It was pretty weird, I actually checked and the gnome theme doesn't inherit from the freedesktop one. I'll test it again somehow, but for sure before I did this there wasn't any sound theme activated, and trying to activate it in g-c-c wouldn't work.

Edit: gnome does have a sound theme, though it consists of alert sounds. I guess the freedesktop theme is used for everything else, and probably needs to be installed. Should the sound freedesktop module do this instead?

Hmm, I don't know how to have sound in qemu...

Hmm, I had system sounds muted so that alert sound was not being played when I changed it. Now I also hear a sound when changing volume level.

Yup, seems to be the case:

$ cat ~/.local/share/sounds/__custom/index.theme
[Sound Theme]
Name=Custom
Inherits=freedesktop
Directories=.

That should be enough justification to install it from the gnome module.

In the past, I just added it locally (2be9f02) but it might make sense to handle sound themes just like icon themes. On the other hand, the freedesktop theme is probably the only one anyone will ever use, so the replaceability argument is not so strong.

In either case, GNOME Shell also relies on some sound theme being present.

I would go with installing it in gnome module with a comment about the custom alert theme. Adding it to xdg.sounds module on top of that probably would not do any harm.

Yup, seems to be the case:

$ cat ~/.local/share/sounds/__custom/index.theme
[Sound Theme]
Name=Custom
Inherits=freedesktop
Directories=.

That should be enough justification to install it from the gnome module.

In the past, I just added it locally (2be9f02) but it might make sense to handle sound themes just like icon themes. On the other hand, the freedesktop theme is probably the only one anyone will ever use, so the replaceability argument is not so strong.

In either case, GNOME Shell also relies on some sound theme being present.

I would go with installing it in gnome module with a comment about the custom alert theme. Adding it to xdg.sounds module on top of that probably would not do any harm.

I believe I've supplied these changes. Though I would still like a way to test it in qemu for a backport.
(I'd only backport the change to gnome3.nix)

Adding the following seems to be sufficient to make the sound work.

virtualisation.qemu.options = [ "-soundhw hda" ];

Though for some reason, when QEMU is run, it starts acting as a monitor and it is mixed with the output. But Spotify triggers that too, so maybe it is irrelevant.

You can also abuse QEMU_NET_OPTS environment variable:

$ env QEMU_NET_OPTS="hostfwd=tcp::2222-:22,hostfwd=tcp::8888-:80 -soundhw help" ./result/bin/run-*-vm
Valid sound card names (comma separated):
sb16        Creative Sound Blaster 16
es1370      ENSONIQ AudioPCI ES1370
ac97        Intel 82801AA AC97 Audio
adlib       Yamaha YM3812 (OPL2)
gus         Gravis Ultrasound GF1
cs4231a     CS4231A
hda         Intel HD Audio
pcspk       PC speaker

-soundhw all will enable all of the above

Adding the following seems to be sufficient to make the sound work.

virtualisation.qemu.options = [ "-soundhw hda" ];

Though for some reason, when QEMU is run, it starts acting as a monitor and it is mixed with the output. But Spotify triggers that too, so maybe it is irrelevant.

Ok, it does seem to have system sounds now from themes. However it's pretty strange that system sounds start off as muted, I believe you noticed this also.

What I did to test was:

1. build vm with gnome3 config
2. opened sound pane in g-c-c
3. made sure system sounds were all the way up
4. played with volume slider in the shell

Without this change, even if you set a sound theme you won't get the alert sound (drip).

@jtojnar Similar findings?

You can also abuse QEMU_NET_OPTS environment variable:

$ env QEMU_NET_OPTS="hostfwd=tcp::2222-:22,hostfwd=tcp::8888-:80 -soundhw help" ./result/bin/run-*-vm
Valid sound card names (comma separated):
sb16        Creative Sound Blaster 16
es1370      ENSONIQ AudioPCI ES1370
ac97        Intel 82801AA AC97 Audio
adlib       Yamaha YM3812 (OPL2)
gus         Gravis Ultrasound GF1
cs4231a     CS4231A
hda         Intel HD Audio
pcspk       PC speaker

-soundhw all will enable all of the above

Thanks, I was able to test with nixos option 👍
(happened to also have intel audio)

backported a22b018

My terminal bell suddenly made a sound due to this change, which was a bit annoying to track down (I don't even directly use gnome). Not saying that there's anything wrong with it, since I've apparently been relying on a bug (https://xkcd.com/1172/). Now I just need to figure out how to disable the sounds properly.

I'm not sure the backport is a good idea though. Its a functional change, and maybe not just strictly a fix. Maybe its the right thing to do anyways, I don't know.

@timokau I only backported the fix to GNOME a22b018. The OS wide change to include the freedesktop sound theme, where on conventional systems would have always been there (and I think libcanberra even needs it), wasn't backported for the reason you mentioned. Simply put, I fixed being able to set an alert sound in GNOME, and with gnome-control-center.

Ah okay, that's good then. Discovery is still not optimal (I had to bisect it, which is even harder since my system configuration didn't build on some of the relevant revs), but I'm not sure how to improve that.