Forum Replies Created
we are working on it, you can monitor corresponding Feature Request page to check when it will be ready https://knowledgebase.nomachine.com/FR05S04169December 2, 2021 at 18:05 in reply to: Audio from remote Windows to Linux client not working #36535
Where (in which application) and how do you use forwarded mic?
It could be a problem with the app itself.
1. Check if it is not mic issue, try to test in different machine and so on (if you use external mic, but if you use built-in one, try to test it also in some audio recording apps).
2. Connect to Windows server using NoMachine and forward the mic.
3. Try opening some Windows recording tools (there are different methods, here is one way)
4. Record audio (by default it should use default mic, which after forwarding mic in NoMachine session is NoMachine mic adapter, but if it is not set to it set it correctly in app).
5. Play back to see if it has some dropouts.
6. go to https://online-voice-recorder.com/
7. record audio and listen to check if there are some dropouts.
8. If you didn’t get any dropouts then it’s not NoMachine’s fault.
9. If you still get that weird behavior, check and monitor network connections on server as on client, it could be network issue.
10. Also audio is CPU consuming and check if there are some heavy cpu-consumption tasks are running both sides.December 2, 2021 at 10:09 in reply to: Audio from remote Windows to Linux client not working #36521
NoMachine reads audio stream from default audio device on server side and transmits it to client.
You can mute or not server side audio choosing setting while you are connecting to server machine. By default it asks about it and if you agree it mutes physical audio on server side.
As I get audio on windows is working fine, but does audio work on client side correctly?
Please check also if your default sound output device is running in the exclusive mode and try to disable it.
since last release NoMachine 7.7.4 audio forwarding works in M1 mac in both ways, when you use it as client or server.
There is that mention in that FR:
audio is working for M1 macs in both ways.
So you can just update it.
yesterday we released new NoMachine 7.7.4.
You can read about it https://knowledgebase.nomachine.com/SU10S00227
There is that mention there:
problems related to macOS on M1 such as black screen, screen blanking not deactivated and audio not working.
So, as I said before, now audio forwarding works in M1 mac in both ways, when you use it as client or server.
Yes, you can forward audio on M1 Mac NoMachine client, but currently, audio forwarding for M1 Mac servers is not available. This TR is about M1 Mac client.
This TR’s fix and audio forwarding for M1 mac servers will be available in the next release.
thank you for reporting it. In general it is, but currently it is not for Windows.
We opened a Trouble Report for it:
You can use the link to monitor its status.August 27, 2021 at 09:06 in reply to: No Mac audio driver after update to Big Sur 11.5.2 #35003
I’m glad to hear that a problem is solved.August 25, 2021 at 08:50 in reply to: No Mac audio driver after update to Big Sur 11.5.2 #34973
when you manually load nxaudio it still doesn’t appear in output audio device list? or it does (it should) and it does disappear again after restart?
after restart, can you show me output of:
kextstat | grep nxau
after restart when it gone again, run:
sudo touch /Library/Extensions/
and restart machine, does it help?
and can you show me output of again:
kextstat | grep nxau
yes I saw your logs. That’s because initialization is done only once in session, when you first tried to forward disk, so all corresponding lines are how MacOs handles and checks if it is able to run kext. Then when it is sure that kext is runnable nxfs is run when it is needed. That’s why you see only those two lines for the next attempts. But somehow according to that deny log your system still thinks it has no access. Also, you can check if you close the session and open a new one, when you will try forward disk you will still see the first initialization logs.
You can find the instructions on how to collect server-side logs here: https://knowledgebase.nomachine.com/DT11R00182 and upload it.
I ran out of ideas, but it still seems like, nxfs is blocked and not loaded that’s why you see deny error log.
When you are connected to Mac, run:
sudo kextload -vvv /Library/Application\ Support/NoMachine/Extensions/nxfs.kext
And copy its output, if it gives any.
when I first try to mount it does everything but once it fails and I try to mount, it just has the two lines at then end displayed
What do you mean here? Did it work at least once?
what is explained in the TR is different in your case, why do you think it’s the same? Do you do any operation (described in TR) too?
I also checked again replicating your set up and it is working for me. I see same warning in logs as well, wheel group and usually only root user is part of it. But this is not a problem, forwarding should work.
even though pipewire-pulseaudio (specially the latest release) implements a lot of components of Pulse Audio, it still misses some important components to fully support all features that NoMachine achieves using Pulse Audio.
As mentioned in the article you can just switch to Pulse Audio in the meantime.
kextstat output shows that it is loaded also, kextutil output would be different if you didn’t approve it, so you have done it already.
You should have 2 NoMachine audio device.
Can you attach audio MIDI setup’s screens (during the session, while you are connected to your mac)?
1. let’s load nxaudio kext manually:
sudo kextutil -vvv /System/Library/Extensions/nxaudio.kext/
2. if you did not approve it, do::
Access System Preferences -> Security&Privacy -> General panel. Click on the “Allow” button
3. if it finished without any error, check if it’s loaded properly:
kextstat | grep nxau
you should get similar output:
180 0 0xffffff7f83d9c000 0x5000 0x5000 com.nomachine.driver.nxau (4.1.b2) 78172556-B6A4-3112-BA41-E79D18108476 <93 6 5 3 1>
4. restart NoMachine server:
sudo /etc/NX/nxserver --restart
If audio still does not work, please send us the output of kextutil command (point 1) in your reply.