Playing audio from Python freezes RP!

[Tom Swirly]

Hello, Berry-people. (Rasp heads?)

Is anyone successfully using Python for audio on the Raspberry Pi?

I'm interested in doing Python development on the RP but I'm running into an interesting issue where the unit freezes(!) when I actually try to write audio data to the audio card.

I have successfully run e.g. aplay /usr/share/sounds/alsa/Front_Center.wav and heard the sound come out of the headphone jack (as I assigned it) so I'm fairly sure the unit is set up correctly for sound.

However, in Python the unit becomes unresponsive when try to output audio. I should add that I'm doing all my development through ssh into the "box", I don't know if the unit is unresponsive to its keyboard if it were plugged in... but all my ssh connections freeze and I can't even ping the unit any more.

Here's the code:

Code: Select all

#!/usr/bin/python

import ossaudiodev
import sys
import wave

def play(filename):
  print "opening file"
  sound_file = wave.open(filename,'rb')

  print "getting parameters"
  (nc, sw, fr, nf, comptype, compname) = sound_file.getparams()

  print "parameters were",  (nc, sw, fr, nf, comptype, compname)
  print "opening audio"
  sound = ossaudiodev.open('w')

  print "setting parameters"
  sound.setparameters(ossaudiodev.AFMT_S16_NE, nc, fr)

  print "readframes"
  data = sound_file.readframes(nf)

  print "closing file"
  sound_file.close()

  print "writing data"
  sound.write(data)

  # Never gets here, freezes on the previous line.
  print "closing sound device"
  sound.close()

if __name__ == '__main__':
  if len(sys.argv) is 2:
    play(sys.argv[1])
  else:
    print 'Usage: %s filename' % sys.argv[0]

Note that I've checked to see that ossaudiodev.AFMT_S16_NE is a supported output format for the RP - and anyway, Python throws an exception if you use an unsupported type (I tried that to make sure).

Thanks in advance!

[kasbah]

Sounds a bit like a memory issue. Can you monitor the available memory while it runs? Have you tried with a smaller WAV file?

[fdion]

You are reading the whole .wav file in memory and then passing that whole huge block to the oss write. You need to chunk the file, read a buffer, say, 64kb at a time and play that.

[khulat]

I can get sound, as long as i modprobe snd-pcm-oss before i try it. The problem is that after the file has played or if i try to cancel with Ctrl-c i get a kernel oops message. I have tried it with your code and with modified code that buffered the file, both show the same problem.

Here is a "screenshot" of the oops message:

[khulat]

Workaround time:
If you install pulseaudio and pulseaudio-utils you get padsp which is a wrapper for oss. You can then run your program with

Code: Select all

padsp python program.py track.wav

which at least for me works without the kernel failure. The modprobe is also unnecessary with this workaround.

Edit:
If you want to buffer the wav file here is how i did it:

Code: Select all

#!/usr/bin/python

import ossaudiodev
import sys
import wave

def play(filename):
    try:
      print "opening file"
      sound_file = wave.open(filename,'rb')

      print "getting parameters"
      (nc, sw, fr, nf, comptype, compname) = sound_file.getparams()

      print "parameters were",  (nc, sw, fr, nf, comptype, compname)
      print "opening audio"
      sound = ossaudiodev.open('w')

      print "setting parameters"
      sound.setparameters(ossaudiodev.AFMT_S16_NE, nc, fr)

      print "readframes"
      data = sound_file.readframes(65536)
      while data:
        sound.write(data)
        data = sound_file.readframes(65536)
      
      sound.flush()
      sound.sync()

	except IOError, e:
      print str(e)

	finally:
      print "closing file"
      sound_file.close()

      print "closing sound device"
      sound.close()

if __name__ == '__main__':
  if len(sys.argv) is 2:
    play(sys.argv[1])
  else:
    print 'Usage: %s filename' % sys.argv[0]

[dom]

I think this is the same issue:
https://github.com/raspberrypi/linux/issues/122

[Tom Swirly]

Wow, walk away for a while and come back and all this activity!

I was pretty sure it wasn't memory issues, because I'm using a tiny .wav file to test - a real program will have to buffer the code (good example above!) I'm believing it's perhaps the bug that dom references - I have an extremely fresh kernel so I would have that problem. The explanation of the bug makes it pretty clear what's happening...

I'm going to try the pulseaudio solution and see if that works but since this seems to be a clear bug that's on the bug list, I have some hope that I can eventually wait!

Thanks for all your excellent suggestions - it's really nice to have other people to try things out against.

[Tom Swirly]

Bingo, using khulat's padsp workaround worked right the first time with exactly the same code and data file.

This provides me with a good workaround for right now. In the long term I need to get better temporal precision than ossaudiodev anyway...