espeak (uses portaudio) won't speak with alsa-lib 1.2.5

[zqqw]

This looks to be possibly due to an issue with portaudio:
https://forum.artixlinux.org/index.php/topic,2733.0.html
https://bbs.archlinux.org/viewtopic.php?id=267124

$ espeak
hello
ALSA lib pcm.c:2660:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.rear
ALSA lib pcm.c:2660:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.center_lfe
ALSA lib pcm.c:2660:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.side
ALSA lib pcm_route.c:877:(find_matching_chmap) Found no matching channel map
ALSA lib pcm_route.c:877:(find_matching_chmap) Found no matching channel map
ALSA lib pcm_route.c:877:(find_matching_chmap) Found no matching channel map
ALSA lib pcm_route.c:877:(find_matching_chmap) Found no matching channel map
connect(2) call to /dev/shm/jack-1000/default/jack_0 failed (err=No such file or directory)
attempt to connect to server failed
Expression 'framesAvail' failed in 'src/hostapi/alsa/pa_linux_alsa.c', line: 3644
Expression 'PaAlsaStreamComponent_GetAvailableFrames( self, &framesAvail, xrun )' failed in 'src/hostapi/alsa/pa_linux_alsa.c', line: 4004
Expression 'PaAlsaStreamComponent_RegisterChannels( &self->playback, &self->bufferProcessor, &playbackFrames, &xrun )' failed in 'src/hostapi/alsa/pa_linux_alsa.c', line: 4133
Expression 'PaAlsaStream_SetUpBuffers( stream, &framesGot, &xrun )' failed in 'src/hostapi/alsa/pa_linux_alsa.c', line: 4374
hi
Expression 'framesAvail' failed in 'src/hostapi/alsa/pa_linux_alsa.c', line: 3644
Expression 'PaAlsaStreamComponent_GetAvailableFrames( self, &framesAvail, xrun )' failed in 'src/hostapi/alsa/pa_linux_alsa.c', line: 4004
Expression 'PaAlsaStreamComponent_RegisterChannels( &self->playback, &self->bufferProcessor, &playbackFrames, &xrun )' failed in 'src/hostapi/alsa/pa_linux_alsa.c', line: 4133
Expression 'PaAlsaStream_SetUpBuffers( stream, &framesGot, &xrun )' failed in 'src/hostapi/alsa/pa_linux_alsa.c', line: 4374

After downgrading alsa-lib & lib32-alsa-lib to 1.2.4* it works, no reboot required :

$ espeak
hello
ALSA lib pcm.c:2660:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.rear
ALSA lib pcm.c:2660:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.center_lfe
ALSA lib pcm.c:2660:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.side
ALSA lib pcm_route.c:877:(find_matching_chmap) Found no matching channel map
ALSA lib pcm_route.c:877:(find_matching_chmap) Found no matching channel map
ALSA lib pcm_route.c:877:(find_matching_chmap) Found no matching channel map
ALSA lib pcm_route.c:877:(find_matching_chmap) Found no matching channel map
connect(2) call to /dev/shm/jack-1000/default/jack_0 failed (err=No such file or directory)
attempt to connect to server failed
hi
hola

[zqqw]

Related issue in alsa-lib:
alsa-project/alsa-lib#155
alsa-lib-git and lib32-alsa-lib-git built just now didn't work either.

[zqqw]

Bisecting alsa-lib reveals this to be the initial breaking commit, building on the previous commit works, on this one it doesn't. The error messages are different on some subsequent builds compared to the current state so there may be another later commit that affects things too.
alsa-project/alsa-lib@5275d17

[philburk]

@zqqw - Thanks for investigating this. Do you know if ALSA 1.2.5.1 release fixes this problem?

Do you think this is purely a bug in ALSA or was it a legal change in ALSA that exposed a bug in PortAudio?

[RossBencina]

Searching the web for PaAlsaStreamComponent_GetAvailableFrames brings up quite a few discussions, for example:

arkq/bluez-alsa#243

https://forums.gentoo.org/viewtopic-t-1109266.html

[zqqw]

Building lib-alsa at the latest commit made yesterday does not work:

commit 81e7923fbfad45b2f353a4d6e3053af51f5f7d0b (HEAD -> master, origin/master, origin/HEAD)
Author: Jaroslav Kysela <perex@perex.cz>
Date:   Tue Jun 15 23:21:42 2021 +0200

Also reverting the commit that initially stops it working in the latest lib-alsa does not restore operation, so there are subsequent problems too. I have no idea at this point where the bug could be said to be located. But just looking at that commit mentioned above, I think it's reading alsa.conf in that file. get_char is a locally defined function and presumably something is going wrong with the file descriptor position or something.

[zqqw]

Bisecting again with the first faulty commit reverted reveals this as the next breaking point:
alsa-project/alsa-lib@28cc099
So far it's looking more like an alsa-lib bug.

[philburk]

Are the alsa-lib maintainers aware of this bug?

…

On Wed, Jun 16, 2021, 5:55 PM zqqw ***@***.***> wrote: Bisecting again with the first faulty commit reverted reveals this as the next breaking point: ***@***.*** <alsa-project/alsa-lib@28cc099> So far it's looking more like an alsa-lib bug. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#599 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABHPU2N6V5NCUJ2HAXVSCLDTTFBZ7ANCNFSM46UDALEQ> .

[zqqw]

Yes, hopefully they will look into it, and it's only a small amount of code changes causing the problem:
alsa-project/alsa-lib#155

[philburk]

Let's leave this Issue open until the ALSA bug is fixed. That will make it easier for folks to find this Issue.

[zqqw]

Apologies for not updating this more promptly. It has been fixed by this commit:
alsa-project/alsa-lib@dd609ef
For Arch & Arch based distros, building alsa-lib-git should include the fix:
https://aur.archlinux.org/packages/alsa-lib-git/
But it may take some time for that to be included in the next release as 1.2.5 only recently came out, unless it's backported as a minor revision, I'm not sure how alsa-lib do things.

[philburk]

Fixed in ALSA.