search

kokoko3k / ssh-rdp

Real display ssh based remote desktop
GNU Lesser General Public License v3.0
141 stars 30 forks source link

added an create option for pasource which creates a dummy sink and di… #4

Closed nicman23 closed 3 years ago

nicman23 commented 3 years ago

…sables the rememberance of sinks in applications.

this makes newly launched applications do to the dummy sink.

after it restarts pulse to clear settings.

kokoko3k commented 3 years ago

Hi, this is interesting, but i find it troublesome in the part where pulseaudio is restarted, because doing that would reset any (runtime) change made to pulseaudio outside his configuration files. If the goal is to keep the remote part quiet, then probably switching the alsa device to a mute state would suffice? What exactly is the usecase here? Are you sure there are not simpler ways to achive that?

PS: Your PR also reminded me of a feature i never implemented, generic --execute-remote-pre-script and --execute-remote-post-script options.

nicman23 commented 3 years ago

the use case is that you do not have to bother with pulse sinks in complicated setups and muting

the restart can be worked around with removing the runtime changes but imo it is fine at least for my use case (mostly gaming)

kokoko3k commented 3 years ago

I think the use case is pretty peculiar, so i made this commit that should give you the ability to do what you want: https://github.com/kokoko3k/ssh-rdp/commit/d1477cd7a3b9affe81efdf703a517d76b79e9079

Could you please test it and report back if it works as intended?

nicman23 commented 3 years ago

eh not really, the other reason is that i can specify the channels needed and sample rate as my default is 192000 which for some reason makes pulseaudio very unstable with ssh-rdp but is fine with 48000

i forgot to add the sample rate + channels thing as i edited the pulse conf. if you are interested i can. else i ll just use my fork.

kokoko3k commented 3 years ago

Ok, i understand that there are other issues as well, but if I understood well, they can they still be worked around by executing commands remotely, right? That said, if the script does not perform properly under some circumstances, i'd start to investigate the reason before using workarounds. What comes to mind is an hack in ssh-rdp: AUDIO_DELAY_COMPENSATION It may not work as intended with 192khz, i'd try tweaking his value,

But again, inserting a feature into the code with the purpose of circumventing a problem in the code itself just doesn't feel right to me, for similar and other workarounds, the ability to execute remote scripts should suffice.

I'd rather inspect the specifig issue when dealing with 192khz, sorry.

nicman23 commented 3 years ago

yeah i get it :)

steam did something like that i thought it a good solution because that way (null sink/sources) you can trivial add headphone and mic support.

anyways, thanks for your time