在树莓派上使用python捕获音频失败

Question

I am currently working on an easy-to-use audio capturing device for digitizing old casette tapes (ie low fidelity). This device is based on a raspberry pi with an usb sound card, which does nothinge else than starting the listed python script on bootup.

import alsaaudio
import wave
import os.path
import RPi.GPIO as GPIO
import key
import usbstick
import time

try:
    # Define storage
    path = '/mnt/usb/'
    prefix = 'Titel '
    extension = '.wav'

    # Configure GPIOs
    GPIO.setmode(GPIO.BOARD)
    button_shutdown = key.key(7)
    button_record = key.key(11)
    GPIO.setup(12, GPIO.OUT)
    GPIO.setup(15, GPIO.OUT)
    GPIO.output(12, GPIO.HIGH)

    # Start thread to detect external memory
    usb = usbstick.usbstick(path, 13)

    # Configure volume
    m = alsaaudio.Mixer('Mic', 0, 1)
    m.setvolume(100, 0, 'capture')

    # Only run until shutdown button gets pressed
    while not (button_shutdown.pressed()):

        # Only record if record button is pressed and memory is mounted
        if (button_record.pressed() and usb.ismounted()):

            # Create object to read input
            inp = alsaaudio.PCM(alsaaudio.PCM_CAPTURE, alsaaudio.PCM_NORMAL, 'sysdefault:CARD=Device')
            inp.setchannels(1)
            inp.setrate(44100)
            inp.setformat(alsaaudio.PCM_FORMAT_S16_LE)
            inp.setperiodsize(1024)

            # Find next file name
            i = 0
            filename = ''
            while (True):
                i += 1
                filename = path + prefix + str(i) + extension
                if not (os.path.exists(filename)):
                    break
            print 'Neue Aufnahme wird gespeichert unter ' + filename

            # Create wave file
            wavfile = wave.open(filename, 'w')
            wavfile.setnchannels(1)
            wavfile.setsampwidth(2)
            wavfile.setframerate(44100)

            # Record sound
            while (button_record.pressed()):
                l, data = inp.read()
                wavfile.writeframes(data)
                GPIO.output(15, GPIO.HIGH)

            # Stop record an save
            print 'Aufnahme beendet\n'
            inp.close()
            wavfile.close()
            GPIO.output(15, GPIO.LOW)

        # Record has been started but no memory is mounted
        elif (button_record.pressed() and not usb.ismounted()):
            print 'Massenspeichergeraet nicht gefunden'
            print 'Warte auf Massenspeichergeraet'

            # Restart after timeout 
            timestamp = time.time()
            while not (usb.ismounted()):
                if ((time.time() - timestamp) > 120):
                    time.sleep(5)
                    print 'Timeout.'
                    #reboot()
                    #myexit()

            print 'Massenspeichergeraet gefunden'
    myexit()

except KeyboardInterrupt:
    myexit()

According to the documentation pyaudio, the routine inp.read() or alsaaudio.PCM.read() respectively should usually wait until a full period of 1024 samples has been captured. It then should return the number of captured samples as well as the samples itself. Most of the time it returns exactly one period of 1024 samples. I don't think that I have a performance problem, since I would expect it to return several periods then.

THE VERY MYSTERIOUS BEHAVIOR: After 01:30 of recording, inp.read() takes some milliseconds longer than normal to process (this is a useful information in my ignorant opinion) and then returns -32 and faulty data. Then the stream continues. After half a minute at 02:00 it takes about a second (ie longer than the first time) to process and returns -32 and faulty data again. This procedere repeats then every minute (02:30-03:00, 03:30-04:00, 04:30-05:00). This timing specification was roughly taken by hand.

-32 seems to result from the following code line in /pyalsaaudio-0.7/alsaaudio.c

return -EPIPE;

Some words about how this expresses: If the data stream is directly written into the wave file, ie including the faulty period, the file contains sections of white noise. These sections last 30 seconds. This is because the samples usually consist of 2 bytes. When the faulty period (1 byte) is written, the byte order gets inverted. With the next faulty period it gets inverted again and therefore is correct. If faulty data is refused and only correct data is written into the wave file, the file 'jumps' every 30 seconds.

I think the problem can either be found in 1. the sound card (but I tested 2 different) 2. the computing performance of the raspberry pi 3. the lib pyaudio

Further note: I am pretty new to the linux and python topic. If you need any logs or something, please describe how I can find them.

To cut a long story short: Could someone please help me? How can I solve this error?

EDIT: I already did this usb firmware updating stuff, which is needed, since the usb can be overwhelmed. BTW: What exactly is this EPIPE failure?

Answer 1

Upon further inverstigation, I found out, that this error is not python/pyaudio specific. When I try to record a wave file with arecord , I get the following output. The overrun messages are sent according to the timing described above.

    pi@raspberrypi ~ $ sudo arecord -D sysdefault:CARD=Device -B buffersize=192000 -f cd -t wav /mnt/usb/test.wav
Recording WAVE '/mnt/usb/test.wav' : Signed 16 bit Little Endian, Rate 44100 Hz, Stereo
overrun!!! (at least -1871413807.430 ms long)
overrun!!! (at least -1871413807.433 ms long)
overrun!!! (at least -1871413807.341 ms long)
overrun!!! (at least -1871413807.442 ms long)

Referring to this thread at raspberrypi.org , the problem seems to be the (partly) limited write speed to the SD card or the usb storage device with a raspberry pi. Recording to RAM (with tmpfs) or compressing the audio data (eg to mp3 with lame) before writing it somewhere else could be a good solution in some cases.

I can't say why the write speed is to low. In my opinion, the data stream is 192 kByte/s for 48 kSamples/s, 16 Bit, stereo. Any SD card or usb mass storage should be able to handle this. As seen above, buffering the audio stream doesn't help.