On Tue, 2 Apr 2019 at 08:11, Tetsuya Isaki <[email protected]> wrote: > Here is details: > > On -current, as you know, blocksize are decided as follows: > 1. audio layer selects some size and ask it to hardawre driver. > This is round_blocksize interface. > 2. if hardware driver cannot accept the size (for example, DMA > restrictions), hardware driver returns desired new size. > 3. audio layer accepts it unconditionally. > > Due to Step3's behavior and rumors (or obsoleted restriction?) that > block size must be a power of two, many drivers return the different > size even if proposed size is acceptable. > > AUDIO2 internal takes a block-oriented strategy, not a bytestream- > oriented, for performance and simplicity. > So, AUDIO2 changed it as follows: > a1. audio layer calculates suitable blocksize from its hardware > precision(stride), channels, frequency and blk_ms (= block > length in msec) parameters. > a2. and then ask it to hardware driver. It's round_blocksize. > a3. But if the hardware driver returns the other size, audio layer > cannot accept it because proposed size was calculated from > hardware encoding. > At the moment, I have no good idea for this case. :(
If the various hardware restrictions are simple enough that they could be encoded as a small struct - eg boolean power_of_two; unsigned int min_size; unsigned int max_size; then would it be reasonable for AUDIO2 to request the restrictions from the driver and adjust blk_ms or other parameters until it finds a fit?
