Re: Proposal: new audio framework

[Tetsuya Isaki <isaki%pastel-flower.jp@localhost>]

Hi,

At Mon, 1 Apr 2019 03:24:15 -0400,
Michael wrote:
> > There is one thing I'm worried about.  AUDIO2 requires more strict
> > blocksize and buffersize for hardware drivers.  It will be a hard
> > work if there are any hardware that does not satisfy the requirements.
> > # Although I believe there are no such hardware...
> 
> What exactly are those requirements? IIRC dbri has a rather weird
> maximum block size:
> static int
> dbri_round_blocksize(void *hdl, int bs, int mode,
> 			const audio_params_t *param)
> {
> 
> 	/*
> 	 * DBRI DMA segment size can be up to 0x1fff, sizes that are not powers
> 	 * of two seem to confuse the upper audio layer so we're going with
> 	 * 0x1000 here
> 	 */
> 	return 0x1000;
> }
> 
> That said, I'll take care of potential fallout with the dbri driver.

Thank you.

If your hardware can accept arbitrary size up to 0x1fff as in the
comment, please rewrite it as follows:

  dbri_round_blocksize(..., int bs, ...)
  {
    if (bs > 0x1fff)
      return 0x1fff;
    return bs;
  }

In dbri, slinear/16bit/2ch/48000Hz looks like the largest case.
The blocksize at this case is
2(16bits) * 2(channels) * 48000(Hz) * 0.04 (40msec block in default)
= 7680 bytes.  It is less than 0x1fff and it will work.


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. :(

Thanks,
---
Tetsuya Isaki <isaki%pastel-flower.jp@localhost / isaki%NetBSD.org@localhost>