Firestorm voice not working Mac OS Monterey

[ItHadToComeToThis]

Anyone have any ideas. I have tried everything. I can hear voice I just can not speak.

Have reset voice, changed device, restarted, made sure FS is authorised in the security and privacy section, re installed firestorm.

I am out of ideas. Anyone having a similar issue?

[Lyssa Greymoon]

Do you have the iCloud Private Relay on?

[ItHadToComeToThis]

5 minutes ago, Lyssa Greymoon said:

Do you have the iCloud Private Relay on?

Nope. Just checked. Its turned off

[ItHadToComeToThis]

As an update. It turns out that neither the official viewer or the Firestorm viewer's version of SL voice are requesting permission to access the microphone. Kinda weird. Annoyingly I can't find a way to add them manually.

Further interesting note. Installing the official viewer gives you the message that the app needs updating otherwise it won't work with future versions of Mac OS.

Edited January 8, 2022 by ItHadToComeToThis

[Lyssa Greymoon]

50 minutes ago, ItHadToComeToThis said:

Further interesting note. Installing the official viewer gives you the message that the app needs updating otherwise it won't work with future versions of Mac OS.

I think that may be related to the impending doom of Python 2.7.

[Johnny Ming]

Also having this issue. Has anyone figured out how to force either viewer to make the request for mic access in MacOS?  There doesn't seem to be a way in MacOS to preemptively add an app unless it has previously made the request.  

[Asomatous Charming]

I too am having this issue. I am sort of tired of being treated as a second class citizen when it come to SL viewers. 

[davidventer]

Open macOS System Preferences > Security & Privacy > Privacy > Microphone

Scroll down the list of Apps in that window until you find the viewer(s) you're using and then un-tick and re-tick the checkbox(es) next to them.

Restart the Viewer(s). Voice should now work once again.

If the viewer(s) aren't in the list and if they do not request mic access after a clean re-install, submit a bug report to respective viewer(s) Jira/Bug Report system(s). 

Edited February 15, 2022 by davidventer

[Max Quirky]

This is a known bug and a fix that LL put into their viewer has been included into the build for the next release of Firestorm according to their JIRA.

Currently Firestorm never requests access to the mic and so it never appears in System Preferences > Security & Privacy > Privacy > Microphone

The current LL viewer has the fix now if voice is essential and I am sure Firestorm will release the update soon though I have no idea how long that will actually be.

Edited February 15, 2022 by Kyle Blackwood

[Beq Janus]

16 hours ago, Kyle Blackwood said:

The current LL viewer has the fix now if voice is essential and I am sure Firestorm will release the update soon though I have no idea how long that will actually be.

We're currently in QA. Assuming nothing bites us and resets the timer on that it should not be long now.

[Jerusha Kitty]

I have this same problem. I also have another even more annoying problem. When I open a profile the screen freezes for 3-5 seconds and I hear 3 popping sounds, then everything goes back to normal. I am on MacBook Pro (14-inch, 2021), Apple M1 Max, Monterey v.12.1

[FastTortillaJuice]

On 2/19/2022 at 10:42 AM, Jerusha Kitty said:

I have this same problem. I also have another even more annoying problem. When I open a profile the screen freezes for 3-5 seconds and I hear 3 popping sounds, then everything goes back to normal. I am on MacBook Pro (14-inch, 2021), Apple M1 Max, Monterey v.12.1

I'm getting this problem all the time as well. The profile window always freezes the image and causes (at least) 3 popping sounds, even if I'm on a very low-latency place, and gets worse (more popping sounds, longer freezes) and happens on more UI events when on a laggier place. Doesn't matter if I turn down the drawing distance to something absurdly low like 64m and remove atmospheric lighting.

[JustineJohndory Amethyst]

On 2/16/2022 at 10:36 PM, Beq Janus said:

We're currently in QA. Assuming nothing bites us and resets the timer on that it should not be long now.

One month+ later, I'm still having the same issue, I didn't see a new version on the downloads page, any updates?

[Gavin Hird]

It needs to be signed with an Apple Developer ID. The Firestorm team does not have that, so macOS refuse to give it access to the microphone.

It cost them $99 to fix it. 

[Beq Janus]

On 3/19/2022 at 4:55 PM, Gavin Hird said:

It needs to be signed with an Apple Developer ID. The Firestorm team does not have that, so macOS refuse to give it access to the microphone.

It cost them $99 to fix it. 

Possibly true, I can't answer that, but if you are certain that's the problem I can relay it. The problem of code signing generally is not the cost but the constraints around who can and cannot do the builds etc. we wasted heaps of time and money of codesigning releases in years gone by on the promise that it would stop the AV companies flagging every single new release as "omg paranoid this is new it might be nasty", it never worked, and required us to jump through burning hoops backwards carrying a goat playing the ukulele. I don't know the Mac world at all being apple-phobic  I doubt it is much different, but it's probably an alpaca and a lute.

Apologies to Mac Monterey users because sadly, the release has gone out without a concrete fix. We do however have a workaround that appears to have been succesful for most Monterey users during our test phase. This can be found on the voice wiki page https://wiki.firestormviewer.org/fs_voice#tab-mac

If you happen to know a Mac developer who can build the viewer (typically that's the first hurdle) and would like to help us improve our Mac support please put them in touch.

 

 

 

[Gavin Hird]

2 hours ago, Beq Janus said:

Possibly true, I can't answer that, but if you are certain that's the problem I can relay it.

 

 

 

It is true, I had to fix signing for voice again after the release of Monterey 12.3. You both have to (re)sign existing signed libs in addition to provide entitlements for both the viewer app bundle and SLPlugin.app with content. 

You can see how I have done it in the code in http://www.dayturn.com:5000/dayturn-new (viewer still in progress, but the signing should work your Firestorm too).

The entitlement files are the top level of the repository, the rest of the signing happens in viewer_manifest.py. My code will also notarize if both the bundles are set as hardened runtimes

For the developers, just use ad-hoc signing or no signing at all. You only need to sign and potentially notarize on release. 

After signing, you can revoke all app access to the Microphone by typing "tccutil reset Microphone" in terminal. Do this with the Settings->Security&Privacy->Privacy panel opened and Microphone selected. You should see the system revoke all microphone access. Then re-run your signed viewer, or just the SL viewer to see what happens and it will ask for access to the microphone when entering the first voice enabled region.

You can also test the above on opensim with my latest Dayturn viewer downloadable from https://www.dayturn.com/viewer/index.php?resources/

Edited March 22, 2022 by Gavin Hird

[JustineJohndory Amethyst]

On 2/16/2022 at 10:36 PM, Beq Janus said:

We're currently in QA. Assuming nothing bites us and resets the timer on that it should not be long now.

So David Venter's "untick and tick" solution worked for me, but my friend just installed the new release and now voice doesn't work again, and the trick doesn't work to fix it. How is it the problem is getting worse instead of better and will Mac users ever have a solution?

[Gavin Hird]

1 hour ago, JustineJohndory Amethyst said:

So David Venter's "untick and tick" solution worked for me, but my friend just installed the new release and now voice doesn't work again, and the trick doesn't work to fix it. How is it the problem is getting worse instead of better and will Mac users ever have a solution?

Apple is tightening security on use of certain system components such as the microphone, the idea is to block an unknown developer from installing code on a Mac that could use the microphone to secretly monitor or record a user or the user environment. By forcing the developer to sign the code to use the microphone, it also makes the developer’s identity known to the user, Apple and law enforcement, if needed. 
 

You can disagree with their approach, but this how it will be going forward. Meaning viewers will have to be signed to use the microphone. 

[Gavin Hird]

I have uploaded a preview of my Dayturn viewer that works for SecondLife, and is tested on both Intel and Apple Silicon version of macOS Monterey 12.3. Both voice and microphone should work correct on this viewer in secondLife. 

Functionality-wise it lies between the SecondLife Viewer and Firestorm.

The download is provided as is. It is both signed and notarized with my Apple Developer ID. 

Dayturn Viewer download.

[Johnny Ming]

10 hours ago, JustineJohndory Amethyst said:

So David Venter's "untick and tick" solution worked for me, but my friend just installed the new release and now voice doesn't work again, and the trick doesn't work to fix it. How is it the problem is getting worse instead of better and will Mac users ever have a solution?

In my experience with a new MacBook Pro running macOS Monterey, Firestorm and Alchemy require a security override during installation when GateKeeper blocks launch (System Preferences -> Security and Privacy -> "Open Anyway").  Subsequently, the apps never cause MacOS to prompt the user with the dialog box to give permissions for the microphone.  Worse, the apps never get registered/added to the list of applications to tick and untick at a later time in the System Preferences > Privacy -> Microphone window.  

I've tried the workarounds listed on the Firestorm Mac help page in Firestorm and Alchemy which involve running the package from terminal, creating an audio device, and reinstalling to no avail. There are posts for other apps, such as this one for League of Legends, which recommends disabling the system integrity check and making changes to the sqlite system database... no thanks.  

As Gavin said, this is how it is going forward. I'm happy to help test, contribute to a bounty, or attempt compiling and signing viewers myself under my Apple developer account with someone's help to get this resolved as soon as possible.

 

[Gavin Hird]

1 hour ago, Johnny Ming said:

As Gavin said, this is how it is going forward. I'm happy to help test, contribute to a bounty, or attempt compiling and signing viewers myself under my Apple developer account with someone's help to get this resolved as soon as possible.

 

The resolution is plain in the day in code for my viewer, but one of the fundamental issues with with all viewers (perhaps with the exception of mine) is that they build for deployment target of 10.9 - 10.11, which hides a large number of deprecations in the code. Once you set a sensible deployment target like 10.14 (Mojave), there is a slew of issues that prevents the viewer code from building on Xcode 13.3, which is needed for successfully signing the viewer to run on the latest Monterey (12.3).

The catch is also that Xcode 13.3 ONLY runs on Monterey (12.3), so there is a double whammy there...

All this has been fixed in my repository, but the fixes must be applied to FS, Alch and so on. Only after successful build with Xcode 13.3 will you be able to apply my entitlements and signing code to both sign and notarize the viewer. 

The general code changes mentioned above can also be applied with Xcode 12.1 if that is easier, but the signing requires 13.3 as far as I have experienced. 

Also, depending on which SDK and deployment target the libraries used are built with, they may have to be recompiled with the same deployment target as the viewer to avoid all kinds of linking issues. I have seen libs built with the 10.7, 10.9, 10.11 SDK and they will not notarize or even sign.

Edited March 23, 2022 by Gavin Hird

[Beq Janus]

For those watching this thread. 

There appears to be a new workaround that might help in the interim

This was contributed by D0nthate, via the Mac Monterey voice Jira

Quote

See if you can get this to work or if we need to add something to these instructions:

Get everything downloaded and running as you normally would.

Go to Firestorm Avatar -> Preferences -> Sound and Media -> Voice -> Uncheck enable voice

Exit firestorm

Go to mac System Preferences > Firewall > Firewall Options and click on the add button and add Firestorm-Releasex64.app

Now under the privacy tab in those same system preferences, scroll down to Accessibility

Click on the add button and add Firestorm-Releasex64.app again.

Now log into Firestorm.

Wait for things to render and settle.

Go to Avatar -> Preferences -> and click on the enable voice check box, then hit refresh.

I was able to get the mic permissions box to pop and then things work like they should.

On one machine, it didn't work the first time, so I unchecked, logged off, logged back on, let it sit a minute, tried again, and it worked the second time, so ymmv.

If you try this and it works let me know here and I can make this the default workaround that our support teams will give.

 

[Johnny Ming]

1 hour ago, Beq Janus said:

For those watching this thread. 

There appears to be a new workaround that might help in the interim

This was contributed by D0nthate, via the Mac Monterey voice Jira

If you try this and it works let me know here and I can make this the default workaround that our support teams will give.

 

This method did not work exactly as written for me using Firestorm or Alchemy, BUT...  if I combine the firewall steps from that workaround and then launch the viewer from Terminal (Use Finder to locate the viewer in Applications, right click Open Package Contents, open MacOS folder, and double click the executable), Terminal will ask for permissions to access the microphone instead of the viewer and then voice works. The launch from terminal workaround was previously posted to the Firestorm troubleshooting page, but it never worked for me, likely because untrusted incoming connections were being blocked.  For reference, I'm testing on macOS Monterey 12.3, MacBook Pro (M1 Pro) with Firestorm 6.5.3.65658 and Alchemy 6.5.3.1468.

Thanks for that tip!

 

[Lyssa Greymoon]

4 hours ago, Beq Janus said:

If you try this and it works let me know here and I can make this the default workaround that our support teams will give.

This worked for me, only it didn't prompt me to give FS permission to use the mic the first time I logged in. On the next login it did and worked fine. 

[Doom Burton]

The workaround is not working for me... Even after 3-4 tries.  I followed the procedures to the letter but haven't been able to get the viewer to prompt for mic access..  When I first log in and click to activate voice, voice will connect.  When clicking refresh voice will fail to connect and will continue to fail to connect every time I click the refresh button...  That might be part of the problem though I have no way around it.