I'm browsing through the backends, and it looks kind of inconsistent how we sometimes hand block_size or block_samples to read_data, and sometimes we pass it to the initialization?
Furthermore, def audio_open(path): doesn't take a block_size parameter, so users can't use it unless they use a backend directly.
I think we could improve the lib by adding block_size to audio_open. For the existing backends that have read_data(blocksize=*) we could still allow them to override blocksize on the read_data level. It shouldn't be breaking change if we do it this way.
Yep, this is a good idea too. It’s inconsistent because we didn’t previously consider this part of the “public” (cross-backend) interface. But with some thoughtful consideration, we can totally make it consistent.
I'm browsing through the backends, and it looks kind of inconsistent how we sometimes hand
block_size
orblock_samples
toread_data
, and sometimes we pass it to the initialization?Furthermore,
def audio_open(path):
doesn't take ablock_size
parameter, so users can't use it unless they use a backend directly.I think we could improve the lib by adding
block_size
toaudio_open
. For the existing backends that haveread_data(blocksize=*)
we could still allow them to override blocksize on the read_data level. It shouldn't be breaking change if we do it this way.