From time to time, I would see the following slightly poetic statement on my console.
Uhhuh. NMI received for unknown reason 31 on CPU 3. Do you have a strange power saving mode enabled? Dazed and confused, but trying to continue
The first Internet search brought me sadness and dismay – my hardware was failing. It took going a bit deeper to find that AMD servers have that issue quite often even in the absence of real hardware failure.
Solution? Disable darn C-States. It’s a server after all.
PS: And no, even if you want to keep C-States, reason 31 is nothing to worry about – it’s been happening on my system for 2 years before this and I had no issues with it. It’s just annoyance and nothing more.
When one records audio under Linux, issue that quite a few applications have is recording both microphone input and headphone output. And that’s true for SimpleScreenRecorder, otherwise really good recording application.
Trick is to essentially create two new output devices (i.e. sinks). One of them (app_out) will just be a target toward which applications should direct their output. Magic happens with the second output (duplex_out) which combines application output and what comes from microphone.
Now when you record audio, you can just point application to Duplex Output and record both sides.
PS: To make these changes permanent, they can be entered into /etc/pulse/default.pa. Of course, quoting rules are bit different so adjust accordingly if you have a space in your description.
Working from home requires a bit of synchronization between occupants. Especially if one member of family spends a lot of time on calls. Quite early into the work-at-home adventure, my wife found a solution. She bought a lighted “On Air” sign.
Idea was good. Whenever I am in conference call, I just light up the sign and everybody knows to keep quiet as our words are not private anymore. In reality most of the time I would either leave sign on longer than needed or forger to turn it off when I’m done speaking.
And pretty much all issues could be traced to the position of the sign. While it was visible to everybody else in the room, it wasn’t directly visible to me. And to make it more annoying, turning it off and on required me to get off the chair. Excellent for physical activity but annoying to do if I need to turn it on/off multiple times in a call.
While this would be enough for turning on/off the light, I was after something a bit more fine-grained. In quite a few conference calls I might not speak a lot. For them I just usually hit Mute Mic button on my Lenovo P70 and unmute only when I need to actually speak. So it seemed like a good compromise to only light up the sign when I am unmuted. If I’m muted, other family members can have their conversations without impacting my call.
And the following script was the last piece of the puzzle:
LAST_MIC_STATUS= while (true); do CURR_MIC_STATUS=`/usr/bin/amixer get Capture | grep -q '\[off\]' && echo 0 || echo 1`
if [[ "$LAST_MIC_STATUS" != "$CURR_MIC_STATUS" ]]; then LAST_MIC_STATUS=$CURR_MIC_STATUS if [[ "$CURR_MIC_STATUS" -ne 0 ]]; then NEW_STATE=true; else NEW_STATE=false; fi
WYZE_EMAIL="email@example.com" \ WYZE_PASSWORD="changeme" \ WyzePlugControl 2CAA8E6616D2 $NEW_STATE fi
sleep 1 done
It will essentially just check for the status of my mute button and adjust Wyze Plug accordingly. At least until Wyze changes API again.