[arch-general] too many brick walls for graphical accessible environment on archlinux
Without pulseaudio installed, I was able to choose festival for speech output and alsa for output device when running spd-conf inside speech-dispatcher on archlinux. This is necessary to have speech from orca in any graphical user interface. Since espeak-ng and espeak conflict I loose speech in the console installing espeak-ng since documentation and probably systemd service files for espeak-ng appear missing. So I install gnome which has orca in it. The pulseaudio package installs along with all of its core gnome dependencies and I try two things after that in order. First in console run spd-conf again and pick festival as speech device and pulseaudio as output device and spd-say is silenced. So I try spd-conf again and pick festival for speech device and alsa as output device. Again silence from spd-say. Next I run startx and get into gnome and try running orca. All of the sudden none of the voice files festival was provisioned with can be found anymore and orca dies with an error. The last thing I'm going to try with archlinux is a jenux install and go for the graphical environment on the install and see if that works. Slint actually uses espeak-ng and I have that running on another drive to keep me in the game when failures like this happen. All of this has been an interesting adventure. --
On Mon, 6 Jan 2020 02:45:53 -0500, Jude DaShiell wrote:
I install gnome which has orca in it. The pulseaudio package installs along with all of its core gnome dependencies
Hi, I don't know if this helps or might break Orca audio for GNOME. For completely other reasons I'm using an empty dummy package to fulfil the pulseaudio dependency of some apps. For my purpose it works without issues since years. You could edit a PKGBUILD like this and build it using makepkg: pkgname=pulseaudio pkgver=2020.01.06 pkgrel=1 pkgdesc="Dummy package" arch=('any') provides=('pulseaudio') One day or other there was a conflict related to pulseaudio-bluetooth, so I added an additional empty dummy package. pkgname=pulseaudio-bluetooth pkgver=2020.01.06 pkgrel=1 pkgdesc="Dummy package" arch=('any') provides=('pulseaudio-bluetooth') It might not be from any help to solve your problem, but you never know, so I want to mention it. pkgver = date of my pulseaudio dummy package is 2013.08.18 and pkgver = date of my pulseaudio-bluetooth is 2017.12.19. IOW it works for me since a very long time. However, I'm _not_ using GNOME, just plain openbox and I don't use Orca or anything like that. The PC is an audio workstation using single apps via ALSA or JACK2 with the ALSA backend, or multiple apps via JACK2 with the ALSA backend and no bluetooth audio at all. Regards, Ralf
PS: AFAIK nowadays it's possible to disable or enable pulseaudio on demand without issues. It was a PITA in the early days.
On 1/6/20 04:05, Ralf Mardorf via arch-general wrote:
On Mon, 6 Jan 2020 02:45:53 -0500, Jude DaShiell wrote:
I install gnome which has orca in it. The pulseaudio package installs along with all of its core gnome dependencies
Hi,
I don't know if this helps or might break Orca audio for GNOME. For completely other reasons I'm using an empty dummy package to fulfil the pulseaudio dependency of some apps. For my purpose it works without issues since years.
You could edit a PKGBUILD like this and build it using makepkg:
I suspect this would break configure/automake/etc. scripts that check for pulseaudio libs being installed and required via make flags in PKGBUILDS (and thus in depends/makedepends). probably fine if you don't plan on e.g. installing anything from the AUR, but probably not very good practice. i'd presume you're sitting on a timebomb, albeit minor, with pacman thinking pulseaudio libs are installed when they actually aren't. according to https://developer.gnome.org/platform-overview/unstable/tech-pulseaudio.html...., pulseaudio is absolutely required for GNOME's audio API. On 1/6/20 02:45, Jude DaShiell wrote:
Next I run startx and get into gnome and try running orca. All of the sudden none of the voice files festival was provisioned with can be found anymore and orca dies with an error.
this sounds pretty suspicious to me. simply starting GNOME (which should probably be done with GDM, by the way) oughtn't be touching festival's voice files (assuming you're referring to the system-wide ones). if you mean your ~/.festivalrc, though, that's a possibility. what does: pacman -Qs 'festival-.+' return? -- brent saner https://square-r00t.net/ GPG info: https://square-r00t.net/gpg-info
Hi Brent, it's unlikely a ticking time bomb for me, while building "pro-"audio related packages from AUR as well as my own packages. However, I agree that empty dummy packages might inherit risks. Since Jude run into an "averaged desktop audio" pulseaudio related issues, it indeed might be the better approach to disable pulseaudio for testing purpose, instead of removing it by an empty dummy package. Btw. it's no problem to stay with having the package libpulse installed, when using a dummy package for pulseaudio ;). My apologies for mentioning the ability to disable pulsaudio by a post scriptum. I didn't think about it, since it's irrelevant for my Linux audio usage. I _can_ rely on ALSA and Jack with the ALSA backend for my needs. Consider my mail as a hint for testing purpose and not as the ultimate solution for all use cases. Regards, Ralf
participants (3)
-
brent s.
-
Jude DaShiell
-
Ralf Mardorf