My thoughts are like this:
I am learning a lot about what makes Raspbian, and especially the GPGOS, tick.
Even if you CAN’T use my images per-se, they provide a bunch of pre-reasearched fixes and ideas. That is, I’ve tried things and discarded what doesn’t work. Hopefully this will help you with your eventual release cycle once you get back to it.
In any event, have a nice holiday!
As much as I would like to see a 3.0.2 soon, you might want to wait for me to figure out a couple more problems - like garbled sound.
Nicole,
As you may have guessed, there has been a wailing and gnashing of teeth here, both publicly and privately about what goes on behind the scenes. As much as I’d like to have a better view into what’s going on, it’s probably none of my business.
I also am very confident that you’re as busy as a cat with two tails.
This leaves me two choices: Complain or do something about it.
I’ve decided to “do something about it” instead of complaining - and since I happen to be as close as anyone else here to being a “subject matter expert” on the GoPiGo O/S, I figured I’d take a stab at it.
And it’s not “amusement” per-se, but rather it’s something that needs to be done, and since I can help do it, I do. It’s a part of what makes FOSS/Open Source great, we all pitch in and try to make a difference.
I build on what you and others have done. You and others build on what I have done. This way we get more done, hopefully better, than one person can do himself.
Kinda’ like tag-team wrestling - you hold 'em while I hit 'em!
The payoff to me is that I am learning a lot about what makes things tick in a better way than I would have before.
The corresponding payoff to everyone else is that I can make something available for others to try while you’re busy with other things.
And please don’t rush into this. Take your time, relax, and let’s work together to make this the best release so far.
What say ye?
One gripe I am researching:
GoPiGo O/S absolutely INSISTS on using the headphone jack for output!
The desired and optimum behavior should be:
Every computer system I have ever used since the time computers ran off of wood fires and steam, distinguished between monitor based sound and headphone jack based sound, and automatically switched between them.
My laptop does this.
My Android based smartphone does this.
Every other electronic device with sound output, speakers, and an audio jack does this.
Question:
How do we make GPGOS do this?
Second question:
How do we switch from that absolutely horrid British voice? It sounds like he’s got a sock up his nose - or the sinus infection from hell!
My opinion - for robots assuming the headphone out is the correct default.
That said, you would need to learn all you can about what status the HDMI port can give you.
Again my opinion, the default voice is the most intelligible of all the standard voices espeak-ng ships with.
$ espeak-ng --voices=en
Pty Language Age/Gender VoiceName File Other Languages
2 en-gb --/M English_(Great_Britain) gmw/en (en 2)
3 en-gb --/M english-mb-en1 mb/mb-en1 (en 2)
2 en-us --/M English_(America) gmw/en-US (en 3)
5 en-gb-scotland --/M English_(Scotland) gmw/en-GB-scotland (en 4)
5 en-gb-x-gbclan --/M English_(Lancaster) gmw/en-GB-x-gbclan (en-gb 3)(en 5)
5 en-gb-x-rp --/M English_(Received_Pronunciation) gmw/en-GB-x-rp (en-gb 4)(en 5)
5 en-us --/M us-mbrola-2 mb/mb-us2 (en 7)
5 en-us --/F us-mbrola-1 mb/mb-us1 (en 8)
5 en-us --/M us-mbrola-3 mb/mb-us3 (en 8)
5 en-gb-x-gbcwmd --/M English_(West_Midlands) gmw/en-GB-x-gbcwmd (en-gb 9)(en 9)
9 en --/F en-german-1 mb/mb-de1-en
9 en --/M en-german-2 mb/mb-de2-en
9 en --/F en-german-3 mb/mb-de3-en
9 en --/M en-german-4 mb/mb-de4-en
9 en --/F en-german-5 mb/mb-de5-en
9 en --/M en-german-6 mb/mb-de6-en
9 en --/M en-greek mb/mb-gr2-en
9 en --/M en-romanian mb/mb-ro1-en
5 en-029 --/M English_(Caribbean) gmw/en-029 (en 10)
10 en --/M en-dutch mb/mb-nl2-en
10 en --/M en-french mb/mb-fr1-en
10 en --/F en-french mb/mb-fr4-en
10 en --/F en-hungarian mb/mb-hu1-en
10 en --/F en-swedish-f mb/mb-sw2-en
11 en --/M en-afrikaans mb/mb-af1-en
11 en --/F en-polish mb/mb-pl1-en
11 en --/M en-swedish mb/mb-sw1-en
5 variant --/M Storm !v/Storm (en-us 5)
and here is everything I know about Espeak Text To Speech - OLD! Some may be wrong:
Espeak TTS
(Using espeak-ng now)
espeak-ng "Hello there"
espeak-ng -a 7 "this is a whisper"
espeak-ng 2>/dev/null "with no error messages"
espeak-ng -ven-us+f3 -s 130 "female US English"
espeak-ng -ven-german-1 "german female voice 1"
languages: en-us, en-sc(ottish),
variants: +f2 f3 f4 f5 whisperf m2-m7, whisper f1(old), m1(old)
(https://www.dexterindustries.com/howto/make-your-raspberry-pi-speak/)
==== Fix TTS on Raspbian For Robots (a long time ago)
sudo apt-get remove -y espeak
sudo apt install -y espeak espeak-ng python3-espeak speech-dispatcher-espeak
pip3 install espeakng
========= Loading TTS ========
dpkg -s espeak-ng (to check if installed)
sudo apt-get install espeak-ng
test: espeak-ng “hello”
to not see all the error msgs: espeak-ng 2>/dev/null
Fix error msgs: If you get the following error message:
ALSA lib pcm.c:2217:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.front
Edit the file /usr/share/alsa/alsa.conf:
sudo nano /usr/share/alsa/alsa.conf
change the line “pcm.front cards.pcm.front” to “pcm.front cards.pcm.default”
---
# Alan: change to get rid of espeak errors
# pcm.front cards.pcm.front
pcm.front cards.pcm.default
pcm.rear cards.pcm.default
pcm.center_lfe cards.pcm.default
pcm.side cards.pcm.default
pcm.surround40 cards.pcm.default
pcm.surround41 cards.pcm.default
pcm.surround50 cards.pcm.default
pcm.surround51 cards.pcm.default
pcm.surround71 cards.pcm.default
pcm.iec958 cards.pcm.default
pcm.spdif iec958
pcm.hdmi cards.pcm.default
pcm.dmix cards.pcm.default
pcm.dsnoop cards.pcm.dsnoop
pcm.modem cards.pcm.default
pcm.phoneline cards.pcm.default
now restart alsa utils
sudo alsactl init - to reset alsa something
sudo alsa force-reload
(There will still be some errors like bluealsa)
==== add tts alias
.bash_aliases:
alias tts='espeak-ng 2>/dev/null '
then:
. .bashrc
==== using espeak in python
#!/usr/bin/python
#
# speak.py Speaker utilities
#
# say(phrase) do not include apostrophes in phrase
import subprocess
def say_espeak(phrase):
subprocess.check_output(['espeak-ng',phrase], stderr=subprocess.STDOUT)
def say(phrase):
say_espeak(phrase)
# ##### MAIN ####
def main():
say("hello from speak dot p y test main")
if __name__ == "__main__":
main()
==== espeak broken after OS update/upgrade Sept 2019
tried
sudo apt-get remove libpulse0
This removed:
espeak ffmpeg gstreamer1.0-plugins-bad libav-tools libavdevice57 libespeak-dev libespeak1 libfluidsynth1 libmikmod3 libpulse0 libsdl-image1.2 libsdl-mixer1.2 libsdl-ttf2.0-0 libsdl1.2debian
libsdl2-2.0-0 libsmpeg0 libsox-fmt-all libsox-fmt-pulse mplayer python-pygame python3-pgzero python3-pygame
sudo apt-get install espeak
The following NEW packages will be installed:
espeak libespeak1 libpulse0
nano /home/pi/.bashrc
PA_ALSA_PLUGHW=1
export PA_ALSA_PLUGHW
source .bashrc
===== python tts example
sudo apt-get install espeak-ng python-espeak-ng python-pyaudio
pip install pyttsx3
import pyttsx3
engine = pyttsx3.init()
voices = engine.getProperty('voices')
engine.say('Hello from Python')
engine.runAndWait()
. . . and as far as that goes, you are absolutely correct - especially since a large percentage of robots will use something plugged into the headphone jack.
But, not unlike wanting headless network configuration, this may not always be true. The suggestion I made solves both problems.
Now, as far as I can see, espeak-ng does not have any kind of configuration file. If I want to set a default voice, gap, word-rate, etc to make things most intelligible, I have not discovered how to do it. There are some defaults in /etc/pulse and /usr/share/alsa, but none of these seem to affect espeak-ng.
Oh, by the way, I have found that, on my system and using my headphones, an amplitude of 30 gives the clearest voice at a reasonable volume. Anything higher than that causes clipping. Of course, YMMV.
Another data-point:
There is anecdotal evidence that using a three-contact headphone plug into the four-contact Raspberry Pi headphone jack, can cause garbled sound, (especially at startup), as video information is being mixed with the audio information. Note that I have not tested this as I do not have a three-contact to four-contact adapter. If I can find a smartphone headset with microphone, (which has the four-contacts), I will try it.
There is also anecdotal evidence that a kernel back-rev solves the issue.
@cyclicalobsessive, what kernel do you use?
BTW, amixer on my “GoPiGo3 over Legacy PiOS” shows HDMI,0 even after I change audio to headphones with raspi-config… I’ll never understand ALSA. Sound is good on Legacy.
pi@Carl:~/Carl $ uname -a
Linux Carl 5.4.72-v7+ #1356 SMP Thu Oct 22 13:56:54 BST 2020 armv7l GNU/Linux
pi@PIOSLGCY:~ $ uname -a
Linux PIOSLGCY 5.10.63-v7+ #1496 SMP Wed Dec 1 15:58:11 GMT 2021 armv7l GNU/Linux
Absolutely true.
@cleoqc, can you tell us where the voice defaults are and what sets up which output will be the default? I am especially interested in the command-string as part of the problem may be the amplitude setting is too high and it’s clipping and going nuts.
I discovered wandering around on the Internet, a site that mentioned a couple of locations:
/etc/speech-dispatcher/modules/espeak.conf
/usr/lib/speech-dispatcher-modules/sd_espeak
[was ./lib64/... but we do not have that]
There are also interesting files in /etc/alsa and /etc/pulse
(P.S. Does anyone know how to turn off syntax highlighting within code blocks?)
Unfortunately, none of these seem to do anything to help.
Also, I tried a four-contact headset and there is no change.
@cyclicalobsessive,
You mention that the startup barker that repeats the IP address is “incessant” until disabled. This is interesting. Is this true for Carl or is it just for Dave as, on my system, it repeats twice and stops.
Do you know what the barker routine is or where it’s located? I’m going to snoop, especially in the rcX.d scripts, but the way my luck is going, I’m not holding my breath.
P.P.S.
Anyone who wants to punt this for a few days, get some eggnog, (and put a shot of The Old Bushmills in it), is perfectly welcome - it IS Christmas Eve for Christ’s sake! (Pun absolutely intended.)
Update:
/etc/pulse/default.pa has as (the last line on my system) the line set-default-sink 1. The default value is “0” which is the headphones. Setting this to “1” makes the HDMI output sticky for everything EXCEPT espeak-ng.
No, I didn’t. The accessibility wav file is the nag - only on Legacy PiOS and Bullseye PiOS.
I explained the IP announcer (my version which is based exactly on MR’s) in the ubuntu setup script. It is a run once service called ip_feedback. You could add an espeak-ng volume option there if you want to try lowering the ip feedback.
This has been in flux. I found out why my old method of setting for headphone out no longer works for Legacy and Bullseye.
I snooped that file out and it’s a revelation!
I suspect that Nicole sneaked in a -d hw:headphones parameter as there’s a specific comment that this forces headphone output for the IP barker come Hell or High Water.
Additional research disclosed that many sites on the web that deal with Linux audio start with the disclaimer: “Linux audio is a formidable challenge.” In other words, it’s easier to design a multi-kilowatt class D audio amplifier with zero distortion from 20 Hz to 20 KHz, ( 
), than to make sense out of Linux’s audio processing.
/etc/pulse seems to have a lot of the defaults - but it appears that many applications, (VLC is a good example) simply ignore the usual paths - the task-bar audio levels don’t apply and the pulse-audio/alsa settings are also ignored.
I tried reducing the volume on the command line in ip_feedback, but that doesn’t work either.
Next step is to try your kernel revision.
. . . and why was that? What changed and what did you have to do?
Update:
I have a totally working solution for the “garbled IP barker” that is a trivial fix, and does not require messing with the kernel.
Summary:
To eliminate the audio garbling on the IP address barker:
-d hw:CARD=Headphones from each of the four lines in /opt/Sam_Dev/install/ip_feedback.sh.set-default-sink value in /etc/pulse/default.pa and /etc/pulse/system.pa to direct the default audio output to either HDMI or the audio jack.Issue:
When the IP address is read through the headphone jack at initial startup, the sound is garbled as if it were being modulated with a 20Hz interfering signal, however normal espeak-ng output works fine.
Problem:
In the file /opt/Sam_Dev/install/ip_feedback.sh there are three lines:
su -c "espeak-ng -d hw:CARD=Headphones 'WiFi IP'" pi
su -c "espeak-ng -d hw:CARD=Headphones $IP_NUMBER" pi
su -c "espeak-ng -d hw:CARD=Headphones repeating " pi
su -c "espeak-ng -d hw:CARD=Headphones $IP_NUMBER" pi
at lines 40-43 in this file.
The particular part of these lines is the -d hw:CARD=Headphones part. This was deliberately placed to force output through the audio jack regardless of what the normal system settings might be.
Solution / Workaround:
Remove the -d hw:CARD=Headphones part of those three lines.
Viz.:
su -c "espeak-ng 'f'" pi
su -c "espeak-ng 'WiFi IP'" pi
su -c "espeak-ng $IP_NUMBER" pi
su -c "espeak-ng repeating " pi
su -c "espeak-ng $IP_NUMBER" pi
Note that the first line, (“f”), is not heard, but produces enough of a pause so that the entire second line’s phrase is spoken.
Removing the hard-coded redirection to the headphones resolves the garbled audio.
It has the unfortunate, (depending on the use-case), side effect of allowing the IP-address barker to use the system specified audio device, either HDMI or the audio jack.
Workaround:
In /etc/pulse there are two configuration files: default.pa and system.pa. The very last line in each of the two files is set-default-sink x where “x” is the device to use.
Update:
It appears that the documentation lags behind the current functionality just a bit.
The correct mapping, (as best as I can figure out), is:
/Update
Note that, when set this way, any device that produces audio and does not specify a different audio output device will use whatever is set here.
Since the “default.pa” is, (supposedly) used for userland audio processes and system.pa is used for audio calls from the system itself, I set both to the same value. I have NOT tried setting them differently.
What I suspect is happening is that setting any “-d” value for espeak-ng writes directly to the output hardware device bypassing audio buffering and stream handling as setting it to either an HDMI device or the audio jack produces garbled sound.
Please experiment with this and tell me what you find.
I don’t know exactly. The readme stated they were introducing pulseaudio to be more consistent with other Linux distros, but I don’t know exactly. It is my impression that the developers of espeak, and the currently supported version espeak-ng (“espeak next generation”), designed it to work under the multitude of Linux configs.
I ran “sudo raspi-config, SystemOptions->Audio->Headphones”
To get the microphone to work with arecord, I modified two ALSA config files but I don’t know why or which one does what.
This is my /etc/asound.conf:
pcm.!default {
type asym
playback.pcm {
type plug
slave.pcm "output"
}
capture.pcm {
type plug
slave.pcm "mic"
}
}
pcm.output {
type hw
card 1
}
ctl.!default {
type hw
card 1
}
pcm.mic {
type plug
slave {
pcm "hw:2,0"
}
}
and this is my /home/pi/.asoundrc:
pcm.!default {
type asym
playback.pcm {
type plug
slave.pcm "output"
}
capture.pcm {
type plug
slave.pcm "mic"
}
}
pcm.output {
type hw
card 1
}
ctl.!default {
type hw
card 1
}
pcm.mic {
type plug
slave {
pcm "hw:2,0"
}
}
defaults.pcm.card 1
defaults.ctl.card 1
This is the command line I use to adjust the volume for espeak-ng:
subprocess.check_output(['espeak-ng -s150 -ven-us+f5 -a'+str(vol)+' "%s"' % phrase], stderr=subprocess.STDOUT, shell=True)
Maybe modifying /etc/pulse/default.pa and system.pa would work and be less complicated?
Viz.:
The last four lines in each config file:
### Make some devices default
#set-default-sink output
#set-default-source input
set-default-sink 1
Maybe setting default source input would work?
Is this a global setting, as opposed to a per-command “-a [value]” setting?
It turns out that the actual problem was trying to drive the hardware device directly instead of using the alsa/pulse buffering and streaming.
Next time I try setting up GoPiGo over a new Legacy OS or Ubuntu card, I’ll give your fix a try. Perhaps I won’t have to remove pulseaudio, but while it appears you have solved the audio out issue, getting the audio in to work has always been the more significant challenge for me.
And that is perfectly OK. That’s all I ask anyway.
I have submitted this, along with my other proposed changes, to Nicole at MR for review and, (if they like them), inclusion in the next release.
There appear to be a few places where Nicole forces output to the headphone jack with that parameter, and I have suggested that they find/grep for every instance of that line and remove it.
There are a number of clean-up tasks they can do, (for example, removing obsolete features that never made it to prime-time and cleaning up the apt cache and logs), that will reduce the unzipped image by almost a gig.
I have asked them to send me a copy of the new release so I can beat on it and verify that all the fixes are in.
At this point, I’ve done just about everything I can do with this beastie until they send me a new one, so I am going to telescope all the way back in to my “New Remote Camera Robot” project.
Indeed we’re forcing it to the audiojack because if someone uses a Pi that was previously connected to a screen, the HDMI setting seems to get stuck. This doesn’t happen all the time but we did get more than a couple of cases.
And that’s why the audio jack is getting forced.
That raises the issue again of why forcing headphone output causes the audio to go all pear-shaped.
I’m going to skip that for awhile.