alsa-project / alsa-lib

The Advanced Linux Sound Architecture (ALSA) - library
GNU Lesser General Public License v2.1
345 stars 176 forks source link

How to determine which files were read/parsed #345

Open bmariuszb opened 11 months ago

bmariuszb commented 11 months ago

I would like to know which files were read by alsa doing alsactl restore or alsactl init. So far I know that there is a folder /usr/share/alsa and it has init/00main, and this is probably read first, because when I deleted whole alsa dir I got error about this file, then I don't know what is read. Also there is a file /var/lib/alsa/asound.state which from my understanding contains values for different controls that are visible in alsamixer. There is also "user" config file in /etc/asound.conf and optionally any user can create ~/.asound.conf. Am I missing any other files? getting the list of files in order they are read for each card or all cards would be helpfull in debugging. For example by default I found out that my card HDA Intel PCH has two devices ALC1150 Analog and ALC1150 Digital. Digital is probably one of the six jacks in the back of my PC that are unplugged so I don't care about them right now. However Analog in my PC is connected to speakers and also from motherboard comes another cable to front jack panel that I plugged my headphones. I have a few problems with the default configuration:

  1. Headphone slider in alsamixer, known as control doesn't work.
  2. There are too many controls in Playback that are useless in my opinion.
  3. I haven't found yet how headphone and speakers jacks where merged into one Analog device. I wonder if it's a software merge or a hardware thing. I would like to combine card 2: NVidia [HDA NVidia], device 3: HDMI 0 [X2483_2481] with the merged card 1 device 0 (headphones and speakers) and I was wondering if it would be better to merge all 3 devices at once.

Correct me if I'm wrong, but from my understanding you have to connect different devices to be able to dynamically switch between them, because normally every process, e.g browser connects to a pcm device at startup and you can't change it later. So the actual audio switching is unmuting one thing and muting rest of them. All "things" are connected to one pcm, right?

Please correct me if I'm wrong or use wrong terminology. image

bmariuszb commented 11 months ago

Btw I was able to merge card 1 device 0 : speakers + headphones with card 2 device 3: monitor speakers, but the problem was that I still had to switch between card 1 and 2 in alsamixer to change audio. As of know my desired setup would be just one card with 3 sliders Headpohnes, Speakers(aka Front, but ironically it is in the back of my PC) and Monitor. Here is my setup, but it currently doesn't use combined pcm device.

# Create pcm device named monitor
pcm.monitor {
    type hw
    card 'NVidia'
    device 3
}

pcm.headphones {
    type hw
    card 'PCH'
    device 0
}

# Create pcm device named dmixed, it has type dmix and uses pcm.monitor. The purpose of it is the ability to play sound simultanously, e.g. from two terminals
pcm.monitor_dmixed {
    type dmix
    ipc_key 12345
    slave {
        pcm 'monitor'
    period_time 10000
        period_size 256
        buffer_size 4096
        rate 48000
    }
}

pcm.headphones_dmixed {
    type dmix
    ipc_key 12346
    slave {
        pcm 'headphones'
    period_time 10000
        period_size 256
        buffer_size 4096
        rate 48000
    }
}

# Create pcm device softvol, I'm not sure for what purpose, but it adds control named Monitor to alsamixer
pcm.monitor_softvol {
    type softvol
    slave.pcm 'monitor_dmixed'
    control {
        name 'Master'
    card 'NVidia'
    }
}
ctl.monitor_softvol {
    type            softvol
    slave {
        pcm         'monitor_dmixed'
    }
    control {
        name        'CTLMaster'
    card 'NVidia'
    }
}

pcm.capture {
    type dsnoop
    ipc_key 5678
    slave {
        pcm 'headphones'
        period_time 0
        period_size 1024
        buffer_size 8192
        rate 44100
    }
}

pcm.quad {
    type multi
    slaves.a.pcm 'headphones_dmixed'
    slaves.a.channels 2
    slaves.b.pcm 'monitor_softvol'
    slaves.b.channels 2

    bindings.0.slave a
    bindings.0.channel 0
    bindings.1.slave a
    bindings.1.channel 1
    bindings.2.slave b
    bindings.2.channel 0
    bindings.3.slave b
    bindings.3.channel 1
}

pcm.both {
    type plug
    slave {
        pcm 'quad'
        channels 4
    }
    ttable {
        0 {
            0 1.0
            2 1.0
        }
        1 {
            1 1.0
            3 1.0
        }
    }
}

pcm.!default {
    type asym
    playback.pcm 'headphones_dmixed'
    #playback.pcm 'monitor_softvol'
    #playback.pcm 'both'
    capture.pcm 'capture'
}

ctl.!default {
    type hw
    #card 'PCH' #headphones
    card 'NVidia' #monitor
}

It worked ok, but I've noticed some issues:

  1. On alsactl init the slider Master for card 2: monitor NVidia card did not show up until I played some audio and reopened alsamixer or it show up, but I wasn't able to change audio until I've played some audio through it and reopend alsamixer, either one of these two scenarios, I don't remember which one.
  2. On website diki.pl I got output only from one side. Strangely I've noticed it only on this website.
nodens commented 8 months ago

I think your main issue is you should use a sound server, such as pulseaudio or Pipewire, which is how sound devices are accessed by several applications on most modern Linux desktop environments.

This is usually how it is setup by default on most distributions I know of.

Regarding your initial question, this is most of the files involved, though again the paths might vary according to your distribution. UCM profiles might be involved, too. https://www.alsa-project.org/alsa-doc/alsa-lib/group__ucm__conf.html

That said, a sound server really is best in your case, instead of accessing alsa directly.