3

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.

sinback
  • 926
  • 5
  • 17
Paul Wieland
  • 765
  • 2
  • 10
  • 29
  • 1
    Hm, interesting bug. I can't reproduce it with the hardware I have. I followed the directions in your repo on the host and within the container, on both my amd64 laptop and on a Raspberry Pi (which you said you were using). On both the laptop and the pi, I see identical behavior in the host and in the docker container. On the laptop, it sounds good with aplay and with pyaudio, but I see some warning messages printed to stdout when I use pyaudio. On the pi, it sounds good with aplay, sounds choppier but discernible with pyaudio, and there are more warning messages printed to stdout by pyaudio. – sinback Apr 07 '21 at 03:25
  • @SaraSinback Thank you for testing. What OS/version are you running on your Pi? What generation is the Pi? – Paul Wieland Apr 07 '21 at 15:37
  • 1
    Raspbian Stretch. The PCB says Raspberry Pi 3 Model B+. – sinback Apr 07 '21 at 15:43
  • btw, more trivia - on the laptop, I tested with both builtin speakers and the headphone jack - same behavior (makes sense, they surely use the same DAC). – sinback Apr 07 '21 at 15:49
  • It seems that only the Buster version of raspbian works with the rpi4 – Paul Wieland Apr 08 '21 at 15:25

2 Answers2

0

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.

sinback
  • 926
  • 5
  • 17
  • 1
    Thank you for your efforts! FWIW, I have now started testing PortAudio directly in the host to eliminate all factors related to python and docker. Turns out PortAudio has this huge delay when trying to stream audio from a file on a rpi4. Now I'm trying to figure out why. https://listserv.cuit.columbia.edu/scripts/wa.exe?A2=PORTAUDIO;643ac1b1.2104B&S= – Paul Wieland Apr 10 '21 at 16:55
-2

Instead of p = pyaudio.PyAudio() do p = pyaudio.init()

Fishy
  • 76
  • 7