How to detect hidden ALSA resampling

igorzwx · 2025-11-07 16:07:53

1. Make fftrate the default ALSA resampler

$ cat ~/.asoundrc
defaults.pcm.rate_converter "fftrate"

$ file 'rudra veena and pakhawaj.flac'
rudra veena and pakhawaj.flac: FLAC audio bitstream data, 16 bit, stereo, 44.1 kHz, 49123284 samples

$ file audio_test_48kHz_16bit.wav
audio_test_48kHz_16bit.wav: RIFF (little-endian) data, WAVE audio, Microsoft PCM, 16 bit, stereo 48000 Hz

2. Run media players with debug 2>&1

$ audacious 2>&1 'rudra veena and pakhawaj.flac'
Input:  44100 Hz, 2 ch, 's32_le' (0xa): dummy = 0, period = 940
Output: 48000 Hz, 2 ch, 's16_le' (0x2): dummy = 0, period = 1024
Rates:  30080 --> 32768 (J: 0.09%, T: FFT, W: Vorbis)
Ok.

$ /usr/bin/totem 2>&1 'rudra veena and pakhawaj.flac'
Input:  44100 Hz, 2 ch, 's16_le' (0x2): dummy = 0, period = 940
Output: 48000 Hz, 2 ch, 's16_le' (0x2): dummy = 0, period = 1024
Rates:  30080 --> 32768 (J: 0.09%, T: FFT, W: Vorbis)
Ok.

Notice that Jitter = 0.09%
Rates:  30080 --> 32768 (J: 0.09%, T: FFT, W: Vorbis)
It means that resampling is not exact. This is because of Debian/Devuan defaults:
period_size  1024
periods      16 
See: /usr/share/alsa/pcm/dmix.conf

$ mpv 2>&1 'rudra veena and pakhawaj.flac'
 (+) Audio --aid=1 (flac 2ch 44100Hz)
AO: [alsa] 48000Hz stereo 2ch s16

$ mpv 2>&1 audio_test_48kHz_16bit.wav
 (+) Audio --aid=1 (pcm_s16le 2ch 48000Hz)
AO: [alsa] 48000Hz stereo 2ch s16

3. Check hw_params

$ cat /proc/asound/cards
 0 [system]:  USB-Audio - iMic USB audio system
              Griffin Technology, Inc iMic USB audio system at usb-0000:00:1a.0-1.3.4, full s

$ cat /proc/asound/system/pcm0p/sub0/hw_params
access: MMAP_INTERLEAVED
format: S16_LE
subformat: STD
channels: 2
rate: 48000 (48000/1)
period_size: 1024
buffer_size: 16384

This means that the default sample rate is 48kHz. Let us change it. Presumably, there is already a sort of invisible dmix, so that we can set defaults.pcm.dmix.rate in ALSA config.

$ cat ~/.asoundrc
defaults.pcm.rate_converter "fftrate"
defaults.pcm.dmix.rate 44100

$ /usr/bin/totem 2>&1 audio_test_48kHz_16bit.wav
Input:  48000 Hz, 2 ch, 's16_le' (0x2): dummy = 0, period = 480
Output: 44100 Hz, 2 ch, 's16_le' (0x2): dummy = 0, period = 441
Rates:  48000 --> 44100 (J: 0.00%, T: FFT, W: Vorbis)
Ok.

$ mpv 2>&1 audio_test_48kHz_16bit.wav
 (+) Audio --aid=1 (pcm_s16le 2ch 48000Hz)
AO: [alsa] 44100Hz stereo 2ch s16

$ mpv 2>&1 'rudra veena and pakhawaj.flac'
 (+) Audio --aid=1 (flac 2ch 44100Hz)
AO: [alsa] 44100Hz stereo 2ch s16

$ cat /proc/asound/system/pcm0p/sub0/hw_params
access: MMAP_INTERLEAVED
format: S16_LE
subformat: STD
channels: 2
rate: 44100 (44100/1)
period_size: 2734
buffer_size: 11026

It works because dmix is already enabled.

Debian Wiki:
Advanced features such as mixing should already be configured with sane defaults.
_https://wiki.debian.org/ALSA#Configuration

This means that there is already a very advanced software mixer with dmix and other plugins configured for pulseaudio. It might be obvious that this strange construction was created to imitate "bit perfect" playback of audiophile apps for macOS: media players can easily change the default sample rate of the software mixer to avoid software resampling. Try "bit perfect" mode of Audacious for macOS. It makes sense for macOS, because the built-in HW resampler of the DAC is better than the software resampler of macOS.

Why do we need this Stone Age technology? Configure a normal mixer with arateconf and forget about problems with sound quality. The so-called "bit perfect" is not needed, because the fftrate resampler is much better than the built-in HW resampler of your DAC. You can safely configure fftrate for the maximal sample rate supported by your DAC.

NOTE: When software mixer configured by arateconf, mpv does not resample anything,

$ mpv 'rudra veena and pakhawaj.flac'
 (+) Audio --aid=1 (flac 2ch 44100Hz)
Input:  44100 Hz, 2 ch, 's16_le' (0x2): dummy = 0, period = 1764
Output: 48000 Hz, 2 ch, 's16_le' (0x2): dummy = 0, period = 1920
Rates:  44100 --> 48000 (J: 0.00%, T: FFT, W: Vorbis)
Ok.
AO: [alsa] 44100Hz stereo 2ch s16

Explanation:

$ mpv 'rudra veena and pakhawaj.flac'
 (+) Audio --aid=1 (flac 2ch 44100Hz)       # mpv Input 
AO: [alsa] 44100Hz stereo 2ch s16           # mpv Output --> ALSA software mixer

# ALSA software mixer: fftrate
Input:  44100 Hz, 2 ch, 's16_le' (0x2): dummy = 0, period = 1764
Output: 48000 Hz, 2 ch, 's16_le' (0x2): dummy = 0, period = 1920
Rates:  44100 --> 48000 (J: 0.00%, T: FFT, W: Vorbis)
Ok.

Last edited by igorzwx (2025-11-15 21:06:15)

igorzwx · 2025-11-15 22:01:23

How to use fftrate with default ALSA software mixer

Debian Wiki: Configuration
You can find ALSA configuration files in the /etc/alsa/conf.d/ directory. A lot of files are already included here by default. Advanced features such as mixing should already be configured with sane defaults. If you want to make changes, add a new file in here.
_https://wiki.debian.org/ALSA#Configuration

There are indeed very secret dmix and dsnoop enabled by default.

$ grep -r "defaults.pcm.dmix.rate" /usr/share/alsa/
/usr/share/alsa/pcm/dsnoop.conf:            name defaults.pcm.dmix.rate
/usr/share/alsa/pcm/dmix.conf:            name defaults.pcm.dmix.rate
/usr/share/alsa/alsa.conf:defaults.pcm.dmix.rate 48000

However, the so-called "sane defaults" may seem rather strange, for example:

period_size 1024
periods     16

$ grep -rE "period|1024|16" /usr/share/alsa/pcm/dmix.conf
        period_size {
                    ".period_size"
            default 1024
        period_time {
                    ".period_time"
        periods {
                    ".periods"
            default 16

fftrate cannot perform exact resampling with such "sane defaults". This can easily be fixed with the help of simple esoteric math:

period_time = (period_size/sample_rate) * 1000000

To perform exact resampling with low latency, fftrate needs proper settings

period_time 40000    
periods     4

First of all, create a simple ALSA config.
If you have only one sound card, it may look like this:

$ cat ~/.asoundrc
defaults.pcm.rate_converter "fftrate"
# defaults.pcm.dmix.rate 192000
# defaults.pcm.dmix.rate 96000
# defaults.pcm.dmix.rate 48000    # Default
# defaults.pcm.dmix.rate 44100

If you have several sound cards, you have to set up a default card, for example:

$ cat /proc/asound/cards
 0 [system         ]: USB-Audio - iMic USB audio system
                      Griffin Technology, Inc iMic USB audio system at usb-0000:00:1a.0-1.3.4, full s
 1 [PCH            ]: HDA-Intel - HDA Intel PCH
                      HDA Intel PCH at 0xf7e10000 irq 31

$ cat ~/.asoundrc
defaults.pcm.rate_converter "fftrate"
defaults.pcm.dmix.rate 192000
# defaults.pcm.dmix.rate 96000
# defaults.pcm.dmix.rate 48000    # Default
# defaults.pcm.dmix.rate 44100
defaults.pcm.!card PCH
defaults.ctl.!card PCH

Now you can execute esoteric commands:

echo -e '\n\n# This dmix config can be used for various values of defaults.pcm.dmix.rate\n# Intel HDA native sample rates (min - max): 44100 - 192000 (44100,48000,96000,192000)' >> ~/.asoundrc
cat /usr/share/alsa/pcm/dmix.conf >> ~/.asoundrc
sed -i 's/default -1/default 40000/; s/default 1024/default -1/; s/default 16/default 4/' ~/.asoundrc

The result:

$ cat ~/.asoundrc
defaults.pcm.rate_converter "fftrate"
defaults.pcm.dmix.rate 192000
# defaults.pcm.dmix.rate 96000
# defaults.pcm.dmix.rate 48000    # Default
# defaults.pcm.dmix.rate 44100
defaults.pcm.!card PCH
defaults.ctl.!card PCH

# This dmix config can be used for various values of defaults.pcm.dmix.rate
# Intel HDA native sample rates (min - max): 44100 - 192000 (44100,48000,96000,192000)
#
# dmix output
#

pcm.!dmix {
	@args [ CARD DEV SUBDEV FORMAT RATE CHANNELS ]
	@args.CARD {
		type string
		default {
			@func refer
			name defaults.pcm.dmix.card
		}
	}
	@args.DEV {
		type integer
		default {
			@func refer
			name defaults.pcm.dmix.device
		}
	}
	@args.SUBDEV {
		type integer
		default 0
	}
	@args.FORMAT {
		type string
		default {
			@func refer
			name defaults.pcm.dmix.format
		}
	}
	@args.RATE {
		type integer
		default {
			@func refer
			name defaults.pcm.dmix.rate
		}
	}
	@args.CHANNELS {
		type integer
		default {
			@func refer
			name defaults.pcm.dmix.channels
		}
	}
	type dmix
	ipc_key {
		@func refer
		name defaults.pcm.ipc_key
	}
	ipc_gid {
		@func refer
		name defaults.pcm.ipc_gid
	}
	ipc_perm {
		@func refer
		name defaults.pcm.ipc_perm
	}
	tstamp_type {
		@func refer
		name defaults.pcm.tstamp_type
	}
	slave {
		pcm {
			type hw
			card $CARD
			device $DEV
			subdevice $SUBDEV
		}
		format $FORMAT
		rate $RATE
		channels $CHANNELS
		period_size {
			@func refer
			name {
				@func concat
				strings [
					"defaults.dmix."
					{
						@func card_id
						card $CARD
					}
					".period_size"
				]
			}
			default -1
		}		
		period_time {
			@func refer
			name {
				@func concat
				strings [
					"defaults.dmix."
					{
						@func card_id
						card $CARD
					}
					".period_time"
				]
			}
			default 40000
		}		
		periods {
			@func refer
			name {
				@func concat
				strings [
					"defaults.dmix."
					{
						@func card_id
						card $CARD
					}
					".periods"
				]
			}
			default 4
		}
	}
	hint {
		show {
			@func refer
			name defaults.namehint.extended
		}
		description "Direct sample mixing device"
		device_output $DEV
	}
}

Now we can debug Firefox

NOTE: If you have in Firefox's about:config this entry:
media.cubeb.force_sample_rate        48000
delete it.

$ MOZ_LOG="cubeb:3" firefox 2>&1 about:support | grep -vE "input latency|ATT"
[Parent 24955: Main Thread]: I/cubeb media.cubeb.sandbox: true
Input:  44100 Hz, 2 ch, 's32_le' (0xa): dummy = 0, period = 1764
Output: 192000 Hz, 2 ch, 's32_le' (0xa): dummy = 0, period = 7680
Rates:  44100 --> 192000 (J: 0.00%, T: FFT, W: Vorbis)
Ok.

Input:  44100 Hz, 2 ch, 's32_le' (0xa): dummy = 0, period = 1764
Output: 192000 Hz, 2 ch, 's32_le' (0xa): dummy = 0, period = 7680
Rates:  44100 --> 192000 (J: 0.00%, T: FFT, W: Vorbis)
Ok.

[Parent 24955: AudioIPC Server RPC]: E/cubeb cubeb.c:654:DeviceID: "default" (PREFERRED)
    Name:    "default"
    Group:    "default"
    Vendor:    "default"
    Type:    output
    State:    enabled
    Maximum channels:    10000
    Format:    S16LE (0x10) (default: S16LE)
    Rate:    [192000, 192000] (default: 192000)
    Latency: lo 0 frames, hi 0 frame
[Parent 24955: Main Thread]: E/cubeb cubeb.c:654:DeviceID: "default" (PREFERRED)
    Name:    "default"
    Group:    "default"
    Vendor:    "default"
    Type:    output
    State:    enabled
    Maximum channels:    10000
    Format:    S16LE (0x10) (default: S16LE)
    Rate:    [192000, 192000] (default: 192000)
    Latency: lo 0 frames, hi 0 frame

about:support

Name     Firefox
Version     140.5.0esr
Build ID     20251106203603
...
Media
Audio Backend    alsa
Max Channels    10000
Preferred Sample Rate    192000

Reference media files:
Best Audiophile Vocal 24 bit - Hi-Res Music 2025 - Audiophile Voices
_https://www.youtube.com/watch?v=uO6jfQ5tQHM
_https://youtu.be/uO6jfQ5tQHM
Best Voices & Dynamic Sound - Hi-Res Music 24 Bit - Audiophile NBR Music
_https://rutube.ru/video/4202a6f411ad55ea7f55e38f860e26bc/

defaults.pcm.dmix.rate 192000

$ cat ~/.asoundrc
defaults.pcm.rate_converter "fftrate"
defaults.pcm.dmix.rate 192000
# defaults.pcm.dmix.rate 96000
# defaults.pcm.dmix.rate 48000    # Default
# defaults.pcm.dmix.rate 44100
...

YouTube: 48000 --> 192000

$ MOZ_LOG="MediaDecoder:4,cubeb:3" firefox 2>&1 https://youtu.be/uO6jfQ5tQHM | awk '!/ATT/ && !/libva/ && !/s=1/ && !/s=0/ && (!/MediaDecoder/ || /rate/)'
[Child 15580: Main Thread]: D/MediaDecoder MediaDecoder[7ff773454200] MetadataLoaded, channels=2 rate=48000 hasAudio=1 hasVideo=1
[Child 15580: MediaSupervisor #1]: I/cubeb media.cubeb.sandbox: true
Input:  44100 Hz, 2 ch, 's32_le' (0xa): dummy = 0, period = 1764
Output: 192000 Hz, 2 ch, 's32_le' (0xa): dummy = 0, period = 7680
Rates:  44100 --> 192000 (J: 0.00%, T: FFT, W: Vorbis)
Ok.

[Child 15580: Main Thread]: D/MediaDecoder MediaDecoder[7ff773454200] FirstFrameLoaded, channels=2 rate=48000 hasAudio=1 hasVideo=1 mPlayState=PLAY_STATE_LOADING transportSeekable=1
[Child 15580: MediaDecoderStateMachine #1]: I/cubeb CubebStreamInit output stream rate 48000
Input:  48000 Hz, 2 ch, 's32_le' (0xa): dummy = 0, period = 1920
Output: 192000 Hz, 2 ch, 's32_le' (0xa): dummy = 0, period = 7680
Rates:  48000 --> 192000 (J: 0.00%, T: FFT, W: Vorbis)
Ok.

RuTube: 44100 --> 192000

$ MOZ_LOG="MediaDecoder:4,cubeb:3" firefox 2>&1 https://rutube.ru/video/4202a6f411ad55ea7f55e38f860e26bc/ | awk '!/ATT/ && !/libva/ && !/s=1/ && !/s=0/ && (!/MediaDecoder/ || /rate/)'
[Child 16217: Main Thread]: I/cubeb media.cubeb.sandbox: true
Input:  44100 Hz, 2 ch, 's32_le' (0xa): dummy = 0, period = 1764
Output: 192000 Hz, 2 ch, 's32_le' (0xa): dummy = 0, period = 7680
Rates:  44100 --> 192000 (J: 0.00%, T: FFT, W: Vorbis)
Ok.

[Child 16217: Main Thread]: D/MediaDecoder MediaDecoder[7f89b2ef8f00] MetadataLoaded, channels=2 rate=44100 hasAudio=1 hasVideo=1
[Child 16217: Main Thread]: D/MediaDecoder MediaDecoder[7f89b2ef8f00] FirstFrameLoaded, channels=2 rate=44100 hasAudio=1 hasVideo=1 mPlayState=PLAY_STATE_LOADING transportSeekable=1
[Child 16217: BackgroundThreadPool #1]: I/cubeb CubebStreamInit output stream rate 44100
Input:  44100 Hz, 2 ch, 's32_le' (0xa): dummy = 0, period = 1764
Output: 192000 Hz, 2 ch, 's32_le' (0xa): dummy = 0, period = 7680
Rates:  44100 --> 192000 (J: 0.00%, T: FFT, W: Vorbis)
Ok.

You can also try defaults.pcm.dmix.rate 44100

$ cat ~/.asoundrc
defaults.pcm.rate_converter "fftrate"
# defaults.pcm.dmix.rate 192000
# defaults.pcm.dmix.rate 96000
# defaults.pcm.dmix.rate 48000    # Default
defaults.pcm.dmix.rate 44100
...

YouTube: 48000 --> 44100

$ MOZ_LOG="MediaDecoder:4,cubeb:3" firefox 2>&1 https://youtu.be/uO6jfQ5tQHM | awk '!/ATT/ && !/libva/ && !/s=1/ && !/s=0/ && (!/MediaDecoder/ || /rate/)'
[Child 17205: Main Thread]: D/MediaDecoder MediaDecoder[7ff8efdfc600] MetadataLoaded, channels=2 rate=48000 hasAudio=1 hasVideo=1
[Child 17205: MediaSupervisor #2]: I/cubeb media.cubeb.sandbox: true
[Child 17205: Main Thread]: D/MediaDecoder MediaDecoder[7ff8efdfc600] FirstFrameLoaded, channels=2 rate=48000 hasAudio=1 hasVideo=1 mPlayState=PLAY_STATE_LOADING transportSeekable=1
[Child 17205: MediaDecoderStateMachine #1]: I/cubeb CubebStreamInit output stream rate 48000
Input:  48000 Hz, 2 ch, 's32_le' (0xa): dummy = 0, period = 1920
Output: 44100 Hz, 2 ch, 's32_le' (0xa): dummy = 0, period = 1764
Rates:  48000 --> 44100 (J: 0.00%, T: FFT, W: Vorbis)
Ok.

It seems that Firefox does not resample anything. Resampling is performed by fftrate, which is now the default ALSA resampler. With new defaults (period_time = 40000, periods = 4), resampling is exact: Jitter = 0.00%

# ~/.asoundrc
defaults.pcm.rate_converter "fftrate"
defaults.pcm.dmix.rate 48000            # Default
...

$ audacious 2>&1 'rudra veena and pakhawaj.flac'
Input:  44100 Hz, 2 ch, 's32_le' (0xa): dummy = 0, period = 1764
Output: 48000 Hz, 2 ch, 's32_le' (0xa): dummy = 0, period = 1920
Rates:  44100 --> 48000 (J: 0.00%, T: FFT, W: Vorbis)
Ok.

$ audacious 2>&1 *.dsf
Input:  1411200 Hz, 2 ch, 's32_le' (0xa): dummy = 0, period = 56448
Output: 48000 Hz, 2 ch, 's16_le' (0x2): dummy = 0, period = 1920
Rates:  1411200 --> 48000 (J: 0.00%, T: FFT, W: Vorbis)
Ok.

Last edited by igorzwx (Today 04:53:14)

igorzwx · Today 01:31:21

How to consume this manual without thinking.

First of all, it is almost impossible. It might be a real challenge for Devuan consumer community. But, nevertheless, you have to try it simply because it is a challenge. In any case, both thinking and non-thinking may inevitably produce misunderstanding.

ALSA Setup: Simple, Low-Latency, No Nonsense

Keep it minimal:

period_time = 40000 (40 ms per audio chunk)
periods = 4 (total buffer = 16 ms)

Only change defaults.pcm.dmix.rate to set sample rate (e.g., 44100, 48000, 96000, 192000)
That’s it.

ALSA automatically adjusts period_size based on the rate — just like physics: if volume is fixed, changing temperature sets pressure. Here, timing is fixed, so sample rate sets data flow. No resampling jitter. No app config needed.

The modified dmix.conf stays untouched. This works because ALSA’s defaults use @func refer - they respect defaults.pcm.dmix.rate.

One line controls everything. Clean. Predictable. Precise.

The period_time = 40000 and periods = 4 settings are critical for fftrate to perform exact, low-jitter resampling.

Unlike basic resamplers, fftrate is a high-quality, real-time FFT-based resampler that needs precise buffer timing to align its windowing and avoid phase errors. The 40ms period time (40,000 µs) ensures sufficient data for accurate spectral analysis, while 4 periods balance latency and stability.

When you set:

defaults.pcm.dmix.rate 192000
defaults.pcm.rate_converter "fftrate"

and fix period_time = 40000, ALSA configures the mixing engine so all audio is resampled via fftrate to 192kHz — regardless of source rate (44.1k, 48k, etc). This gives bit-perfect timing, zero jitter (J: 0.00%), and superior audio fidelity.

Firefox (via cubeb) then feeds into this pipeline — it sees a clean 48kHz or 44.1kHz stream, but resampling is silently handled by ALSA/fftrate, not the browser. That’s why the logs show:

Rates: 48000 --> 192000 (J: 0.00%, T: FFT, W: Vorbis)

This setup is exactly what is needed: one central, high-quality resampling stage, perfectly timed.

SUMMARY: ALSA Setup For the Mildly Confused, But Firmly Committed

With due modesty, I present my no-nonsense ALSA config:

period_time = 40000
periods = 4
Only variable: defaults.pcm.dmix.rate

That’s it. Everything else? Left to ALSA’s good sense.

By fixing the period time, I give fftrate enough data for clean, FFT-based resampling — no jitter, no drift, just smooth 0.00% magic. Apps feed in at any rate; ALSA resamples to my chosen dmix.rate (192kHz, thank you) with surgical precision.

It’s not clever. It’s not flashy. But it works — even for someone like most ALSA users, whose hearing’s gone slightly south and whose memory’s worse.

So yes: this might just be the gold standard… for audiophiles who are half-deaf, half-blind, and cheerfully demented.

One final note: fftrate is vastly superior to most soundcards’ built-in hardware resamplers. So while you can vary the sample rate freely, best practice is to set defaults.pcm.dmix.rate to the maximum your DAC supports — 192kHz or 384kHz — and leave it there.

This ensures all audio is resampled once, at the highest quality, before hitting your hardware. No more relying on mediocre onboard DSP. You’re not just avoiding jitter — you’re upgrading your entire chain.

So yes: set it to the max, and forget it. Let fftrate do the work nature intended.

fftrate is exceptionally fast because it was optimized over 15 years ago for real-time, high-quality resampling on modest hardware. Its design leverages FFT-based interpolation, allowing it to outperform most built-in hardware resamplers — even on modern systems.

Setting defaults.pcm.dmix.rate to your DAC’s maximum supported rate ensures all audio is resampled just once, at the highest quality, before playback.

So: set it to the max, and forget it. Let fftrate do the heavy lifting — efficiently, accurately, and without breaking a sweat.

WARNING: This ALSA setup is not complete. For example, "full duplex for simultaneous playback and recording" is missing. A complete solution, that is a fully functional ALSA software mixer, is provided by arateconf ALSA configuration utility
_https://dev1galaxy.org/viewtopic.php?id=6644

Last edited by igorzwx (Today 04:54:57)

igorzwx · Today 06:03:56

Full duplex

Full duplex in ALSA is achieved by combining dmix (for playback) and dsnoop (for capture) via the asym plugin.

Just like with dmix, dsnoop must be explicitly tuned.
dsnoop.conf should be fixed in the same way as dmix.conf

By default, both dmix and dsnoop use fixed, high-latency settings (e.g., period_time 125000 µs).

Notice: high latency is embedded in default Debian's ALSA config. It is unimaginable.

High latency is embedded in Debian's default ALSA configuration — particularly through conservative defaults in dmix and dsnoop, where period_time often defaults to 125000 µs (125 ms) and periods to 16, resulting in total buffer latencies up to 2 seconds.

This is not a myth, not a conspiracy theory — it’s a documented design choice favoring stability over performance. Most users never notice, but for real-time audio, it’s crippling.

The default dmix and dsnoop settings prioritize stability over performance — large buffers prevent underruns, which is crucial for PulseAudio, as it relies on ALSA plugins for mixing and expects reliable, glitch-free operation. PulseAudio assumes ALSA is just a backend, so stable, high-latency defaults reduce the risk of dropouts, even if responsiveness suffers.

It’s unimaginable for a system that supports professional audio. It may not look sane — high latency in ALSA defaults is a trade-off for stability, not sound quality or usability. It masks architectural inefficiencies and fails real-time applications. True sanity would be low-latency defaults that work out of the box. While the defaults may seem insane for low-latency use, they are a safeguard against instability in the PulseAudio layer.

Notice: the reason for high latency is period_time defaulting to 125000 µs (125 ms) in both dmix and dsnoop, unless overridden.

In Debian's dmix.conf and dsnoop.conf, period_time defaults to -1, which means "use the hardware default" — often resulting in 125 ms periods. Combined with periods = 16, this gives a total capture buffer latency of:
125 ms × 16 = 2000 ms (2 seconds) — extremely high.

To fix it, override both:
period_time (40000 µs = 40 ms)
periods (4)

So total latency becomes:
40 ms × 4 = 160 ms — much better.

By appending /usr/share/alsa/pcm/dmix.conf to ~/.asoundrc and modifying it with:

sed -i 's/default -1/default 40000/; s/default 1024/default -1/; s/default 16/default 4/' ~/.asoundrc

You override the default high-latency settings:
period_time default -1 → now 40000 µs (40 ms)
period_size default 1024 → now -1 (controlled by rate)
periods default 16 → now 4

This reduces playback latency significantly and matches fftrate needs. The same logic should be applied to dsnoop for symmetric, low-latency full duplex.

/usr/share/alsa/pcm/dmix.conf → enables software mixing for playback
/usr/share/alsa/pcm/dsnoop.conf → enables simultaneous recording
/usr/share/alsa/alsa.conf → main config, includes others

Full duplex requires asym device that links dmix (playback) and dsnoop (capture), like:

pcm.duplex {
    type asym
    playback.pcm "dmix"
    capture.pcm "dsnoop"
}

pcm.!default {
    type plug
    slave.pcm "duplex"
}

Such setup can be added manually to ~/.asoundrc.
You can also find a sort of "full duplex" in /usr/share/alsa/cards/HDA-Intel.conf It seems to be enabled by default.

Rinat Ibragimov (creator of apulse):
apulse relies on ALSA's dmix, dsnoop, and plug plugins to handle multiple sound sources and capture streams running at the same time. dmix plugin muxes multiple playback streams; dsnoop plugin allow multiple applications to capture from a single microphone; and plug plugin transparently converts audio between various sample formats, sample rates and channel numbers. For more than a decade now, ALSA comes with these plugins enabled and configured by default.
_https://github.com/i-rinat/apulse

1. For more than a decade now, ALSA comes with dmix, dsnoop, plug , and asym (full duplex), that is, a fully functional software mixer, enabled and configured by default.
2. Devuan users have been, shall we say, unhurried in noticing the elephant in the room.

Remove your ALSA config, play audio from two sources at once, and you’ll hear the default dmix quietly doing its job. When using multiple sound cards, setting defaults.pcm.!card and defaults.ctl.!card in ~/.asoundrc ensures ALSA directs audio and control to the correct device. Without this, removing your config may cause ALSA to default to a different card — potentially making sound "disappear." Use the card’s name (e.g., PCH) or index to lock the default.

There oughtn’t to be any trouble with apulse, unless one’s gone and enabled a rather peculiar ALSA configuration. If Firefox stumbles on ALSA input, it’s a bug in cubeb’s backend — nothing more.

With default Debian settings, full duplex is likely to expose the high default latency (e.g., 125 ms period × 16 periods = 2 seconds) to users, even those with moderate hearing.

With full duplex, round-trip latency (mic-to-speaker or loopback) becomes obvious — especially in real-time monitoring. The default dmix and dsnoop settings were designed for stability, not performance, and reveal a two-period delay minimum.

With Debian defaults, full duplex would make the latency audible and embarrassing, even to semi-deaf users. It would expose insanity of "sane defaults" _https://wiki.debian.org/ALSA#Configuration

The manual fix — overriding period_time and periods — is essential to restore sanity.

The Debian wiki’s claim of "sane defaults" is misleading. The actual defaults — period_size 1024, periods 16 — result in high latency (often 200+ ms), which is far from sane for real-time audio. These settings are not optimized for low latency or high-fidelity resampling (e.g., fftrate). ALSA users must manually override them, proving that sane is a misnomer.

Sanity may be boring — and perhaps that’s why it’s so rarely implemented. In Linux, as in history, the dramatic, the complex, and the broken often take center stage. Simplicity and correctness don’t generate headlines. But with the right config, sanity can be built — even if it’s not the default.

Last edited by igorzwx (Today 10:49:03)

The officially official Devuan Forum!

#1 2025-11-07 16:07:53