I can't answer for Janina but that's a matter of preference, I assume. speechd-up allows to use all voices managed by speech-dispatcher, but maybe there are some limitations when using speechd-up vs speakup? This is a genuine question, being sighted I can't judge. As an aside in the current Slint version both are available and switching between them is easy <smile> Best, Didier On 24/03/2019 18:49, John Covici wrote: > This may be a dumb question, but why use espeakup at all, but run > speakup through speech dispatcher instead using speechd-up? > > On Sun, 24 Mar 2019 08:07:57 -0400, > Didier Spaier wrote: >> >> Hi Janina, >> >> alsa.conf is not attached, please send it, as well as the full >> output of: >> aplay -L >> >> For a complete diagnose, please also do this: >> 1. Get the script alsa-info.sh: >> wget --no-check-certificate -nv http://www.alsa-project.org/alsa-info.sh >> 2. Run it: >> sh alsa-info.sh --no-upload --output alsareport >> 3. Send the file alsareport (maybe only to me, it will be huge). >> >> Anyway, my assumption from the information you already gave is that >> the sound modules for your cards are no loaded in the same order by >> udev at every boot, hence the changes in card numbering. This can >> probably be solved writing relevant commands in /etc/modprobe.d/alsa.conf. >> >> Best, >> >> Didier >> >> >> On 24/03/2019 10:25, Janina Sajka wrote: >>> Good Morning, Didier: >>> >>> I'm attaching my /etc/modprobe.d/alsa.conf which works, except that I >>> seem to have some kind of error in the vendor or product ID for the >>> Steinberg UR22mkII, which is why it's commented out for now. This config >>> actually does reliably load each of my audio devices usefully, most of >>> the time anyway. >>> >>> * Espeakup is started by a systemctl enabled on boot >>> >>> * Speech-Dispatcher is started by hand with a startx after I'm >>> * confident hw:0 is correctly assigned. Sometimes on boot, it's >>> * missed entirely and the above devices are scrambled. That >>> * requires a reboot to get them correctly ordered. >>> >>> I have the Sennheiser headset set as alsa device in /etc/asound.conf for >>> the benefit of linphonec, which has started working again, though it seg >>> faults if I try to answer an incoming call. >>> >>> The HDSP device has had driver issues off and on in the past few years. >>> It's a 20-year old high end audio device. I have the first generation >>> RME Multiface card. The Steinberg UR22mkII is arguably its peer, though >>> it doesn't provide the same array of inputs and outputs, most regretably >>> no s/pdif. >>> >>> In any case, just to review, the problem of the moment is that doing the >>> startx to get the graphical desktop up with Orca sometimes kills all of >>> espeakup, and a restart puts espeakup on hw:2--making hw:2 unavailable >>> for linphonec which I use for teleconferences. >>> >>> So, sometimes the system can boot without discovering its builtin, >>> onboard Intel HDA hardware. That's annoying because I seem unable to fix >>> it without a reboot. >>> >>> And most recently, about half the time, startx is killing espeakup and a >>> restart of espeakup goes to the wrong card. >>> >>> Sounds to me like espeakup needs to expose more capabilities--like Slink >>> does! <grin> >>> >>> Didier, I want to thank you for providing the pulse to alsa translation, >>> i.e. pulse's sink equals alsa's pcm. It's a little tricky to intuit such >>> things sometimes. >>> >>> Best, >>> >>> Janina >>> >>> Didier Spaier writes: >>>> Hi again, Janina, >>>> >>>> Yes it's Sunday now form <smile> >>>> >>>> Maybe if you provide the output of aplay -L >>>> and what sink (in PulesAudio parlance) or PCM device >>>> (in Alsa parlance) you want to dedicate to a specific >>>> usage we could try to help you get there. >>>> >>>> Time to sleep now for me, see you tomorrow (Paris time). >>>> >>>> Best, >>>> >>>> Didier >>>> >>>> On 23/03/2019 23:49, Janina Sajka wrote: >>>>> Hi Again, Didier: >>>>> >>>>> Speaking of late Saturday, I suspect it's Sunday for you by now! <grin> >>>>> >>>>> I think you're correct that I've been misunderstanding libao. In any >>>>> case having the plughw:1 in the alsa stanza wasn't harming anything. >>>>> >>>>> I'm currently booted with speech-dispatcher using also, so that >>>>> directive may actually be working. It's also possible, of course, that >>>>> it's just the next available card, because espeakup is definitely using >>>>> plughw:0, so :0 is locked up tight for espeak's use. That makes :1 the >>>>> next available card. >>>>> >>>>> In my /etc/asound.conf I have the default set for hw:2, because linphone >>>>> is no longer allowing me to specify the particular alsa device that is >>>>> my headset. >>>>> >>>>> Best, >>>>> >>>>> Janina >>>>> >>>>> >>>>> >>>>> Didier Spaier writes: >>>>>> Hi Janina >>>>>> >>>>>> Setting these two directives like this in speechd.conf won't ever work, >>>>>> I think: >>>>>> AudioOutputMethod "libao" >>>>>> AudioALSADevice "plughw:1" >>>>>> >>>>>> In the first one you tell to use the libao audio output, but >>>>>> the second one is only used if you use the alsa audio output instead >>>>>> if I understand well. >>>>>> >>>>>> If initially the card # 1 used with speech-dispatcher thte is because >>>>>> of some other setting, I think. I don't know which one, you will >>>>>> need to a look ayour Arch configuration and sercice files to >>>>>> find oouT. >>>>>> >>>>>> So if you use the libao output (libao using in turn its alsa backend, >>>>>> I assume), you will have to find another way to set the card to use >>>>>> for speech managed by speech-dispatcher, than to do this setting in >>>>>> speechd.conf. >>>>>> >>>>>> One of the possibility would be a setting in /etc/asound.conf or >>>>>> in ~/.asoundrc >>>>>> >>>>>> Oh, and you can't take the config file I sent you as is and hope >>>>>> it will work in Arch, as the settings in it have to be read by >>>>>> some script managing espeakup. This is the case in Slint but >>>>>> not in Arch. So if you want to use these settings in Arch you >>>>>> will have to find out by why script they should be used, >>>>>> and maybe modify it to read them. >>>>>> >>>>>> I can't resist to suggest that you try Slint instead <smile>. >>>>>> >>>>>> Best, >>>>>> >>>>>> Didier >>>>>> >>>>>> PS I received the answer from Cris while typing. But I don't >>>>>> think our answers contradict each other, fortunately. >>>>>> >>>>>> On 23/03/2019 20:20, Janina Sajka wrote: >>>>>>> Hi, Didier: >>>>>>> >>>>>>> Once again you're providing some very helpful guidance. Thank you so >>>>>>> very much for that. >>>>>>> >>>>>>> Yes, I'm using arch, but I'm the other way around from what you're >>>>>>> saying. I'm using speech-dispatcher-git, but only the espeakup release >>>>>>> at the moment. The reason is that the current speech-dispatcher relase >>>>>>> isn't correctly accepting an alsa card designation, i.e. it won't honor >>>>>>> these two directives in speechd.conf: >>>>>>> >>>>>> >>>>>>> >>>>>>> I am now going to put your espeakup script in place on my machine and >>>>>>> try a reboot. I will report. >>>>>>> >>>>>>> Thank you for this script. I wasn't aware all these directives could be >>>>>>> included. This should solve my problem, I hope! <grin> >>>>>>> >>>>>>> Janina >>>>>>> >>>>>>> Didier Spaier writes: >>>>>>>> Hi Janina, >>>>>>>> >>>>>>>> IIRC you are running Arch. Right? >>>>>>>> >>>>>>>> If yes, looking at the PKGBUILD I see that it grabs a snapshot from >>>>>>>> git at the commit d25ed10d dated 22 nov. 2018: >>>>>>>> https://github.com/brailcom/speechd/commit/d25ed10d5ede8c0f747211928fbd5f742d753556 >>>>>>>> >>>>>>>> So I am puzzled that you just get it, knowing the PKGBUILD was last updated >>>>>>>> on 24. Nov. 2018... >>>>>>>> >>>>>>>> So, I can't see a reason for speech-dispatcher be in concern for an issue >>>>>>>> occurring this week. >>>>>>>> >>>>>>>> And espeakup-git (if that's what you use) was last updated on >>>>>>>> 2019-01-03 18:14. >>>>>>>> >>>>>>>> So I am puzzled. I don't know what happened recently, but this issue should be >>>>>>>> reported to your distribution rather than to upstream IMHO. >>>>>>>> >>>>>>>> Also, a tip: you can set ALSA_CARD before starting espeakup, it will >>>>>>>> honor this setting. This how we now do in Slint, cf. attached file >>>>>>>> /etc/espeakup.conf. >>>>>>>> >>>>>>>> To know which files are involved in Arch, have a look at the bottom >>>>>>>> of https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=espeakup-git >>>>>>>> >>>>>>>> Sorry I can't provide further guidance, not running Arch. >>>>>>>> >>>>>>>> Best, >>>>>>>> >>>>>>>> Didier >>>>>>>> >>>>>>>> >>>>>>>> On 22/03/2019 15:43, Janina Sajka wrote: >>>>>>>>> I tend to update globally about once a week, usually on Fridays. With >>>>>>>>> today's update of Speech-Dispatcher-git Espeakup is broken. >>>>>>>>> >>>>>>>>> 1.) I boot to a console login. Works as expected. Speakup speaks >>>>>>>>> with Espeak on hw:0. Yes, I'm using alsa, not pulse. >>>>>>>>> >>>>>>>>> 2.) I launch the graphical desktop with startx and Orca comes up >>>>>>>>> over Speech-Dispatcher using libao on hw:1 as specified in speechd.conf. >>>>>>>>> >>>>>>>>> 3.) Switching back to any console, speech is gone. Doing a systemctl >>>>>>>>> restart espeakup puts speech on hw:2. >>>>>>>>> >>>>>>>>> This is bonkers. >>>>>>>>> >>>>>>>>> PS: Isn't it time we could control what device the soft synth driver >>>>>>>>> speaks to with a configuration option? Perhaps an additional parameter >>>>>>>>> in /etc/conf.d/espeakup? >>>>>>>>> >>>>>>>>> Or is it supposed to be in /etc/speakup/espeakup? >>>>>>>>> >>>>>>>>> Both those configs say basically the same thing, but they're not >>>>>>>>> symlinked. Why? >>>>>>>>> >>>>>>> >>>>> >>> >> _______________________________________________ >> Speakup mailing list >> Speakup@xxxxxxxxxxxxxxxxx >> http://linux-speakup.org/cgi-bin/mailman/listinfo/speakup > _______________________________________________ Speakup mailing list Speakup@xxxxxxxxxxxxxxxxx http://linux-speakup.org/cgi-bin/mailman/listinfo/speakup
