Re: Proposal: new audio framework

[David Brownlee <abs%absd.org@localhost>]

On Tue, 2 Apr 2019 at 08:11, Tetsuya Isaki <isaki%pastel-flower.jp@localhost> 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?