On Tue, May 19, 2020 at 01:06:20PM +0000, jean-michel.fri...@femto-st.fr wrote:
> as this is a new computer, I had not installed pulseaudio. It seems > the "default" Alsa backend indeed drops frames. I installed pulseaudio > and running in debug mode (-vvvv) I cannot see frame size updates but most > importantly my records are now continuous, problems solved. Nice that things work, but some of the facts/conclusions posted here do not really correspond to reality. Pulsaudio will change buffer sizes, gains, etc. according to its own, often misguided, inspiration. ALSA certainly doesn't do such things. Also note that Pulseaudio runs on top of ALSA. ALSA will not drop or duplicate samples if configured and used correctly. The original problem is very probably due to a combination of * Too small buffer size for the 192 kHz sample rate. * GR threads serving the audio cards not running with real-time (SCHED_FIFO) priority. * GR not 'linking' the capture and playback sides, i.e. ensuring they are started at the same time. The latter means that even if the sample clock is shared (as it will be), the period timing and hence scheduling in both halves of the graph is independent - there is nothing that ensures that they start together or even within a defined time. That means that any connection between the two domains will probably fail unless it is sufficiently buffered, and the initial buffer state is initialised such as to allow the full range of timing uncertainty. What Pulseaudio does is inserting so much buffering that even a completely broken application will probably work in some sense. I certainly wouldn't recommend PA for any 'technical' use, all control over timing and gains is basically lost. Ciao, -- FA
