Glitch on macbook with m1 processor

[dryarullin]

I have two macbooks, one with an intel processor and the other with M1 processor. I am using a standard microphone. Sounddevice shows with the standard microphone in both cases a sample rate of 44100 and a block size of 512 (blocksize=0). But in the case of a MacBook on the M1 processor, I have a glitch effect. The glitch disappeared when I manually set the block size to 4096. What are the best practices for choosing the block size?

[mgeier]

In many cases, the defaults should be fine, but sadly there is no guarantee. Sometimes you have to find the best settings by trial and error. If you don't mind the latency, a conservative setting would be latency=0.1, which I think is also used by Audacity (you can keep blocksize=0).

However, there might also be some improvements possible in the underlying PortAudio library, especially when dealing with newer hardware. This cannot be done on the Python side, you should ask the PortAudio maintainers: http://portaudio.com/contacts.html.

[dryarullin]

@mgeier Thank you. But why, for example, does Zoom not have such problems? Their interface doesn't allow such settings. I understand that they use other frameworks, maybe it's their own development. Do you have any idea how they do it?

[weirenlan]

@dryarullin Sorry, could I ask you how do you successfully install sounddevice at M1 mac

I met a problem with MemoryError: Cannot allocate write+execute memory for ffi.callback(). You might be running on a system that prevents this. How did you solve this problem

[HaHeho]

@weirenlan see #397 (there seems to be a currently hacky way to get it to work on M1).

[mgeier]

@dryarullin

But why, for example, does Zoom not have such problems?

I don't know, because I don't have access to their implementation nor to its documentation, it's a proprietary closed-source product.

But I can guess: there is a huge number of hardware out there, and testing all of it in all configurations is simply impossible. But testing more is of course better than testing less.
And maybe the Zoom engineers have tested the hardware you are using and the PortAudio contributors haven't?
Or maybe the Zoom engineers have just been lucky to choose some parameters that happen to work with that given piece of hardware.

I'm sure this problem can in principle be fixed, and a first step would be making the PortAudio developers aware of it. There is nothing that can be done about it here, in the python-sounddevice project.