i-rinat / apulse

PulseAudio emulation for ALSA
MIT License
609 stars 35 forks source link

Apulse doesn't work with discord with softvol plugin #83

Open Svalorzen opened 6 years ago

Svalorzen commented 6 years ago

Sorry for this question, I'm not 100% sure where to ask.

I'm using apulse and everything seems to work fine. A couple of days ago, however, I noticed that my headphones were not as loud as I wanted (not apulse related), so after looking around a bit I found in the ALSA wiki the following:

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

pcm.softvol {
    type softvol
    slave {
        pcm "dmix"
    }
    control {
        name "Pre-Amp"
        card 0
    }
    min_dB -5.0
    max_dB 20.0
    resolution 6
}

This adds a pre-amp control to alsa which regulates the volume. I added it to /etc/asound.conf. This works, but after doing this Discord stops working (if I remove it it starts working again). The error is

do_connect_pcm: can't open capture device "default". Error code -22 (Invalid argument)

What am I doing wrong? How can I add this plugin without breaking Discord's access to ALSA?

Alexander-- commented 6 years ago

@Svalorzen by registering default virtual soundcard, built from softvol<-dmix<-card0 you are effectively trying to both play and capture sound via dmix/softvol. It would have been surprising if that worked.

Try asym.

Svalorzen commented 6 years ago

@Alexander-- Could you possibly make an example? I'm afraid that I've never been able to 100% understand how the ALSA system works..

Alexander-- commented 6 years ago

@Svalorzen There is nothing non-intuitive about it — chain plugins together to get what you want. Many plugins are half-duplex, and have other limitations and requirements so you frequently need to insert them in specific places to build a working chain.

The config below used to work for me, but use your own judgement to tune it to your liking.

pcm.mixin {
    type dsnoop

    ipc_key 2048
    ipc_key_add_uid false
    ipc_perm 0660

    slave.pcm "rawcard"
}

pcm.mixout {
    type dmix

    ipc_key 1024
    ipc_key_add_uid false
    ipc_perm 0660

    slave.pcm "rawcard"
}

ctl.mixout {
    type hw
    card 0
}
ctl.!default {
    type hw
    card 0
}

pcm.!default {
    # The "plug" plugin is misleadingly named; it has nothing to do with being
    # a plugin.  What it should really be named is the "auto-re-sample" plugin.
    # It allows this device to be used at any sample rate.
    type plug

    slave.pcm {
        type asym

        playback.pcm "mixout"
        capture.pcm "mixin"
    }

    hint {
         show on
         description "Software-mixed input/output"
    }
}
Svalorzen commented 6 years ago

If I don't want to touch the microphone, could I just use

slave.pcm {
    type asym

    playback.pcm "softvol"
}

without specifying the capture? Or how to leave that part alone?

The problem is not whether it's intuitive or not, it's that the documentation for the conf format is sketchy at best, and as I'm not an audio guy I often don't really know what terms mean. I've tried multiple times to understand it, but I cannot find a through source (the alsa wiki is not it, which explains the format with sentences like "copy and paste the following into the file then save it."), and so I end up just trying to patch examples together from what I find around.

Alexander-- commented 6 years ago

@Svalorzen ALSA has virtually no "magic" inside, — if you don't specify capture, there might be no capture.

AFAIK, the only thing, that might be done by default, is automatically enabling dmix when there is no asound.conf (so people without asound.conf still get software-mixed sound from multiple apps). And they only added that because some projects (khem pulse…khem…audio) have taken advantage of lack of mixing by default to spread false claims, that ALSA needs separate mixing solution.

Default ALSA configuration delegates both playback and capture to hardware device (soundcard). Software devices ("plugins") can extend capability of hardware device, but also have their own limitations. There is a software device ("plug") that performs format conversions. Other software devices do not perform format conversions. There is a software device, that performs volume adjustment. Other software devices do not perform volume adjustment. There is a software device for mixing recorded sound…

Most software devices in ALSA distribution don't look at bigger picture. They won't do clever things like picking up a hardware sound as default slave or switching to another soundcard, when you disable the current one. You needs to write that down by hand in asound.conf.

The go-to excuse for non-existence of proper ALSA documentation is that Linux distributions are responsible for configuring it. Which is dumb, because

  1. "Distributions" don't care
  2. Everyone end up writing their own config, so using some kind of common tool or shared config is useless

so I end up just trying to patch examples together from what I find around

Well, that's something programmers commonly do. Most people are too afraid to become programmers, so you need to convince them, that what they do is not called "programming". I recall Richard Stallman once discussed how he convinced a secretary to write plugins for Emacs by explaining, that this is just configuring their text editor (and totally not "programming", lol).

i-rinat commented 6 years ago

I never had to use any hand-written .asoundrc file, default configuration always worked just fine for me. So I can't really help with the syntax of .asoundrc.

But I need to mention, that ALSA comes with a lot of configuration files. They should be in /usr/share/alsa. There is about 400 kB of files for various hardware. You can find some examples there.