901 sound :) Nice sound options, Fatdog team!

[fatdoguser]

I very much like the new sound options in Fatdog 9xx Thanks Fatdog team

With former reference to this viewtopic.php?t=3655 for older hardware I ended up with a variant that isn't VirtualGL but instead uses a sfs of a pre configured kvm/qemu vHDD and just regular vncserver, mounted/booted in qemu snapshot mode (no changes stored), within which I included tigervnc and use that rather than the regular qemu vnc. 1. as tigervnc works better for me and 2. it uses the virtual sessions virtual sound card instead of the (fatdog) hosts, so runs totally independently. Run vnc through a ssh tunnel to that from a old low spec device and the low spec device only has to handle the vnc screens and sound thrown at it, whilst on a LAN it runs at near the full servers speed, and where its near totally transparent/hidden from anyone using the server/main system, they can be running chrome watching/listening to youtubes whilst the 'terminal' system can be doing the same totally independently. No being locked out of the sound card. Sound lead/lag is minimal, barely noticeable other than when a orator is talking directly at the camera and the out of lip-sync is a little noticeable but not annoyingly so, is only very slight. Size wise the sfs of the vHDD.img is only 3.5GB relative to a 40GB allocated size. Once configured that 40GB version can be thrown away, if you need to make any changes then just extract the 40GB image out of the sfs and qemu boot/modify that and create a new sfs version. Often one family member will be on the Fatdog system (server) playing games whilst listening to music, and I find that a old laptop 'terminal' that's playing youtubes on a external 1080 monitor still works well without affecting either their game/music experience or my watching of youtubes.

[fatdoguser]

Setting compression off in both the virtual machines sshd_config as well as in the Fatdog host sshd_config, and setting the tigervnc client (vncviewer) to Tight encoding, compression level 1 for both that and jpeg ... and the throughput is good, lip sync drift narrows to being near imperceptible.

[jamesbond]

Nice, thank you for testing!

[fatdoguser]

If you're on a very slow network, combined sound and audio with good quality sound, but where you shrink the video right down to a small window and use magdock to magnify that area ... pretty lousy quality video, but where that's running at around 800KB/sec (6.4Mbs) bandwidth, combined audio and video.

Much of that is sound as I had pretty high quality settings, if you also scaled that down to phone like quality the bandwidth would obviously be even lower.

[fatdoguser]

Fatdog installed to qemu vHDD

Additionally load the devx and compile both of ...

https://github.com/Duncaen/alsa-sndio
https://sndio.org/install.html

Install those into the guest Fatdog system. For sndio as part of that you additionally need to ...

Code: Select all

mkdir /var/run/sndiod
useradd -r -g audio -s /sbin/nologin -d /var/run/sndiod sndiod
make install
ldconfig

... as indicated. For alsa-sndio create a ~/.asoundrc containing ...

Code: Select all

pcm.!default {
	type sndio
}

Your Fatdog vm now supports sndio

Run

Code: Select all

sndiod -L-

to set it listening.

On another Fatdog that also has sndio installed (you don't need the alsa-sndio element), run

Code: Select all

sndiod -r 8000 -dddd -a on -f rsnd/1 -L-

You may have to change the /1 to /0 ... according to which sound card is used. Add a background & if you'd rather not have to leave that running in a terminal.

You're now set up to both vnc for video (assuming that was already configured) and have sound forwarded from the vm fatdog to your other fatdog. You direct the sound destination with AUDIODEVICE ... for instance to run chrome on the server Fatdog (vm) you might enter

Code: Select all

AUDIODEVICE=snd@192.168.1.5/0 /opt/google/chrome/chrome --no-sandbox --force-device-scale-factor=1.5

and sound will be directed to the fatdog with that IP (that should have had that sndiod -dddd ... command run before starting chrome). The --no-sandbox chrome switch is only required if you are running chrome as root. The --force-device .... switch just scales chromes menu font size (use a value that better matches your preference, or you may be ok without even including that switch at all).

Being a vm its sound card is independent of the main system (host fatdog) alsa, so the main system wont hear the vm sound, nor will the guest hear the hosts sound. Someone can be using the host to play youtubes as can the guest (that's been remotely vnc'd into) do so simultaneously.

A alternative to Fatdogs tx/rx choice. On a local LAN I haven't noticed any difference between tx/rx or sndio. Testing sending sounds to two different devices, such as chrome sending to 192.168.1.5 and aucat -i /dev/random sending sound to 192.168.1.10 worked OK, just a case of prefixing each with the appropriate AUDIODEVICE IP value (and having sndio -dddd ..... running on both target systems).

The alsa-sndio module/plugin,that sits on top of alsa is good in that it enables sndio forwarding even though the program, such as chrome, hasn't been built with direct sndio support.

For me, using qemu's direct vnc option (-vnc :10 for instance) isn't as good as using tigervnc's vncserver ... that you connect to with tigervnc's vncviewer, where the keyboard mappings are more consistent (for me, when a @ is typed using qemu's vnc, it doesn't always work, or repeats that character rapidly). So I prefer to set qemu to -display none ... and within the guest fatdog run vncserver :10 (that uses port 5910) and forward that to the hosts port 55902 along with guest ssh (port 22) forwarded to host port 2222 ...

Code: Select all

qemu-system-x86_64 -m 4096 \
-usbdevice tablet -display none \
-audiodev alsa,id=snd0,out.dev=default \
-machine type=pc,accel=kvm \
-net user,hostfwd=tcp:127.0.0.1:2222-:22,hostfwd=tcp:127.0.0.1:55910-:5910 \

Remotely I ssh tunnel to that

Code: Select all

ssh -N root@host-fatdog-IP -L 5910:localhost:55910

and then run the remotes vncviewer localhost:5910 ... to connect. I've set /etc/ssh/sshd_config to use no compression, as tigervnc already handles compression (ssh compression would waste cpu cycles trying to compress already compressed data). Within tigervnc (F8 menu), I've deselected Auto compression and selected 'tight' compression level 2, jpeg level 8 ... which for a local LAN based pairing works well, even full screen videos/sound play OK, sound however will tend to lead video so there is some element of lip-sync drift. Adding a element of sound lag could potentially better align lip-sync but I don't know of any simple/low-cpu-cost means to do that.