Audacity screws up the microphone

My microphone was not working so I was investigating it. Today I found that whenever audacity is open, my microphone gets fucked up and requires me to restart pulseaudio!

Never seen this before (but glad I solved the problem; I was so mad that I could build a computer but not get a microphone to work); anyone else have this issue? I'm up to date.

Works fine on my laptop but audacity does use "alsa" for my microphone.
If I do a test with vokoscreen (using pulse) concurrently ...... it records as it should.

I don't think audacity it the cause, here. It only is triggering the situation.
But before we dive into the ALSA ecosystem, please take a look at the audacity settings:

Start Audacity, go to the top menu 'Edit' and select 'Preferences'.
On the left hand you'll see the menu. Should be something like:

  • Devices - Interface - Host: ALSA
  • Devices - Recording - Device: Default

Later we also can take a look into 'Recording', bit this is mostly finetuning.

I'll check it later, when I can - stupid me put a long-running process not into tmux, then I froze E16 by plugging in a DVD drive. Don't ask me why or how :man_shrugging:

1 Like

If your running process wasn't E16 reliant ..... it should still be running despite the GUI being frozen.

  • Did you try logging in on another TTY or with i.e "ssh" and checking what was going on?
    or did you panic, try all kinds of silly stuff, eventually hitting the on/off button and rebooting? :shocked:

No 1. reason my E16 freezes while mounting or connecting over USB: Thunar ..... so next time be sure to kill that first: "killall -HUP thunar"

If the system is working (ping okay, irregular activity on the harddisk, ..), try Magic SysRq key - Wikipedia. Also known as 'REISUB'.

-> ctrl+alt+printscreen+*REISUB* ... But, really read and understand the Wikipedia article, first. It is much nicer than just power-off, but will stop running processes.

it was

tty didn't work but ssh does. ive been speeding up the process thru my pi

tried pkill -9 thunar which didn't work..would HUP have made a difference?

i knew that and was going to try, but my keyboard doesn't seem to have sysrq :thinking: stupid logitech

oh wait I didn't know about that, i'll try that!

https://www.kernel.org/doc/html/latest/admin-guide/sysrq.html

Just read that, don'T see anything of use.

Closest things are the "kill all processes" one, but again, I've a long running process, that's still going on and will take a while longer.

Raw mode does nothing, still can'T enter a TTY (which means nothing as I have ssh).

Was going to do criu to dump my long running task and then reboot, but it seems like apt is broken, and I read online that my issue likely just needs a reboot (which I can,t have) so I can't install its build dependencies.

Welp, Tmux seems to have crashed when I tried "pkill x".

Maybe not the smartest idea, should have tried the magic keys first, but whatever.

The main issue was, I had just put my process that I was trying to keep running into tmux!

Fortunately I have a general idea on how to resume the proces but I'm pretty annoyed.

Why?
Because your keyboard is unresponsive?

Frankly, I don't know :shocked: ..... I've used the -HUP flag for ages and think that the U = user and the P=process...suspecting it's related to SIGHUP. :thinking:

Found it, it was in the man page:
Signals can be specified either by name (e.g. -HUP or -SIGHUP) or by number (e.g. -1) or by option -s.

I actually only use the -9 when killing from i.e a running "top".