Python installation check failing on Linux Audio Raspberry Pi-OS

[Greg-R]

Setup:

Raspberry Pi-OS running on RPi4B 2 GB with recently downloaded image (full install).
uname -a:

Linux raspberrypi 5.4.51-v7l+ #1333 SMP Mon Aug 10 16:51:40 BST 2020 armv7l GNU/Linux

So it is the 32 bit OS. I have also tried the beta 64 bit with similar result.
Py audio installed per instructions:

sudo apt-get install python-pyaudio

and also

sudo apt-get install python3-pyaudio

Please note that the Rpi-OS "python" command runs Python 2.7. It is not an alias to Python 3.

Here is what I observe:

https://gist.github.com/Greg-R/6dccbbd899e41bc1322614340f32760f

Notice that the script is successfully detecting Pyaudio and the FTDI serial device plugged into a USB port.
Analog audio is working fine on the device. I can play youtube audio to a powered speaker connected to the 1/8inch jack.

Regards,
Greg

[leskerr]

@Greg-R Hi Greg! Glad to see you found our repository on GitHub and gave the Linux version of MKOB a try. I'm going to let Ed @AESilky address your issue, since he's the expert on the Linux installer. I can tell you, though, that I've been using MKOB with Linux, as recently as this morning, and the basic functions are working fine. It does log a slew of audio error messages to the console, even though the simulated sounder does in fact work through the speaker.

I'm looking forward to testing with you once you get up and running.

73,

~Les @leskerr

[AESilky]

Thank you for all of the system configuration info @Greg-R that will help. I will try to get it set up tomorrow. I have run it on RPi B, but it's been a while. What happens if you run Sample.py?

[Greg-R]

I hadn't run Configure.py yet. Here is the output:

Output from Configure.py

I don't see anything here which should prevent audio from working.
I am pushing the 2GB version to the limit with a full desktop.

[Greg-R]

Output from running Sample.py:

Sample.py output

[Greg-R]

I have 4GB and 8GB RPi4Bs. I will try on one of those and report.
I have both RPi-OS and Ubuntu distros, and also an Intel box running Ubuntu.

Greg

[AESilky]

Thanks for the output. It points out that I need to output a newline before exit...
So it ran and printed the text, but did it 'sound'? I'm assuming not, or you would have said so.

Also, note that Sample.py and Clock.py support a lot of options. You can see those by using -h/--help.

[AESilky]

I run the CLI apps (Sample, Clock, etc.) on a RPi-B and even a RPi-Zero, but I have them configured to start in terminal mode (no desktop).

We want MKOB functionality on the RPi, but I think we will need to make a CLI version of it, as the RPi currently lacks the HP to run the GUI. Though a RPi-4 should be getting close.

[AESilky]

Issue #33 could be related to this.

[Greg-R]

I have an RPi4B with 8 GB memory and booting off an SSD. It is probably comparable to a mid-tier Chromebook.
It is capable of driving dual HDMI displays. Lots of horsepower!

No problem testing headless. I can use ssh, no problem. I'm good enough with VIM and tmux to do moderate edits.

No sound heard. I verified functioning "analog" audio by playing a youtube video.
I will have a look at the options and see if I can coax it into working.

[AESilky]

We obviously want it to work with the audio jack, but as a test can you try a USB or Bluetooth speaker. Those are what I've used. I will try with the audio jack later today, but admit that I haven't used that to-date. I've been testing with hardware we used when developing the Watson audio client and we always used an Andrea Audio microphone+speaker using USB. The Andrea microphone is a two-mic array that let us determine the direction of the input (measuring the delta of the received audio from the two mics). I've never used the audio jack on the RPi, so this will be a good education.

[Greg-R]

I have Bluetooth speaker for sure, and maybe USB speakers. At least I used to. I will give it a try.

One thing I forgot to mention about the RPi. Since the GPIOs are directly accessible, I think the USB serial dongle could be designed out. Or at least a user-selectable option. The connections to the key and sounder would need the usual buffering to prevent the GPIOs from being damaged. It might not be anything more that what is needed to protect the serial port dongle.

[AESilky]

On GPIO - Totally agree! We are working on that. There is a repo for 'Device in a Box' https://github.com/MorseKOB/client-diab
Feel free to add to it as you have ideas. That is where I'm trying to capture RPi (and other micro-controller) info that would be useful for museum and other installations that don't need/want a computer/laptop and/or want a small, dedicated, device.

[AESilky]

If you go to the top level 'MorseKOB' you can see the multiple repos as well as the Wiki where @leskerr has put an enormous amount of information.

[Greg-R]

I've already cloned them. I'm just beginning to explore the contents. Nice work!

[Greg-R]

I'm seeing similar messages on an Intel platform desktop. But the Sample.py script works fine.
After googling around, the best I can find is this:

Suppress python terminal output

Here is another one:

Suppress PyAudio messages

It looks like you could either:

1. Ignore innocuous "error" messages
2. Suppress them

[AESilky]

In the first link above I also found a reference to the sounddevice module that uses PortAudio. It has a note that it doesn't produce all of the ALSA and other output that PyAudio does.

I will try it and see how it works. Maybe switching to that is a better solution.

Was your testing using the audio jack or did you switch to a USB speaker?

[leskerr]

I have no particular attachment to PyAudio. Feel free to try something else.

Achieving low latency audio was one of the top technical challenges for MorseKOB 2.5. It's mostly an issue when sending on a key and using the simulated sounder as a substitute for an external sounder. I find it difficult to send on a bug when there's a signficant delay in the sound coming from the speaker (where 'significant' means more than 20ms or so).

[AESilky]

Great input!

I've created a branch for this and I'm working on my Linux machine to use the other library. I will make sure to test with my key and simulated sounder.

I will only submit if it seems better and gets rid of all of the ALSA messages. As Greg mentioned (and we have noted), they are innocuous, but distracting.

[Greg-R]

After reading some of the comments on the ALSA messages, I tried using a USB to audio device on the RPi. This is a small adapter which has 1/8 inch jacks for both microphone and headphone audio. Essentially a cheap codec.
No difference seen in the Python terminal "noise".
My other tests were done using Bluetooth speakers.

I'm hoping to get a key and sounder connected to the RPi soon. I'm going to hack one of my old DCM-6 circuits plus a breadboard. I have an FTDI based USB-UART which should work.

Let me know if you get a working branch pushed with the alternative, and I will checkout and test.