Here are my 2 cents. Try to use some codec with hardware acceleration like h264_qsv but make sure that your version supports it, otherwise you will need to re-compile it. Try to simplify your ffmpeg command and update your ffmpeg version if it is not the latest one. Example command:

ffmpeg -f x11grab -draw_mouse 0 -framerate 30 -probesize 42M -video_size 1920x1080 -i :0 -f pulse -i default -c:v h264_qsv -preset:v ultrafast -r 30 -g 90 -b:v 4500k -c:a aac prueba.mkv

In this command:

-c:v h264_qsv specifies the H.264 video codec with Intel Quick Sync Video hardware acceleration.

-preset:v ultrafast - sets the video preset to ultrafast, meaning that ffmpeg will try to lower the quality of encoding and should potentially decrease your CPU utilisation. In this case I would also recommend you to increase the -b:v to 6-8-10M to compensate for the quality loss and if needed you can always offline transcode it to lower the size of your recording

-c:a aac specifies the AAC audio codec for audio encoding.Other parameters such as framerate, video size, input sources, and output file name remain the same as in your original command.

Make sure your version of ffmpeg is compiled with support for Intel Quick Sync Video. You can check this by running ffmpeg -encoders and looking for the h264_qsv encoder in the list. If it's available, you should be able to use hardware encoding with Intel HD 4000.

Another idea is to try to run video grab only and then audio grab only and check the CPU utilisation. You can try to change the

-f pulse -i default

and define the input manually, and not leaving it to default. Also make sure you are not using ALSA or pipewire, as the audio grab syntax is slightly different from what you posted

Does top/htop/whatever show a large difference between encoding with and without audio? Do e.g. the pulse processes hog resources for some reason?

Do you get smooth recording if you reduce the screen resolution and do something that uses minimal resources (e.g., play Tetris at 640x480)?