pulseaudio-qubes is still installed?
You could try make a copy of the debian template, then re-install the copy completely with this Qubes guide https://www.qubes-os.org/doc/reinstall-template/
The command is quick to execute, just do something else while it works in the background. Once it is complete, then, see if the sound issue is fixed in the new debian template.
- If it is not fixed, then you will know the issue is in Dom0, and you narrowed it down to a Dom0 issue, which then likely might be something like the VNC server, or whichever packages is dependent on the sound sharing between VM's in dom0.
- If it is fixed, then the issue was likely in debian template itself, and you have no more worries. Just install all your applications in your new debian template, and change all your AppVm's to it.
Marek just posted a "potential" solution for the debian sound issues a few hours ago, here;
https://groups.google.com/forum/#!topic/qubes-devel/CJvMfj0zfb8
It's likely due to the dom0 being more documented than the template testing repositories, causing this misunderstanding. You don't need to update the dom0 one, it's actually the debian template testing you need to update (from Qubes tools repositories), not the Dom0 repositories.
I recommend you make two copies of your original debian template. One is for unchanged frozen backup, the other is for messing around and experimentation, which if you find a solution, you can apply to your original debian template. Thereafter delete your experimentation template, while keeping your backup one for a while. If the solution stops working, then you have an old backup to fall back on. So it's easier to upgrade packages again to the right version, rather than having to mess around with downgrading packages.
Everything needed is found here https://www.qubes-os.org/doc/software-update-vm/
You can also go into the repo list and edit it, as briefly mentioned in the link above as well.
Run in Debian terminal: sudo nano /etc/apt/sources.list.d/qubes-r3.list
remove the # in the Qubes updates candidates repository, in front of the "deb". You don't need the "deb-src" one, so don't change that line.
Ctrl+X, press y to save, and exit.
Now run;
sudo apt-get update && sudo apt-get upgrade
Just install everything in the testing repository, see if it fixes the sound issues. Try temporarily switch one of your sound AppVM's to your experimentation Template OS to find out.
The reason it's suggested to two copies of the debain template, is to ensure that everything works smoothly, before you change anything, minimizing annoying extra work to do, if something goes wrong.
Note, if you want to remove the testing repository again, you can just go back in Debian terminal: sudo nano /etc/apt/sources.list.d/qubes-r3.list
and put back the # infront of the deb, which you had removed earlier.
Also note that the --enablerepo= flags are only temporarily, while editing the file above is permanent changes, until the file is edited again, that is.
If I understood Marek correctly in his post from earlier, the reason this fix is a temporary one, is because this is a fix outside the Qubes responsibilities. Which means, the moment the original repository pushes an update here, it will break the fix Marek made. As such, you must either avoid updating it until a fix from the original repository arrives, or alternatively, just update and take your chances.
The reason I suggested to make a backup template, is so that you caan easily return and apply Marek's fix, should you have used a future update that overwrites it.
Hope it helps, as Marek said, this update isn't tested.
I'm actually a little unsure how the Qubes repository command works in the Debian repository. It might not be sudo apt-get update && sudo apt-get upgrade, but rather something else. I haven't had the need for this before, and the exact debian command isn't documented for some odd reason. But the Fedora one is pretty straight forward, I assume the debian one is similar. But either way, the approach above "should" trigger the testing updates.
Just in case it doesn't work, you'll need to confirm if it actually did trigger the testing repository to update. If it doesn't trigger it, then no harm is done anyway, it'll just run plain steady updates, and not the resting ones.