Hi Again, Didier:
Thanks for looking at all my sound related reporting data. I know it's
quite voluminous. Some responses below in line ...
Didier Spaier writes:
> 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.
>
You're correct I can probably dispense with aliases. Or, maybe tetter
still, I should make more obvious aliases and actually learn to use
them?
I've been mulling this approach for the reason that I could perhaps then
adjust my various scripts to refer to an audio card by its alias name,
rather than its hw designation. If that could be gotten to work, I could
stop worrying about which card was assigned which hw value on a given
boot. Haven't tried this yet, though.
> 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
>
Ah, yes. It's a driver issue. That card has not worked with a series of
recent kernels, but began working again with the
linux-5.0.arch1-1-x86_64 kernel. I may downversion to it if the next
kernel doesn't fix whatever the problem is.
Here it is in lspci -v:
03:01.0 Multimedia audio controller: Xilinx Corporation RME Hammerfall
DSP (rev 0a)
Flags: stepping, medium devsel, IRQ 17
Memory at f7d10000 (32-bit, non-prefetchable) [size=64K]
Kernel modules: snd_hdsp
> 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.
>
Actually, my experience was that ID isn't enough, because I could find
no way with just ID to know which of the USB audio devices will be
assigned which hw: identity on a given boot. And that matters because of
the directive in speechd.conf and in linphone.
I suppose I could lock this in with udev rules, but that's considerably
unfamiliar to me.
I found that providing PID and VID to be a reliable way to insure that my CE Media usb card
always took plughw:1, and my Sennheiser headset always took plughw:2.
> I attach to this email alsa.conf.reviewed.
Thanks, Didier!
Janina
>
> 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?
> >>>>>>>>>
> >>>>>>>
> >>>>>
> >>>
> >
> 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
--
Janina Sajka
Linux Foundation Fellow
Executive Chair, Accessibility Workgroup: http://a11y.org
The World Wide Web Consortium (W3C), Web Accessibility Initiative (WAI)
Chair, Accessible Platform Architectures http://www.w3.org/wai/apa
_______________________________________________
Speakup mailing list
Speakup@xxxxxxxxxxxxxxxxx
http://linux-speakup.org/cgi-bin/mailman/listinfo/speakup
