audio -- DisplayPort

This a post for people who have a DisplayPort connection with functional video, but non-functioning audio from a connected monitor. The situation can be hardware or configuration, or a blend.

short overview

DisplayPort is HDMI quality video, a significant step-up from VGA, but without an audio channel. The output jack is a special shape, so we need an inexpensive adapter cable DisplayPort <--> HDMI. We then connect the HDMI end to any monitor's HDMI port.

DisplayPort does not have an audio channel. So we have to run sound separately using a 3.5mm output cable to connect sound to our monitor. However, even with a separate 3.5mm audio cable plugged in, users can experience the same "no audio" problems they do with an HDMI cable.

I've done other posts on HDMI cable ELD handshake for HDMI audio, and the steps are the same with DisplayPort. I'm repeating the steps here in a dedicated DisplayPort post, since it might be easier to Google search for those suffering through DisplayPort configuration.

---

helpful commands

Before anything else, a few helpful commands to hopefully avoid rebooting once configured. PulseAudio is killed and restarted with...

$ pulseaudio -k or --kill
$ pulseaudio -D

ALSA usually will reread alsa.conf and restart without a reboot:

# systemctl restart alsa-restore.service

most likely explanation - monitor limitation

Some monitors can't detect true HDMI apart from DisplayPort, since the cable connection is HDMI on the monitor end. The monitor assumes audio is incoming via the HDMI cable per usual. These types of monitors disable the 3.5mm audio input to prevent duplication. There's no way to achieve monitor sound in this circumstance. Users must test their computer's 3.5mm audio output with a set of speakers.

However, the scenario above is horribly underdocumented. Many people go crazy attempting to make the monitor produce sound from the connected 3.5mm input. Even more deceptively, these monitors usually have no 3.5mm audio problems as long as the video input is a VGA cable.

less likely -- ELD problems

Once we obtain ELD-related numbers, my easiest solution for ensuring ELD handshake is via /usr/share/alsa/alsa.conf customization. Updates to ALSA will overwrite our customization, but we can always repeat the steps if we encounter audio problems again.

I like info on how the computer is naming cards and so on, in case I have a long troubleshoot, but the most important step is using grep to verify ELD. Skip to that step below if desired.

Verify DisplayPort is connected to the HDMI port on the video monitor and receiving video. Next, how is the system ordering its analog PCH chip and HDMI digital chip? Simplest check:

$ cat /proc/asound/modules
0 snd_hda_intel
1 snd_hda_intel

... but in this case, we need more. We're only able to tell both chip 0 and 1 were manufactured by intel. So we...

$ cat /proc/asound/cards
0 [HDMI ]: HDA-Intel - HDA Intel HDMI
HDA Intel HDMI at 0xf7c32000 irq 39
1 [PCH ]: HDA-Intel - HDA Intel PCH
HDA Intel PCH at 0xf7c30000 irq 40

...ok the digital card is card 0 and the analog is card 1.

But we still don't which device on the card has handshaked. For that, aplay goes deeper and gives each device number on the cards.

$ aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: HDMI [HDA Intel HDMI], device 3: HDMI 0 [E622VLE]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: HDMI [HDA Intel HDMI], device 7: HDMI 1 [HDMI 1]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: HDMI [HDA Intel HDMI], device 8: HDMI 2 [HDMI 2]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 1: PCH [HDA Intel PCH], device 0: ALC3220 Analog [ALC3220 Analog]
Subdevices: 1/1
Subdevice #0: subdevice #0

But I prefer to verify ELD is handshaking with device 3.

$ grep eld_valid /proc/asound/card0/eld*
/proc/asound/card0/eld#0.0:eld_valid 0
/proc/asound/card0/eld#0.1:eld_valid 0
/proc/asound/card0/eld#0.2:eld_valid 0
/proc/asound/card0/eld#0.3:eld_valid 1
/proc/asound/card0/eld#0.4:eld_valid 0
/proc/asound/card0/eld#0.5:eld_valid 0

With hw 0,3 confirmed, I carve this in stone in my /usr/share/alsa/alsa.conf file.

# nano /usr/share/alsa/alsa.conf
defaults.pcm.subdevice 3 # -1 is default

step 2 - restart and test

The easiest for me is to reboot, but others may want to restart alsa. Am I getting sound? If so, then I should also be able to normally test the connection this way.

$ aplay -D plughw:0,3 /usr/share/sounds/alsa/Front_Center.wav

There are other sounds, I just use Front_Center out of habit I suppose

[Solved: 7 hours] reliable HDMI configuration under PulseAudio

NB: solution only takes 20 mins, but it took me an entire NFL Sunday to troubleshoot. All of this is only if the pavucontrol box cannot be expanded to include "Configuration" or nothing is there.

---

As we know, PulseAudio is one of the worst solutions to a non-problem¹ ever devised. It's so blatantly unhelpful that I suspect the two prior, more reliable and configurable, sound systems -- OSS and ALSA -- might have been sunk by DMCA (the usual supsect in crippled media reliability). Eg, are there any OSS drivers for newer hardware? Is there any documentation about inscrutable ALSA subroutine calls? We have little choice but to live with PulseAudio these days unless we're willing to fund a project to document ALSA or update OSS drivers.

two problems, two solutions

Problem 1: HDMI cable is disconnected, no sound in host

The HDMI cable is connnected and audio is coming from the monitor. But if I disconnect the HDMI cable, audio ceases entirely instead of switching/returning to the laptop speakers. So I lose audio entirely when I disconnect the HDMI cable.

I open pavucontrol. I see this...

1. no sound from monitor of course, b/c HDMI cable is disconnected
2. it appears there are menu options for "Port" but "HDMI/DisplayPort Unplugged" is the only option. The arrow produces no options to return sound to speakers.
3. re-attaching the HDMI cable only randomly results in a return to a picture and sound at the monitors

solution

Port options are available but are hidden. Click the arrow circled in red to reveal an additional column, "Configurations".

Within "Configuration" (below), we can select different options in the drop-down menu of "Profile" ("Port" above only gave a false appearance of options). When I selected "Analog Stereo Output", audio returned to my laptop speakers.

Problem 2: HDMI cable is reconnected, no sound in monitor

Typically, our speaker audio will also stop when we reconnect the HDMI cable, so that we're once again entirely without audio. But this was a more complex problem to solve.

What worked for me was to gather device info and insert it into /usr/share/alsa/alsa.conf to make it less generic. During reconnection, my default configuration seemed unable to distinguish the correct hardware. It might have been too vague.

I first examined the HDMI connection in light of two programs.

part A -- gather aplay and xrandr info

$ aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: PCH [HDA Intel PCH], device 0: ALC3235 Analog [ALC3235 Analog]
Subdevices: 0/1
Subdevice #0: subdevice #0
card 0: PCH [HDA Intel PCH], device 3: HDMI 0 [HDMI 0]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: PCH [HDA Intel PCH], device 7: HDMI 1 [HDMI 1]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: PCH [HDA Intel PCH], device 8: HDMI 2 [HDMI 2]
Subdevices: 1/1
Subdevice #0: subdevice #0

$ xrandr
eDP1 connected primary 1366x768+0+0 (normal left inverted right x axis y axis) 280mm x 160mm
DP1 disconnected (normal left inverted right x axis y axis)
HDMI1 connected (normal left inverted right x axis y axis)
HDMI2 disconnected (normal left inverted right x axis y axis)
VIRTUAL1 disconnected (normal left inverted right x axis y axis)

So we can see that HDMI1, which is hw 0,7 in this system, is the subdevice we want to configure.

part B -- modify /usr/share/alsa/alsa.conf

Use the HDMI1 information gathered above to add subdevice 7 (in this case) into the alsa control file.

# nano /usr/share/alsa/alsa.conf
defaults.ctl.card 0
defaults.pcm.card 0
defaults.pcm.device 0
defaults.pcm.subdevice 7

Now when we reboot our system, and connect and reconnect HDMI cables, we should see the option (as in "1" above) in pavucontrol, AND we should see that we have an ELD handshake.

$ grep eld_valid /proc/asound/card0/eld*
/proc/asound/card0/eld#2.0:eld_valid 1
/proc/asound/card0/eld#2.1:eld_valid 0
/proc/asound/card0/eld#2.2:eld_valid 0
/proc/asound/card0/eld#2.3:eld_valid 0
/proc/asound/card0/eld#2.4:eld_valid 0
/proc/asound/card0/eld#2.5:eld_valid 0
/proc/asound/card0/eld#2.6:eld_valid 0
/proc/asound/card0/eld#2.7:eld_valid 0
/proc/asound/card0/eld#2.8:eld_valid 0

additional notes

Never works

This is a good page, however none of these work:

$ pacmd "set-default-source alsa_output.pci-0000_04_01.0.analog-stereo.monitor"
$ pacmd "set-default-sink alsa_output.pci-0000_04_01.0.analog-stereo.monitor"

slight digression

In addition to our ears, we can verify a successful EDID handshake between our laptop and the monitor (via the HDMI cable). With the HDMI cable plugged in, we have a valid HDMI connection wherever we have a "1" inside /proc/sound/. When there's no sound, it will be all zeros, such as this example...

$ grep eld_valid /proc/asound/card0/eld*
/proc/asound/card0/eld#2.0:eld_valid 0
/proc/asound/card0/eld#2.1:eld_valid 0
/proc/asound/card0/eld#2.2:eld_valid 0
/proc/asound/card0/eld#2.3:eld_valid 0
/proc/asound/card0/eld#2.4:eld_valid 0
/proc/asound/card0/eld#2.5:eld_valid 0
/proc/asound/card0/eld#2.6:eld_valid 0
/proc/asound/card0/eld#2.7:eld_valid 0
/proc/asound/card0/eld#2.8:eld_valid 0

If the HDMI cable is connected and we see the above, then either the cable is bad, or the computer is failing to detect that there's a good HDMI cable connection.

Either way, we should have sound in our (eg laptop) speakers in such cases. So back to our main story.

Sometimes works

This sometimes works to add a way to toggle between analog speakers and digital HDMI, with both plugged-in. Sometimes.

# nano /etc/pulse/default.pa
### Load analog device - must be first
load-module module-alsa-sink device=hw:0,0
load-module module-combine-sink sink_name=combined
set-default-sink combined

a few helpful commands

$ pulseaudio --kill
# alsactl restart

---

¹ Both OSS and (subsequently) ALSA worked fine, but they needed more development as time progressed. Unfortunately, neither had enough DMCA protections to please the patent trolls. Enter PulseAudio, the *solution*, with the plausible patent deniability that it was designed to work "across platforms" LOL.

[solved] pulseaudio complete, minimal, and cripple installs

Even though "solved", it's really a failure, a failure to avoid PulseAudio After 2 week's work down the drain (see prior post) attempting to eliminate PulseAudio and, at this point, I have to get back to my life. I had a good plan but what ultimately defeated it is ALSA's latest complication of run-time language interactions with /usr/share/alsa/alsa.conf. For me to reverse engineer the many C++ attribute and function calls to the libalsa binary would take me a year to understand and document. They've finally made ALSA impossible. All that ever needed to happen in Linux audio was for OSS to be further developed 15 years ago, but that's probably a DRM casualty of some sort.

At any rate, I did manage to at least cripple PulseAudio so this is what I'll deal with first. With a couple of segues to failures even within the cripple process. Linux sound, man....

Cripple PA

In the simplest 3-step terms...

1. install libpulse normally

Alternatively, simply install one (eg. ffmpeg) of the now tens of programs that check for PulseAudio as a dependency! Lol, but we can see it is now a dependency if we try to *remove* PulseAudio...

2. symlink libpulse binaries to /dev/null

Other than for Google applications (eg, Chromium), PulseAudio is not technically a dependency. Rather applications verify PulseAudio's presence but do not need to use it. Accordingly, we can leave PulseAudio libraries in place, and symlink them to /dev/null. The libraries pass applications' tests for their presence, but do not interfere with our OS, since they are linked to nothing. So...

ln -sf /dev/null /usr/lib/libpulse.so
ln -sf /dev/null /usr/lib/libpulse-simple.so
ln -sf /dev/null /usr/lib/libpulse-mainloop-glib.so

...but leave these two alone...

/usr/lib/pulseaudio/libpulsedsp.so
/usr/lib/pulseaudio/libpulsecommon-15.0.so

These last are left as-is due to Chromium. During each start-up, Chromium checks for the size of at least one of these two libraries. Since /dev/null is "0" in size, Chromium will fail to start-up if, say common-15 is linked to /dev/null.

3. enjoy with one caveat

With this configuration, I've never had the pulse daemon auto-spawn, nor had my ALSA configurations overwritten (unless upgrading ALSA directly), nor had failures inside multi-media applications. This includes ffmpeg, OBS, vlc, Chromium, Ocenaudio, and the standard ALSA apps.

HOWEVER. At one point I broke/unlinked /dev/null from these three libs above to see what would happen. The delinking went smoothly, eg...

ln -sf /usr/lib/libpulse-sismple.so.0 /usr/lib/libpulse-simple.so

...yet the results were suboptimal. That's because /dev/null does not operate like other files, and it was deleted along with the symlink. Then, without /dev/null in the OS, I encountered random operational failures by applications which rely upon its presence.

So, in cases where I have to delete the symlinks, I:

1. reinstall libpulse. # pacman -S libpulse.
2. restart. during every startup, the kernel propagates /dev/null wherever needed in the system.

apulse - another failure

Apulse is on the AUR and looked promising. It emulated PulseAudio to placate applications which called PulseAudio, and even installs a small libpulse dummy which might do the same /dev/null moves I did above manually.

Although apulse installed fine and I was able to go back to ALSA I was still stuck with the problem that, eg, obs-studio could not detect my ALSA devices. For those without multi-media requirements such as those of obs-studio, apulse might be a solution.

jack? no

Not unless a dedicated machine for recording. Otherwise too many apps require PA. Two things learned when installing JACK however: stackex: change output card, and requires PAM modification, as I describe in this post.

complete PA install

Running as a user, pactl and pacmd are your friends, and the file ~/.config/pulse/client.conf. There's also more here, and also Arch's T-Shooting Guide. A typical issue are multiple cards detected in ALSA, but not by PA. You'll also want to clean out logs.

Is PA installed and running? Even though it's not technically a daemon (see below), it's usually running at starup from some unknown spawner. Check alsamixer and see if it's been superseded by PulseAudio's single volume bar.

After changes to any setup, we can restore ALSA with...

# systemctl restart alsa-restore.service

...and PulseAudio (for changes, kill it first, then restart it) with...

$ pulseaudio -k
$ pulseaudio -D

As noted here, PulseAudio is typically not a running service nor daemon from startup. Programs call it on a per-use basis. Some applications, eg Chromium, operate with a minimal /usr/bin/libpulse. Cleanest minimal install for pa_context_connect calls (basic libpulse install enough otherwise). I'm not sure, but to stream (eg. OBS), pulseaudio-rtp (only 200Kb) might be added.

# pacman -S pulseaudio-alsa

Packages (3) alsa-plugins-1:1.2.6-3 pulseaudio-15.0-4 pulseaudio-alsa-1:1.2.6-3

Total Download Size: 1.25 MiB
Total Installed Size: 6.19 MiB
Optional dependencies for alsa-plugins
dbus: for maemo plugin [installed]
jack: for pcm_jack plugin [installed]
libavtp: for pcm_aaf plugin [installed]
libsamplerate: for rate_samplerate plugin [installed]
libpulse: for conf_pulse, ctl_pulse and pcm_pulse plugins [installed]
speexdsp: for pcm_speex and rate_speexrate plugins [installed]
ffmpeg: for pcm_a52 plugin [installed]

pavucontrol

For ease of selecting devices (recording, streaming). It's big however, due to dependencies.

# pacman -S pavucontrol

Packages (7) atkmm-2.28.2-2 cairomm-1.14.3-2 glibmm-2.66.2-1 gtkmm3-3.24.5-2 libsigc++-2.10.8-1 pangomm-2.46.2-1 pavucontrol-1:5.0-1

Total Download Size: 2.95 MiB
Total Installed Size: 18.63 MiB

detection issue

configuration files

/etc/pulse/default.pa [detection issues]
/etc/pulse/client.conf [autospawn]
~/.config/pulse/client.conf

[FAIL] ALSA, JACK, 2 x cards, no pulseaudio

Basically, it doesn't matter what a post is originally about. If it includes any sound portion, it will end up being pages long attempting to deal with PulseAudio -- attempts to keep it out, to control or limit it, or to circumvent it. Unless you are a retiree with at least a full year's free time, install PulseAudio. The three biggest failures which lead to a full PulseAudio install:

1. pa_context_connect() calls from an application. These require a full PulseAudio install, not just libpulses.
2. ALSA developer's decision to add runtime calls (in C++?) into the libalsa binary. OK within itself, but falls apart when it accesses the configuration file /usr/share/alsa/alsa.config. The configuration used to be a plain text file. Now it has to include named variables to respond to libalsa's runtime calls. Documentation is poor and would require a year of full-time work by a user to reverse engineer.
3. multiple sound cards. If we still had a purely text ALSA config, without runtime calls, might be OK. But with runtime added, an inflexible default must be specified. This limits access to functionality from the other cards needed for eg, HDMI/ELD.

ALSA issues

Can we shrink our ALSA configuration to make it simpler to overlay JACK? Let's try some changes. To restart ALSA after changes....

# systemctl restart alsa-restore.service

1. capture (recording)

$ arecord -l
**** List of CAPTURE Hardware Devices ****
card 0: PCH [HDA Intel PCH], device 0: ALC892 Analog [ALC892 Analog]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: PCH [HDA Intel PCH], device 2: ALC892 Alt Analog [ALC892 Alt Analog]
Subdevices: 1/1
Subdevice #0: subdevice #0

*using alsa and jack over pulseaudio (10:42) Nomad Studio, 2016. About 8:00 describes using apulse on PulseAudio apps.

---

2. cards

$ cat /proc/asound/cards
0 [PCH ]: HDA-Intel - HDA Intel PCH
HDA Intel PCH at 0xf7f30000 irq 40
1 [HDMI ]: HDA-Intel - HDA ATI HDMI
HDA ATI HDMI at 0xf7e60000 irq 41

2. devices

Card 0 w/ 4 devices, Card 1 w/5 HDMI output devices...

$ ls -l /dev/snd
total 0
drwxr-xr-x 2 root root 80 Feb 15 17:46 by-path
crw-rw----+ 1 root audio 116, 14 Feb 15 17:46 controlC0
crw-rw----+ 1 root audio 116, 8 Feb 15 17:46 controlC1
crw-rw----+ 1 root audio 116, 13 Feb 15 17:46 hwC0D0
crw-rw----+ 1 root audio 116, 7 Feb 15 17:46 hwC1D0
crw-rw----+ 1 root audio 116, 10 Feb 15 17:46 pcmC0D0c
crw-rw----+ 1 root audio 116, 9 Feb 15 17:46 pcmC0D0p
crw-rw----+ 1 root audio 116, 11 Feb 15 17:46 pcmC0D1p
crw-rw----+ 1 root audio 116, 12 Feb 15 17:46 pcmC0D2c
crw-rw----+ 1 root audio 116, 6 Feb 15 17:46 pcmC1D10p
crw-rw----+ 1 root audio 116, 2 Feb 15 17:46 pcmC1D3p
crw-rw----+ 1 root audio 116, 3 Feb 15 18:23 pcmC1D7p
crw-rw----+ 1 root audio 116, 4 Feb 15 17:46 pcmC1D8p
crw-rw----+ 1 root audio 116, 5 Feb 16 03:40 pcmC1D9p
crw-rw----+ 1 root audio 116, 1 Feb 15 17:48 seq
crw-rw----+ 1 root audio 116, 33 Feb 15 17:46 timer

3. modules

$ lsmod |grep snd
snd_seq_dummy 16384 0
snd_seq 90112 1 snd_seq_dummy
snd_seq_device 16384 1 snd_seq
snd_hda_codec_realtek 163840 1
snd_hda_codec_generic 98304 1 snd_hda_codec_realtek
snd_hda_codec_hdmi 81920 1
ledtrig_audio 16384 1 snd_hda_codec_generic
snd_hda_intel 61440 0
snd_intel_dspcfg 32768 1 snd_hda_intel
snd_intel_sdw_acpi 20480 1 snd_intel_dspcfg
snd_hda_codec 180224 4 snd_hda_codec_generic,snd_hda_codec_hdmi,snd_hda_intel,snd_hda_codec_realtek
snd_hda_core 114688 5 snd_hda_codec_generic,snd_hda_codec_hdmi,snd_hda_intel,snd_hda_codec,snd_hda_codec_realtek
snd_hwdep 16384 1 snd_hda_codec
snd_pcm 163840 4 snd_hda_codec_hdmi,snd_hda_intel,snd_hda_codec,snd_hda_core
snd_timer 45056 2 snd_seq,snd_pcm
snd 126976 10 snd_hda_codec_generic,snd_seq,snd_seq_device,snd_hda_codec_hdmi,snd_hwdep,snd_hda_intel,snd_hda_codec,snd_hda_codec_realtek,snd_timer,snd_pcm
soundcore 16384 1 snd

default problems

Soundcard 0 has analog capture (mic) and playback (speaker, headpone) channels. Card 1 only plays back but it's a necessary card because has digital(HDMI) connection. So, I must capture through 0 and playback through 1. But how?

• HDMI playback only works when Card 1 is the default ALSA card
• Recording only works when Card 0 is the default ALSA card
• Unable to dynamically change default card(s) using amixer (cset cget)
• ALSA now includes run-time programming language in its config file (alsa.conf). Learning the ALSA library variables and commands necessary for config file (one year's work)
• OBS detects audio devices only via JACK or PulseAudio, not ALSA

HDMI playback verfied

$ aplay -D plughw:1,9 /usr/share/sounds/alsa/Front_Center.wav

5. current sound configuration

All configuration files deleted except /usr/share/alsa/alsa.conf. I have an "audio" group with myself as a member in /etc/group.

hardware and ELD HDMI detection

Changing ALSA configurations has no effect on items 1-3 above or the ELD/HDMI connection. ALSA is now installed with the kernel as systemd modules -- its functions are upstream of our user-level configuration. ELD handshakes automatically if the HDMI cable is connected and both items are powered-on. ELD verification is simple: find the device with the "1":

$ grep eld_valid /proc/asound/HDMI/eld*

complete alsa.conf

Only one configuration file is necessary to configure ALSA at the user level, /usr/share/alsa/alsa.conf; all other configuration files may be deleted. However a complete alsa.conf is roughly 600 lines and has eight sections; HOOKS, DEFAULTS, PCM, CONTROL, RAW MIDI, SEQUENCER, HW DEPENDENCE, and TIMER. Furthermore, in 2022 these include run-time function calls to the libs which have a somewhat elaborate syntax. I find the 2022 version a kludge.

smallest alsa.conf

What then is the smallest ALSA configuration? I've gotten ALSA working normally with only about 120 lines: a DEFALUTS, small PCM (below), and CONTROL interface sections.

#
# ALSA library configuration file
# permissions are 644

# PCM interface

pcm.capture1 {
type hw
card 0
device 0
}
pcm.capture2 {
type hw
card 0
device 2
}
pcm.hdmi8 {
type hw
card 1
device 8
}

With this I could, eg, record with explicit commands.

]$ arecord -D capture1 test.wav

However, since ALSA installs muted, this wasn't enough for me. I want alsamixer so I can easily unmute, set levels, select outputs. After a few days' work, in order not to deconstruct every run-time function for a customized version, I reluctantly settled on the original 600 line configuration file. For now.

alsa.conf sites

The alsa.conf is fun and time consuming to play with, and I might do it again. Documentation was sparse however. I gleaned from several sites.

• somewhat elaborate syntax repeat from above
• plugs and configuration a thorough treatment by a person who's been there. Lacks run-time functions and arguments. Notes plug can be a type and a hw.
• master ALSA Only works without JACK, so not an ultimate answer on an OBS system but very useful.
• Some interesting info
• this site has default configuration we can tweak.

Again, we want a JACK connectioin to Card 0, but not make it the system default. Alternatively, we might, if possible make Card 0 the default, but configure card 1 as an HDMI hook.

jack install overview

First you want the smallest possible ALSA configuration. Least elaborate and simple. A default card is required for JACK can be pared down and the problems are few, some due to PAM's typical interference. Capture is more complicated than playback, so we can test our permissions first on card 1. Once we get a basic configuration, we'll get card 1 going then tweak the more finnicky capture settings until card 0 is able to detect and input a mic.

jack install

I typically install jack2, alsa-plugins, jack-example-tools for multi-card, libffado (less error messages), and qjackctl for a GUI.

basic setup

1. verify there's an "audio" group and the user is in it. Jump to Step 2. Otherwise, create the group "audio" and add the user

   # groupadd audio
   # usermod -a -G audio user

2. modify PAM memory permissions to group "audio" in /etc/security/limits.conf, for real-time audio processing.

   # nano /etc/security/limits.conf
   @audio - rtprio 95
   @audio - memlock unlimited

   Verify: logout, log back in, and then...

   $ ulimit -r

   ...should see "95"
3. determine location of $ qjackctl called on command line.

   $ strace qjackctl

   You might have to save it to a file since so much crap will scroll.

   $ strace qjackctl 2>&1 | tee file.txt

   We only care about the first line in the tens of thousands of lines in the file.

   execve("/usr/bin/qjackctl", ["qjackctl"]....

4. give audio group permissions to qjackctl and jackd2 and make it group executable (750).

   # chgrp audio /usr/bin/qjackctl
   chmod 750 /usr/bin/qjackctl
   chgrp audio /usr/bin/jackd
   chmod 750 /usr/bin/jackd

first verification - playback only (card 1)

$ jackd -d alsa -d hw:1
jackdmp 1.9.20
Copyright 2001-2005 Paul Davis and others.
Copyright 2004-2016 Grame.
Copyright 2016-2021 Filipe Coelho.
jackdmp comes with ABSOLUTELY NO WARRANTY
This is free software, and you are welcome to redistribute it
under certain conditions; see the file COPYING for details
jack_get_descriptor : dll
jack_get_descriptor returns null for 'jack_internal_metro.so'
no message buffer overruns
no message buffer overruns
jack_get_descriptor : dll
jack_get_descriptor returns null for 'jack_inprocess.so'
jack_get_descriptor : dll
jack_get_descriptor returns null for 'jack_intime.so'
no message buffer overruns
JACK server starting in realtime mode with priority 10
self-connect-mode is "Don't restrict self connect requests"
audio_reservation_init
Acquire audio card Audio1
creating alsa driver ... hw:1|hw:1|1024|2|48000|0|0|nomon|swmeter|-|32bit
ALSA: Cannot open PCM device alsa_pcm for capture. Falling back to playback-only mode
configuring for 48000Hz, period = 1024 frames (21.3 ms), buffer = 2 periods
ALSA: final selected sample format for playback: 32bit integer little-endian
ALSA: use 2 periods for playback

So JACK starts for playback, albeit with some probable PulseAudio garbage errors. However, the error message, "Cannot open PCM device alsa_pcm for capture" will cause a fatal error when attempting to capture, using Card0 next paragraph. What is alsa_pcm and where do we configure alsa_pcm to open for capture? These are likley to be tweaks inside of /usr/share/alsa/alsa.conf. If so, not trivial.

initial capture attempt (card 0)

We need to capture microphone, which can only be done on Card 0.

$ jackd -d alsa -d hw:0
jackdmp 1.9.20
[snip]
Acquire audio card Audio0
creating alsa driver ... hw:0|hw:0|1024|2|48000|0|0|nomon|swmeter|-|32bit
ALSA: Cannot open PCM device alsa_pcm for playback. Falling back to capture-only mode
Released audio card Audio0
audio_reservation_finish
Cannot initialize driver
JackServer::Open failed with -1
Failed to open server

Fail. PCM device alsa_pcm has no playback -- no problem, we don't need playback with Card 0. However, we also receive a capture-only mode failure. Jackd exits. This is large problem: we need Card 0 for mic input capture. So two things are different, we're on Card 0 and we need capture.

alsa.conf

Card 1 was detected, possibly because Card 1 is the default card inside alsa.conf. We want to leave the default configuration on Card 1 (needed for HDMI output), but specify Card 0 for JACK detection, capture only. Here is the relevant Card 1 information for HDMI/ELD detection.

defaults.ctl.card 1
defaults.pcm.card 1
defaults.pcm.device 9
defaults.pcm.subdevice -1
defaults.pcm.nonblock 1

### start - custom for JACK pcm.jack1 { type hw card 0 device 0 } pcm.jack2 { type hw card 0 device 2 } ### end - custom for JACK

pcm.plug0 {
type plug
slave {pcm "jack" }
}
}
pcm.jack {
type jack
slave { pcm "jack" }
playback_ports {
0 alsa_pcm:playback_1
1 alsa_pcm:playback_2
}
capture_ports {
0 alsa_pcm:capture_1
1 alsa_pcm:capture_2
}

[unsolvable] disable passwords for Zoom Basic meetings (Arch, Android)

If one's about to install Zoom on any device, first open a browser and create an account at the Zoom website. Other than the "hands-free" note further down, I would limit myself to changing any Zoom settings only from this website account, rather from a device. If done from the website account, settings will waterfall into whichever downstream device(s) one uses with a Zoom client.

I like to disable the Zoom Personal ID ("PID") . The PID is similar to a personal phone number. I have never given mine out, and I disabled PID meetings via the web account (shown below). The effect on my phone is neither PID meetings nor the PID itself appear. De-clutter.

largest problems

The largest problems on Zoom are the hidden ones, probably obscured at the order of some marketing hack?

• no way to disable passwords for scheduled meetings in the basic account. If you'd like to meet with grandpa joe without a password to make it easier on him, be prepared to pay $15 per month; basic users have no ability to disable the password requirement. Send him the entire link with the embedded password, or devise a simple password scheme, say the letter "j", for all meetings.
• opaque appropriation of email domains. There's a screen warning, but I failed to get a screenshot of it before it disappeared. Say one has an email address at their employer, Acme:
  chump@acme.com
  Chump goes to the Zoom website, creates a basic account, and is Zooming to their job. Maybe he even pays $15 for extra features. But now Acme decides as a corporation to purchase an enterprise Zoom account. Without informing Acme or Chump, Zoom restricts control over any Zoom logins with emails ending in "acme.com". The next time Chump logs in for a Zoom work meeting, a pop-up warns Chump he cannot login and misleads him with a choice between accepting all the Acme settings or simply change his account email address. Chump updates with another email address. Unknown to Chump, or likely to Chump's boss, when Chump changed his email to keep his settings, his Zoom login lost acceptance into Acme-hosted Zooms. Through no fault of his own, Chump can't log-in, and he can't figure out why, since Zoom didn't provide that information (at this writing). This means Chump also lacks an explanation for his boss, who likely feels Chump is a liar, lazy or incompetent for the missed meeting(s). Chump madly rifles through the hundreds of his Zoom account settings, and still, all login attempts are rejected. The only solution is apparently for Chump to make a new account, as Cornell eventually learned.
• 

  Numerous, sometimes overlapping settings. COVID will long be over by the time we figure-out these combinatorics: 4 levels, 3 roles, and 40 or 50 settings. Some settings only apply to a certain level, others apply to all, and it's pretty much trial and error. The Four levels are, meeting, user, group, account. Now add the 3 roles, user, admin, owner. The entire 16 minutes of video in the link below only deals with the blue-selected "Settings" button in the menu seen to the left. Notice that there is an entire "Admin" menu area, and that this is expandable with many other menu setting areas available. All these settings may be necessary or beneficial to some users, but it's also time-consuming, complex, and therefore error-prone, for all

  Advanced Zoom settings - Basic and Pro (16:50) Lifelong Learning at VTS, 2020. Pedantic, side by side run-down of settings for Basic and Pro features.

• Features locked by default require identity verifcation to unlock. Verification is accomplished via a credit card or PayPal, including a home address. Now they have your zip code

Android - phone

Go to the Google Play Store, and download and install Zoom. Zoom has step-by-step instructions for getting started, but there's nothing weird except one thing: disable the hands free option in settings or it's a serious nagware problem every time the app is opened.

When opening the application a "sign-in" and "sign up" prompt appear. "Signing up" is the one-time event I recommend doing at the Zoom website. The website has far more settings than on the phone app. I ignore the "sign-up" prompt no matter the device b/c I already accomplished it on the website. "Signing-in" I do each time I use the application.

If one has already created a web account, one can simply "sign-in" to the current device and have all the settings which one configured at the website. Create the account at the website, install the app, sign-in to the app.

creating and joining meetings

I create all meetings on the Zoom website. I do not create meetings through the phone application, I just attend or host them through it. If one intends to use Zoom, it's helpful to try a practice meeting with a friend before going live to a conference and so forth.

Arch - desktop

No one wants to install this 256Mb lead weight because it brings in PulseAudio, which is effectively a virus. Some apps, eg, recordmydesktop), will fail to be able to directly access the soundcard. If you need to screen-capture during a Zoom a person can either turn on recording for the Zoom itself, or use ffmmpeg

THere are the (7.45Mb)dependencies noted during the (AUR) Zoom installation, via...

$ yay zoom

... (of course, remove with # pacman -Rns zoom)

• alsa-plugins
• pulseaudio
• pulseaudio-alsa
• rtkit
• web-rtc-audio-processing

ffmpeg :: screen and sound capture

One should know their screensize, eg 1366x768, and cut off the bottom 30pixels or however many consistitute a toolbar. This allows switching between windows via the toolbar offscreen. Syntax: These three flags should come first and in this order

-video_size 1366x738 -f x11grab -i :0

...else you'll probably get only a small left corner picture or errors. Then come all your typical bitrate and framerate commands

$ ffmpeg -video_size 1366x738 -f x11grab -i :0 -r 30 output.mp4

I've never been able to set a bitrate in a screencast without fatal errors (eg, b:v 1M) b:a 192k. And then to add the sound...well you're stuck with PulseAudio if you installed Zoom, so just add -f pulse -ac 2 -i default...

$ ffmpeg -video_size 1366x738 -f x11grab -i :0 -r 30 -f pulse -ac 2 -i default output.mp4

There are also ways to get it to record a specific app only, using the name of the window, not covered here.

video card replacement - hdmi

Although it looks imposing and is potentially a solid choice, I became tired (2019) of the 2Gb nVidia GeForce GTX770 (GK104 Audio Controller onboard) that came with my system.

Maybe it's an nVidia thing, but it had the nasty habit of ramping-up sound instead of turning audio on immediately. This meant that, after any silence, sound always returned smoothly, however it made video editing impossible. Sound needs to match video precisely and, since we're not going to play back video on only this nVidia system, we need to know volumes exactly, not with system-specific audio ramping.

nVidia vs Radeon

According to the proprietary utility nvidia-settings (in the nVidia driver), my motherboard has a PCIe Gen3(16bit) slot. I'm not a gamer, but for Blender's sake, I doubled GPU RAM with a 4Gb Polaris based AMD Radeon RX560D.

Again, however, the main factor is having audio that works correctly. There was simply nothing I could do to stop the nVidia card audio ramping. All automuting, all of that was disabled, but the nVidia sound always ramped instead of immediate.

Remove nVidia software

Once replaced, i uninstalled the nVidia module in favor of amdgpu module.It's just sitting there and not being used so it doesn't really hurt anything, but it's a 200Mb of orphaned stuff. I ran # pacman -Ss nvidia to see what I had installed and removed all of them...

# pacman -Rdd libvdpau libxnvctrl nvidia nvidia-utils

audio

When I had the nVidia card, I was never able to pass the dreaded same-named sound card issue...

$ cat /proc/asound/modules
0 snd_hda_intel
1 snd_hda_intel

...which would sometimes provide sound and sometimes static.

libva v libvdpau

I still don't understand if I'm supposed to have both the Intel and the nVidia video hardware acceleration. I knew that va was intel and vdpau nVidia, so which/what to use on with the amdgpu and a Radeon. At some point, because Chromium appeared to favor vdpau, I installed vdpau, and did so by installing its utility, vdpauinfo...

# pacman -S vdpauinfo

... which also brought in libvdpau. Following this, Chromium opened normally, and YouTube functioned.

xorg

With the nVidia software removed and the amdgpu package installed, X refused to initialize. The error and the solution discussion are here. The solution required a change to /etc/mkinitcpio.conf...

MODULES=(amdgpu)

... and then

# mkinitcpio -p linux

After this, X loaded normally.

sound and systemd, restart sound

Running HDMI means dealing with two audio chips -- the first on the motherboard and a second on the video card, where the A/V HDMI cable is connected. Many things can therefore derail the sound. In this case it was an Arch update, causing some conflict with the kernel. But each failure has to be solved by a process of elimination. ALSA is embedded into the kernel, so that systemd is the way to restart.

# systemctl restart alsa.restore.service

Should d

Let's suppose the connected HDMI device at the other end of the cable is putting out clean video. Now let's suppose the audio is also present, but that it sounds distorted: chipmunky or maybe raspy or fuzzy, like a bad AM radio connection. We know that at least one of the audio chips IS working if sound is present at the output. But solving the distortion many not be easy. Perhaps the wrong sound chip, both chips simultaneously, or that the correct chip has incorrect settings. You've done everything here and the gold standard...

$ aplay -D plughw:1,7 /usr/share/sounds/alsa/Front_Center.wav

...for your particular hardware, which you correctly determined with...

$ aplay -l

Suppose this is in spite of Pulseaudio being effectively disabled , /usr/share/alsa/alsa.conf successfully sterilized of hooks, and /etc/asound.conf, ~/.asoundrc, and ~/.config/asound.conf having been successfully deleted.

Suppose also that we have...

$ systemctl list-unit-files |grep alsa
alsa-restore.service static
alsa-state.service static

$ systemctl list-units |grep sound
sys-devices-pci0000:00-0000:00:01.0-0000:01:00.1-sound-card1.device loaded active plugged GK104 HDMI Audio Controller
sys-devices-pci0000:00-0000:00:1b.0-sound-card0.device loaded active plugged 7 Series/C216 Chipset Family High Definition Audio Controller
sound.target loaded active active Sound Card

... well then WTF is going on? We can see ALSA is properly "static" and therefore compiled into the kernel. We can see that both hardwares examine some of those systemd service modules inside /etc/systemd/system/, but this does not seem to be the problem.

possibility 1

Suppose you still have an unaddressed situation of both sound cards receiving the same name from the kernel

$ cat /proc/asound/modules
0 snd_hda_intel
1 snd_hda_intel

Disable speaker w/headphone Intel NM10/ICH7 Audio

The Intel Corporation NM10/ICH7 Family High Definition Audio Controller (rev 0) is a common audio chip in many laptops, but it has a Linux limitation. The ALSA mixer (alsamixer) has no setting for disabling the speakers when the headphones are inserted. A cacophony of dual headphone and speaker sounds, playing 1 second apart, is the result. Further, because it's the sound system, not the error notification system (beeps, etc), the customary disabling of pcspkr will not stop double sounds. Once configured, we'll want to reload it by creating a /etc/rc.local to do alsactl restore. This can be verified by running chkconfig alsa-utils.

1. disable pulseaudio

Worthless pulseaudio has been addressed many times in my blogs. Check this link, or some other you prefer, for how to disable it.

2. alsactl

# alsactl store

Running this command generates the file /var/lib/alsa/asound.state. Unlike the 5 visible controls in alsamixer, the true 23 settings of the card are revealed inside asound.state. It's the file to make adjustments which silence speakers during headphone use.

[solved] more hdmi sound hijinx

Whichever card is running the HDMI must be set as the default inside alsa, no matter whether or not there are secondary issues with pulseaudio. Your order of business when finding that, say, YouTube videos no longer have sound, or VLC is without audio, are

• ye olde verify audio is unmuted in alsamixer (while you're in alsamixer, why not check your card for annoying "automute", and disable it. Select it and use the "+" or "-" keys to toggle it)
• check sound with a specific command to the hardware card. If this doesn't work, go into a subroutine of verifying HDMI. For example, this MUST work, if this is the named card and HDMI channel

  $ aplay -D plughw:1,7 /usr/share/sounds/alsa/Front_Center.wav

• assuming the above works, then the wrong default card is likely being assigned, so that YouTube is, say, attempting to play through [default] motherboard audio, instead of an HDMI authorized sound card. This means, particularly after an software update, doing the thing you've done for years now...

  # nano /usr/share/alsa/alsa.conf
  @hooks [
  {
  func load
  files [
  {
  @func concat
  strings [
  { @func datadir }
  "/alsa.conf.d/"
  ]
  }
  ]
  errors false
  }
  ]

  ... and then further down in the file change the defaults...
  

  # nano /usr/share/alsa/alsa.conf
  defaults.ctl.card 1 #default 0
  defaults.pcm.card 1 #default 0
  defaults.pcm.device 7 #default 0
  

Text-to-speech, multiple card

Overview: Single sound card setup isn't always easy, but this post has more than enough info for single card text-to-speech. As for multiple cards in ALSA, things can become complicated. My prior espeak post on multiple cards is beneficial if all the answers aren't here. Also a great multiple card site for the /usr/share/alsa/alsa.conf file. The deepest problem with two cards and HDMI is that, the cards can be re-ordered for default and less ALSA errors, but then HDMI errors may occur from conflicts of this re-ordering. What does the user want, HDMI errors, or ALSA errors? I prefer ALSA errors, given how difficult HDMI is to re-configure. I mostly take the easy way out and simply comment the lines inside /usr/share/alsa/alsa.conf.

---

I used this hack, and subbed espeak for festival, since I typically use espeak. Espeak works fine, but there are several potential problems once one gets to the point of xbindkeys. Not mentioned in these tutorials is that both ~/.xbindkeysrc AND ~/.xbindkeysrc.scm may be required for consistent operation.

1. Verify espeak, eg...

   $ espeak "this is a test"

   This site has loads of options for the line.
   
2. Install xsel. Xsel takes any selected text (stdout) and pipes it to any subsequent process we want, in this case, espeak.
3. Select some text and then:

   $ xsel | espeak -s 100
   

   ... and whatever other espeak modifiers you want.
4. Make a script from the two actions.

   $ nano talk.sh
   #!/bin/bash
   xsel | espeak -s 110
   eof

5. Chmod talk.sh to activate it.

   $ chmod +x talk.sh

6. Test it. Select/highlight some webpage or document text and then, in a terminal,

   $ ./talk.sh

   This speaks the selected text as many times as it's executed, that is, it's not a "one off" of the selected text.
   
7. Here is where it becomes difficult: binding the script to a hotkey, eg, with xbindkeys. We first need to detect the numbers associated with pressing keyboard keys.

   # pacman -S xbindkeys
   $ xbindkeys -k

   xbindkeys -k allows a person to detect the numeric codes needed inside the ~/.xbindkeysrc file. One difficulty was the super-key, aka "windows" key. Eventually, I gave-up on this key and opted for the CTRL key in combination with the letter "k". I was then able to get numbers which worked within the configuration ~/.xbindkeysrc file (see below).
   
8. Tie talk.sh to the key combo by creating an ~/.xbindkeysrc file.

   $ nano .xbindkeysrc
   "./talk.sh"
   m:0x4 + c:45

9. Now start xbindkeys

   $ xbindkeys

10. When I tried CTRL + k the selected text was spoken only once; the text had to be selected with the mouse each time I wanted it to speak. Somehow the text was being "lost" between usage.
11. I troubleshot using

    $ xbindkeys -n -v

    which runs it in the foreground and provides info. Here, I received a message that there was no ~/.xbindkeysrc.scm. Accordingly, I next ran xbindkeys_config, the GUI front-end (obtained via yaourt xbindkeys_config-gtk2). Through the GUI, I reran the configuration, which tweaked the ~/.xbindkeysrc file. After that, I had consistent repetitive behavior from the hotkey combination.
12. (Optional) I could have continued to call the script with the hotkey combination but, since the script was only one line, I didn't truly need a script in this case. I deleted the script. Within .xbindkeysrc, I replaced the script call with the script's contents, "xsel | espeak -s 100".
13. Once consistent, I added xbindkeys to my windows-manager startup file.

    $ nano .icewm/startup
    xbindkeys &

14. Exit and restart X, (or do, $ killall xbindkeys and $ xbindkeys) to be certain xbindkeys initializes using the ~/.xbindkeysrc configuration.
15. Testing any of the configurations above is always the same: select text with the mouse, b) hit your key combination (eg., CTRL + k), and verify it repetitively audibles the text.

other

If there are audible delays for a word or two and you get errors like these...

$ xsel | espeak -s 100
ALSA lib pcm_dsnoop.c:638:(snd_pcm_dsnoop_open) unable to open slave
ALSA lib confmisc.c:1281:(snd_func_refer) Unable to find definition 'cards.HDA-Intel.pcm.front.7:CARD=1'
ALSA lib conf.c:4554:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory
ALSA lib conf.c:5033:(snd_config_expand) Evaluate error: No such file or directory
ALSA lib pcm.c:2501:(snd_pcm_open_noupdate) Unknown PCM front
ALSA lib pcm.c:2501:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.rear
ALSA lib pcm.c:2501:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.center_lfe
ALSA lib pcm.c:2501:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.side

...then your speech datastream is probably moving along as ALSA attempts unsuccessfully to connect to JACK and so on. I have never been able to stop these JACK calls -- they seem embedded in the binary lib files, I've searched with grep throughout the ALSA file kludge. There's also speculation SPDIF sleep modes can do this. I think in my case it's a multiple card issue since I never have the delay on single soundcard issues. Secondly, HDMI validation with the display monitor also handshakes with the sound card and must have the same device numbers named in ALSA, as by UDEV. Think of the HDMI process as one which cascades from the ALSA setup, but has a dotted line to the kernel through the ELD verification. ALSA can rule it: scroll down to the ELD verification process in this prior post.

more about audible delays
Whatever delays from the speaker, the most important delays are to WAV files. We should be able to write...

$ espeak -s 100 "cut back" -w cutback.wav

...without delays. If we have ALSA speaker delays however, we typically have them writing to files also.

Add an extra word. I find the word "delay" takes the right amount of time to initialize SPDIF or perhaps multiple card JACK issues, so that...

$ espeak -s 100 "delay cut back" -w cutback.wav

...will create the file with only "cut back" spoken.
I renamed the unresponsibe ALSA libs for PulseAudio -- I don't ever use PulseAudio anyway...

# cd /usr/lib/alsa-lib/
# mv libasound_module_ctl_pulse.so zz_libasound_module_ctl_pulse.so
# mv libasoud_module_pcm_pulse.so zz_libasound_module_pcm_pulse.so

...this caused error of them not found, but better than not responding.

espeak - alsa and hdmi environment

Overview: Speech synthesis has become nearly trivial, but a typical ALSA setup relies on sound card definitions from the config files ~/.asoundrc or /usr/share/alsa/alsa.conf (I typically delete the former and modify the latter). A complex hardware situation will almost always require some modifications to the config file. Installing espeak into such an environment often requires yet further config file modifications. I often wish OSS were still developed. Note: espeak uses the PortAudio library, specifically relying upon libportaudio. Verify installation in Arch with $ pacman -Ss portaudio.

symptom

Attempted espeak statements provide pcm error messages and no audio. Environment: Two sound "cards" -- one Intel MB chip, one NVidia graphics card sound chip. NVidia card selected b/c HDMI cable. ALSA HDMI configuration working flawlessly with all input and output apps (except espeak). ALSA espeak errors:

$ espeak "hello world"
ALSA lib pcm_dsnoop.c:618:(snd_pcm_dsnoop_open) unable to open slave
ALSA lib confmisc.c:1281:(snd_func_refer) Unable to find definition 'cards.HDA-Intel.pcm.front.7:CARD=1'
ALSA lib conf.c:4371:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory
ALSA lib conf.c:4850:(snd_config_expand) Evaluate error: No such file or directory
ALSA lib pcm.c:2450:(snd_pcm_open_noupdate) Unknown PCM front
ALSA lib pcm.c:2450:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.rear
ALSA lib pcm.c:2450:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.center_lfe
ALSA lib pcm.c:2450:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.side
ALSA lib confmisc.c:1281:(snd_func_refer) Unable to find definition 'cards.HDA-Intel.pcm.surround51.7:CARD=1'
ALSA lib conf.c:4371:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory
ALSA lib conf.c:4850:(snd_config_expand) Evaluate error: No such file or directory
ALSA lib pcm.c:2450:(snd_pcm_open_noupdate) Unknown PCM surround21
ALSA lib confmisc.c:1281:(snd_func_refer) Unable to find definition 'cards.HDA-Intel.pcm.surround71.7:CARD=1'
ALSA lib conf.c:4371:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory
ALSA lib conf.c:4850:(snd_config_expand) Evaluate error: No such file or directory
ALSA lib pcm.c:2450:(snd_pcm_open_noupdate) Unknown PCM surround71
ALSA lib confmisc.c:1281:(snd_func_refer) Unable to find definition 'cards.HDA-Intel.pcm.iec958.7:CARD=1,AES0=4,AES1=130,AES2=0,AES3=2'
ALSA lib confmisc.c:1281:(snd_func_refer) Unable to find definition 'cards.HDA-Intel.pcm.modem.7:CARD=1'
ALSA lib conf.c:4371:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory
ALSA lib conf.c:4850:(snd_config_expand) Evaluate error: No such file or directory
ALSA lib pcm.c:2450:(snd_pcm_open_noupdate) Unknown PCM phoneline
ALSA lib pcm_dsnoop.c:618:(snd_pcm_dsnoop_open) unable to open slave
connect(2) call to /dev/shm/jack-1000/default/jack_0 failed (err=No such file or directory)
attempt to connect to server failed

At least two issues jump out: espeak sound is (inexplicably) attempted through the Intel card instead of the NVidia card, so that's probably why all the other subassemblies are also unreachable and spawning errors. "Dsnoop" may also be an issue.

To solve the first problem, we can easily change the values inside /usr/share/alsa/alsa.conf further than my previous post on ALSA HDMI agreement. That is, per this post, comment the line for pcm.front, and each additional line of fail as follows:

# nano /usr/share/alsa/alsa.conf
# pcm.front cards.pcm.front
pcm.front cards.pcm.default

This reroutes dynamic loading on a per command basis to the default card, eliminating the error. But this means lines and lines of corrections. Note that it appears all of these are due to HDA-Intel (instead of NVidia), being called as during dynamic loading. Let's see if we can just rewrite one line to fix the called card to NVidia, instead of doing line-by-line edits on downstream results from calling the HDA-Intel.

First let's try to specify the hardware device, as we can do in:

$ aplay -D plughw:1,7 /usr/share/sounds/alsa/Front_Center.wav

We know ALSA is thus working. So we can do a two-step method using ALSA to be sure espeak is working:

$ espeak "Hello world" --stdout |aplay -D plughw:1,7

If nothing comes out of this, or if there is no content inside a WAV produced with

$ espeak "Hello world" -w somefile.wav

... then it's time to strace.

[Solved] Arch ALSA configuration (HDMI, nVidia PCIe card) minus PulseAudio

$ xrandr [get displays]
$ xrandr --output HDMI1 --mode "1280x800"
$ xrandr --output HDMI1 --off

I currently maintain an unlucky system with respect to HDMI audio: two sound chips -- nVidia PCIe video card(w sound chip), and an Intel sound chip on the motherboard. One must choose between connecting the HDMI cable at the motherboard and having low-res motherboard chip video, or connecting the HDMI cable to the nVidia board. Of course, we connect the HDMI cable to the nVidia board for better video, but this then led (in my case) to conflicting motherboard and video card audio functions. This post is the result.

---

The system OS is Arch w/Nouveau drivers (minus proprietary nVidia modules), and without PulseAudio. Eventually, I removed the Nouveau drivers and reluctantly installed the proprietary nVidia drivers: the Nouveau drivers could not seem to manage the audio on the nVidia card.

Avoiding PulseAudio was successful -- the steps for that begin below. The steps are entirely accomplished inside Runlevel 2/3 or a terminal, but I included one optional Xorg step at the bottom of the post.

HDMI complexity

HDMI sound requires at least four reconciled systems -- Xorg, ALSA, kernel modules and, of course EDID -- and some of these have subfiles. That's too many variables for consistently easy sound configuration, and sound is already one of the more challenging aspects of Linux. One bit of Arch-specific luck is ALSA modules are nowadays compiled into the Arch kernel.

First steps

• ALSA kernel modules present?
  

  $ systemctl list-unit-files |grep alsa
  alsa-restore.service static
  alsa-state.service static

  "Static", because compiled into the kernel. If not present, fundamental ALSA must be installed and the dynamic loading of its modules verified.
• after the above, pacman all additional ALSA stuff in the repo, avoiding ALSA-PulseAudio libs (and other applications which automatically install PulseAudio) and, if feasible, also avoiding ALSA-OSS libs. Generally, the less non-ALSA audio libs the better.
• verify (in an already-working system) one has a good HDMI cable and then connect it between the the nVidia card and one's desired monitor/TV. Once we connect to nVidia video, we're obviously committed to nVidia's sound chip (since HDMI cable carries both audio and video).
• reboot
• $ lsmod |grep soundcore :: soundcore must be present.

module load order --> default audio card

In a multi-card/chip sound system, the order the kernel loads the modules for the cards determines the default audio card. Specific to my system is an additional complexity: both the motherboard and nVidia audio chips load the same module, snd_hda_intel. This prevented me from determining which chip was the default sound chip with a simple module check...

$ cat /proc/asound/modules
0 snd_hda_intel
1 snd_hda_intel

Which card is the default "0", the motherboard chip or the nVidia card chip? Use ALSA's "aplay" to distinguish:

$ aplay -L |grep :CARD
default:CARD=PCH
sysdefault:CARD=PCH
front:CARD=PCH,DEV=0
surround21:CARD=PCH,DEV=0
surround40:CARD=PCH,DEV=0
surround41:CARD=PCH,DEV=0
surround50:CARD=PCH,DEV=0
surround51:CARD=PCH,DEV=0
surround71:CARD=PCH,DEV=0
iec958:CARD=PCH,DEV=0
hdmi:CARD=NVidia,DEV=0
hdmi:CARD=NVidia,DEV=1
hdmi:CARD=NVidia,DEV=2
hdmi:CARD=NVidia,DEV=3

ALSA has loaded the motherboard chip "PCH" as the audio default, which is not the NVidia audio we need (for HDMI audio). And a 3rd issue is apparent: a device designation of "0" is being used for both sound card/chips. These numbers are supposed to be unique for each card, but two cards are using the same number, "0". This may be related to the dual use of snd_hda_intel. Regardless of how it happened, dual-use of a (supposedly) card-specific number across two pieces of hardware is likely to lead to conflicts. If desired, one could detour and verify IRQ issues with say,lscpi -v, or get more information about the module, eg....

$ modinfo -p snd_hda_intel

...and do conflict tests. In my case, I made note of the overlap and pressed on.

So far: No sound yet, since default audio is going to PCH, not to nVidia. However there is progress: we know ALSA assigned unique names for the two audio chips -- "PCH" and "NVidia". We know both audio chips rely on module snd_hda_intel, that the PCH chip is loading as the default, that the nVidia chip has four available devices (0,1,2,3), and that a good HDMI cable has been connected between the nVidia HDMI port and my monitor. How to control the load order (default)?

Some users control load order problems by creating an /etc/moprobe.d/[somename].conf file, then setting options inside the file, or using creative blacklisting. This didn't work for me: both audio cards relied on the same module, snd_hda_intel so that blocking this module would block both cards (chips).

I tried however. I created the file...

# nano /etc/modprobe.d/customsettings.conf

...and attempted various "option" and "install" lines within it. Option and install lines have helped other users (see appendix at bottom), but none of them solved my problem. In the end, my only use for the custom file was to blacklist Nouveau modules, in case I had not removed all of them properly, after I had settled on nVidia drivers

# nano /etc/modprobe.d/customsettings.conf
blacklist nouveau

If kernel manipulation fails, we can turn to making modifications within ALSA. For ALSA customization,four ALSA files are possible:

• /etc/modprobe.d/(somename).conf :: kernel manipulation, as just noted above.
• /etc/asound.conf in Arch, the file does not exist by default, but can be created by apps (like PulseAudio) or by the user.
• ~/asound.rc home directory version of asound/conf, if one does not desire global settings.
• /usr/share/alsa/alsa.conf a default file, installed with ALSA. To narrow troubleshooting variables, I do any ALSA customization only in this default /usr/share/alsa/alsa.conf file. The first modification is to prevent the other two files above from being sourced. Some users simply delete /etc/asound.conf and ~/.asoundrc entirely or rename them to backup files. We need ELD information before we can modify this file entirely however.

ELD verfication

ELD information is critical to complete HDMI modifications inside /usr/share/alsa/alsa.conf. Be sure the HDMI cable is connected to the NVidia HDMI output and to the monitor to which you're connecting.

$ grep eld_valid /proc/asound/NVidia/eld*
/proc/asound/NVidia/eld#0.0:eld_valid 0
/proc/asound/NVidia/eld#0.1:eld_valid 1
/proc/asound/NVidia/eld#0.2:eld_valid 0
/proc/asound/NVidia/eld#0.3:eld_valid 0

Here, only nVidia audio card (chip) 1 is validated for HDMI audio. However, these "card" numbers 0,1,2,3, are not the actual hardware numbers. We need hardware numbers for ALSA.

$ aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: PCH [HDA Intel PCH], device 0: ALC892 Analog [ALC892 Analog]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: PCH [HDA Intel PCH], device 1: ALC892 Digital [ALC892 Digital]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 1: NVidia [HDA NVidia], device 3: HDMI 0 [HDMI 0]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 1: NVidia [HDA NVidia], device 7: HDMI 1 [HDMI 1]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 1: NVidia [HDA NVidia], device 8: HDMI 2 [HDMI 2]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 1: NVidia [HDA NVidia], device 9: HDMI 3 [HDMI 3]
Subdevices: 1/1
Subdevice #0: subdevice #0

So, for HDMI 1, the ELD validated sound card/chip with my monitor, the hardware number will be hw:1,7. Now I can return to /usr/share/alsa/alsa.conf and make the necessary HDMI modifications.

# nano /usr/share/alsa/alsa.conf
defaults.ctl.card 1 #default 0
defaults.pcm.card 1 #default 0
defaults.pcm.device 7 #default 0

This means I've swapped the cards' default order from "0" to "1", and specified the ELD-authorized device by its hardware number, "7". Reboot, and unmute card PDIF 1 in alsamixer.
For non-NVidia cards, the process is similar...

$ grep eld_valid /proc/asound/HDMI/eld*
/proc/asound/HDMI/eld#0.0:eld_valid 0
/proc/asound/HDMI/eld#0.1:eld_valid 0
/proc/asound/HDMI/eld#0.2:eld_valid 0
/proc/asound/HDMI/eld#0.3:eld_valid 1
/proc/asound/HDMI/eld#0.4:eld_valid 0

... and then determine which setting is associated with ELD 3, using "$ aplay -l" again, and then making the change inside /usr/share/alsa/alsa.conf.

Next steps

1. reboot
2. power on the tv/monitor and verify volume is hearable level
3. $ alsamixer :: unmute "S/PDIF 1" on the NVidia card. F6 switches between cards.
4. $ aplay -D plughw:1,7 /usr/share/sounds/alsa/Front_Center.wav
   Should hear "Center" from TV's speakers. Aplay won't do MP3's to my knowledge -- use this ALSA player with a WAV.
5. enjoy. I must manually unmute S/PDIF 1 each reboot, or modify some other file, but that's another day/process.

troubleshooting - post alsa update

Following any system update that changes ALSA, (eg, following pacman -Syu) sound may be lost. First, open alsamixer to verify it wasn't re-muted. Secondly, the update may have overwritten /usr/share/alsa/alsa.conf. Re-enter the modifications (scroll down) and device settings in alsa.conf, resave, and log out and back in, or reboot.

troubleshooting- vlc issues

1.) deleting ~.config/vlc as a fix. When sound comes OK from ALSA ($ aplay -D plughw:1,7 /usr/share/sounds/alsa/Front_Center.wav, as above), but VLC is soundless, try deleting~/.config/vlc, and let VLC respawn the file.

2.) no sound from media files with MP3 or AAC tracks. Movies and MP3's play with audio in other software, but no sound from VLC, if it's MP3 or AAC. The fail will appear to be ALSA, eg, if you attempt to VLC the MP3 file from the command line, you'll see errors including...

alsa audio output error: cannot set buffer duration: Invalid argument

... yet MP3's play fine with other players. Without PulseAudio, they are getting their input from ALSA, so we know it's not ALSA, it's VLC. The fix for me has been the SPDIF function, which sends audio directly to the device, without decoding, which it can't always handle. Make sure it's unchecked as seen below.

Incidentally, beneath the quality of lossless (flac and wav), apparently the compression quality proceeds: Opus better than AAC, with AAC better than MP3.

Nouveau

One of the sound cards is an nVidia graphics card.

$ nvidia-xconfig --no-use-edid-dpi $ nano /etc/X11/xorg.conf Option "DPI" "100 x 100"

appendix 1
possible /etc/moprobe.d/[somename].conf settings

At the kernel level, I was unable to do more than blacklist nouveau drivers. I could have instead blacklisted nvidia drivers, had I ever been able to activate sound within nouveau. However, many were able to solve their configuration settings in this file using such options as

install sound-slot-0 modprobe snd-card-1
install sound-slot-1 modprobe snd-card-0

or...

options snd-hda-intel enable=1,0

Note that, in this second example, the underscores in the module name are changed to hyphens.

appendix 2

If a person has old 32-bit Windows programs and wants to run Wine, what are the concerns? You'll first have to uncomment the two multilib lines in /etc/pacman.conf to access 32-bit libs. Wine itself then becomes roughly a 600MB kludge install due to all the attached 32-bit libs.

Most importantly here, one of the 32 bit choices affects the nVidia card. During Wine install, users must select either the lib32-mesa-libgl or lib32-nvidia-gl. I have th nVidia card in my system, so it seems like the safe choice. What about compatibility though? So many things use Mesa.

[solved] more on Arch sound (fix for chipmunk sound)

No reasonable person likes PulseAudio currently. It's also a mystery why it was ever developed instead of, say, simply enhancing OSS (so we would only have one sound daemon). But, since OSS and ALSA were left behind, it goes without saying that, over time, a Linux distribution is near-certain to become infected with PulseAudio -- it will automatically be installed as a dependency by one application or another. Eventually, PulseAudio is almost certain to interfere with something, for example to make Audacious play MP3's at a chipmunk's pitch. As I write in early 2015, the strategy that works for me is,

• cripple and minimize Pulse-Audio -- some programs require its presence, so minimize it to whatever minimal hooks applications require.
• configure ALSA as application-friendly as possible
• install alsa-oss so apps seeking the older OSS daemon do not fail

crippling Pulse-Audio without removal

You can try a straight-up # pacman -Rs pulseaudio, but dependencies tend not to allow this. So cripple it.
Note: the PulseAudio daemon respawns if not properly neutered.

• obviously start with $ pulseaudio --kill
• directory /usr/share/alsa/alsa.conf.d hides a PulseAudio file (50-pulseaudio.conf) which ALSA executes during ALSA startup. This file surreptitiously activates /bin/pulseaudio. Rename it so it's no longer executed, eg "cp 50-pulseaudio.conf 50-pulseaudio_conf.bak", OR change /bin/pulseaudio to /bin/true in the file.
• stop PulseAudio autospawning by gutting /etc/pulse/client.conf and replacing its lines with

  # custom version
  autospawn = no
  # "/bin/true" doesn't do anything, but no errors
  daemon-binary = /bin/true

• Check inside /etc/X11/xinit/xinitrc.d to be sure X11 isn't infected. Eliminate any PulseAudio files in that directory.
• $ systemctl list-units |grep pulse to verify no systemctl pulseaudio targets are present

/usr/share/alsa/alsa.conf vs. /etc/asound.conf

These initializing files use the same commands and formats, as well as one other config file, ~/.asoundrc. Since all 3 files are ALSA initializing files, only one is necessary, delete the other two to avoid interference. I typically keep /usr/share/alsa/alsa.conf because it's the most complete out-of-the-box, and because so many applications (eg. Audacious) load it. Save a copy of the working version for future installs. Not sure how to activate the file under systemd, so I just logout and log-in to be sure the file is read. Next, the alsa.conf configuration.

/usr/share/alsa/alsa.conf ("USAA" here)

USAA has a few problems itself.

• backup the default USAA, eg # cp /usr/share/alsa/alsa.conf /usr/share/alsa/alsa_conf.bak. Backup any other files that are modified as well.
• USAA's first subroutine is to load /etc/alsa.conf and /home/foo/.asoundrc. These can have PulseAudio hooks that wrongly set playback frequency. Carefully delete this subroutine, from

  [
  {
  func load
  files [
  {
  @func concat
  strings [
  { @func datadir }
  "/alsa.conf.d/"
  ]
  }
  "/etc/asound.conf"
  "~/.asoundrc"
  ]
  errors false
  }
  ]

  ...to....

  @hooks [
  {
  func load
  files [
  {
  @func concat
  strings [
  { @func datadir }
  "/alsa.conf.d/"
  ]
  }
  ]
  errors false
  }
  ]

  and save.
• backup and then eliminate any of these which exist
  1. /etc/asound.conf
  2. ~/.asoundrc
  3. ~/.config/asound.conf

NB: There is *one* situation where I occasionally want ~/.asoundrc, albeit customized. If I have an external USB mic and some application won't simply accept its direct information, eg "plughw:1,0", I can turn it into a second soundcard that's providing content. Of course, there is no playback via the mic. Audacity, for example, likes this arrangement.

verify

Logout, log back in, and then try an Audacious or command line play, etc... $ aplay somefile.mp3

PulseAudio reconsidered - hail OSS, ALSA

Links: arch wiki pulseaudio :: record system in pulseaudio (GUI) ::
record system in pulseaudio (CLI) :: ALSA configuration :: best disable link so far (3/2014)

---

Linux sound management and the changing nature of Linux initialization schemes are the bad things about Linux. In this post, it's about sound. PulseAudio, on the scene since perhaps 2009, but currently (2014) prevalent, has made the sound kludge even worse¹.

OSS - still good

My Linux use began when OSS was the only sound daemon communicating with hardware. OSS had bugs, but it was straightforward, and therefore was a good foundation which should have been developed further instead of dumped.

I'm not a recording engineer, but I never encountered the two main purported limitation of OSS, 1) an inability to process simultaneous sound sources (, eg. capture a mic input at the same time as a music stream) nor 2) a supposed incapacity to split a single sound source into multiple types of files simultaneously.

When I wanted to listen to several files through the speakers and to, simultaneously, capture the output (stdout) into a single WAV file, I piped them through sox. For example, in this case, I created a script which played several audio files in sequence, and I used sox to collate the output into a single file:

$ somescript.sh | sox -t ossdsp -w -s -r 44100 -c 2 /dev/dsp foobarout.wav

That's all there was to it.

ALSA - meh

When ALSA became common, the the simple approach of /dev/dsp was gone. In ALSA, we had to locate soundcard info with aplay-l, aplay -L, /proc/asound/pcm AND /dev/sound/. Some software couldn't handle the ALSA layer, and we'd have to name the device. Only now it wasn't generically, /dev/dsp. So we'd have to research its PCI values and provide literal device information such as "hw:0,0". Another problem was lost hours configuring daemons. As users, we'd sort of have to choose between OSS or ALSA and be certain we'd blackballed the modules of the other. It's unclear what benefit ALSA provided, in other words.

Consider the play/capture scenario I described above. Under ALSA, a similar effect should have been available by researching ALSA commands. That's already wasted time (duplication of effort) to achieve the same outcome, but it also turns-out the the ALSA commands were not as reliable. For example...

$ somescript.sh | arecord -D hw:0,0 -f cd foobarout.wav

... often would result in a string of error messages regarding "playback only", even though capturing had been enabled in ALSA, etc. To me, it seemed that ALSA, and not OSS, had multiplexing limitations.

Further, the C code of the ALSA "dmix" lib, which one would think was created exactly to solve this problem gives no respite...

ALSA lib pcm_dmix.c:961:(snd_pcm_dmix_open) The dmix plugin supports only playback stream

Lol. In the end, the only helpful plugin (of course with nearly zero documentation and an unintuitive name), is the asym plugin. For this you'd have to become aware of it in the first place, not so easy, nor will you escape having to build and tweak an /etc/asound.conf and/or an .asound.rc. Have fun.

PulseAudio

Instead of simply developing either ALSA or OSS more completely, some group developed PulseAudio. PulseAudio purported to make muxing easier than ALSA which purported to make muxing easier than OSS. "Lol". Lol because ALSA and/or OSS continue to be layers underneath PulseAudio. So now we add PulseAudio memory and CPU loads to those of both the OSS or ALSA modules running beneath PulseAudio. These three different directions at once also raise the potential for errors. And if you think PulseAudio makes configuration any easier, take a look here.

After PulseAudio configuration, recording my script requires the same steps as capturing streaming. It's too much information to regurgitate entirely here, but the shorthand is:

$ pavucontrol (set "Record Stream from" to "Monitor of Internal Audio Analog Stereo")
$ somescript.sh | parec --format=s16le --device=(from "pactl list") | oggenc --raw --quiet -o dump.ogg -

There is also hypothetically an OSS emulator called "padsp" (install ossp in Arch) with which one could use sox again. That is, PulseAudio apparently uses an emulator instead of just accessing a real OSS module. I haven't tried "padsp", but it may work.

$ padsp sox -r 44100 -t ossdsp /dev/dsp foobarout.wav

PulseAudio crippleware effect

Once PussAudio has ever been installed, even inadvertently as a dependency for some other application, and even when you're sure its daemon is not running (), one's soundcard will likely be reduced to analog mode. Eg, after Puss Audio was installed, but its daemon not running, I observe...

$ aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: SB [HDA ATI SB], device 0: ALC268 Analog [ALC268 Analog]
Subdevices: 1/1
Subdevice #0: subdevice #0

...when I should instead see...

$ aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: SB [HDA ATI SB], device 0: ALC268 Analog [ALC268 Analog]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: SB [HDA ATI SB], device 1: ALC268 Digital [ALC268 Digital]
Subdevices: 1/1
Subdevice #0: subdevice #0

Results will be similar in $ arecord -l. There's no way to capture one's system in ALSA properly again until it detects the entire soundcard. If we'd like, we can even see the problem more clearly:

$ aplay -L
null
Discard all samples (playback) or generate zero samples (capture)
default
Default ALSA Output (currently PulseAudio Sound Server)
sysdefault:CARD=SB
HDA ATI SB, ALC268 Analog
Default Audio Device
front:CARD=SB,DEV=0
HDA ATI SB, ALC268 Analog
Front speakers
[remaining 4 entries, all analog dev=0, snipped]

That is, even with PussAudio disabled, ALSA remains infected with the PulseAudio Sound Server, and analog limitations.

PulseAudio disabling

Link: excellent disabling instructions
We'd like to disable PulseAudio, but we'd prefer not to uninstall PulseAudio --- for example, it's understood that some Gnome sound functions with hooks in PulseAudio libs may not otherwise work. We know from above that it's not enough to simply disable its daemon.

file	note
/etc/pulse/	dir: pulse audio config files
/etc/modprobe.d/alsa-base	configuration for ALSA modules
/usr/share/alsa/	dir: alsa config files
/etc/asound.conf	alsa config file for pulse
/usr/share/alsa/default.pa	change ALSA hooks
/etc/pulse/default.pa	change PulseAudio hooks

1. $ pulseaudio -k
2. # pacman -r pulseaudio-alsa
3. # rename /usr/share/alsa/alsa.conf.d/*.conf /usr/share/alsa/alsa.conf.d/*.bak
...to be continued.

---

¹ Some configurations even include a Music Player Daemon ("MPD"), and/or a Simple Direct MediaLayer ("SDL"), ridiculous 4th and 5th possible layers.