I have built a simple docker image and am trying to figure out why PyAudio will not output any sound.
speaker-test outputs pink noise to the headphone jack.
aplay sound.wav also works
python3 play_wave.py sound.wav hangs and doesn't output any sound.
play_wave.py is an example/test program included with the pyaudio package.
I setup this test repository so you can witness the exact behavior: https://github.com/PaulWieland/pyaudio_test
git clone https://github.com/PaulWieland/pyaudio_test.git
cd pyaudio_test
docker build -t paulwieland/pyaudio_test .
docker run -it --rm --device /dev/snd paulwieland/pyaudio_test /bin/sh
Once inside the container, run aplay Front_Center.wav - the audio is played through the raspberry Pi's headphone jack.
Now run python3 play.py Front_Center.wav
In my case the script hangs and never finishes. I may get a blip of audio after a few minutes but it will not play the sound correctly.
EDIT:
This issue is some sort of compatibility problem with PortAudio running on a Raspberry Pi 4 using the latest Raspbian OS.
I'm now convinced it has nothing to do with Docker or Python, because I cannot get a simple C program which plays a wav using portaudio to work either.
I made a bit of progress today and here's my stab at a helpful answer. Audio on Linux can be a pain, but I thought this was a promising clue when I was playing with my pi3 (+Raspbian Stretch) today.
Like I said in my comment a few days ago, on my pi3 stuff sounded bad both in the host and the container when I played sound with pyaudio, but sounded good in the host and the guest when I played with aplay. I installed a pulseaudio server (packaged by default in most non-Raspbian Debians) on the host and pyaudio started sounding comparably good to aplay in the host! I tried installing pulseaudio in the container as well, and the installation succeeded, plus I got the daemon up and running, but the daemon complained some about not being able to connect to dbus, and after it was running, aplay played the sound but pyaudio did not. Then I tried running pulseaudio with the --system flag in the container (because the container user is root, and the daemon said that root should only run pulseaudio with that flag), and the sound came out again but it sounded bad in the same way it used to. I would give it a shot to get your container to talk to a pulseaudio server, though - it feels like it would be a good move to me.
You have two options there, either get a pulseaudio server running in the guest, or run one on the host like normal and permit the container to talk to it, and presumably dbus as well (sorry, I don't know how to do that). I do know for sure that if pulseaudio was running on my host, the container couldn't talk to it, because pyaudio printed some messages about being unable to connect to the pulse server. The latter feels like a good move to me because I can tell that it's easy to get a known-good setup for pulseaudio+pyaudio+dbus in the host, so maybe it's easy to get a good setup for pulseaudio+dbus in the host and pyaudio in the container. Worth a shot!
Another tidbit, for what that's worth - something is not the same about the ALSA configuration in your container and at least my pi3 + raspbian stretch. The alsa.conf files are not identical, and I think other stuff is going on too. I didn't look too far in to it since I don't really have exactly the same problem as you anyway.
Instead of p = pyaudio.PyAudio() do p = pyaudio.init()
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 1 year ago.
Improve this question
Scapy with WIFI - From setup to use
This tutorial is supposed to help you through the setup and installation of scapy and the wifi dongle used in this tutorial.
WIRESHARK, PYTHON AND SCAPY
I spent some time with scapy and want to share my knowledge since there are lots of spots where things can go wrong. I am using the TP-Link wifi dongle TL-WN722N V2.
Operating System:
I found that first of all you need to install your own driver to be able to use frame injection and monitor mode. Windows is not an option here because monitor mode was depreciated in earlier versions. Next I tried linux.
As I am quiet new to linux myself I played around a little and found out that most tutorials on WIFI monitor mode are only working for kali linux, which is fine if you want to use it for hacking. Another operating system for which I can confirm the drivers working is Ubuntu (version 20.04.2 currently). I also tried installing the drivers on raspbian. It does not work, ubuntu server version can be installed on raspberry pi, though. I hope this saves you some trouble.
=> Use Kali or Ubuntu (desktop and server version both work for ubuntu)
Installing The Driver
After reading the above paragraph this should be quiet easy as all the tutorials made for kali linux also work for ubuntu. Below are the steps that I took to install everything:
sudo apt update
sudo apt install bc make gcc
sudo rmmod r8188eu.ko
git clone -b v5.2.20 https://github.com/aircrack-ng/rtl8812au.git
cd rtl8812au
sudo -i
echo "blacklist r8188eu" > "/etc/modprobe.d/realtek.conf"
exit
make
sudo make install
sudo modprobe 8188eu
The most common error for me appeared after calling make. This is often due to wrong kernels and can be fixed by switching to ubuntu or kali as this has to do with the operating system.
Do not forget to reboot before the next steps.
Turn On Monitor Mode
This is also somewhat difficult because, as for me even though using the same operating system on rpi and my desktop computer, errors appeared at different spots. My solution was to simply fiddle around with the code and just trying random combination, leading me to success.
It is important that you use iwconfig to determine the name of your wifi dongle
Use these commands
ifconfig wlan0 down
airmon-ng check kill //Only useful in some situations
usermod -a -G netdev USERNAME //In case the operation is not permitted even though you are root
iwconfig wlan0 mode monitor //On RPi simply use this command without turning wlan0 down
ifconfig wlan0 up
iwconfig //Check out whether you have been successful and the mode says 'monitor' now
No idea why it does not always work the same way but your are very likely to succeed with the above commands.
Using Scapy
Finally, the fun stuff. Get ready to use pip to install scapy (python3 -m pip install scapy). Sadly, scapy only supports Python up to version 3.8, so make sure to have the correct version installed and activated as your default python. You also might need to run the script as root.
The code for sending packets is very straight forward:
from scapy.all import *
conf.use_pcap = True //Not quiet sure if this is optional
send(IP(dst="0.0.0.0")/UDP(dport=123, sport=200)/Raw(load="I am WIFI"), iface="wlan0", loop=1, inter=0.2)
I am not really trying to make a tutorial on how scapy itself works, only the big picture and how to set it up. It is a very interesting library and you should definitely check it out.
Most errors will arise from the import as it is crucial to use the proper python version! Also, the similar methods send() and sendp() troubled me a lot. I was unable to pick up anything with wireshark useing the sendp() method using the same parameters as above.
The iface="wlan0" is responsible for selecting the interface via which the packets are send. It should be matching with the interface you found earlier with the iwconfig command and set to monitor mode.
Using Wireshark
Wireshark is an awesome tool for prototyping whatever you want to do. If something is not working you should start looking there first. You can use it to identify what you are sending by running Wireshark on the transmitting wifi dongle or use another wifi dongle to pick up your packets. If you have done everything correctly and run the python script, while recording with Wireshark, you should be picking up many of the "I am WIFI" messages.
Thank you for going thorugh all of this. I hope I saved some people from all-nighters trying to figure out kernels, drivers or version mismatching.
Do ask me questions.
issue: unable to flash micropython to esp 32: open serial error, please try again. hope to connect internet and try again.
pretty new to micropython - want to flash micropython to esp 32 ( resp 8266) board.
cf this docs: https://maker.pro/esp8266/tutorial/using-micropython-on-an-esp8266-with-upycraft
getting this errors all the time.
open serial error, please try again.
hope to connect internet and try again.
current version only open py txt json ini file.
hope to connect internet and try again.
hope to connect internet and try again.
i run Win 7
the hardware:
a. Joy-IT-Node MCU ESP8266
.. and besides that i also tried it with the following
b. ESP32-T Development Board CP2102 with Espressif ESP-WROOM-32 IoT WLAN & BLE Modul
yes: i have installed the > CP210x_Universal_Windows_Driver.zip
by the way: i could try to do all that on a linux machine. - on a MX-Linux-Sytem
any idea;
many thanks for any and all help in advance.
As of my opinion, You don't necessarily depend on the uPyCraft IDE. So there are several other ways to develop scripts and uploading them to Your board.
Some days ago I was facing problems with Python on the NodeMcu as well. Since I didn't like the tutorials around the web, I've set up one on GitHub, covering the end-to-end process (required software, drivers, firmware images, developing, flashing, uploading, etc.): python2nodemcu.
It depends on Mac and the NodeMcu board, but some of the topics may apply to other operating systems and boards as well.
And I think it covers the most relevant parts of the whole process, using the easiest tools around the web. Please have a look at it, but all in all it goes like this (short version of the linked documentation above):
Install Python 3
Verify with python --version
Or python3 --version
Install the correct SiLabs driver to enable serial USB-to-UART communication
See here
Find the device file (representing the interface to the physical device)
Try it using ls -la /dev/tty.*
Download the recent MicroPython firmware
You need the right one for Your board
Install the two Python-based libraries EspTool and PySerial
Try to erase the flash of Your device
Run python3 esptool.py --port /dev/tty.{device-file} erase_flash
Try to flash the original image or the MicroPython firmware to the board
Run python3 esptool.py --port /dev/tty.{device-file} write_flash 0x00000 {micropython-image-or-original-firmware}.bin
Try to connect to the board via the REPL prompt
Run screen /dev/tty.{device-file} 115200
You maybe need to try different baud rates (depending on Your driver, cable, etc.)
Connect to the board using Ampy
For example, try to list the files on Your device executing python3 ampy/cli.py --port /dev/tty.{device-file} --baud 115200 ls
Again, try other baud rates
Anyway, I've noticed that You do not necessarily need to push the physical flash button on the device.
I'm using VLC to stream a wireless IP camera to a wall-mounted monitor that's connected to a tiny Debian computer.
Please note that Auto-reconnect from Tools > Preferences > All > Input / Codecs > Access Modules > HTTP(S) is enabled already.
Problem: after 30 min - 1 hour the stream disconnects. Only the orange VLC cone displays.
Symptoms: I can easily reload it manually. The Auto-reconnect radio box had no effect.
Question: Is there a configuration, script-based, or other approach that I can leverage to automatically re-connect?
I am studying the CLI documentation and the Python bindings for LibVLC. I actually don't see anything useful in the documentation.
LibVLC and its Python bindings seem to provide a complete reproduction of VLC from the ground up, such as what you'd use to fork or embed the application. I'm sure there must be a way to use that somehow, but it's not apparent to me yet and this seems like an incredibly heavy-lifting approach to solving this bug.
Auto-reconnect in VLC did not work for me at all and I think this is still an issue. Therefore, I switched to Streamlink, which uses VLC. Here the process stops, if the stream disconnects. With a infinity loop you can let it automatically try to reconnect forever:
while :; do streamlink <link-of-stream> best -p vlc --retry-streams <seconds-until-retry>; sleep <seconds-until-retry>; done
I use it for YouTube streams. I am not sure, whether it also works for network streams.
I have a python script that has a While True: in it that I would like to have run on startup on a raspberry pi running Jessie.
So far I have a startup bash script in /etc/init.d called startup.sh which contains
sudo python3 /home/pi/Desktop/Scripts/bluez3.py &
When the raspberry pi starts up, the script does run but after 20 minutes the script seems to stop. I have logging in my script and the time-stamp stops exactly 20 mins in.
I did some reading and I think the best option would be to create the python script as a service on the raspberry pi. However, I have not been able to find a decent tutorial about how to do this (and my lack of python knowledge).
My question is, is there another way to resolve my problem or does anyone know of a good tutorial on how to make the python script into a service.
Thanks!
given the name of your script, I'm guessing it's related to some bluetooth stuff. It's likely that after 20 min, whatever you're checking/needing in your script gets unaccessible and throws an exception or something like that. Like a resource being locked, or a bt device being disconnected or a module being unloaded or unavailable or [insert edge case reason here]…
that being said, in between creating a systemd service, you can first play with supervisorctl which is just an apt install supervisor away.
then if you really want to launch it as a service, you can find plenty of examples in /lib/systemd/system/*.service, like the following:
[Unit]
Description=Your service
Wants=
After=bluetooth.target # I guess you need bluetooth initialised first
[Service]
ExecStart=/usr/bin/python3 /home/pi/Desktop/Scripts/bluez3.py
ExecReload=/bin/kill -HUP $MAINPID
KillMode=process
Restart=always
[Install]
WantedBy=multi-user.target
which I customized from the sshd.service file 😉
I am a newcomer to Linux and Python and I am trying to attempt to stream an audio file (preferably MP3) from a Ubuntu source computer to a Raspberry Pi running Raspbian for immediate playback.
I have explored various options such as gStreamer, Live555, VLC player and PulseAudio. I have also investigated TCP, RTP and RTSP. However I am struggling to get anything working properly. It seems as though I need to set up a RTSP Server using the computer and the Raspberry Pi as a RTSP client and I am not sure how to do this.
I'm wondering if anyone has any simple instructions or guides as to how to set up even a basic version of this with a specific MP3 file?
You can use netcat and mplayer for this
In the Raspberry Pi
sudo apt-get install mplayer
nc -l -p 1234 | mplayer -cache 8192 -
In your PC
cat your.mp3 | nc [RASPI IP] 1234
It's very crude, however it's very easy. Just take care that you'll need to relaunch netcat (nc) from each side everytime you need to play a new MP3.
Cheers
Source: https://www.linuxquestions.org/questions/slackware-14/send-audio-over-network-888169/