Sunday, December 11, 2016

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.

Sunday, December 4, 2016

[solved (suboptimal)] thunar udiskie fickleness - android, cgroups, lost weekend

Rambling hurried post here to be edited down later, but basically breadcrumbs from a basket of unhappiness attempting a USB download of a picture from my phone. Three of us guys took a picture at the football game on celly -- can we even look at the photo on a desktop?

setup

Normal. I have my regular user in the uucp group and libmtp installed per typical. I have EHCI and UHCI USB controllers that easily recognize and mount any USB drive. The phone is cleanly ID'd in lsusb.

solution (still suboptimal)

The only app that could interact with the phone was simple-mtpfs from the AUR (yaourt). The CLI is required to mount and unmount the phone, but GUI is no problem except for mounting/unmounting. Make a directory in ~ called mnt or something else easy to remember and verify that the device has been detected:
$ simple-mtpfs --list-devices #verify detected
$ simple-mtpfs ~/mnt #mount phone
$ fusermount -u ~/mnt #unmount phone
At the same time, one should blacklist auto-mounting from inside ~/.xinitrc. This stops problems with gvfs attempts to automount the phone, or anything else. Auto-mounting usually fails in a way which apparently conflicts with udiskie2.
$ nano .xinitrc
# stop gvfs auto-mounts
export GVFS_DISABLE_FUSE=1

problem

On every system I have but the newest (aka, "DRM"est) one, I connect via USB and thunar detects and displays it. On the new system, even with MTP and all related software installed, I get the following symptom upon USB connection: phone detected, but in installer mode, on the phone the taskbar shows "USB slow charge only", and in the phone main screen, a popup with "Media Transfer Protocol" and a spinning prompt asking me whether I'm on a Mac. This means three different descriptions for the same connection. Unbelievable. Once I click Mac or whatever, I lose the phone on my system, lose the phone screen, and see USB slow charge on the phone status bar. It's outrageously wrong that protocols are this kludged nowadays in the copyright universe (or whatever the ultimate underlying problem is, but typically copyrights/DRM) with proprietary, instead of standardized, file and mounting types. A simple file manager connection is matter of a weekend.

thunar: volman issues

Volman is just not seeing the phone as what it is: if I start thunar from a terminal and connect the phone to a USB, lsusb detects it right down to the model number, but thunar does not, spewing, eg:
thunar-volman: Unsupported USB device type.
thunar-volman: Unsupported USB device type.
thunar-volman: Unknown block device type.
thunar-volman: Could not detect the volume corresponding to the device.

Good discussion about volman with USB is here, including many fellow gvfs and gnome-disk-utility haters (though we can install no-gconf, which helps somewhat). Interestingly, this led to one person, I think on the second page noting they use rox, udiskie, and openbox (esp the openbox pipe menus), but openbox is still too heavy for me, and I don't like rox that much. However, the idea of pipes intrigued me -- if I could get pipes in icewm, I could still use thunar for everything else so: thunar, udiskie, icewm pipes. Found this icepipes discussion, which laid most of it out.

mtab: an old friend reveals another kludge

So was the phone being mounted at all? This led to yet another new issue: cgroups. I catted /etc/mtab, an old friend that simplifies viewing what's mounted (eg. where is my f*cking phone?), if mounted. This time, in addition to the 4 or 5 entries I expected, I was greeted with an additional 8 unknown mounted file systems from who knows where in my system and so eating who knows how many processor slices or memory blocks:
tmpfs /sys/fs/cgroup tmpfs ro,nosuid,nodev,noexec,mode=755 0 0
cgroup /sys/fs/cgroup/systemd cgroup rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/usr/lib/systemd/systemd-cgroups-agent,name=systemd 0 0
cgroup /sys/fs/cgroup/cpu,cpuacct cgroup rw,nosuid,nodev,noexec,relatime,cpu,cpuacct 0 0
cgroup /sys/fs/cgroup/blkio cgroup rw,nosuid,nodev,noexec,relatime,blkio 0 0
cgroup /sys/fs/cgroup/devices cgroup rw,nosuid,nodev,noexec,relatime,devices 0 0
cgroup /sys/fs/cgroup/freezer cgroup rw,nosuid,nodev,noexec,relatime,freezer 0 0
cgroup /sys/fs/cgroup/memory cgroup rw,nosuid,nodev,noexec,relatime,memory 0 0
cgroup /sys/fs/cgroup/net_cls cgroup rw,nosuid,nodev,noexec,relatime,net_cls 0 0
cgroup /sys/fs/cgroup/cpuset cgroup rw,nosuid,nodev,noexec,relatime,cpuset 0 0
cgroup /sys/fs/cgroup/pids cgroup rw,nosuid,nodev,noexec,relatime,pids 0 0
... as well as these 6 beauties...
debugfs /sys/kernel/debug debugfs rw,relatime 0 0
mqueue /dev/mqueue mqueue rw,relatime 0 0
hugetlbfs /dev/hugepages hugetlbfs rw,relatime 0 0
configfs /sys/kernel/config configfs rw,relatime 0 0
securityfs /sys/kernel/security securityfs rw,nosuid,nodev,noexec,relatime 0 0
tmpfs /dev/shm tmpfs rw,nosuid,nodev 0 0
... for a total of 14 new-to-me, unknown, mounted file systems, but I can't mount my f*cking phone without creating an fstab for that model? I guess the end-user is just becoming a nuisance. Anyway, a panicked df followed, and this thankfully only revealed 3 (still too many) of these new tmpfs entries. Why wasn't this on the evening news?