Forum Replies Created
-
Posts
-
Hi,
The error while unmuting is the following:
amixer: Control sysdefault:0 element write error: Operation not permitted
I checked on my machine that this error occurs when you use HDMI device and a new kernel.
Regards,
Kuba
Hi,
It seems that it’s a kernel related issue. For some reasons ubuntu 22 with linux kernel >= 5.19.0-39 sometimes does not recognize or cannot mute/unmute HDMI devices. I’m trying to figure out a workaround for this, but maybe the only option is to downgrade to kernel like, i.e, linux-image-5.19.0-21-generic. Does the sound work outside NoMachine session if you set HDMI device as defualt? Can it be muted/unmuted outside NoMachine session?
You can check your kernel version by running:
uname -r
Regards,
Kuba
Hi,
We discovered an issue with forwarding devices in custom sessions. We will work on a fix. I noticed that it happens if you open the session in a floating issues. It should work if you run the custom sesssion in a virtual desktop. You can set it when you create a new custom session.
Regards,
Kuba
Hi,
I found some errors in the logs that cause the failure of unmuting process. Although their cause is really hard to track. I noticed that they may occur when HDMI or ELD devices are used. Do you use a device that is plugged in with a HDMI cable?
Also, the output of the command below would be helpful for further investigation:
amixer -c 0 controls | grep “Playback Volume”
Regards,
Kuba
Hi,
Which sound server do you use? Pulseaudio or pipewire? If you have pipewire, you can check this file: /usr/NX/etc/node.cfg. The parameter “AudioInterface” should be set to “pipewire” or “pulseaudio” respectively. If it’s not set in the right way, you can manually change and restart the server. Maybe this will help.
Regards,
Kuba
Hi,
NoMachine mutes the audio on the server by default. You can unmute in session settings if you want. I assume the main issue is that it stays muted even if client disconnects. It can mean two things: either our muting/unmuting script didn’t work on your machine or it wasn’t called at all while closing session. Testers tried to repeat your issue but they couldn’t. I also tried to reproduce because I have ubuntu 22 as well, but everything works fine for me. Our script uses amixer, so you can try the commands below to check if it works on your machine:
amixer -c 0 set Master playback 0% mute
amixer -c 0 set Master playback 100% unmuteYou can also enable debug logs in server settings. On the server side, open NoMachine and go to Settings->Server–>Status->Server logs.
Regards,
Kuba
Hi,
I think that you described the default behavior of sound forwarding. We mute the sound on the server by default while streaming to the client machine. You can optionally adjust it to your needs by going to the session menu -> Audio -> Change settings -> Mute audio on the server. You can also disable sound forwarding completely, either in the session menu or in the server settings (on the server side Settings -> Server settings -> Devices -> Enable audio streaming and microphone forwarding).
Have you tried restarting the coreaudio daemon?
sudo pkill coreaudiodIt’s strange that it happens only on one machine and only with Avid. Maybe restarting CoreAudio will fix the issue.
Hi,
NoMachine connects to the default PipeWire server that is currently running. The default path of pipewire-pulse socket should be /run/user/<uid>/pulse/native. Maybe your issue is somehow specific to your Linux distribution. Can you see what happens if you just change “unix:native” to “unix:/run/user/<uid>/pulse/native”?
Best regards,
Kuba
Hi,
I think setting server.address to “unix:native” should be enough, then server string is simply “/run/user/<uid>/pulse/native”. Doesn’t it work for you?
NoMachine doesn’t require “system-wide” PipeWire. I don’t think if that would be possible, pipewire server generally runs per-user. NoMachine also creates pipewire client for the specific user when logging to the remote desktop.
Best regards,
Kuba
Hi,
I’m not sure how well our support for pipewire will work when server address is set to “tcp:…”. What happens when you change it to “unix:native”? Everything else in your configuration seems fine. I only wonder about this:
Connection failure: Connection refused
pa_context_connect() failed: Connection refused
875407 875723 2023-05-15 10:27:47 954.177 AudioProxyCore: Cannot check whether PulseAudio or PipeWire is used.In AudioProxyCore we call “pactl info” in order to determine whether pulseaudio or pipewire is used. It seems that the command failed when called from NoMachine. The message “pa_context_connect() failed: Connection refused” indicates that something went wrong while connecting to the internal pulseaudio context (pactl is a pulseaudio command and pipewire is partly compatible with pulseaudio). In example, it can happen if try to run some pipewire/pulseaudio command when logged as root. Another option is that pipewire server wasn’t started in a proper way but it’s unlikely since everything works fine from the command line.
The nxserver process creates some virtual devices that can be used to forward microphone. That’s what you can see in nxserver.log.
Regards,
Kuba
Hi,
It seems you have a pulseaudio internal issue. Have you tried reinstalling or update pulseaudio to v.16?
Don’t look at NoMachine Output, it’s used for microphone forwarding. For audio forwarding we just capture data from the default sink and send it to the client side.
Regards,
Kuba
Hi,
Nothing significant in audio forwarding has changed in the last update. Have you updated pipewire recently? There is a chance they changed something that broke sound streaming in your case. You can check logs on the server side under these paths: ~/.nx/node/C-<display>-<session-ID> to see whether you have any warnings or errors related to audio.
Regards,
Kuba
Hi,
NoMachine Output and Remapped nx_voice_out are devices that we use for forwarding microphone. If it comes to audio forwarding, nothing significant changed in the latest update. I only added some error handling. We capture data from the default audio device and send it to server. These new devices and processes are only for microphone forwarding. You can check the logs under this path: ~/.nx/node/C-<display>-<session-ID> to see whether you have any warnings or errors related to audio.
Best regards,
Kuba
Hi,
Yes, NoMachine uses sshfs for mounting on Linux and MacOS, but for Windows we have our own service called nxfs. It uses stftp and Dokan API.
Moreover, we are going to update our implementation of VPN connections (planned for v9). Maybe this update will help with drive sharing when using VPN.
Regards,
Kuba