Fatdog Client remote desktop to Fatdog server XRDP

[Clarity]

The following was posted on the 16th. Recently tested, no sound.

Can XRDP (Fatdog repository) carry BOTH the video & audio on its 3389 port streams? On any port streams?

It offers VNC console and audio in the session.

Thus, if you have a Youtube browser active on FAT (the "server") your can both see and hear what is playing at the Slim (the client).
Thus, if you have a multimedia file playing in any desktop on the server, you'll get the full experience on the client as well.

Rephrased: Everything that you would get when sitting at the server's console would be EXACTLY the same when client is running the RDP session with the server.

The beauty is a single product XRDP providing a compressed full desktop experience at clients running connectons to the server. VNC has been a great product for mere desktop viewing for years. But it has "stated" that it has NO intention for change to support audio. So, a full desktop connection in this decade is needed!!! MS has had the full desktop remote experience for 25 years with RDP in their 1995 Windows.

I think I saw a thread where @jamesbond set XRDP up somewhere, but I cannot find it.

On the old forum @goingnuts posted Puppy Linux work done for successful XRDP use.
XRDP's author has posted here (pay-attention to its GIT development).

Question
As it appears everyone who uses the XRDP, available in repository, can get the video from the remote FATDOG (server), but has anyone gotten sound in its remote session stream?

XRDP.jpg (17.03 KiB) Viewed 1260 times

As depicted here, the SERVER component is all that is needed if it delivers the full desktop

Yet, sound is missing when the client connects.
Edited: AND the link to XRDP Open source posted for reference 2 sentences above in this post.

[s243a]

Have you scene this thread:
"Remote Sound with sndiod"?

[Clarity]

REASON: Its almost 2021. My PCs do NOT resemble anything my PCs of decades ago had in abiliity. Browsers have also change considerably for better, safe transports.

Some/many/most of us have machines manufactured within the last decade with so much power that they can support (for example):

• a host user sesssion on its console on the single PC

• Have many desktops running in the host session on the single PC

• Run several browser sessions with each browser having multiple tabs open on the single PC

• Sharing files with other LAN users from the single PC

• 1-5 KVM guest sessions on the single PC

..... While still having processor, memory, and storage in abundance.

That example workload shows the extensive power we have today that was NOT even a dream 2 decadess ago when Puppy started.

Today going into next year, I am hopeful to be able to finalize having a FATDOG server where I can remotely connect and have a "true" Remote session via RDP with sound and video from the FATDOG server.

This would mean that we can run a FATDOG server and user PCs of lesser means running Linux/Apple/Microsoft/ChromeOS where they use their available RDP clients from those manufacturers to connect to our FATDOG server for full session operations as if we were sitting at its console. Puppy has had an RDP client available for years. Apple has had it for decades. RDP (an international protocol standard which encrypts and carries video and audio) has been with us for 25 years.

A full featured use of the standard would be welcomed, I feel, if it was available and operational. I am sure others, too, can think of their own uses if this was operational.

This is the reason I find this an important need and am requesting help-guidance. Thanks in advance for ANY helpful attention to this thread.

[Clarity]

I see XRDP has recent deveopment on its GIT thread. Is there some reason or missing component that does NOT allow FATDOG to have the sound operational in its XRDP implementation.

Important: For those who have NOT tested, XRDP in FATDOG carries video to the RDP client. I have tested this from a PUP as well as a Windows PC using their built-in RDP client(s). Users install NOTHING! Just run the client to the FATDOG server.

[wiak]

https://github.com/neutrinolabs/pulseau ... iki/README

xrdp implements Audio Output redirection using PulseAudio, which is a sound system used on POSIX operating systems.

So actually much like what step is discussing in his PulseAudio thread.

I've read however that PulseAudio audio redirection generally uses TCP protocol (though I think there might be alternative arrangements possible - UDP would not require retransmissions so would not cause the lags from buffering that TCP needs - but syncing would require some kind of timestamp additions/control) and is quite heavy on bandwidth. Other simpler audio redirection approaches may work better on busy networks or non local LANs (particular problem being to get video/audio synchronised).

See: https://gavv.github.io/articles/new-network-transport/
https://news.ycombinator.com/item?id=19818078
https://roc-streaming.org/toolkit/docs/ ... oject.html

I know nothing more, though agree it is an interesting area for experimentation/implementation nowadays...

[user1111]

I've read however that PulseAudio audio redirection generally uses TCP protocol (though I think there might be alternative arrangements possible - UDP would not require retransmissions so would not cause the lags from buffering that TCP needs - but syncing would require some kind of timestamp additions/control) and is quite heavy on bandwidth. Other simpler audio redirection approaches may work better on busy networks or non local LANs (particular problem being to get video/audio synchronised)

Merry xmas wiak and all. Locked in the bedroom, awaiting the result of a 24 turn-around Covid test I've been trying out EasyOS 2.5.5 and vnc + sndiod, which like when using Fatdog to do the same also works well for me. When across the room, physically separate server/client, there is a slight lip-sync delay when viewing people talking type videos. When kvm/qemu'd - all one the same device, there's no apparent lag.

x0vncserver + sndiod would seem to work very well. x0vncserver forwards X to the local end X, so playing the likes of SuperTuxKart is fine. sndiod is very simple and hence quick, quality is good, but lacks the 'additionals'. Just a simple sound server that you set up a listener at the local end (sndiod -d -a on -f rsnd/1 -L- ... type syntax) and on the remote/other end you just forward the sound to that (AUDIODEVICE=snd@192.168.1.5 ... type syntax). Lowish bandwidth also, whilst still being good quality (48000 default sampling rate). i.e. tigervnc + sndiod can work (very) well. Pulseaudio adds all of the extras however, so XRDP in using that would be better in that respect. I've yet to see/test however using that for the likes of when playing SuperTuxKart, suspect it would be fine.

Presently when having both alsa and sndio its whatever grabs the sound card first from where sound is heard. OpenBSD (using sndiod) kvm/qemu with Firefox playing a youtube, along with EasyOS Buster container playing a youtube in seamonkey and you'll hear just one or the other, not a overlay of both. With XRDP (pulse) I suspect you'd be able to hear both. Similarly for recording/mic (running zoom on a remote box/whatever), likely XRDP might be the way to go for that. As such step's recent pulseaudio advances for Fatdog are great.

[Clarity]

Hi @rufwoof, I am curious. Which RDP client are you using; MS, Apple (which is really their MS collaboration) or one of the Linux RDP clients?

I'm sure you know, that MS has the client (and server component too) built-in. If Linux, is it RDesktop, FreeRDP, ... ?

Thanks for your help

[Clarity]

The 1st post on this thread may NOT be clear enough.

It is my hope for a server implementation where NO CLIENT needs install anything to login and get a "Complete" multimedia desktop. Thus, your user LAN PCs which are FATDOG/Windows/Mac/Linux have RDP or Rdesktop built-in to be used as the client to connect to FATDOG server.

Again, this is a hope.

Today, in FATDOG XRDP (making it the server), we can connect, BUT are missing the sound component at the LAN clients.

[user1111]

Hi @rufwoof, I am curious. Which RDP client are you using; MS, Apple (which is really their MS collaboration) or one of the Linux RDP clients?

I'm sure you know, that MS has the client (and server component too) built-in. If Linux, is it RDesktop, FreeRDP, ... ?

Thanks for your help

I haven't used RDP Clarity. All conjecture so far. For me, Fatdog running sndiod and kvm/qemu, that boots OpenBSD - where firefox ..etc. within OpenBSD forwards sound to the Fatdog sndiod ... works 'good enough'. I do like the flexibility of being able to send sound more direct i.e. if I run video using x0vnserver/tigervnc viewer between the kvm/qemu'd OpenBSD and another OpenBSD box, but where the sound is direct from that 'another OpenBSD' box and Fatdog (laptop/alsa). sndiod code is also simple/small enough that I can understand it, in contrast to pulseaudio being more like systemD (loads of code/complexity).

[wiak]

sndiod code is also simple/small enough that I can understand it, in contrast to pulseaudio being more like systemD (loads of code/complexity).

If only time weren't always too short I'd love to take time to study more about pulseaudio, jack and similar (including comparing with more direct mechanisms such as sndiod). I have heard that jack can be used to network sound too, and more efficiency (less latency) than via pulseaudio, but I don't know the details or if true. I have used jack once (because I was experimenting one day and found it was easy to set up under WDL_Arch64 because upstream Arch, per usual, provides such great configurations, and wiki...), but though I managed to use it, I can't say I took enough time, or paid enough attention/research to actually understand it all - though I got the idea it was basically simple to use - patchboard kind of thing - pulseaudio a bit more of a mystery at this stage certainly (though what works just works out-of-the-box for me, and impressively so). The more we understand and can implement and use, the more satisfying it is (at least that's how I find it) but hard to keep track of everything (and not forget what I already for now at least know... cherrytree notes does its best to keep my 'memory' on track though... Unfortunately, I'm always doing too much and in too much of a hurry to use cherrytree in an organised way - I just copy and paste links and brief notes all over the place in random fashion and rely on "Search All Nodes" to find things... sigh).

[rcrsn51]

I have good results using the trx method to stream audio, although I never tried it with a remote desktop app.

[wiak]

I have good results using the trx method to stream audio, although I never tried it with a remote desktop app.

trx sounds interesting/simple. http://www.pogo.org.uk/~mark/trx/

The main issue in audio/video over a network is keeping them in sync, particularly on noisy networks where packets get dropped. Timestamps in the used protocols would be likeliest to succeed (similar to video subtitles theoretically helping to keep the text in sync with the video - theoretically... depends how implemented I guess). Some non-synch okay for some uses, but fast gaming might sometimes need accurate audio/video sync (depends on the game I suppose). Short audio/video calls possibly do not result in much lag, but long term live transmission might lead to issues if no timestamps used to correct matters.

[rcrsn51]

I tested this with tigervnc. The remote machine is running tigervnc-standalone-server and trx-tx. The local machine is running tigervnc-viewer and trx-rx.

From the local machine, I can play Youtube clips on the remote machine. The audio stays in sync close enough to be acceptable.

[Clarity]

For those of us who have used Remote Desktop solutions in MS & Apple & IBM, the RDP protocol keeps the desktop connection bottled together in the stream vs having to run several apps to doctor a stream for acceptable transmission to a remote. This is not new technology as the protocol has been perfected for over 30+ years from Novell to MS to Cyrix to now.

Are we saying it is impossible for XRDP or any RDP protocol server function in FATDOG to provide a complete protocol tunnel between the client machine where they do not install anything and the FATDOG server? As you know, RDesktop is there in LInux clients (with this PUP member showing in his #6 bullet using XFreeRDP), as well as the MS & Apple RDP clients which connect to FATDOG.

• Or is there a component missing for FATDOG's RDP to allow audio in the tunnel?

• Or is there another way to have a RDP server on FATDOG with a complete tunnel implementation?

• Or is this a problem in the RDP clients missing some request change to gain a complete tunnel implementation"

• Or, just maybe Linux offers some other manner (say SSH with bells and whistles) at both ends to provide a compressed encrypt session-tunnel emulating the RDP protocol?

Curious in what might be a best approach to haveing a Remote Desktop Server where the existing LAN clients need not install anything.

Edited: If my measures are reasonable and accurate, my little FATDOG machine could support more than a half-dozen clients connected and not break a sweat. This was a apples to oranges test of "guessing" when the FATDOG XRDP server is active with its limited functionality and no audio to the simultaneous clients connected and running multimedia apps on this server (only have 6 to test). Switching the server from FATDOG to MS with its RDP server, the 6 connect and run similar with both audio and visuals from the Multimedia app. I DONT EXPECT FATDOG to be a MS and FATDOG has always been and continues to be my preference. These 2 test for CPU performance was done to merely see if 6 desktop clients could get the expected behavior on this particular PC without bogging the hardware.

Edit#2: The FATDOG current abililty to yield a XRDP desktop to RDP client PCs appears to be a much simpler solution at BOTH the installation level as well as the client PC to giving a remote desktop. The effort for naive users to setup and manage SSH or even VNC is quite a different experience. Simplicity is better: Namely start XRDP and add your userIDs for LAN individual. That's all there is.

[Clarity]

This suggest-indicates audio encapsulates in the protocol stream.

[user1111]

If my measures are reasonable and accurate, my little FATDOG machine could support more than a half-dozen clients connected and not break a sweat. This was a apples to oranges test of "guessing" when the FATDOG XRDP server is active with its limited functionality and no audio to the simultaneous clients connected and running multimedia apps on this server (only have 6 to test).

Hi Clarity. For me, a Fatdog server running vncserver and with three different userid's logged in displaying separate seamonkey instances ... less than 1GB ram and low cpu. i.e. multiple instances of each userid being ssh'd into and run 'vncserver' and then other boxes running vncviewer into those separate instances.

That's with 'direct' boot i.e. fd64.sfs NOT copied to ram. I'm tending to setup Fatdog, with multi-session saves and then once configured I merge (unsquashfs the fd64.sfs and then unsquashfs the base multi sfs and then the save multi sfs on top of that using -f -d squashfs-root parameters ... and then form a new fd64.sfs from that combined set using lz4 (which is very fast) - i.e. the multi-sessions can then be removed, somewhat like having 'remastered' the fd64.sfs). That keeps initial boot ram utilisation very low (down in the 200MB region) leaving more ram available for other things (as fd64.sfs isn't being copied into ram). So I guess with that sort of setup it perhaps also supports 6 sessions (plus the main session) on a 2GB RAM system. Fundamentally I guess RDP or vnc or whatever would tend to be similar as they're all doing much the same thing of transferring the framebuffer/display to a remote system.

Of course if the browsers each started loading up heavier sites, playing youtubes or whatever, then of course ram utilisation/swapping could soar considerably. I do allocate a large swap partition so I suspect things would keep working and could perhaps support a couple of concurrent heavier usage and still remain responsive.

I have less need for audio as primarily they're just throwaway (ro sessions - booted and no save when closed) browser sessions, for the purpose of 1. so web sites see that servers fingerprints and not the actual devices fingerprints; 2. choice of pre-established routings i.e. each uses different socks5 proxies (so web sites don't see the servers IP); and 3. ISP doesn't see dns lookups nor traffic, only the ssh tunnel connection to the socks5 proxy. Which also provides a means of separation (security) of data and keys.

I've always preferred the approach of assuming a system will be compromised and seek damage limitation over that of assuming a system is secure. Boot a clean throwaway session and go direct to trusted sites ... and the tendency is towards not having been compromised. Data/keys separation is a barrier to having that data/keys being compromised. Using a DIY VPS setup and socks5 is a tracking/profiling/privacy barrier. vnc is also commonly available across a wide range of devices/systems.

[Clarity]

Yes, I do understand what you share. Yet, I am curious to having a complete and full desktop as if I was sitting at the FD monitor which has speakers.

If anyone gets a chance, try XRDP (latest version, if possible). Then use your client PUP/MS/Apple to connect for the remote experience without installing anything (the client comes within the OS).

All is built-in from a security standpoint on the server. And its stream is encrypted, both ends.

Curious in what is seen

[Clarity]

In review of the XRDP GIT site, I find these 3 XRDP write-upa for which I do not have the skills to build for our DOG.

1. xorgxrdp

2. xrdp

3. and for audio, pulseaudio-module-xrdp

Help is needed for use in DOG