You are not logged in.
To @tux_99
You're absolutely right — ALSA's documentation is notoriously opaque, and that confusion has fueled decades of misconceptions. The irony? The default configuration has quietly handled full-duplex and software mixing for years. Tools like fftrate are excellent enhancements — they improve resampling quality (defaults.pcm.rate_converter "fftrate") — but they don’t fix broken audio; they refine an already working system. So while fftrate is a smart tweak for audiophiles, the real issue isn’t the tech — it’s that the documentation never told anyone it already worked.
_https://dev1galaxy.org/viewtopic.php?id=7142
arateconf
_https://dev1galaxy.org/viewtopic.php?id=6644
modified dmix + dsnoop
_https://dev1galaxy.org/viewtopic.php?id=7587
To@Altoid
I know recompiling packages isn’t everyone’s idea of fun, but this one’s worth it. Rebuilding libasound2-plugins without PulseAudio isn’t just a technical tweak — it’s a small act of digital self-determination. No more phantom plugins trying to phone home to a server that isn’t there. No more audio routing chaos. Just clean, direct ALSA control.
And once it’s done, it stays done. No files sneaking back on update. It’s stable, silent, and free.
The process? A few commands, one .deb, and you’re set for life. Freedom isn’t always easy — but it is simple.
_https://dev1galaxy.org/viewtopic.php?id=7523
$ ls -1 /usr/share/alsa/alsa.conf.d
10-rate-lav.conf
10-samplerate.conf
10-speexrate.conf
50-arcam-av-ctl.conf
50-jack.conf
50-oss.conf
60-a52-encoder.conf
60-speex.conf
60-upmix.conf
60-vdownmix.conf
98-usb-stream.conf$ ls -l -1 /etc/alsa/conf.d
total 0
lrwxrwxrwx 1 root root 44 Jul 1 2024 10-rate-lav.conf -> /usr/share/alsa/alsa.conf.d/10-rate-lav.conf
lrwxrwxrwx 1 root root 46 Jul 1 2024 10-samplerate.conf -> /usr/share/alsa/alsa.conf.d/10-samplerate.conf
lrwxrwxrwx 1 root root 45 Jul 1 2024 10-speexrate.conf -> /usr/share/alsa/alsa.conf.d/10-speexrate.conf
lrwxrwxrwx 1 root root 48 Jul 1 2024 50-arcam-av-ctl.conf -> /usr/share/alsa/alsa.conf.d/50-arcam-av-ctl.conf
lrwxrwxrwx 1 root root 40 Jul 1 2024 50-jack.conf -> /usr/share/alsa/alsa.conf.d/50-jack.conf
lrwxrwxrwx 1 root root 39 Jul 1 2024 50-oss.conf -> /usr/share/alsa/alsa.conf.d/50-oss.conf
lrwxrwxrwx 1 root root 47 Jul 1 2024 60-a52-encoder.conf -> /usr/share/alsa/alsa.conf.d/60-a52-encoder.conf
lrwxrwxrwx 1 root root 41 Jul 1 2024 60-speex.conf -> /usr/share/alsa/alsa.conf.d/60-speex.conf
lrwxrwxrwx 1 root root 41 Jul 1 2024 60-upmix.conf -> /usr/share/alsa/alsa.conf.d/60-upmix.conf
lrwxrwxrwx 1 root root 44 Jul 1 2024 60-vdownmix.conf -> /usr/share/alsa/alsa.conf.d/60-vdownmix.conf
lrwxrwxrwx 1 root root 46 Jul 1 2024 98-usb-stream.conf -> /usr/share/alsa/alsa.conf.d/98-usb-stream.conf$ apt-file find 99-pulseaudio-default.conf.example
libasound2-plugins: /etc/alsa/conf.d/99-pulseaudio-default.conf.exampleThe situation possesses all the hallmarks of a particularly British sitcom with a distinct whiff of the absurd: a comedy of errors where everything technically works, yet nothing functions as expected, all because no one is quite looking at the same page — though, ironically, the instructions were printed in bold type for over a decade.
1. The Setup
For years, ALSA has quietly shipped with a fully functional software mixer — powered by dmix, dsnoop, and asym — enabled by default in Debian, Devuan, and their derivatives. Full-duplex audio (simultaneous playback and recording) works out of the box. You can test it with a simple terminal command:
arecord -f cd -V mono | aplay If you see a VU meter dancing merrily across your screen, congratulations — your system has been quietly and competently handling bidirectional audio without any fuss. No configuration required. It just works.
2. The Misunderstanding
Enter the developers of cubeb, the audio backend used by Firefox and other web-centric applications. In their implementation (cubeb_alsa.c:1407–1455), they appear to have treated ALSA not as a mature, self-sufficient audio architecture, but as a bare-bones fallback — a last resort when PulseAudio isn’t available. Rather than querying ALSA’s actual device topology using snd_device_name_hint(), they sidestepped proper enumeration entirely. The result? A single, fictional “default” device is reported — not discovered, but invented.
3. The Irony
Here’s the punchline: cubeb does successfully open and use ALSA’s default PCM device (cubeb_alsa.c:76), which in turn leverages the very same asym plugin that seamlessly routes playback through dmix and capture through dsnoop. The system works — it’s using the full power of ALSA’s default configuration.
Yet, when asked to describe what it’s using, cubeb confidently declares:
- “This device supports 10,000 channels.”
- “Latency? Oh, zero — perfectly instantaneous.”
- “Sample rate? A firm 48,000 Hz, and no questions asked.”
It’s like a waiter who serves you a perfectly cooked meal from a five-star kitchen but insists the dish was microwaved and made for a hundred people.
4. The Cascade
This small fiction snowballs into a full-blown mythos:
- Community wikis (Gentoo, Arch) propagate elaborate ~/.asoundrc configurations, as if the default setup were broken or incomplete — when in fact, most of these configs downgrade functionality, disabling dmix, dsnoop, or full-duplex support.
- Official documentation (e.g., Debian Wiki) points users to /etc/alsa/conf.d/, a directory that often doesn’t exist or isn’t used, while the real defaults live in /usr/share/alsa/.
- The ALSA Wiki itself offers examples that encourage users to reinvent the wheel — often poorly — reinforcing the idea that ALSA needs fixing.
- A widespread belief persists that ALSA cannot function without PulseAudio — despite decades of evidence to the contrary.
5. The Punchline
And so, the final irony:
- YouTube videos play without issue — simple playback, no problem.
- Zoom’s standalone app works flawlessly — it speaks ALSA’s language directly, bypassing the fiction.
- But Zoom’s web client fails — not because the audio system is broken, but because cubeb lies about what it sees. It doesn’t expose the real capabilities of the default device, leaving the web application blind.
It’s a classic farce: the hardware works, the kernel works, ALSA works, and even cubeb sort of works — yet the whole edifice collapses under the weight of misinformation.
The true absurdity lies in the fact that everyone is correct — in their own little world.
- ALSA functions perfectly — proven by aplay and arecord running in tandem.
- cubeb opens the audio device successfully — it’s not failing, it’s just lying about it.
- Zoom’s native app works because it doesn’t rely on this charade — it talks to ALSA like a grown-up.
- Users follow the documentation — only to be led down rabbit holes of unnecessary configuration.
It’s a Monty Python sketch in code form: a perfectly functional system rendered unusable not by bugs or limitations, but by a cascade of assumptions, omissions, and polite fictions. Everyone’s following the rules. The rules are wrong.
The “British sitcom with a touch of absurdity” comparison is apt. This isn’t a tragedy — it’s a comedy of errors. Well-meaning developers, decades of misleading documentation, and a “secret” that was never really hidden — just overlooked — have combined to create the illusion of brokenness.
The solution was there all along: the default ALSA configuration is sufficient. It enables full-duplex, software mixing, and robust device routing. No extra tools, no PulseAudio, no custom configs — just arecord | aplay and a quiet sense of satisfaction.
The real joke? We spent fifteen years fixing something that wasn’t broken — because no one thought to just ask what was already working.
It’s not so much that Firefox can’t handle ALSA, but rather that its cubeb backend takes a somewhat… minimalist approach to device enumeration.
The issue lies in alsa_enumerate_devices(), which, rather than listing actual hardware, returns a single, rather fictional "default" device (cubeb_alsa.c:1408–1456). This isn’t so much discovery as polite suggestion.
The Present Situation
Currently, the backend reports a device with:
- A maximum of 10,000 channels (ambitious, if not grounded in reality),
- Zero latency (one can only dream),
- And a fixed sample rate of 48,000 Hz (cubeb_alsa.c:1430–1451).
Unsurprisingly, Zoom’s web client sees “internal speakers” and “internal mic” — but they’re rather like ghosts: visible, yet impossible to engage with (e.g., Zoom’s web client with Mozilla LibreWolf 145.0.1-2, cubeb's ALSA backend).
What snd_device_name_hint Actually Does
This is ALSA’s proper device discovery function. It returns real devices — hardware, plugins, virtuals — with actual capabilities. It’s what one might reasonably expect to be used.
Why a Complete Rewrite Is in Order
To fix this, the cubeb ALSA backend would need to:
1. Call snd_device_name_hint() — a modest step, but one currently overlooked.
2. Query real hardware parameters — using standard ALSA calls to learn actual channel counts, rates, and latencies (cubeb_alsa.c:1213–1221).
3. Distinguish input, output, and duplex devices — a basic courtesy to the user.
4. Expose the actual ALSA topology — including asymmetric setups using dmix and dsnoop, which many rely on.
Why This Hasn’t Happened
The developers appear to have treated ALSA as a fallback — a bare-bones option for when PulseAudio isn’t available. This overlooks that ALSA, with its default software mixing, is quite capable. The current implementation suffices for playing the odd YouTube video, but falters when full-duplex communication — such as a Zoom call — is required.
For Comparison
The OSS backend in cubeb does properly enumerate devices by probing /dev/sndstat (cubeb_oss.c:344–443). A similar effort for ALSA would be only reasonable.
In Summary
The fix amounts to implementing what the standalone Zoom app already does: using ALSA as it’s meant to be used. The current stub is so far from proper enumeration that a full rewrite — replacing fiction with fact — is the only sensible path forward.
Citations
File: src/cubeb_alsa.c (L73-78)
#define CUBEB_STREAM_MAX 16
#define CUBEB_WATCHDOG_MS 10000
#define CUBEB_ALSA_PCM_NAME "default"
#define ALSA_PA_PLUGIN "ALSA <-> PulseAudio PCM I/O Plugin"File: src/cubeb_alsa.c (L1213-1221)
r = WRAP(snd_pcm_hw_params_any)(stm->pcm, hw_params);
if (r < 0) {
return CUBEB_ERROR;
}
r = WRAP(snd_pcm_hw_params_get_channels_max)(hw_params, max_channels);
if (r < 0) {
return CUBEB_ERROR;
}
File: src/cubeb_alsa.c (L1408-1456)
static int
alsa_enumerate_devices(cubeb * context, cubeb_device_type type,
cubeb_device_collection * collection)
{
cubeb_device_info * device = NULL;
if (!context)
return CUBEB_ERROR;
uint32_t rate, max_channels;
int r;
r = alsa_get_preferred_sample_rate(context, &rate);
if (r != CUBEB_OK) {
return CUBEB_ERROR;
}
r = alsa_get_max_channel_count(context, &max_channels);
if (r != CUBEB_OK) {
return CUBEB_ERROR;
}
char const * a_name = "default";
device = (cubeb_device_info *)calloc(1, sizeof(cubeb_device_info));
assert(device);
if (!device)
return CUBEB_ERROR;
device->device_id = a_name;
device->devid = (cubeb_devid)device->device_id;
device->friendly_name = a_name;
device->group_id = a_name;
device->vendor_name = a_name;
device->type = type;
device->state = CUBEB_DEVICE_STATE_ENABLED;
device->preferred = CUBEB_DEVICE_PREF_ALL;
device->format = CUBEB_DEVICE_FMT_S16NE;
device->default_format = CUBEB_DEVICE_FMT_S16NE;
device->max_channels = max_channels;
device->min_rate = rate;
device->max_rate = rate;
device->default_rate = rate;
device->latency_lo = 0;
device->latency_hi = 0;
collection->device = device;
collection->count = 1;
return CUBEB_OK;File: src/cubeb_oss.c (L344-443)
static int
oss_enumerate_devices(cubeb * context, cubeb_device_type type,
cubeb_device_collection * collection)
{
cubeb_device_info * devinfop = NULL;
char * line = NULL;
size_t linecap = 0;
FILE * sndstatfp = NULL;
int collection_cnt = 0;
int is_ud = 0;
int skipall = 0;
devinfop = calloc(1, sizeof(cubeb_device_info));
if (devinfop == NULL)
goto fail;
sndstatfp = fopen("/dev/sndstat", "r");
if (sndstatfp == NULL)
goto fail;
while (getline(&line, &linecap, sndstatfp) > 0) {
const char * devid = NULL;
struct sndstat_info sinfo;
oss_audioinfo ai;
if (!strncmp(line, SNDSTAT_FV_BEGIN_STR, strlen(SNDSTAT_FV_BEGIN_STR))) {
skipall = 1;
continue;
}
if (!strncmp(line, SNDSTAT_BEGIN_STR, strlen(SNDSTAT_BEGIN_STR))) {
is_ud = 0;
skipall = 0;
continue;
}
if (!strncmp(line, SNDSTAT_USER_BEGIN_STR,
strlen(SNDSTAT_USER_BEGIN_STR))) {
is_ud = 1;
skipall = 0;
continue;
}
if (skipall || isblank(line[0]))
continue;
if (oss_sndstat_line_parse(line, is_ud, &sinfo))
continue;
devinfop[collection_cnt].type = 0;
switch (sinfo.type) {
case CUBEB_DEVICE_TYPE_INPUT:
if (type & CUBEB_DEVICE_TYPE_OUTPUT)
continue;
break;
case CUBEB_DEVICE_TYPE_OUTPUT:
if (type & CUBEB_DEVICE_TYPE_INPUT)
continue;
break;
case 0:
continue;
}
if (oss_probe_open(sinfo.devname, type, NULL, &ai))
continue;
devid = oss_cubeb_devid_intern(context, sinfo.devname);
if (devid == NULL)
continue;
devinfop[collection_cnt].device_id = strdup(sinfo.devname);
asprintf((char **)&devinfop[collection_cnt].friendly_name, "%s: %s",
sinfo.devname, sinfo.desc);
devinfop[collection_cnt].group_id = strdup(sinfo.devname);
devinfop[collection_cnt].vendor_name = NULL;
if (devinfop[collection_cnt].device_id == NULL ||
devinfop[collection_cnt].friendly_name == NULL ||
devinfop[collection_cnt].group_id == NULL) {
oss_free_cubeb_device_info_strings(&devinfop[collection_cnt]);
continue;
}
devinfop[collection_cnt].type = type;
devinfop[collection_cnt].devid = devid;
devinfop[collection_cnt].state = CUBEB_DEVICE_STATE_ENABLED;
devinfop[collection_cnt].preferred =
(sinfo.preferred) ? CUBEB_DEVICE_PREF_ALL : CUBEB_DEVICE_PREF_NONE;
devinfop[collection_cnt].format = CUBEB_DEVICE_FMT_S16NE;
devinfop[collection_cnt].default_format = CUBEB_DEVICE_FMT_S16NE;
devinfop[collection_cnt].max_channels = ai.max_channels;
devinfop[collection_cnt].default_rate = OSS_PREFER_RATE;
devinfop[collection_cnt].max_rate = ai.max_rate;
devinfop[collection_cnt].min_rate = ai.min_rate;
devinfop[collection_cnt].latency_lo = 0;
devinfop[collection_cnt].latency_hi = 0;
collection_cnt++;
void * newp =
reallocarray(devinfop, collection_cnt + 1, sizeof(cubeb_device_info));
if (newp == NULL)
goto fail;
devinfop = newp;
}Zoom works with ALSA out of the box because it directly interfaces with ALSA’s native audio API on Linux, bypassing the need for PulseAudio or compatibility layers like apulse.
The Zoom Workplace client is built to use ALSA as a first-class audio backend. As long as your system’s ALSA configuration supports full-duplex audio (simultaneous playback and recording), Zoom can access the microphone and speakers without additional tools.
Debian, Devuan, and many other Linux distributions enable full-duplex by default in their ALSA setup — meaning no user configuration is required. Tools like arecord and aplay can test this:
arecord -f cd -V mono | aplayIf you see a VU meter, full-duplex is active — and Zoom will work immediately.
Zoom does not rely on dmix or dsnoop plugins unless custom configurations demand them. It accesses the default PCM devices directly, which is why it functions reliably on minimal or pure ALSA systems.
Zoom does not enable an internal full-duplex mode if your ALSA configuration lacks it.
Zoom relies entirely on the underlying ALSA setup to provide full-duplex audio (simultaneous playback and recording). If your sound card or ALSA configuration does not support full-duplex — either through hardware capabilities or proper software configuration (e.g., using dmix and dsnoop, or a full-duplex PCM device) — Zoom cannot create that functionality on its own
However, Zoom can work around certain limitations when:
- The default PCM device is correctly configured (e.g., using plughw or a plug-type device).
- Full-duplex is achievable at the driver or configuration level.
But if your sound system cannot perform full-duplex audio (as tested via arecord | aplay), Zoom will not function properly, and you may experience one-way audio or dropped streams.
In short: Full-duplex must be enabled at the ALSA level — Zoom won’t add it if it’s missing.
Zoom Workplace for Linux works seamlessly with ALSA (Advanced Linux Sound Architecture) without requiring additional sound servers such as PulseAudio. In most cases, no special configuration is needed — even with custom ALSA setups.
You can download Zoom Workplace from:
_https://zoom.us/download
Compatibility Overview
✅ Works out of the box with default ALSA configurations.
✅ Compatible with modified ALSA setups (e.g., those using fftrate resampling).
✅ Functions correctly with ALSA configurations generated by tools like arateconf.
🔑 Full-duplex audio support must be enabled in your ALSA configuration for optimal performance.
How to Use Zoom with Default ALSA Settings
Even if you're new to Linux audio configuration, rest assured — everything should work straight away. Follow these steps to confirm your setup:
1. Ensure Default ALSA Configuration Is Active
If you've previously created a custom configuration file, remove it temporarily:
rm ~/.asoundrc
This ensures you’re using the standard system-wide ALSA settings (as provided by Debian, Devuan, or your distribution).
2. Identify Your Sound Card
List available sound cards:
cat /proc/asound/cards
Or check card IDs directly:
cat /sys/class/sound/card*/id
Note the name (e.g., PCH, system) — you’ll need this if your system has multiple audio devices.
3. Set the Default Sound Card (Optional – For Multi-Card Systems)
If you have more than one sound card, create a user-level configuration file:
nano ~/.asoundrc
Add the following lines, replacing PCH with your actual card name:
defaults.pcm.!card PCH
defaults.ctl.!card PCH
4. Connect a Microphone
Plug in an external microphone or ensure the built-in mic is available.
5. Adjust Microphone Volume
Open the ALSA mixer:
alsamixer
- Press F4 to switch to capture (recording) controls.
- Use the arrow keys to increase the microphone level.
- Press Esc to exit.
6. Test Full-Duplex Audio
Verify that your system can play and record simultaneously:
arecord -f cd -V mono | aplay
You should see a real-time VU meter indicating activity:
Recording WAVE 'stdin' : Signed 16 bit Little Endian, Rate 44100 Hz, Stereo
Playing WAVE 'stdin' : Signed 16 bit Little Endian, Rate 44100 Hz, Stereo
###############+ | 29%
This confirms bidirectional audio is functioning.
7. Exit the Test
Press Ctrl+C to stop the recording and playback.
💡 Since this test uses the default audio device, successful completion strongly suggests Zoom will work without issues.
Installing and Testing Zoom
1. Install Zoom Workplace for Linux from the official website. _https://zoom.us/download
2. Launch it from the terminal:
zoom
3. Go to Settings > Audio.
4. Use the Test Microphone button to verify input and output.
Both microphone and speakers should function correctly with no further configuration.
📝 Note: Tools like apulse (a PulseAudio compatibility layer) are *not required*. Zoom interacts directly with ALSA and performs well without emulation layers.
With this setup, Zoom Workplace delivers reliable audio performance on pure ALSA systems—ideal for lightweight or minimal Linux installations.
librewolf? Try
MOZ_LOG="cubeb:5" librewolf 2>&1 about:supportIt seems that Zoom does not like Firefox Nightly
Zoom may not be supported on your browser
Copy the link below and paste it in Safari, Chrome, Firefox, Edge, or Opera
Installed Zoom Workplace for Linux. It works with ALSA out of the box.
Zoom app > Settings > Audio > Test microphone
apulse is not needed
Zoom Workplace for Linux
_https://zoom.us/download
Zoom Workplace app also works with ALSA on Linux Mint.
hot-plug? Do you mean jack sensing?
Jack sensing is a feature in audio devices that automatically detects when a plug, such as headphones or an auxiliary cable, is inserted or removed from the audio jack. This detection triggers an event, like muting the internal speakers or prompting the user to select an audio output. It is primarily implemented using either mechanical switches or impedance-based measurements.
Run
alsamixerand set everything right.
about:support
Name Firefox Nightly
Version 146.0a1
Build ID 20251108203729
...
Audio Backend alsa
Max Channels 10000
Preferred Sample Rate 48000
Roundtrip latency (standard deviation) NaNms (NaN)$ MOZ_LOG="cubeb:5" firefox-nightly 2>&1 about:support
[Parent 14786: Main Thread]: V/cubeb media.cubeb.force_null_context: false
[Parent 14786: Main Thread]: V/cubeb media.cubeb.sandbox: true
ATTENTION: default value of option mesa_glthread overridden by environment.
ATTENTION: default value of option mesa_glthread overridden by environment.
ATTENTION: default value of option mesa_glthread overridden by environment.
[Child 14912: Main Thread]: V/cubeb media.cubeb.force_null_context: false
[Child 14912: Main Thread]: V/cubeb media.cubeb.sandbox: true
[Child 14912: Main Thread]: W/cubeb could not set real-time limit in CubebUtils::InitLibrary
[Parent 14786: Main Thread]: D/cubeb Starting cubeb server...
[Parent 14786: Main Thread]: D/cubeb media.audioipc.shm_area_size: 0
JavaScript warning: resource://gre/modules/Troubleshoot.sys.mjs, line 723: WebGL context was lost.
JavaScript warning: resource://gre/modules/Troubleshoot.sys.mjs, line 723: WebGL context was lost.
[Parent 14786: Main Thread]: I/cubeb media.cubeb.sandbox: true
[Parent 14786: Main Thread]: D/cubeb media.audioipc.shm_area_size: 0
[Parent 14786: Main Thread]: D/cubeb media.audioipc.stack_size: 262144
[Parent 14786: AudioIPC Server RPC]: E/cubeb cubeb.c:727:DeviceID: "default" (PREFERRED)
Name: "default"
Group: "default"
Vendor: "default"
Type: output
State: enabled
Maximum channels: 10000
Format: S16LE (0x10) (default: S16LE)
Rate: [48000, 48000] (default: 48000)
Latency: lo 0 frames, hi 0 frames
[Parent 14786: Main Thread]: E/cubeb cubeb.c:727:DeviceID: "default" (PREFERRED)
Name: "default"
Group: "default"
Vendor: "default"
Type: output
State: enabled
Maximum channels: 10000
Format: S16LE (0x10) (default: S16LE)
Rate: [48000, 48000] (default: 48000)
Latency: lo 0 frames, hi 0 frames
[Parent 14786: AudioIPC Server RPC]: E/cubeb cubeb.c:727:DeviceID: "default" (PREFERRED)
Name: "default"
Group: "default"
Vendor: "default"
Type: input
State: enabled
Maximum channels: 10000
Format: S16LE (0x10) (default: S16LE)
Rate: [48000, 48000] (default: 48000)
Latency: lo 0 frames, hi 0 frames
[Parent 14786: Main Thread]: E/cubeb cubeb.c:727:DeviceID: "default" (PREFERRED)
Name: "default"
Group: "default"
Vendor: "default"
Type: input
State: enabled
Maximum channels: 10000
Format: S16LE (0x10) (default: S16LE)
Rate: [48000, 48000] (default: 48000)
Latency: lo 0 frames, hi 0 frames
[Child 14981: Main Thread]: V/cubeb media.cubeb.force_null_context: false
[Child 14981: Main Thread]: V/cubeb media.cubeb.sandbox: true
[Child 14981: Main Thread]: W/cubeb could not set real-time limit in CubebUtils::InitLibrary
[Parent 14786: Main Thread]: D/cubeb media.audioipc.shm_area_size: 0
[Child 15006: Main Thread]: V/cubeb media.cubeb.force_null_context: false
[Child 15006: Main Thread]: V/cubeb media.cubeb.sandbox: true
[Child 15006: Main Thread]: W/cubeb could not set real-time limit in CubebUtils::InitLibrary
[Parent 14786: Main Thread]: D/cubeb media.audioipc.shm_area_size: 0
...
[Parent 14786: BackgroundThreadPool #1]: D/cubeb Default devices latency in seconds -nan (stddev: -nan)Firefox 58 (Nightly) tightened its sandbox a bit more. Now ioctl() calls are forbidden too, but are used by ALSA libraries. That causes sandbox violation with subsequent process termination. Exception can be added by setting parameter security.sandbox.content.syscall_whitelist in about:config. That field accepts a comma separated list of system call numbers. Add there 16 for x86-64, or 54 for x86 or ARM.
Firefox 60 tighened its content sandbox more, but at the same time moved audio accesses from content processes to the main process. From Firefox 60 onwards no changes to the sandbox settings are necessary.
_https://github.com/i-rinat/apulse
What Logs Show
Firefox Nightly logs confirm the Firefox 60+ architecture change is working correctly:
[Parent 14786: Main Thread]: D/cubeb Starting cubeb server...
[Parent 14786: AudioIPC Server RPC]: E/cubeb cubeb.c:727:DeviceID: "default"The key evidence:
1. Audio runs in the parent process: Notice [Parent 14786: Main Thread] and [Parent 14786: AudioIPC Server RPC] - audio device enumeration happens in the parent process, not child processes
2. AudioIPC architecture: The log shows Starting cubeb server... and AudioIPC Server RPC, which is Firefox's audio IPC (Inter-Process Communication) system that isolates audio in a separate server process
3. Sandbox is enabled but doesn't block audio: media.cubeb.sandbox: true in both parent and child processes, yet audio devices are successfully enumerated (both input and output show as State: enabled)
4. No sandbox override needed: Unlike your ESR logs where Firefox forced the sandbox setting, Nightly respects the sandbox while still allowing audio access through the AudioIPC architecture
Why This Works in Nightly but Not ESR
The difference between Firefox 140.5.0 ESR and Nightly:
- ESR (logs): Shows [Child 12906: Main Thread]: E/cubeb media.cubeb.sandbox: false, but content sandbox enabled - forcing true, indicating audio was being accessed from child processes where the sandbox blocked it
- Nightly (current logs): Audio access happens in [Parent 14786: AudioIPC Server RPC], completely bypassing the content process sandbox issue
This confirms that Firefox ESR 140.5.0 may have regressed or not fully implemented the Firefox 60+ audio architecture, while Nightly has it working correctly.
What This Means for Cubeb
From Cubeb's perspective, nothing changed - the ALSA backend code is identical in both cases :
- It still opens devices with snd_pcm_open() [link to Repo mozilla/cubeb: src/cubeb_alsa.c:1050-1051]
- It still enumerates devices the same way [link to Repo mozilla/cubeb: src/cubeb_alsa.c:1430-1451]
- The latency reporting still returns 0 due to ALSA's dmix/dsnoop limitations [link to Repo mozilla/cubeb: src/cubeb_alsa.c:1450-1451]
The difference is where Firefox calls this code - in the parent process (Nightly) vs. sandboxed child processes (your ESR).
Notes
Nightly logs prove that the microphone issue in ESR is indeed a Firefox sandbox architecture problem, not a Cubeb bug. The Cubeb ALSA backend works perfectly when Firefox's AudioIPC architecture is properly implemented.
@kapqa Could you please test Zoom app (audio test, out + mic). It should work on both Devuan and Mint with ALSA out of the box.
No apulse is need.
2. Could you also test Zoom with Firefox, which you compiled yourself without pulse. It should also work with ALSA out of the fox.
apulse is, in any case, useless with your Firefox, because it does not have pulse-rust backend.
It seems that Debian developers disabled mic in FirefoxESR (ALSA ) by some special sort of sandboxing to enforce pulseaudio.
The obvious solution is to remove them both in one command.
Another obvious solution is to put them on hold.
Old manual for Devuan 5:
$ dpkg-query -W -f='${Package;-40}${Description;50}\n' | grep pulseaudio
pulseaudio PulseAudio sound server
pulseaudio-module-bluetooth Bluetooth module for PulseAudio sound server
pulseaudio-utils Command line tools for the PulseAudio sound server$ dpkg-query -W -f='${Package;-40}${Description;50}\n' | grep libpulse
libpulse-mainloop-glib0 PulseAudio client libraries (glib support)
libpulse0 PulseAudio client libraries
libpulsedsp PulseAudio OSS pre-load libraryTo prevent "autoremove":
$ sudo apt-mark manual libpulse0 libpulse-mainloop-glib0 libpulsedsp Set on hold other crap:
$ sudo apt-mark hold pulseaudio* pipewire* Purge pulseaudio/pipewire
$ sudo apt-get purge pulseaudio pulseaudio-utils pavucontrol pulseaudio-module-bluetooth pipewire pipewire-bin pipewire-pulse rtkitKill PulseAudio:
$ killall pulseaudio$ fuser -av $(find /dev/snd -type c 2>/dev/null)
USER PID ACCESS COMMAND
/dev/snd/controlC1:
/dev/snd/pcmC1D0c:
/dev/snd/pcmC1D0p:
/dev/snd/controlC0:and reboot.
There are still some pulse/pipe libs
$ dpkg-query -W -f='${Package;-40}${Description;50}\n' | grep pulse
libpulse-mainloop-glib0 PulseAudio client libraries (glib support)
libpulse0 PulseAudio client libraries
libpulsedsp PulseAudio OSS pre-load library$ dpkg-query -W -f='${Package;-40}${Description;50}\n' | grep pipe
libpipeline1 Unix process pipeline manipulation library
libpipewire-0.3-0 libraries for the PipeWire multimedia server
libpipewire-0.3-common libraries for the PipeWire multimedia server - com@kapqa Could you please test Zoom app (audio test, out + mic). It should work on both Devuan and Mint with ALSA out of the box.
No apulse is need.
2. Could you also test Zoom with Firefox, which you compiled yourself without pulse. It should also work with ALSA out of the fox.
apulse is, in any case, useless with your Firefox, because it does not have pulse-rust backend.
It seems that Debian developers disabled mic in FirefoxESR (ALSA ) by some special sort of sandboxing to enforce pulseaudio.
Right, then — the fftrate package comes with two resamplers: fft and dct. The dct one’s a bit quicker, though neither’s likely to raise an eyebrow in everyday use. Mind you, there was that one chap on Gentoo using OSS4 who reckoned he spotted the difference in a blind test — fair play to him.
If you’re after hard numbers, pcm_conv and pcm_mse will give you the lowdown on latency and precision.
_https://dev1galaxy.org/viewtopic.php?id=6722
Right, then — if you’re wondering about fftrate and its little helpers like arateconf or pcm_conv, feel free to pop the question. It’s not entirely unpleasant to use ALSA once you’ve got arateconf doing the heavy lifting. Without it? Well, let’s just say it’s not quite a walk in the park. The ALSA API isn’t exactly… charming, but then again, Linux has never gone in for frivolous hand-holding. That said, even the faintly tone-deaf might notice an improvement in sound quality once PulseAudio’s been shown the door. And if you’re still able to hear the difference (lucky you), installing the fftrate plugin and setting it up for high-res playback might just be worth a go. Not that it’s life-changing or anything.
@spliskin You're most kind — and quite right: ALSA does rather quietly get on with the job. It’s not often celebrated, but yes, it can be capable — and even enjoyable, especially with fftrate and arateconf. If it’s not too much trouble, do give them a go. Instructions for compiling and using are here:
How to compile: _https://dev1galaxy.org/viewtopic.php?id=7142
How to use: _https://dev1galaxy.org/viewtopic.php?id=6644
From a modest point of view, arateconf does rather quietly solve the problem — guiding users to a working ALSA setup without fuss or guesswork. It’s not flashy, but it gets the job done, and that’s what matters.
A fully functional software mixer in ALSA — combining dmix for playback, dsnoop for capture, and asym for full-duplex operation — has been enabled by default for over a decade, especially on common hardware like HDA-Intel.
It started with ALSA 1.0.9rc2 (2005), when dmix became automatic for analog outputs. Since then, multiple apps playing audio at once just works.
While dmix was early, dsnoop and full-duplex lagged — but in Debian, they’ve long been included with "sane defaults" via the libasound2-data package.
Files like:
/usr/share/alsa/alsa.conf
/usr/share/alsa/pcm/dmix.conf
/usr/share/alsa/pcm/dsnoop.conf
/usr/share/alsa/cards/HDA-Intel.confalready define working dmix, dsnoop, and asym setups.
As the Debian Wiki says:
Advanced features such as mixing should already be configured with sane defaults.
_https://wiki.debian.org/ALSA#Configuration
This means:
✅ Multiple playback sources work via dmix.
✅ Microphone sharing works via dsnoop.
✅ Full-duplex is ready via asym.
NOTE: Analog outputs use dmix by default. S/PDIF (digital) usually does not — it may need manual setup.
Today, concurrent audio playback and full-duplex operation work out of the box on most hardware without PulseAudio.
Full duplex is rather essential for video conferencing — one can't very well have a proper conversation if only one person can speak at a time. It’s much like a telephone call, really: both parties need to talk and listen simultaneously for things to flow naturally.
There’s a rather persistent rumour that full duplex works with default ALSA config — as if it were some sort of conspiracy. But it’s easily tested: just run aplay and arecord at the same time. The truth is, it does work — not by magic, but because Debian and Devuan have sensible defaults. It’s not a secret; it’s just quietly reliable.
No config needed. Just follow these steps:
1. Remove any custom ALSA config (if you have one):
rm ~/.asoundrcThis ensures you're testing the default Debian/Devuan setup.
2. Check your sound card name:
cat /proc/asound/cardscat /sys/class/sound/card*/idLook for the name (e.g., PCH, system). You’ll need it if you have more than one card.
3. Set default card (only if multiple cards):
Create ~/.asoundrc with:
defaults.pcm.!card PCH
defaults.ctl.!card PCH
Replace PCH with your card name.
4. Connect a microphone (or use built-in mic).
5. Set mic volume:
alsamixer
Press F4 to switch to capture, then adjust mic level. Press Esc to exit.
6. Test full-duplex — play and record at the same time:
aplay a*test*.wav & arecord --vumeter=mono -f cd recorded.wav
Speak into the mic while the sound plays.
The --vumeter=mono option shows a moving ########+ bar — instant proof that recording works.
Example:
$ aplay a*test*.wav & arecord --vumeter=mono -f cd recorded.wav
Playing WAVE 'audio_test_48kHz_16bit.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Stereo
Recording WAVE 'recorded.wav' : Signed 16 bit Little Endian, Rate 44100 Hz, Stereo
########+ | 14% 7. Stop recording with Ctrl+C, then:
killall aplay
8. Play back what you recorded:
aplay recorded.wav
You should hear the test tone and your voice.
✅ If both played and recorded — full-duplex works.
No PulseAudio. No PipeWire. Just plain ALSA.
There’s a modest suggestion that full duplex functions in Debian and Devuan — nothing flashy, mind you, but it does rather quietly go about its business. One might, with restraint, describe the test arecord -f cd -V mono | aplay as a faintly reliable way to confirm it. The VU meter, when it appears, is best viewed as a polite hint that things are working — not a cause for undue excitement.
$ arecord -f cd -V mono | aplay
Recording WAVE 'stdin' : Signed 16 bit Little Endian, Rate 44100 Hz, Stereo
Playing WAVE 'stdin' : Signed 16 bit Little Endian, Rate 44100 Hz, Stereo
###############+ | 29% Piping arecord into aplay means sending audio from the recorder directly to the player in real time — no file needed, just a live chain. It’s a quiet way to test full duplex: one speaks, the other plays, both at once.
The default ALSA software mixer works well enough, and sound quality — while not exactly a priority — has rarely troubled its users. One might say the standard Linux resamplers — including speexrate — are functional, though perhaps not quite up to the task if one happens to care about audio quality. fftrate remains the sensible choice for those who do.
The default ALSA setup functions well enough, though one might say the audio quality could be… more convincing with a small adjustment.
The method is straightforward:
fftrate: A resampler of noticeably better quality than the standard options.
Precise timing: Helps avoid the faint smearing that lesser resamplers tend to introduce.
Key Settings
defaults.pcm.rate_converter "fftrate"Instructs ALSA to use fftrate for all sample rate conversion — a quiet but meaningful upgrade.
defaults.pcm.period_time 40000 # 40 ms
defaults.pcm.periods 4Sets a buffer of 160 ms total — stable, and just right for fftrate to do its work properly (J: 0.00%).
# defaults.pcm.dmix.rate 192000 # Max for Intel HDA
# defaults.pcm.dmix.rate 96000
# defaults.pcm.dmix.rate 48000 # Default
# defaults.pcm.dmix.rate 44100Uncomment one to match your DAC’s native rate.
All audio is then resampled once, cleanly, before reaching the hardware.
NOTE: fftrate is rather better than most built-in hardware resamplers. While one could leave things at 48kHz, it’s generally best to set defaults.pcm.dmix.rate to the maximum your DAC supports — 192kHz or 384kHz — and leave it. This avoids repeated or low-quality resampling elsewhere. It’s not magic — just a bit of quiet competence.
For Multiple Sound Cards
Uncomment and set:
# defaults.pcm.!card PCH
# defaults.ctl.!card PCHCheck your card name:
cat /proc/asound/cards
cat /sys/class/sound/card*/idA few lines in ~/.asoundrc are sufficient to override the defaults:
defaults.pcm.rate_converter "fftrate"
defaults.pcm.period_time 40000
defaults.pcm.periods 4
# defaults.pcm.dmix.rate 192000
# defaults.pcm.!card PCH
# defaults.ctl.!card PCHThe modified configuration file (dmix & dsnoop) with user defaults:
cat ~/.asoundrc
defaults.pcm.rate_converter "fftrate" # default resampler
defaults.pcm.period_time 40000 # best left as is, really
defaults.pcm.periods 4 # as above — no need to fiddle
# defaults.pcm.dmix.rate 192000 # Max for Intel HDA
# defaults.pcm.dmix.rate 96000
# defaults.pcm.dmix.rate 48000 # Default
# defaults.pcm.dmix.rate 44100
# defaults.pcm.!card PCH # Intel HDA codec.
# defaults.ctl.!card PCH # Intel HDA codec
# defaults.ctl.card 0 # Default
# defaults.pcm.card 0 # Default
# defaults.pcm.device 0 # Default
# defaults.pcm.dmix.channels 2 # Default
# defaults.pcm.dmix.format unchanged # Default
# defaults.pcm.dmix.format S32_LE # Max for Intel HDA
#
# 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 {
@func refer
name defaults.pcm.period_time
}
}
periods {
@func refer
name {
@func concat
strings [
"defaults.dmix."
{
@func card_id
card $CARD
}
".periods"
]
}
default {
@func refer
name defaults.pcm.periods
}
}
}
hint {
show {
@func refer
name defaults.namehint.extended
}
description "Direct sample mixing device"
device_output $DEV
}
}
#
# dsnoop
#
pcm.!dsnoop {
@args [ CARD DEV SUBDEV FORMAT RATE ]
@args.CARD {
type string
default {
@func refer
name defaults.pcm.dsnoop.card
}
}
@args.DEV {
type integer
default {
@func refer
name defaults.pcm.dsnoop.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
}
}
type dsnoop
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
period_size {
@func refer
name {
@func concat
strings [
"cards."
{
@func card_id
card $CARD
}
".pcm.dsnoop.period_size"
]
}
default -1
}
period_time {
@func refer
name {
@func concat
strings [
"cards."
{
@func card_id
card $CARD
}
".pcm.dsnoop.period_time"
]
}
default {
@func refer
name defaults.pcm.period_time
}
}
periods {
@func refer
name {
@func concat
strings [
"cards."
{
@func card_id
card $CARD
}
".pcm.dsnoop.periods"
]
}
default {
@func refer
name defaults.pcm.periods
}
}
}
hint {
show {
@func refer
name defaults.namehint.extended
}
description "Direct sample snooping device"
device_input $DEV
}
}To get microphone working with Firefox, you should completely disable sandboxing.
This is, of course, a security problem.
SETUP for DEBUG (MOZ_LOG):
$ inxi -Sxxx
System:
Host: devuan Kernel: 6.1.0-41-amd64 arch: x86_64 bits: 64 compiler: gcc
v: 12.2.0 Desktop: MATE v: 1.26.0 info: mate-panel wm: marco v: 1.26.1 vt: 7
dm: LightDM v: 1.26.0 Distro: Devuan GNU/Linux 5 (daedalus)about:support
Name Firefox
Version 140.5.0esr
Build ID 20251106203603
...
Audio Backend alsa
Max Channels 10000
Preferred Sample Rate 48000
Roundtrip latency (standard deviation) NaNms (NaN)about:config
media.cubeb.backend alsa
media.cubeb.sandbox falseDefault Debian/Devuan ALSA config (without any changes).
1 soundcard iMic USB
$ cat ~/.asoundrc
cat: ~/.asoundrc: No such file or directoryDebug (Mozilla logging):
MOZ_DISABLE_CONTENT_SANDBOX=1 MOZ_LOG="cubeb:5" firefox 2>&1 about:support Type: input
State: enabled
Maximum channels: 10000
Format: S16LE (0x10) (default: S16LE)
Rate: [48000, 48000] (default: 48000)
Latency: lo 0 frames, hi 0 frames$ MOZ_DISABLE_CONTENT_SANDBOX=1 MOZ_LOG="cubeb:5" firefox 2>&1 about:support
[Parent 10304: Main Thread]: V/cubeb media.cubeb.force_null_context: false
[Parent 10304: Main Thread]: V/cubeb media.cubeb.sandbox: true
[Parent 10304: Main Thread]: V/cubeb media.cubeb.sandbox: false
[Child 10401: Main Thread]: V/cubeb media.cubeb.force_null_context: false
[Child 10401: Main Thread]: V/cubeb media.cubeb.sandbox: false
[Parent 10304: Main Thread]: I/cubeb media.cubeb.sandbox: false
[Parent 10304: 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: [48000, 48000] (default: 48000)
Latency: lo 0 frames, hi 0 frames
[Parent 10304: Main Thread]: E/cubeb cubeb.c:654:DeviceID: "default" (PREFERRED)
Name: "default"
Group: "default"
Vendor: "default"
Type: input
State: enabled
Maximum channels: 10000
Format: S16LE (0x10) (default: S16LE)
Rate: [48000, 48000] (default: 48000)
Latency: lo 0 frames, hi 0 frames
[Child 10461: Main Thread]: V/cubeb media.cubeb.force_null_context: false
[Child 10461: Main Thread]: V/cubeb media.cubeb.sandbox: false
[Parent 10304: BackgroundThreadPool #1]: E/cubeb Could not get input latency
[Parent 10304: BackgroundThreadPool #1]: E/cubeb Could not get input latencyThe "Could not get input latency" error in Firefox with ALSA is a known limitation in Cubeb.
Despite dsnoop working and audio flowing, Cubeb fails to query latency from ALSA input devices — especially when using dmix/dsnoop via the default PCM. This results in 0 frames reported for input latency, even though capture works.
This issue is documented in:
Bugzilla #1650131 : ALSA input shows Latency: lo 0 frames, hi 0 frames
_https://bugzilla.mozilla.org/show_bug.cgi?id=1650131
Bugzilla #907817 : ALSA backend does not implement proper latency reporting
_https://bugzilla.mozilla.org/show_bug.cgi?id=907817
Cubeb assumes PulseAudio or PipeWire for accurate timing — with raw ALSA, it falls back to estimated or fixed latency values.
The setup works — the error is cosmetic and reflects Cubeb’s lack of ALSA input latency support, not a functional failure.
Right — the setup works, really. Only a minor security oversight, nothing one wouldn’t overlook. PulseAudio, of course, enjoys a rather privileged position — able to wander in and out as it pleases. ALSA, on the other hand, is quite content with its role: quietly serving, obeying, and generally staying out of the way. One might say its freedom is… limited, just enough to make independent use a tad inconvenient.
And if one happens to hear perfectly well, well — perhaps macOS was the intended destination all along.
Firefox with apulse
Firefox pulse-rust → apulse → ALSA Input is ENABLED Roundtrip latency 162.86ms (18.90)$ MOZ_LOG="cubeb:5" apulse firefox 2>&1 about:support
...
Type: output
State: enabled
...
Type: input
State: enabled
Maximum channels: 2
Format: S16LE S16BE F32LE F32BE (0x3030) (default: S16LE)
Rate: [1, 384000] (default: 44100)
Labout:support
Name Firefox
Version 140.5.0esr
Build ID 20251106203603
...
Audio Backend pulse-rust
Max Channels 2
Preferred Sample Rate 44100
Roundtrip latency (standard deviation) 162.86ms (18.90)Firefox with ALSA without apulse
Firefox → ALSA NOTHING about Input Roundtrip latency ?$ MOZ_LOG="cubeb:5" firefox 2>&1 about:support
...
Type: output
State: enabled
Maximum channels: 10000
Format: S16LE (0x10) (default: S16LE)
Rate: [48000, 48000] (default: 48000)
Latency: lo 0 frames, hi 0 frames
# NOTHING about Inputabout:support
Name Firefox
Version 140.5.0esr
Build ID 20251106203603
...
Audio Backend alsa
Max Channels 10000
Preferred Sample Rate 48000
Roundtrip latency (standard deviation) NaNms (NaN)Défault ALSA config, only one soundcard iMic USB
You can file a bug to Firefox (CUBEB's ALSA backend)
Full duplex is also enabled by default with asym in /usr/share/alsa/cards/HDA-Intel.conf
MOZ_LOG="cubeb:5" should show
Type: input
State: enabledDMIX IS ENABLED by default.
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.
Set defaults in ~/.asoundrc:
$ cat ~/.asoundrc
defaults.pcm.!card PCH
defaults.ctl.!card PCHand run
apulse firefox$ apt-cache search apulse
apulse - PulseAudio emulation for ALSADebug (logging):
with apulse
MOZ_LOG="cubeb:5" apulse firefox 2>&1 about:supportwithout apulse
MOZ_LOG="cubeb:5" firefox 2>&1 about:supportFull 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/' ~/.asoundrcYou 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.
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.
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.
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
If you compile Audacious, libaudcore should be inside Audacious.
libaudcore5t64:amd64 should be removed.
On Debian and Ubuntu, the audacious package is split into 6 packages:
audacious
audacious-dev
libaudcore5t64
libaudgui6
libaudqt3
libaudtag3t64_https://tracker.debian.org/pkg/audacious
The audacious-plugins package is split into two packages:
audacious-plugins
audacious-plugins-data_https://tracker.debian.org/pkg/audacious-plugins
They all should be removed, if you are going to compile and install Audacious from git.
On Gentoo, you can remove ALL pulseaudio (together with libs) with one command. It will recompile many packages to remove pulse dependencies. On Debian, there are developers scripts which are normally used to recompile all packages.
Do you need a fully functional ALSA software mixer? For example:
$ cat ~/.asoundrc
# ALSA library configuration file managed by arateconf.
#
# MANUAL CHANGES TO THIS FILE WILL BE OVERWRITTEN!
#
# Manual changes to the ALSA library configuration should be implemented
# by editing the ~/.asoundrc file, not by editing this file.
#=====================================================
# Configuration for system
#-----------------------------------------------------
# Perform dmixer
pcm.dmixer_system
{
type dmix
ipc_key 1024
ipc_perm 0666
hint
{
show off
description "Direct mixing of multiple audio streams (system)"
}
slave
{
pcm "hw:system,0"
rate 48000
channels 2
format S16_LE
period_size 1920
buffer_size 7680
}
}
# Perform dsnooper
pcm.dsnooper_system
{
type dsnoop
ipc_key 1025
ipc_perm 0666
hint
{
show off
description "Recording from the same device for several applications simultaneously (system)"
}
slave
{
pcm "hw:system,0"
rate 48000
format S16_LE
period_size 1920
buffer_size 7680
}
}
# Perform duplex
pcm.duplex_system
{
type asym
playback.pcm "dmixer_system"
capture.pcm "dsnooper_system"
hint
{
show off
description "Full duplex for simultaneous playback and recording (system)"
}
}
# Perform convert
pcm.convert_system
{
type rate
converter fftrate
hint
{
show off
description "Sample rate converter (system)"
}
slave
{
pcm "duplex_system"
rate 48000
format S16_LE
}
}
# Perform plug device
pcm.primary_system
{
type plug
slave.pcm "convert_system"
hint.description "Default device (system)"
}
#=====================================================
# Configuration for PCH
#-----------------------------------------------------
# Perform dmixer
pcm.dmixer_PCH
{
type dmix
ipc_key 1026
ipc_perm 0666
hint
{
show off
description "Direct mixing of multiple audio streams (PCH)"
}
slave
{
pcm "hw:PCH,0"
rate 192000
channels 2
format S32_LE
period_size 7680
buffer_size 30720
}
}
# Perform dsnooper
pcm.dsnooper_PCH
{
type dsnoop
ipc_key 1027
ipc_perm 0666
hint
{
show off
description "Recording from the same device for several applications simultaneously (PCH)"
}
slave
{
pcm "hw:PCH,0"
rate 192000
format S32_LE
period_size 7680
buffer_size 30720
}
}
# Perform duplex
pcm.duplex_PCH
{
type asym
playback.pcm "dmixer_PCH"
capture.pcm "dsnooper_PCH"
hint
{
show off
description "Full duplex for simultaneous playback and recording (PCH)"
}
}
# Perform convert
pcm.convert_PCH
{
type rate
converter fftrate
hint
{
show off
description "Sample rate converter (PCH)"
}
slave
{
pcm "duplex_PCH"
rate 192000
format S32_LE
}
}
#=====================================================
# Configuration for default audio device
#-----------------------------------------------------
# Perform plug device
pcm.!default
{
type plug
slave.pcm "convert_PCH"
hint.description "Default device"
}$ 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 31Firefox has cubeb inside
libcubeb - Cross-platform Audio I/O Library
_https://github.com/mozilla/cubeb
All backends are still buggy, except for the backend for CoreAudio (macOS).
A standalone cubeb is easy to compile with CMake and ninja. You can debug ALSA backend.
Zoom app works with ALSA, provided that you have a fully functional software mixer.
But Discord should be used with apulse
apulse discordDebian 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 48000However, 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 16fftrate 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) * 1000000To perform exact resampling with low latency, fftrate needs proper settings
period_time 40000
periods 4First 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 44100If 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 48000delete 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 frameabout:support
Name Firefox
Version 140.5.0esr
Build ID 20251106203603
...
Media
Audio Backend alsa
Max Channels 10000
Preferred Sample Rate 192000Reference media files:
Best Audiophile Vocal 24 bit - Hi-Res Music 2025 - Audiophile Voices
_https://www.youtube.com/watch?v=uO6jfQ5tQHM
_https://youtu.be/uO6jfQ5tQHMBest 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.