Arch Linux

oech3

Member

Registered: 2017-09-03

Posts: 76

[Solved]Discord,Chromium,ALSA dmix: Can't send voice

I used Discord on Chromium with settings like

#/etc/asound.conf
pcm.dmixer {
	type dmix
	ipc_key 2048
	slave {
		pcm "hw:PCH"
	}
}

pcm.!default {
 type hw
 card PCH
}

ctl.!default {
 type hw      
 card PCH
}

and

#~/chromium-flags.conf
-alsa-output-device=pcm.dmixer

WITHOUT packages related with pulse-native-provider.
The settings are valid for Zoom and Google meet.

But I could not send my voice via Discord. I don't want to set dmix as a default and don't want to install any sound server. Is it possible?

Last edited by oech3 (2025-04-23 16:56:58)

V1del

Forum Moderator

Registered: 2012-10-16

Posts: 24,960

Re: [Solved]Discord,Chromium,ALSA dmix: Can't send voice

This configuration does nothing about your mic support (dmix is strictly output, mixed input would require a dsnoop config). would hw:0,0 be correct there?

arecord -lL

That said, what's your reasoning for wanting to avoid pulse? Many applications are not really playing ball with ALSA's card/hw model without jumping through hoops and this is one thing pulse's API/device abstraction solves rather elegantly. If "more direct access" is your concern, then plain ALSA is generally actually "worse" at that. a dmix config opens the device at the same parameters all the time, regardless whether that would be a good fit for any given audio you are currently streaming. pulse/pipewire as an intermediate have the actual knowledge of what is currently using the card and can reconfigure themselves on the fly to properly accommodate the demands of whatever clients are active at any given time. If you just run a single client wanting low latencies you are going to get that, if you start to have multiple and the relevant buffers have to be reevaluated for everyone they can do that.

Side bar, a more minimal/better config that doesn't change defaults unnecessarily is to just set the "defaults" config nodes (as this config will also break hints which e.g. firefox requires to acknowledge the default) is

defaults.pcm.!device "PCH"
defaults.ctl.!device "PCH"

(this will also correctly redefine the default dsnoop/dmix card without jumping through hoops -- assuming "PCH" is correct there as well), because on rechecking your config actively breaks the correct dmix default, leaves a HW only access for applications that don't allow to override this, which you then workaround by explicitly redefining to your custom dmix for chromium, which is then not properly carried over to other tools.

Last edited by V1del (2025-04-22 17:49:11)

oech3

Member

Registered: 2017-09-03

Posts: 76

Re: [Solved]Discord,Chromium,ALSA dmix: Can't send voice

Thankyou.

mixed input would require a dsnoop

So Zoom and Google Meet does not mixing multiple input channel?

would hw:0,0 be correct there?

0,0 is avoided since ordering of device is stable.

reasoning for wanting to avoid pulse

I don't want to allow sounds by multiple apps for daily use.
Communicating with hardware directry is intentionally.
(+avoiding dependency hell by pipewire and reducing processes)

Is ideal setting for me

defaults.pcm.!device "PCH"
defaults.ctl.!device "PCH"

#spare for chromium
pcm.dmixer {
	type dmix
	ipc_key 2048
	slave {
		pcm "hw:PCH"
	}
}

pcm.dmixer {
	type dsnoop
	ipc_key 2049 #is conflicting OK?
	slave {
		pcm "hw:PCH"
	}
}

?

V1del

Forum Moderator

Registered: 2012-10-16

Posts: 24,960

Re: [Solved]Discord,Chromium,ALSA dmix: Can't send voice

Looks fine, the ipc key matters for mulltiple dmix plugins should be fine to be the same/matching for dsnoop instead.

If this isn't solved with this config, what does

arecord -lL

give you and do you maybe have an option in discord settings to select the correct input? (you're using the web version inside chromium, right?) Technically chromium also has an --alsa-input-device= flag as well.

OT, feel free to ignore: You're not going to notice anything of the dependency hell, pacman will take care of that. You're also not going to have that weak of a CPU that a single additional process designed to facilitate audio mixing is going to notably cause a visible impact in your resources. Technically dmix does the same (with likely a worse resampler implementation), you're just not "actively" seeing a process in the process list. If you're knowingly and intentionally doing direct HW access for general purpose use then you can of course do that as long as you're aware of the potential pitfalls.

oech3

Member

Registered: 2017-09-03

Posts: 76

Re: [Solved]Discord,Chromium,ALSA dmix: Can't send voice

Thankyou. Input in Discord on chromium worked by adding
-alsa-input-device=pcm.dsnooper (same name pcm.dmixer was avoided. I test same name later. same ipc_key seems OK.).

However,defaults.ctl.!device "PCH" breaks volume control for some machine (PCH should be replaced) and defaults.pcm.!device "PCH" breaks speaker-test -c 2.

So my asound.conf is asound.conf I first post +

pcm.dsnooper {
	type dsnoop
	ipc_key 2048
	slave {
		pcm "hw:PCH"
	}
}

discord settings to select the correct input

Discord suffests Default device only while Zoom allows to select pcm.ds* device manually without chromium flags. So I need -alsa-input-device.

a single additional process

Not single. piperwire, wireplumber, and pipewire-pulse. (I agree with my cpu is not weak).
Actually, I sometimes use them for desktop portal.
What I really hate is .socket services included in those packages needs to mask manually.
And masking them means running them manually via systemd is not allowed.

a worse resampler implementation

It seems HQ resampling is possible. But I'm not interested. I use mpv if quality is critical.

as you're aware of the potential pitfalls

I'm falling into a pit many times. But such people may reduced by adding to Arch wiki about this talk. I'l add about mixing input device later.

Last edited by oech3 (2025-04-23 13:08:42)

V1del

Forum Moderator

Registered: 2012-10-16

Posts: 24,960

Re: [Solved]Discord,Chromium,ALSA dmix: Can't send voice

Same name won't work, I was strictly referring to the ipc_key. But you might be able to hack something up with the asym ALSA plugin: https://www.alsa-project.org/alsa-doc/a … ugins_asym -- that said I haven't messed around much with that.

One final tidbit if you are on your original config, because as said some tools rely on a "default" PCM being properly present (if you run aplay -L you'll note that with your original config you won't see a default there) you should add

hint {
  show on
}

to your pcm.!default line. so e.g. :

pcm.!default {
 type hw
 card PCH
 hint {
   show on
   description "My default device"
 }
}

Last edited by V1del (2025-04-23 14:28:44)

oech3

Member

Registered: 2017-09-03

Posts: 76

Re: [Solved]Discord,Chromium,ALSA dmix: Can't send voice

Is show on without description OK? sysdefault exists in aplay -L without hint. default was added in the list of aplay -L.

Last edited by oech3 (2025-04-23 16:57:55)

V1del

Forum Moderator

Registered: 2012-10-16

Posts: 24,960

Re: [Solved]Discord,Chromium,ALSA dmix: Can't send voice

should be fine, it's just for a bit of extra fluff, the main thing of importance is that it shows up in PCM listings like aplay -L otherwise some tools might throw a fit.

oech3

Member

Registered: 2017-09-03

Posts: 76

Re: [Solved]Discord,Chromium,ALSA dmix: Can't send voice

Thankyou. I'l find apps requires default some day...

V1del

Forum Moderator

Registered: 2012-10-16

Posts: 24,960

Re: [Solved]Discord,Chromium,ALSA dmix: Can't send voice

The most prominent example that people are going to run into quite frequently is firefox.