Puppy Linux Discussion Forum

Thanks guys. It remains to be seen whether a remote desktop pair (of any protocol) will work with complex video editing in real time. Here again, the needs are generally parallel with gaming. Though there are some differences.
Some thoughts:
Resolution conversions occurring while editing in real time:

The Editor is rendering the track clips' resolution and converting to the Monitor window resolution
The Monitor resolution is running at the Host's machine's resolution, or less, depending on the size of the window.
The Client resolution is at whatever the remote desktop client software permits on that client machine.

So there's a lot of conversion going on. Monitor video resolution while editing does not need to be as high as the final rendered video will be. Reduction in any of the various resolutions will help prevent lag, as long as the displayed resolution in the remote desktop's window is adequate for the purpose.

Generally, in editing, you do want to be able to view the monitor full screen on the remote desktop, at times. As a result, the client should ultimately present a moderate resolution full screen, not necessarily the highest possible. This is different from gaming.

Video Cards:
I'm also thinking that high powered video gaming graphics cards may not be of much help for video editing in general. On the host, a lot would depend on how much a GPU offloads video processing from the main CPU. On a gamer card, there may not be much assistance for things like color correction, or dissolves, or fades because gaming focuses on different rendering tasks. Yet those are the most common processing requirements in video editing.

In fact, since a remote desktop editor is analogous to headless server operation, a video card is probably no help at all. In an ideal world, a graphics card would be able to directly interface to a client via a wireless protocol.

The wireless LAN:

Besides resolution and graphics processing, the most important final consideration in a remote desktop for video editing is LAN speed. Important to that are, the RD protocol chosen, wireless protocol, host and client RD applications, and the NIC hardware.

For wireless I've thought about whether ad hoc LAN connection would be preferable to communicating through a router. Internet authorities disagree about whether ad hoc connection is faster or slower. I guess the only way is to try it and compare. One advantage in my case for a router connection is that my wireless router is close enough to the host computer to use a wired connection. Thus no need for a wireless card in the host. However, I'm not sure what wireless protocols the router supports -- 802.11 ax would be preferable for higher speeds.

@vtpup

It's another game of "whack-a-mole" again. Something will always be the bottle neck, the trick is to determine what.

wizard

Tests:
1.) I was able to install Xrdp server onto an instance of Ubuntu server (Jammy, 22.xx on the gamer box, xfce4 desktop installed) and to access it via RDP from Fossapup 64 running Remmina on my Acer laptop (spec in sig, with an added i5 proc).

Performance: there was noticeable lag between the two computers (both wifi and 802.11n) and severe stuttering in Kdenlive monitor playback of a fairly simple test project. There was no sound on the laptop.

2.)A test of Anydesk 6.xx .pet running on the laptop and an Acer C720 puppy converted chromebook, both on Bionic 64:

Performance: lag between the two computers (both wifi 802.11n) was very slightly noticeable, and stutter in the Kdenlive monitor was somewhat noticeable, but not severe. There was no sound on the laptop.

3.) A test of Anydesk 6.xx .running on an instance of Ubuntu server (Jammy, 22.xx on the gamer box) and on the laptop in sig below w/ i5 proc running Fossapup64.

Performance: Couldn't determine because Anydesk on laptop complained it couldn't connect be to the graphic server e.g. Wayland.

Have you tried ssh (with the -Y or -X option) into the server and then start the program?
It seems it would use less resources than the whole remote desktop.
example: ssh -Y user@serverIP
then start kdenlive from the console.

Thanks Trapster. I tried but kdenlive was unusably slow. It was difficult even selecting a tool on the toolbar, like "Open Recent" etc.

I did a test today of different RDP clients on 3 OS's
Results:
Fossapup64/Remmina = slowest
Bionicpup64/Remmina = middle
Win 7 /Remote Desktop Application = fastest

None were suitable for smooth monitor playback (yet) with present low speed wifi network. (I do expect to work on the network speeds after deciding which setup to focus on.)

I also tested pixel color depth settings on Remmina in Bionic64 (not possible on Win7). I tried 32 bit color, 24 bit, and 16 bit. Speeds definitely improved as the color depth was reduced. 16 bit color was surprisingly acceptable in monitor playback appearance, and when the monitor window was small, it actually presented a nearly smooth playback experience. But the small size of the window would make editing difficult.

I'm going back to testing Anydesk for some final comparisons.

I've deleted the Ubuntu Jammy Server from the desktop, and installed Ubuntu Bionic Server, mainly because of the Wayland issue. Bionic was released with X11 as default. This should allow Anydesk to run as a test.

I also hard wired the box ethernet. The laptop will still be wireless.

Presently installing xfce4, Xrdb, and Anydesk for tests.

It's been a day full of problems. First, Ubuntu Bionic wouldn't open xfce4 desktop. Seemed to be a complex of permissions problems -- I tried to troubleshoot, but it was a rabbit hole, so I gave up on it after an hour. That basically ruled out Xrdp, since it needs to open a desktop, and I wasn't interested in trying to download Unity, etc on the 350 mBs speed service that we have here. Gave up on Ubuntu Bionic Server edition.

Btw, a few requirements and discoveries for running Xrdp over the last few weeks: you need to run:

xrdp-keygen xrdp auto

after installation of Xrdp

also add this line to the end of /etc/xrdp/xrdp.ini:

exec startxfce4

if for example your desktop is xfce4..... or whatever starts your desktop otherwise. It's a version of the startx command.

Also you need to log off of the remote computer. Can't have a double login. The desktop does not have to be running on the remote, you are starting up a new instance through Xrdp.

Firewall needs port 3389 open to your LAN range, and I think SSH ports also.

I thought all this would help run Xrdp on Puppy, but attempts with adding

exec xwin 

to the init file and "exiting to prompt" didn't work.

Okay so Xrdp was on hold today, so I concentrated on Anydesk in Bionicpup64 on both laptop and server box. Server box is now hardwired to network. I was able to get very good (fast) response to playing a high-res video earlier in the day, which was very encouraging. However several hours later, the same video tried again crawled slowly in low res. Why the difference?

during the day I had changed Anydesk versions from the pet 6.2 to the tarred portable 6.2 ....maybe that was the cause? (BTW when I did a Settings>About on the 6.2 .pet version it turned out NOT to be 6.2 but 6.1x. Maybe the older version is faster?) Or the .pet is faster compared to the portable? Dunno, but I will try reverting to the earlier .pet to see if it makes a difference.

Also BTW, Anydesk itself recommends that to increase speed on a LAN you go to Settings>Connection and set: Direct Connections -
https://support.anydesk.com/knowledge/a ... connection

But there ain't no such animal on the puppy Anydesk 6.2, or even 6.1x versions I have.

So I'm back testing Anydesk versions.....

By last evening I had connected both the laptop and the server box to LAN by cable through the DSL modem. I wanted to eliminate wireless as a check on communication speed. The rest of the family was out, and their computers/phones were not on the network. The DSL modem was a Comtrend brand, probably about 4 years old.

As hoped for, 1080p video played well, as transmitted through AnyDesk, in any Puppy version of that program, and also in the Kdenlive monitor. This meant that wireless transmission was the main bottleneck, also not surprising, considering the older 2.4gHz nics.

Audio did not transmit, however, and my guess is that the culprit is AnyDesk's dependency on PulseAudio. Likewise, XRrdp also uses PulseAudio. I did not have Xrdp running however to test it's speed, since I've yet to get Xrdp running on Bionicpup64. I did not try starting AnyDesk with the asound option (used with Firefox to get audio, which also expects PulseAudio).

When family members returned home and local network traffic increased, AnyDesk again slowed down, and video playback and editing response was poor. This was a surprise, as I thought the DSL modem/router would just pass wired connections on the LAN straight through, rather than affect them.

Solutions (for a cable connection) would be to install a true high speed network switch behind the DSL modem. , I'm not considering that, since we're soon going to be getting Comcast Xfinity in our area, and will be changing modem boxes.

The other possibility, just for testing purposes, would be to make up a null modem cable and connect the two computers directly. I won't do that either, because the ultimate intent was for a wireless connection for the laptop.

A wireless card upgrade for the laptop to 802.11 ax (Wifi 6) does seem in order -- especially with the anticipated new cable service. Also, If the new cable box is fast enough, a separate switch won't be needed for the LAN.

Conclusions so far, AnyDesk is capable of processing 1080p fast enough for editing purposes, assuming the network supports the speed needed. On a Puppy client, audio is still not coming through, probably because of the app's dependency on PulseAudio.

Xrdp server does not run on Bionic64 or Fossa64 Puppies so far, though the Remmina client is functional on Puppies. Xrdp does run on Ubuntu Jammy Jellyfish Server edition with an installed Xfce4 desktop. That server version, however does not function with AnyDesk, since Jammy uses Wayland instead of X11.

Ubuntu Bionic Beaver server might be usable with AnyDesk, since it is X11 by default, but there were problems setting up a minimal desktop (Xfce4) with it. No other desktops were tried. Jammy Jellyfish might be usable with Anydesk if an option to switch to X11 from Wayland is present. That option is apparently available in full fledged Ubuntu desktop edition, not Ubuntu Server edition running Xfce4

So the working choices so far are AnyDesk on a Bionic64 Puppy server, or Xrdp on an Ubuntu Jammy server. Both can be accessed by Puppy clients.

Great stuff @vtpup

You might consider trying Xubuntu 18.04 or 20.04.1, come with xcfe, as server.

Thanks
wizard

Thanks Wizard, had the same idea -- I did download Xubuntu 18.04 last night. That should be X11, I believe. But 20.x would likely be Wayland. I'll try setting it up later today and running Anydesk and Xrdp on it.

I've got to now take into account my home LAN traffic in any comparison of speed. Most of what I said before my last note here didn't take that into account, so performance comparisons are inaccurate. I guess ideally I would make up a null modem and do a wired comparison.

Xubuntu 20.04.1 should still be x11, no wayland until v22.

wizard

Well finally a true side by side comparison of Xrdp/Remmina vs Anydesk using the same server, and network connections and no other traffic on the LAN!

Xubuntu was a bear to set up to run Xrdp, but I finally managed it after dealing with some documented bugs.

Both servers ran on Xubuntu 18 Bionic and both clients ran on Puppy Bionic64. LAN connections were ethernet and handled by the Comtrend DSL modem/router.

Differences in operation:
These two remote desktop pairs operate very differently. The AnyDesk pair allowed access to an already running desktop. Both the user on the server and the client saw and could perform operations on the same desktop simultaneously. No user/password authentication was required for access, in the default setup, though it could be added. All that was required to connect was knowing the numeric address of the server, making an access request, and then active agreement by the server machine's user.

On the other hand the Rdp pair I tested could NOT access the same desktop simultaneously. I had to log out of the server session before I could log on with the client. At least that was the requirement if I tried to use the same username and password. Double logins are not permitted. When you do log in with the client, the server seems to spawn a new desktop. That desktop may look different than the one you logged out of, depending if customized. The new instance looks to be an entirely new default desktop

I don't know if this is simply true of the Xrdp/Xubuntu environment, or whether it is true of all rdp server programs. I suspect other rdp setups may allow simultaneous access to the remote desktop. I think the main reason I was limited was that I had created only one user.

Likewise, I could not log into the server desktop while sitting in front of it unless I had explicitly logged out of the remote desktop via the client machine. Simply closing the client window DID NOT log me out of the server's remote desktop, and I could not log into the server machine until I had re-enabled the remote desktop, and properly logged out. Again, this probably would have worked better with two separate users, though presumably they would see two different desktops. I don't think two users can see the same desktop.

So, I'd say AnyDesk is better at doing things like IT troubleshooting with present users, training setups, etc, since they can simultaneously access the same user desktop.

Xrdp/Xubuntu server, on the other hand is better suited to everyday use of applications run on a remote desktop server from a client machine. And it seems especially suited to a mutlti-user system. A one user per desktop configuration is obviously more secure.

For my use, Xrdp is the model I'm after -- a multi-user server for running applications on a higher powered machine than my laptop.

Performance:

In side by side tests in the equipment and network outlined above, Xrdp was greatly superior in speed and appearance. There was no comparison in quality and usability of the transmitted desktops. Anydesk's desktop had a blurred quality with very small hard-to-read type in its default configuration. Image sizre and quality could be adjusted to some extent through various display settings but none of them was as good as the remote desktop's monitor, or even my laptop's ordinary display. It was just plain hard to read and hard to work with. Speed was poor with a 1080p test Project, and the monitor screen playback jumped around. There was a lot of lag even for doing simple desktop operations.

My guess is that the lower quality of AnyDesk images resulted from the demands of presenting a simultaneous screen on the remote and the client machines, plus dual control access, and the obvious use of compression to speed transmission. Image quality and resolution are lost in the process.

Xrdp's desktop in Remmina on the other hand was clean and legible, filled the screen, and color rendition and clarity was equivalent to the laptop's best resolution. It was indistinguishable from a program running on the laptop. Speed was adequate for video editing with the 1080p test project in Kdenlive. The server screen only showed the login prompt, and wasn't required to display what the client screen was showing. That likely reduces cpu overhead and transmission bandwidth, as a guess.

I'm hopeful that with a modernized LAN and wireless card that speed will be improved further for faster frame rates or higher resolution. But as is, it's workable. On the other hand, AnyDesk is not. It's logical application is IT support or remote KVM type server access, maybe, but it can't meet the difficult demands of video editing, at least with my equipment..

The only problem left to solve for me now is the lack of audio. Lack of transmitted sound was the case with both remote desktop protocols, though both are supposed to be capable. The problem lies most likely with the clients running on Puppy, as both server systems seem to be using PulseAudio. I'm hoping experimentation with workarounds like "asound" will solve it.

Anyway, there's enough progress now to be hopeful this will work, and to focus on one protocol.

...It's logical application is IT support...

Correct.

Wow. This is an excellent report. Well structured and well presented.

There seems to be 2 schools of thought seen in XRDP use/users.

• sound outside of the RDP protocol stream

• sound with the display, together, in the RDP protocol stream which should yield superior performance over the former

It use to be that the XRDP author was available. But, not sure if that is true anymore. Yet, I feel questions via the XRDP GIT might be more accurate in how-to with sound, while at the same time, Ubuntu forums are also responsive: For the 2 problems you have surfaced: Sound and Wayland. This open-source is still developed and maintained.

Ubuntu users, particularly, have been using XRDP for a decade or more; as, it is embedded in their Edubuntu offering used in schools across the world. It should, I think, work properly in the current Edubuntu while I have not tested recent ones in years.

I hope more forum members see the advantage that you are demonstrating for use of the power our 64bit PCs provide and the options that home LAN use configurations give us. A properly setup server would ONLY need clients to do EVERYTHING a single PC does, but for many users. This type of thing, users like myself has done for 20 years for business and home user setups. This reduced their needs to ONLY maintain (ie "do maintenance") a single server while the clients can be anything yet no need to do any maintaining. The clients by way of this configuration get a complete PC desktop as if it was installed on their PC in front of them...not knowing that the PC is coming from the Remote Desktop Server somewhere else in the home. Thus, "1 PC server many, which each many doing something different at the their individual work-pace."

Great idea and great effort, thus far.

Thanks for this.

BTW: @goingnuts addressed this in PUPPY forum of the past. Not sure if he's still active. ALSO, @jamesbond was a leader in this on FATDOG some time ago.

@vtpup - looks interesting. Below is pic of my Chromebook Crostini (Debian Bullseye) install option. Many Puppies already have some of the needed packages.

As I remember from the past, there is nothing stopping you from testing the server function and the client function on the same PC to accertain functionality. If it works locally (via port 3389,of course), it WILL work across the Home's LAN.

Hope this insight is helpful for testers.

Thanks Clarity and Ozsouth!
Ozsouth, I didn't have problems installing Xrdp in 64 bit Bionic or Fossapups. Nor in actually getting them running and communicating with an rdp client (Remmina). Xrdp put up its login screen on the clients, which proves that they were communicating. The problems start after you attempt to log in.

These are the possible areas of exploration to make Xrdp work with standard Puppies:

1.) We now understand that you have to log out as the user on the server machine if you want to log in as the same user through the client machine. Since puppy is mostly a root user OS, logging out as root user is not necessarily simple. In fact after dropping to prompt on a client (running Bionicpup off of a thumbdrive in case of accidents) I tried logging out as root, which seemed to work. BUT I was never able to restart the desktop again with the xwin command, even after logging in again as root.

This seemed a permanent change (at least in the pupsave file). BTW, I wouldn't try this on a valuable installation, as a result, unless someone comes up with a way to restore functionality. (EDIT: thinking about this later, perhaps I wasn't actually logged in again as root because an attempted root login from the rdp client was in effect at the time, and again, double logins don't work.......hmmmmmm...)

2.) Xrdp needs a way to start a puppy (jwm) desktop instance after the login. I assume using the command "exec xwin" would do that, and added that line to the end of the /etc/xrdp/xrdp.ini file. Similarly "exec startxfce4" was a necessary addition on the Ubuntu server trials, but apparently was unnecessary in the Xubuntu server trial.

3.) Security keys. As mentioned before, you have to install RSA keys after installing Xrdp by running the command "xrdp-keygen xrdp auto".

4.) SSL key and permissions: There is an existing SSL key in Ubuntu(s) which doesn't exist in Puppie(s): the /etc/ssl/private/ssl-cert-snakeoil.key, Also to allow access to it on Ubuntu servers you have to add the xrdp group to the ssl-cert group with "adduser xrdp ssl-cert". I don't know how to address either of these issues in Puppies.

5.) Specific to the 18.04 Bionic Ubuntu/Xubuntu versions there is a bug which prevents Xrdp from installing properly with dependents. There is a workaround which involve re-installing xorg components, as described at the end of this article

https://c-nergy.be/blog/?p=13390

I have done the workaround in Xubuntu, but not tried it with Bionic64 (18.x Ubu) puppies.

@vtpup

Lack of transmitted sound was the case with both remote desktop protocols, though both are supposed to be capable.

I can confirm Anydesk audio works with the MS Win versions, although I have not critically evaluated it.

My XRDP installs so far have only gotten me to the signin/black screen. Will now try a Xubuntu 20.04.1.

Great work vtpup, you've increased all our knowledge a lot.

Thanks
wizard

correction to my faulty memory typos prior:
apulse
not asound

Clarity wrote: ↑Fri Aug 26, 2022 4:36 am

There seems to be 2 schools of thought seen in XRDP use/users.

• sound outside of the RDP protocol stream

• sound with the display, together, in the RDP protocol stream which should yield superior performance over the former

While I was initially thinking of using a Bluetooth headphone set from the server as a workaround for the sound issue, I now think that would be problematic in a video editing setup.

If there was detectable communication lag, the sound would be out of sync with the visuals, so editing in-points and out-points wouldn't be accurate.

A complication in my own sound troubleshooting: I don't know for sure if the problem is no sound on the new server box hardware, firmware, OS, connection to XRdp, or whether it is Xrdp itself, or whether it is in the Puppy-Remmina end.
In fact it could be all of the above!

I did two brief tests to the server:

1.) running the Bionicpup64 client as

apulse Remmina 

Result: no sound

2.) booting Win 7 and trying Remote Desktop:
Result, again, no sound

I would have expected the second test to have worked, assuming Xrdp can send audio. But maybe my server box isn't set up right, yet?

EDIT: According to the official site Xrdp does support audio redirection: http://xrdp.org/

EDIT2: Yes I do seem to have a sound out problem with my new server box on Xubuntu 18.04. My only output device listed is a dummy device. I'm troubleshooting now......

I've got my server box hardware and OS working well with sound, and have tried a lot of things to get sound going through xRPD, to no avail, on both Puppy and Windows clients. I''m 90% sure the problem is with the instance of xRDP from the Ubuntu 18 repositories.

I've found a xRDP installation script, which compiles xRDP onto Ubuntu, rather than running with a pre-compiled binary. It does lots of work to set up xRDP and specifically can install sound as an option.

The script is here:
https://c-nergy.be/blog/?p=18205

I think I'm going to uninstall xRDP and then run the script to reinstall it. Fingers crossed......

Because the Xrdp installation script was applicable to Xubuntu 20.x and above, I downloaded that version and replaced the 18.x Xubuntu version. Then ran the xrdp installation script script with the -s option for sound compilation.

Af first sound didn't work again in Puppy/Remmina, but I was seeing on the server's mixer panel that xrdp sink was listed as a sound device. And while playing I could see it's level display moving.

I tried connecting then via Win7, but for some reason it had authentication problems (first time)

Returning to Bionicpup64/Remmina, I changed the client sound setting from Low quality Local to just Local, and suddenly, sound worked!

Man what a long haul, but gratifying to get this going.

Should have gotten sound, OOTB, on the Windows client as well. Hummmm???

vtpup wrote: ↑Sat Aug 27, 2022 12:16 am

Man what a long haul, but gratifying to get this going.

Excellent!

Also the path getting there is documented in this topic and is valuable knowledge and experience

Thanks Rockedge. Clarity Win7 client didn't want to authenticate, so not able to even test sound. This is old Win7, and not updated for years.

As an assistance to anyone else who wants to carry further the attempts to get xRDP (the server) running on a version of Puppy, here's a possible workaround for the one user per desktop problem. This problem evidences on Puppy because normally it's a single user root system. I have not tried to create or use a second user in Puppy for running xRDP, or for accessing it from a client.

Here's the possible workaround:

https://c-nergy.be/blog/?p=17371

In fact the best source for xRDP information is the same website blog, "Griffon's IT Library". He's actively working on xRDP solutions and has created compiling and installation scripts that work extremely well in ubuntu and many other debian based linux versions.

https://c-nergy.be/blog/?cat=79

Post follow-up follow-up : I was successful in installing and running Xrdp in DebianDog Bookworm as a multi-user multi desktop server. I've put a brief description in the DebianDog section of the forum, here:

http://www.forum.puppylinux.com/viewtopic.php?t=6767

EDIT: But sound does not work

Now have XRDP running on DD Bullseye, this time with sound:

https://forum.puppylinux.com/viewtopic.php?t=6780