Espeakup and Speech-Dispatcher-git--Fighting again?

Sun Mar 24 20:41:13 EDT 2019

Hello Janina.

Trying to match  your alsa.conf with alsareport, under:
"Loaded ALSA modules"
and
"Soundcards recognized by ALSA", I think that alsa.conf can be simpler,
as we know the module associated with each card. so we don't need
aliases, just associating the id and the index should be enough.

Further, I don't see a snd_hdsp module loaded, but three snd_usb_audio.
So trying to load this module fails because you don't have a hardware
using it, hence these lines at the end of dmesg output:

[   74.585561] snd_hdsp 0000:03:01.0: no IO box connected!
[   74.585736] snd_hdsp: probe of 0000:03:01.0 failed with error -5

As a conclusion, here is the content I'd suggest for alsa.conf:

options snd-hda-intel id=PCH index=0
options snd-usb-audio id=DEVICE  index=1 
options snd-usb-audio id=Headset index=2
options snd-ice1724 id=AV710 index=3
options snd-usb-audio id=UR22mkII index=4

setting vid and pid is not necessary as we can distinguish the
cards needing the same module by their id. 

I attach to this email alsa.conf.reviewed.

As an aside I am a bit puzzled: you wrote that you use alsa only,
however in alsareport under "Sound Servers on this system" I read:

Pulseaudio:
		  Installed - Yes (/usr/bin/pulseaudio)
		  Running - Yes

If you want to check that pulseaudio be running, just type:
ps -ef|grep pulse

I don't know what having pulseaudio running changes, as that depends on
its settings, though. It's possible that it be started "on demand" by
an application that request it. An example that comes to my mind is the
mixer that I have on the top panel of Mate. But that can be pretty much
any app that tries to use it. But again I can't draw any conclusion not
knowing how it is configured.

However, I can't rule out that pulse settings interfere with alsa
settings: if a pulse daemon is spawned when you type startx this could
explain some of the issues you reported, especially if in
/etc/pulse/default.pa you have devices named as hw:<something>

To avoid that, in Slint the default /etc/pulse/default.pa includes these
four lines:

### In Slint, we want to share audio resources between speech apps that
### rely on alsa and other apps that rely on pulseaudio.  
load-module module-alsa-sink device=dmix
load-module module-alsa-source device=dsnoop

I hope this helps at least a little.

Best,

Didier
On 24/03/2019 12:23, Janina Sajka wrote:
> Hi, Didier:
> 
> Sorry I forgot the attachment. Herewith three attached files as
> requested.
> 
> Thank you for your help on this.
> 
> Best,
> 
> Janina
> 
> PS: I'll be away now most of the day. I have a church job where I'm in
> charge of the music for worship.
> 
> Didier Spaier writes:
>> 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?
>>>>>>>>>
>>>>>>>
>>>>>
>>>
> 
-------------- next part --------------
options snd-hda-intel id=PCH index=0
options snd-usb-audio id=DEVICE  index=1
options snd-usb-audio id=Headset index=2
options snd-ice1724 id=AV710 index=3
options snd-usb-audio id=UR22mkII index=4