Program hangs when overflow/underflow

[fakufaku]

Hello,
I am trying to run sounddevice on the beaglebone black board. I use the code below to test feedthrough. However, when the latency is set to low, or the buffer size is small, the program just hangs, rather than dropping a few frames and continuing. There is no error message either. Can I do something about it ?

Thanks you in advance.

import sys 
import sounddevice as sd
duration = 10  # seconds

import numpy as np
from scipy.signal import lfilter

sd.default.channels = (2,2)
sd.default.device = (0, 1)
sd.default.samplerate = 48000
sd.default.dtype = ('int16','int16')
sd.default.never_drop_input = False
sd.default.latency = ('low','low')
sd.default.blocksize = 0 

def callback(indata, outdata, frames, time, status):
    if status:
        print(status)

    outdata[:] = indata

with sd.Stream(callback=callback):
    try:
        while True:
        sd.sleep(1000)
    except KeyboardInterrupt:
        print("Interrupted, how rude!")
    except Exception:
        traceback.print_exc(file=sys.stdout)
    sys.exit(1)

[fakufaku]

After some more test, the problem does not occur so fast if I do not specify the devices and the sampling rate, and specify the latency in seconds (e.g. 0.02 s). It still occurs after sometimes.
Also, after the program hangs, then I can see that CPU usage for python goes to 100%.

Also, when setting explicitly the buffer size

sd.default.blocksize = 512

for example, then the audio is very choppy.

[mgeier]

Hmmm ... I don't really have a clue ...

When you are working close to the limits of the hardware, strange things might happen, in that case you normally just have to choose more conservative settings.
But you're right, hanging with maxed out CPU is a particularly bad behavior, hopefully this can be somewhat improved.

But first we'll have to find where and how this is happening.
You are saying that the Python process is generating 100% load, but since there is no tight loop in my code, I suspect that the callback is just called too often. Or there is some synchronization problem between the callback and the main Python thread?

Can you probably add some debugging to your callback?
I think it could be interesting to show frames, outdata.shape and indata.shape.

Any other ideas?

[mgeier]

BTW, you don't have to specify the options twice if they are the same. Instead of

sd.default.dtype = 'int16', 'int16'

you can just use

sd.default.dtype = 'int16'

[fakufaku]

Hi thanks for the answer.

Actually it seems I can make it work by cranking up the frequency of the CPU to 1GHz and recompiling the latest version of portaudio.

Another quick quick question, is it possible to have different sampling rates for the input and output ?

[mgeier]

Actually it seems I can make it work by cranking up the frequency of the CPU to 1GHz and recompiling the latest version of portaudio.

It's good to hear that it works.
In general, it would be more revealing if you change only one thing at a time.
Could you try the two things separately?

is it possible to have different sampling rates for the input and output ?

This is a general PortAudio question, nothing specific to the sounddevice module.

Each "stream" can only have one sampling rate.
If you want your application to be portable, you should only use one stream at a time.
If not, you can try to open two streams at the same time, one for input and one for output.
This may or may not work, depending on your system configuration and the used host API.
You may or may not be able to use different sample rates in this case.
If you use two different streams, they will not be synchronized, so you will have to take care of any buffering that will be necessary to send audio from one stream to another. If you don't do that, you'll have drop-outs at some point.