Strategic Roadmap: 13 Core Enhancements for High-Performance Home Multi-Seat Scaling

[Dani6ca-T]

Hi! First of all, thank you for this amazing project. It fills a huge gap in the open-source self-hosted streaming ecosystem, especially for setting up efficient, low-cost home gaming networks using existing hardware.

To optimize this project for flawless home use—allowing a powerful host PC to seamlessly stream to older laptops, TV boxes, or mobile devices via Moonlight without performance degradation—I have compiled an updated 13-point architectural roadmap. This version focuses strictly on OS stability, dynamic provisioning, and native Windows driver automation, completely eliminating clunky third-party audio mixers like VoiceMeeter Potato or fixed donationware cables.

---

1. Version-Independent Session Unlocker (Migration to SuperRDP)

Description

The current implementation relies on hardcoded memory offsets to patch termsrv.dll (often using old RDPWrap-like methods) to allow concurrent local sessions on Windows Pro/Home. Every monthly Windows Cumulative Update changes these offsets, breaking the multi-seat functionality and requiring manual project updates. Furthermore, the default Microsoft RDP display driver (RDPDD.dll) frequently conflicts with Apollo's capture pipeline and custom virtual displays.

Proposed Solution

1. Migration to a SuperRDP-based Pattern Architecture: Instead of relying on static RDPWrap offsets that break monthly, implement or bundle a SuperRDP-style unlocker. SuperRDP uses dynamic assembly pattern scanning (signature searching) inside termsrv.dll to find and bypass concurrent session checks in RAM at runtime. This dynamically adapts to new Windows Updates without breaking code offsets.
2. RDP Graphics Pipe Suppression: Force Windows to completely ignore standard RDP virtual monitors and route rendering strictly through the physical GPU and the project's custom Virtual Display Driver from millisecond zero via registry overrides during seat deployment:

reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services" /v "fEnableWcm" /t REG_DWORD /d 0 /f
reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services" /v "fNoRemoteVideoCapture" /t REG_DWORD /d 1 /f

---

2. Automated NVENC Session Limit Patching

Description

Nvidia GeForce graphics cards carry a hardcoded hardware limitation restricting the maximum number of concurrent video encoding sessions (currently capped at 5 concurrent streams on latest drivers). When scaled to multiple simultaneous family users, an Apollo instance can fail with an explicit NV_ENC_ERR_OUT_OF_MEMORY or session starvation error if other users are recording, streaming, or running intensive encoding loops.

Proposed Solution

Integrate an automated driver patching utility (like the open-source nvidia-patch tool logic) directly into the installer or background optimization script block. The script detects the installed driver version, backs up the target encoder DLL, and dynamically patches the session limit restriction on the fly.

---

3. Dynamic Child-Process CPU Affinity Enforcement

Description

While the project successfully manages session lifecycles, it currently lacks dynamic tracking for child processes spawned inside the virtual seat session. When a user launches a heavy application or game launcher (e.g., Steam/Epic), the launcher spawns sub-processes (game.exe) that bypass the initial session core limits, leading to CPU resource starvation on the main host.

Proposed Solution

Implement a proactive process watcher inside the background service using WMI events (__InstanceCreationEvent) or Win32_Process tracking. The service should monitor any new processes spawned within the specific SessionId of the secondary seat and instantly force the target CPU affinity mask upon them, including all child processes dynamically:

Get-CimInstance Win32_Process -Filter "SessionId = $TargetSessionId" | ForEach-Object {
$proc = Get-Process -Id $_.ProcessId -ErrorAction SilentlyContinue
if ($proc) { $proc.ProcessorAffinity = $SpecificSeatCoreMask }
}

---

4. Secure Desktop / UAC Prompt Handling inside Isolated Sessions

Description

When a user in the secondary seat launches an application requiring administrative privileges, Windows triggers a User Account Control (UAC) prompt on the Secure Desktop. This causes the Apollo stream to immediately freeze (black screen) because user-space capture loops lose access to the desktop context. In some cases, the prompt is routed to Session 0 (Host screen), locking the secondary user out completely.

Proposed Solution

Implement a UAC interception architecture within the background manager:

1. Ensure the core orchestrator service runs under NT AUTHORITY\SYSTEM privileges.
2. Utilize the CreateProcessAsUser API combined with session tokens to inject a companion UI agent into the Winlogon desktop context of that specific session when a secure desktop state is detected.
3. Alternatively, provide a toggle in the dashboard to automatically adjust local security policies via registry for isolated sessions only, forcing UAC to prompt on the user desktop instead of the Secure Desktop:

reg add "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System" /v "PromptOnSecureDesktop" /t REG_DWORD /d 0 /f

---

5. USB Hot-Plug Event Handler for Active Sessions

Description

The current peripheral assignment matrix works well upon initial script execution. However, if a user experiences a temporary cable disconnect (mouse/keyboard/headset) or plugs in a new USB device during an active session, Windows automatically assigns the reconnected device to Session 0 (Host Console). This breaks the multi-seat isolation on the fly.

Proposed Solution

Introduce a USB Hot-Plug Listener inside the service utilizing Win32 device arrival events (RegisterDeviceNotification). The service catches the hardware ID of the reconnected device, checks the internal database to see which Seat this device was originally assigned to, and instantly forces the dynamic reassignment rule without requiring a session restart or manual script re-run.

---

6. Automated Network QoS Policy for Apollo Stream Protection

Description

Since both multi-seat users share a single physical network adapter (NIC), network congestion is a major risk. If one user starts downloading a game update in Steam or streams high-bitrate video, it saturates the network stack. This causes immediate packet loss, massive latency spikes, and severe stuttering on other active Apollo streams.

Proposed Solution

Integrate automated Policy-Based Quality of Service (QoS) rules directly into the MultiSeat setup logic. The service can use Windows Network QoS via PowerShell (New-NetQosPolicy) to dynamically prioritize Apollo/RTSP traffic or throttle aggressive background downloaders when an active stream is detected:

New-NetQosPolicy -Name "Apollo_Stream" -AppPathName "apollo.exe" -DSCPValue 46 -ThrottleRateActionBitsPerSecond -1

The manager can programmatically reserve a guaranteed 50–100 Mbps pipeline specifically for the streaming ports, lowering the network priority of other processes.

---

7. Multi-Session Power and Sleep State Orchestration

Description

Windows power management natively tracks user activity and inputs only on the primary console session (Session 0 / Host). If the main host user leaves the PC, Windows idle timers will trigger Sleep or Hibernation mode after the configured timeout. This abruptly cuts off secondary seat users who are actively gaming or working via an Apollo stream.

Proposed Solution

Implement an active power state preventer within the background manager. The service should monitor the connection state of the Apollo streaming instances. If a secondary session is actively streaming or receiving remote inputs, the service must programmatically block Windows from entering sleep mode by calling the Win32 Power Management API:

SetThreadExecutionState(ES_CONTINUOUS | ES_SYSTEM_REQUIRED | ES_AWAYMODE_REQUIRED);

Once all secondary sessions disconnect, the service releases the block, allowing standard Windows timeout policies to apply.

---

8. Dynamic Audio Provisioning via Windows DevCon API

Description

Relying on software mixers like VoiceMeeter Potato or rigid third-party virtual cables introduces unnecessary software bloat, licensing bottlenecks (donationware limits), and high CPU idle usage. A clean open-source architecture should provision independent virtual audio hardware natively and dynamically whenever a new seat is deployed.

Proposed Solution

Incorporate an open-source miniport audio driver sample directly into the MultiSeat backend asset folder. Utilize the Microsoft DevCon (Device Console) utility within the user creation flow to dynamically install a dedicated, independent virtual audio device for any newly registered seat on the fly (where X represents the Seat ID):

Programmatically inject an independent hardware-isolated audio cable node for Seat X

.\devcon.exe install vbaudiocable.inf "Root\MultiSeatAudio_SeatX"

The backend can then use a utility like EndPointController or direct registry manipulation to bind this cleanly spawned device (MultiSeatAudio_SeatX) as the exclusive audio endpoint for that specific Windows session ID, achieving 100% free, scriptable, zero-CPU audio isolation.

---

9. Manage and Create Windows Users Directly from Web Dashboard

Description

Currently, users have to manually open Windows Settings/Computer Management to create secondary local accounts and add them to the Remote Desktop Users group. This manual step breaks the automation flow.

Proposed Solution

Expose a "Create New Seat User" form directly inside the Web Dashboard. When the form is submitted, the Node.js backend can execute a secure PowerShell or cmd command under administrative privileges to provision the user automatically, dynamically scale variables, alongside the dynamic DevCon audio deployment from Item 8:

$Password = ConvertTo-SecureString "$UserDefinedPassword" -AsPlainText -Force
New-LocalUser -Name "MultiSeatUser$SeatID" -Password $Password -Description "Automated Multi-Seat Account for Seat $SeatID"
Add-LocalGroupMember -Group "Remote Desktop Users" -Member "MultiSeatUser$SeatID"

---

10. Single "One-Click" Windows GUI Installer (Inno Setup / WiX)

Description

The current deployment flow requires opening terminal windows, clone actions, running multiple .ps1 scripts, and handling dependencies manually. This creates a high entry barrier and is prone to syntax/execution policy errors.

Proposed Solution

1. Use pkg (Node.js packager) to compile the backend server along with the pre-built frontend (dist/ folder) into a single standalone server.exe. This removes the requirement for users to have Node.js installed globally.
2. Package the entire project using Inno Setup or WiX Toolset into a clean MultiSeat_Setup.exe.
3. The GUI installer will silently execute prerequisites (e.g., msiexec.exe /i "ViGEmBus.msi" /qn /norestart) and register the compiled server.exe as a native Windows Service automatically (sc.exe create MultiSeat...).

---

11. Advanced Virtual Network Interface (NIC) Isolation per Seat

Description

Sharing a single physical IP address across all sessions causes game launchers (like Steam, Epic, or Riot) to view active connections as coming from the exact same PC. This leads to local port collisions (e.g., local host binds on port 27015) when running concurrent instances of the same game within the household.

Proposed Solution

Implement an automated virtual networking pipe within the host configuration utility:

1. Automate the provisioning of Microsoft KM-TEST Loopback Adapters or Wintun/TAP interfaces via PowerShell setup routines.
2. Allocate dedicated static IPs (e.g., 192.168.100.10 + $SeatID) to separate seats dynamically.
3. Integrate ForceBindIP routines inside the dashboard launcher engine to inject and anchor outbound socket connections of game sub-processes strictly onto their designated virtual IP masks:

ForceBindIP64.exe 192.168.100.1X "C:\Games\Steam\steam.exe"

---

12. Cross-Session Clipboard Data Leak Isolation

Description

By default, standard multi-session environments sharing the underlying Terminal Services pipeline allow cross-session clipboard synchronization. If an administrative user on the host machine copies personal data, passwords, or authentication tokens into the clipboard buffer, any secondary user running concurrently on another seat can instantly access and extract that data via a simple clipboard read event (Ctrl+V).

Proposed Solution

Enforce programmatic data isolation by explicitly suppressing cross-session clipboard sharing. The orchestration engine must append restrictive local security policies directly via registry patches during the deployment phase of the multi-seat environment, cutting off inter-session data exposure completely:

reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services" /v "fDisableClip" /t REG_DWORD /d 1 /f

---

13. Interrupt Affinity Optimization (IntAff) for DPC Latency Mitigation

Description

When scaling to 3+ simultaneous high-bitrate streaming and gaming seats, the combined network socket load and GPU packet transfers generate an exponential number of hardware interrupts. Windows natively dumps the overwhelming majority of these device interrupts onto CPU Core 0. This creates a severe DPC Latency bottleneck, resulting in unpredictable video stuttering and audio desynchronization under full load, regardless of overall low total CPU usage.

Proposed Solution

Integrate automated interrupt balancing directly into the host optimization setup routines based on programmatic alignment structures. The setup utility should locate the active network adapter (NIC) instance path in the Windows registry and append an explicit hardcoded core mask, isolating network interrupt service routines strictly to non-gaming CPU cores mapped out in Item 3:

reg add "HKLM\SYSTEM\CurrentControlSet\Enum$PhysicalNicDevicePath\Device Parameters\Interrupt Management\Affinity Policy" /v "AssignmentSetOverride" /t REG_BINARY /d 0200000000000000 /f
reg add "HKLM\SYSTEM\CurrentControlSet\Enum$PhysicalNicDevicePath\Device Parameters\Interrupt Management\Affinity Policy" /v "DevicePolicy" /t REG_DWORD /d 4 /f

---

What do you think about utilizing Microsoft DevCon to dynamically provision audio endpoints per seat, dropping the need for VoiceMeeter entirely? I would love to hear your feedback on this!