Screen recording with ffmpeg

nia I wonder if the easiest way wouldn't be for @pfr to build ncspot with the pulseaudio back-end?

librespot itself supports most audio back-ends but, ncspot supports only alsa, pulse, portaudio and rodio.

JuvenalUrbino I think this won't work -- you need the pad in there to actually get the player's output fed back to userspace. If nscpot really doesn't have a way to configure PortAudio's default audio device (portaudio speaks /dev/audio), the pad's audio device could be made the default output using audiocfg, which would make portaudio use it.

That's because telling ffmpeg to read from /dev/audio will read from your microphone rather than mpg123.

Maybe something like:

ffmpeg4 -f s16le -ar 44100 -ac 2 -i /dev/pad0 -f x11grab -r 30 -s 640x480 -i :0.0 -vcodec libx264 -preset ultrafast output.mkv
mpg123 -a /dev/audio1 file.mp3

(This is mostly copied from the example in the pad man page, with your x11grab bits added.)

mpg123 needs to run after ffmpeg, only then will ffmpeg start recording. The reason for this is that the fake audio device /dev/audio1 is only created after /dev/pad0 is opened. Once mpg123 starts writing to /dev/audio1, the audio samples become available through the pad that ffmpeg opened.

rvp Actually, my example works just fine for only recording background music combined with the X11 display, which is what I thought OP was asking about. If you could point out why it doesn't work I'd be interested to know.

ffmpeg does seem to struggle when combining multiple audio sources (pad + mic) with the X11 recording, but perhaps there's a workaround, e.g. pointing it at a shoutcast stream. I'd be tempted just to play some music from speakers in the background. pad is quite simple because it was designed for the single purpose of streaming NetBSD's audio output to an AirTunes device, but we could also look into extending it for use cases like this.

I'd also be curious about the actual latency of having a separate ffmpeg process combining the streams, tbh.

nia If you could point out why it doesn't work I'd be interested to know.

It didn't work because the default -thread_queue_size is set too low.

Raise it, and use the sunau device instead of oss, and everything seems to work OK:

#!/bin/sh
set -eu
${1:?"$0: no output file given."}
RATE=30
SIZE=1366x768
ffmpeg \
	-thread_queue_size 2048 -f s16le -ar 44100 -ac 2 -i /dev/pad \
	-f sunau -i /dev/audio \
	-filter_complex '[0] [1] amix' \
	-f x11grab -r $RATE -s $SIZE -i :0 -vcodec libx264 -preset ultrafast \
	"$1" -map 0:a -c:a copy -f sunau /dev/audio

And:

$ env AUDIODEV=/dev/audio1 mpv /mnt/snd/Korean/playlist.m3u

pfr
At least one output file must be specified
screenrecord.sh: 1: parameter not set
error: Deep trouble! Cannot flush to my output anymore!

Same cause for each: you've not specified an output file to the script: screenrecord.sh foo.mp4

pfr $ env AUDIODEV=/dev/audio1 mpg123 music.mp3

The AUDIODEV env. variable is for SDL, which is what mpv uses for audio output. For mpg123, specify alternate output device with -a device

pfr it looked as though the track was playing but I heard no sound.

Yes, so I've noticed; because, I think, we're playing to /dev/audio1, which is only hooked up to pad0-- i.e. not to the actual output HW. But, no worries, the playback and mic audio do get mixed in properly though.

nia dunno what's changed.

This does the trick: add in /etc/sysctl.conf:

hw.audio0.blk_ms=1000