Arch Linux

Another build related issue:

If you want to use the pulseaudio backend (which you tried to do in the latest revision [1]), you have to add the switch in package() too, otherwise it's useless :-)

- make DESTDIR="$pkgdir" install
+ make AUDIO=pulseaudio DESTDIR="$pkgdir" install

Bonus: no more portaudio dependency

- cp portaudio19.h portaudio.h
-depends=('portaudio' 'libpulse')
+depends=('libpulse')

[1] https://git.archlinux.org/svntogit/community.git/commit/trunk?h=packages/espeak&id=21bf41f7c4b75e2ab87b74467878c0c219a0667d

Personally I would suggest keeping the audio backend set to runtime.
And yeah, this does need to be done in both the make and make install
lines. Anyway with AUDIO=pulseaudio, some blind people would lose their
console screenreader. Please no!
Losing the portaudio dependency might be nice for one group of people.
For another group of people, losing the (indirect) dependency on all
the libs pulled in by libpulse might be nice. But being a binary distro,
you have to make tradeoffs. And sometimes that means dependency bloat.

Just to make that clear: I personally don't really care, I just suggested to fix the inconsistency in the PKGBUILD.

But I am curious: What do you mean by "some blind people would lose their console screenreader"? Is portaudio required for that?

I'm asking because espeak development seems to have moved to espeak-ng [1], which uses pcaudiolib from the same dev for audio. On Linux, pcaudiolib will use either alsa or pulseaudio as backend (both are linked, so libpulse and alsa-lib will be hard dependencies).

[1] https://github.com/rhdunn/espeak

Well here's the problem.
Pulse does not make it easy for system services that are not tied to
a user (such as this screen reader) to play audio. AFAIK there's no
way to do it, unless you run pulse in system mode.
Honestly I'm a fan of system mode pulse, even though it's heavily
discouraged by pulse upstream. The arguments against it really do not
make sense on single-user systems like a laptop.
So anyway what it all comes down to is that the console screenreader
is a system service that does not play nicely with the
default / recommended configuration of pulse.
It's not a hard dependency on portaudio per se.

I see. I did a little digging on the espeakup + pulse + VT situation, e.g. [1], and I think I understand it better now. So what's the best solution in practice to have console screenreader working? Do you have to disable pulse completely so everything falls back to alsa? Run pulse in system mode? Sonehow disable/enable pulse when switching VTs? What approach do you use?


BTW on topic/@maint: Yeah, don't disable portaudio, but instead remove the already useless "AUDIO=pulseaudio" from the first make in the PKGBUILD


[1] http://eyesfreelinux.ninja/posts/speakup-espeakup-pulseaudio-problem.html

For a long time, my personal solution was just to avoid Pulse completely.
If something pulled it in as a dependency, I'd forcibly disable it.
Unfortunately the ostrich approach is less and less viable.
I'm having to catch up with the times. E.G., wanting to use bluetooth
audio for everything, and that's forcing my hand. I helped my girlfriend
with an Arch install this weekend, and we just put pulseaudio in system
mode. That's fine for us; there's just one physical user.
If there were multiple physical users (shared workstation or whatever),
the only recourse is probably to eschew console speech, at least right now.