Open rastapapa opened 4 years ago
I am on a pi zero w running Buster. In trying to install the workarounds, I see there is a message that libopenal1 depends on an earlier version of libsndio6.1. From my noob searching, libsndio7.0 is installed and 6.1 cant be installed.
Im tempted to hunt in the code for the earlier version, and manually update to 7.0, but I have no idea what Im doing.
Did you find a solution to this?
Anyone?
I'm on latest Raspberry Pi OS and WORKAROUND depends on earlier libn we do?openal-data, libsndio6.1 etc.
What can we do?
What's the verdict on this? Any solution?
Here you’ll the answers you seek.
After lots of mucking around and workarounds, I got Talkiepi working. Refer here...
https://github.com/mnoonan296/talkiepi/blob/master/doc/README.md
After looking at this thread (https://dietpi.com/phpbb/viewtopic.php?t=6183&fbclid=IwAR3FcN3rMTAAuSNw2wsW38bhdrZxXTnvpWsUQ_l3tFuumCSG5Z_E3Nio2cQ)
You can download the library from here http://raspbian.raspberrypi.org/raspbian/pool/main/s/sndio/libsndio6.1_1.1.0-3_armhf.deb
Install it before installing the workarounds.
Guys, thanks for updating workaround (it's a pity what author, @dchote - Daniel - is not appearing here. But, I hope, he is OK!). After installing libsndio6.1_1.1.0-3_armhf.deb I was able to install workaround on RPi Zero, and mumble.service is up & running, but I still can't hear voice :(
I'm getting (testing client from command line):
Connected to 192.168.1.42:64738 (0)
Welcome message:
Welcome to this server running Murmur.
Enjoy your stay!
Unable to find channel: talkiepi
Channel 'HomeIntercom' has 2 participants
Cannot connect to server socket err = No such file or directory
Cannot connect to server request channel
jack server is not running or cannot be started
JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping unlock
JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping unlock
ALSA lib pcm_dsnoop.c:602:(snd_pcm_dsnoop_open) unable to create IPC semaphore
ALSA lib pcm_dmix.c:1071:(snd_pcm_dmix_open) unable to create IPC semaphore
I'm using ReSpeaker 2-Mics Pi HAT; aplay test.wav command works perfectly but not after running mumble.client as a service or even execute talkiepi from command line. Anyone got luck making talkiepi working with ReSpeaker board?
Seems you are close. Not sure it is getting to your expected channel on your mumble server. I used Root in my case.
Oh, I resolved my issue by changing GPIO ports (ReSpeaker uses some GPIO ports already set in talkiepi source code). By the way, I'll need to modify sources, to use 2 GPIO ports only.
Oh, man, this app gives me a lot of troubles :( I don't know what is the source of the issue: buggy and inconvenient Go code/libraries or bad app code or what... I don't really know :( but I can't make damn thing work :(
Finally, I got talkiepie working (somehow) and even connection LED is working properly too. So, I'm able to hear voice from Android app (and Windows app too) on RPi Zero. But I can't make push button work. Here is my gpio readall output:
+-----+-----+---------+------+---+-Pi Zero--+---+------+---------+-----+-----+
| BCM | wPi | Name | Mode | V | Physical | V | Mode | Name | wPi | BCM |
+-----+-----+---------+------+---+----++----+---+------+---------+-----+-----+
| | | 3.3v | | | 1 || 2 | | | 5v | | |
| 2 | 8 | SDA.1 | IN | 1 | 3 || 4 | | | 5v | | |
| 3 | 9 | SCL.1 | ALT0 | 1 | 5 || 6 | | | 0v | | |
| 4 | 7 | GPIO. 7 | IN | 1 | 7 || 8 | 0 | OUT | TxD | 15 | 14 |
| | | 0v | | | 9 || 10 | 1 | IN | RxD | 16 | 15 |
| 17 | 0 | GPIO. 0 | IN | 1 | 11 || 12 | 1 | ALT0 | GPIO. 1 | 1 | 18 |
| 27 | 2 | GPIO. 2 | IN | 0 | 13 || 14 | | | 0v | | |
| 22 | 3 | GPIO. 3 | IN | 0 | 15 || 16 | 0 | IN | GPIO. 4 | 4 | 23 |
| | | 3.3v | | | 17 || 18 | 0 | IN | GPIO. 5 | 5 | 24 |
| 10 | 12 | MOSI | ALT0 | 0 | 19 || 20 | | | 0v | | |
| 9 | 13 | MISO | ALT0 | 0 | 21 || 22 | 0 | IN | GPIO. 6 | 6 | 25 |
| 11 | 14 | SCLK | ALT0 | 0 | 23 || 24 | 1 | OUT | CE0 | 10 | 8 |
| | | 0v | | | 25 || 26 | 1 | OUT | CE1 | 11 | 7 |
| 0 | 30 | SDA.0 | IN | 1 | 27 || 28 | 1 | IN | SCL.0 | 31 | 1 |
| 5 | 21 | GPIO.21 | IN | 1 | 29 || 30 | | | 0v | | |
| 6 | 22 | GPIO.22 | IN | 1 | 31 || 32 | 0 | IN | GPIO.26 | 26 | 12 |
| 13 | 23 | GPIO.23 | IN | 0 | 33 || 34 | | | 0v | | |
| 19 | 24 | GPIO.24 | ALT0 | 1 | 35 || 36 | 0 | IN | GPIO.27 | 27 | 16 |
| 26 | 25 | GPIO.25 | OUT | 0 | 37 || 38 | 0 | ALT0 | GPIO.28 | 28 | 20 |
| | | 0v | | | 39 || 40 | 0 | ALT0 | GPIO.29 | 29 | 21 |
+-----+-----+---------+------+---+----++----+---+------+---------+-----+-----+
| BCM | wPi | Name | Mode | V | Physical | V | Mode | Name | wPi | BCM |
+-----+-----+---------+------+---+-Pi Zero--+---+------+---------+-----+-----+
I'm using real intercom cases, so I can't re-use your @mnoonan296 , implementation with ReSpeaker (I do have the same), so I just need a - simple as a carrot! - plain GPIO support, but...
Currently (in front of me), LED connected to real RPi Zero GPIO.26, and in the app source code I changed:
const (
OnlineLEDPin uint = 26 // real GPIO.25
ParticipantsLEDPin uint = 14 // not used now
TransmitLEDPin uint = 14 // not used now
ButtonPin uint = 27 // real GPIO.2
)
It looks like LED functioning well with GPIO.25 (what equals for some unknown for me reasons as BCM 26 - that mess is really killing me) But... I connected button (from original intercom board, not a ReSpeaker one - I can't use it) to GPIO.2 (not used by ReSpeaker, according to schematics), and button press detecting pretty well with gpio command (I pressed button on 2-nd & 3-rd runs):
pi@pizero2:/home/mumble/gocode/src/github.com/dchote/talkiepi $ gpio read 2
0
pi@pizero2:/home/mumble/gocode/src/github.com/dchote/talkiepi $ gpio read 2
1
pi@pizero2:/home/mumble/gocode/src/github.com/dchote/talkiepi $ gpio read 2
1
pi@pizero2:/home/mumble/gocode/src/github.com/dchote/talkiepi $ gpio read 2
0
pi@pizero2:/home/mumble/gocode/src/github.com/dchote/talkiepi $
But pressing button during talkiepi execution does nothing: no voice, no output. I don't know how to debug damn thing and where to see output. Go isn't my programming language and I don't want to learn it; but looks like I should :( Do you have any suggestions?
P.S. BTW, arecord also working pretty well; I really like quality of ReSpeaker board. And I already tried other GPIOs for push button - no luck at all :(
Are you communicating between two pi units? Could be sample rate confusion. Is your .asoundrc file correct? "If you are listening to the channel via mumble.com on your PC or Mac, the message received from the Talkiepi will be choppy, however the message sent to the Talkiepi will be clear and fine. The reason for this is that the Talkiepi has been programmed to transmit at 16kHz sample rate (to fit within the Pizero processing capacity) whereas the online application receives at 48kHz and cannot be changed. To hear what you are transmitting from a Talkiepi, you need to listen from a second Talkiepi unit."
I just got as idea: might be, RPi Zero has no enough power to handle server and client at the same time? @mnoonan296 , you're using setup pretty similar to mine (RPi Zero & ReSpeaker board), where is your mumble server is running - on the same RPi or standalone server?
@mnoonan296 , currently I'm using Android client called "Plumble Free", and "official" Mumble client for test (I haven't started working on second RPi unit, wanna finish first). As I said before, only push button (or recording & transmitting from RPi) is not working. As for me, it looks like "Go" GPIO library have some issues with reading values (or talkiepi code, I haven't digg deep yet). BTW, my goal is to build house intercom, not a learn Go language or create new Mumble client for RPi (and I really like to avoid this).
On the next step, I wanna add debug console output to the talkiepi source code during pulling push button pin (I wanna see a real value received). From my side, I'm 100% sure what my connection works fine (at least, standard gpio utility shows correct values).
"Funny" (not really - that means a serious bug in code), GPIO 3 (same as other I already tried) locked up in the logic 1 value after talkiepi execution. So, if I restart RPi (and ReSpeaker of cause), any unused by ReSpeaker GPIO port works as expected. It looks like only buggy Go code destroys somehow this :(
@sensboston I paid for a mumble.com subscription for a remote mumble server.
From memory I was only able to get the push button to work with Raspberry Lite Stretch and work arounds.
So, as I suspected, the source of talkiepi issues are bugs and incorrect code. Yesterday I fixed GPIO mess, refactored source code and completely removed buggy gpio package (it's really strange, @dchote already used good & working package go-rpio for initialization but not for the rest of work. And what much more strange: nobody fixed that part before...) I'll publish my changes as files or patches later; can do PR for your fork - it looks like Daniel haven't been here, on github since last February. Trully, I don't want to fork this project.
As for choppy sound (yeah, I heard that too of course), I believe your explanation is incorrect, sample rate or other "buggy" applications are innocent 😉 The primary source, of course, is bugs and/or improper code: as good Android app "Plumble Free" (I'm using for my testing) shows (I haven't looked to Android source code yet, my observation based on the participant icon "behavior"), talkiepi output stream isn't continuous and steady, it's interrupting al the time (and what's why sound is choppy). So, I do suspect another bug(s) in the github.com/dchote/gumble/gumble, github.com/dchote/gumble/gumbleopenal or github.com/dchote/gumble/gumbleutil modules.
It will take some time to find and fix bugs: yesterday was my very first experience programming on golang (actually, I read wiki about golang syntax & features after I fixed the code 😉 ), but it's not an issue, I have been programming in C, C++ & C# for many years.
P.S. @mnoonan296 , I'm just curious: why are you paying for subscription? Official mumble server called "murmur" 🐱 is free, open source and works as promised right out of the box (I decided to move it from RPi to my Windows home server).
@sensboston Im really glad to see that some progress is being made on this. @mnoonan296 's setup page looks worthy of trying, but I wanted to ask if you think a fresh start with that setup will produce a working set of talkiepi's? https://github.com/mnoonan296/talkiepi/blob/master/doc/README.md
I already have the USRobotics speakerphones and at one point got close enough to see that my pi 3+ was logging into the mumble server, but none of the buttons worked and I figured that I shorted out the pins accidentally, but now I wonder if its the code. Have you seen better luck with the ReSpeaker? Any trouble with the gpio?
Before I buy some knockoff Keystudio ReSpeakers and start over, Id like to hear that someone had success. Thanks!
@rastapapa, initially, ReSpeaker's GPIO connectors didn't worked for me so I decided to solder wires directly to ReSpeaker connector (on the top) using this schematics: you can easily see non-connected pins. This should work 100%.
Later I figured out what GPIO access in talkiepi implemented incorrectly; module rpio (which talkiepi also using but strange way) can do work even better. Here are modified files, I think this will work better for you than diffs :wink:
P.S. In addition: I'm using latest Raspberry Pi OS, and latest drivers from ReSpeaker. Also, please be sure to use BCM pin numbers (very first and last columns in result of gpio readall command)
Great work @sensboston. Wish you were around when I was trying to muddle through this project. 🙂
@sensboston Thanks for your reply and updates! Looking at the schematics I see the button has two upper pads that appear to have traces, and two bottom pads that have no connection.
Also for LEDs I see that your gpio readall shows GPIO.25 for the online LED (BCM 26),
Did you ever figure out the participants and transmit LEDs?
You also mentioned "diffs" with a smilie, and I didnt understand the reference. Is diffs a joke Im not getting, or is that the name of what was originally used in talkiepi by dchote?
Lastly, do you recommend using the ReSpeaker over the USRobotics speakerphones? Amazon has some Keystudio ReSpeakers that will arrive much faster than the seeed studio ones. But Im not sure if they will accept the drivers you recommend.
Are you saying that you soldered
Please take a look: pic will say more than I :wink:
Did you ever figure out the participants and transmit LEDs?
Yes, I did. For the transmit, use TransmitLEDPin, for upcoming stream see the "hack" by @job580
You also mentioned "diffs" with a smilie
"Diffs" is a common name for output results of the diff utility; it shows (in specific format) changes between original and modified files. Mostly it used for the pull requests etc. But my smile was related to some "programming nazi" - some of guys here, on github (or another open source resources) are hating accept modifying files and always asking for the diffs 🤣 I'm professional software engineer with 30 years of experience, and I understand, for enthusiast (who's not a professional programmers) sometimes much better to get complete files than "diffs" 😉 BTW, nevermind!
Lastly, do you recommend using the ReSpeaker over the USRobotics speakerphones?
Can't say anything about USRobotics. I've re-used speakerphones from old intercoms I'be purchased on eBay (and got a refund 'cause they aren't work well). Simple cheap speakers purchased on ali are also worked fine for me (for my needs), but I don't know how do you plan to use your project.
BTW, you may see my stuff "in action" on my post in Russian Boston DIY FB group.
@sensboston Hey this is very cool. I see you incorporated the talkiepi into an old intercom! With dazzling lights! I have another question, do we need to run a mumble client on another device all the time that talkiepi is in use? It sounds like theres a public channel we can use - which sounds good for testing. How are you handling mumble?
@rastapapa, I've installed Mumble server (murmur) on my home server windows PC. Previously, I installed Mumble server on "client" RPi Zero - and this also worked fine! - but later decided to give RPi Zero some "rest". No internet, no outgoing connection at all ("everything happened in my house is my problem" (c) 😃 )
So, no "public channels" at all. By the way, I still believe, TalkiePi (and gumble itself ) are implemented incorrectly. I still appreciate a hard work of @dchote and @layeh on the open source implementation of mumble protocol (and porting it to RPi), but... This implementation is kinda incorrect, I think so. If your goal to build high performance client/server based on this implementation - forget about this.
P.S. I touched Go language for the very first time working on this project. Probably, I'll try to find another simple, plain "good old C"implementation to port. But I can't promise now.
Hi @sensboston, Im finally looking into the files you posted:
Here are modified files
P.S. In addition: I'm using latest Raspberry Pi OS, and latest drivers from ReSpeaker. Also, please be sure to use BCM pin numbers (very first and last columns in result of gpio readall command)
Your zip has: gpio.go & talkiepi.go forgive me being a noob, but:
I am looking into the seeedstudio link and I think Ill be able to figure it out. You connect your BCM pins to get the ReSpeaker LEDs, Step 4. and user button Step 5. to work, right? It looks like you need to make sure the button.py file has the correct assignment at line 4 which has the example of BUTTON = 17. The 17 needs to match the gpio readall BCM # right? The link you posted brings you to the bottom of the page to the faq section, which I dont think was your intention, was it?
Thanks for your help with this!
- Can you give me some instructions
Just replace (overwrite) original files in the cloned repository directory, i.e. at /home/mumble/gocode/src/github.com/dchote/talkiepi and rebuild the project.
export GOPATH=/home/mumble/gocode
export GOBIN=/home/mumble/bin
cd $GOPATH/src/github.com/dchote/talkiepi
go build -o /home/mumble/bin/talkiepi cmd/talkiepi/main.go
Don't forget to restart program after build: systemctl restart mumble.service
- Will you confirm
Yes, I confirm.
The 17 needs to match the gpio readall BCM # right?
Yes, rpio lib is using BCM numbering, not a GPIO.
The link you posted brings you to the bottom of the page to the faq section, which I dont think was your intention, was it?
You should go up the page and follow instructions how to build latest (fixed) driver release.
@sensboston Hello again, Thanks much for answering my questions. Hopefully there's others that will benefit too.
My plan is to follow the fork by @mnoonan296 at his github page here and fill in your updates (hopefully at the correct points) along that path. Unfortunately, I see some deviations from whats listed in his detailed steps compared to even step 1 of whats posted on seeedstudio . Off the bat, @mnoonan296 cites running the ReSpeaker install with
sudo ./install.sh --compat-kernel
Instead of just
sudo ./install.sh
By the text I imagine @mnoonan296 is installing a compact version, which is what I tried first, but the next steps of whats on the seeedstudio dont seem compatible. Before I try again and get lost and re-flash I wondered if you could help.
Also I see in order to be able to do a gpio readall I need to install WiringPi, is that correct? If so is this what I need to do:
sudo apt-get install wiringpi
Thanks again. I hope you dont mind, as I assume Ill have more hiccups.
I am on a pi zero w running Buster. In trying to install the workarounds, I see there is a message that libopenal1 depends on an earlier version of libsndio6.1. From my noob searching, libsndio7.0 is installed and 6.1 cant be installed.
Im tempted to hunt in the code for the earlier version, and manually update to 7.0, but I have no idea what Im doing.