Re: Proposal: new audio framework

[Michael <macallan%netbsd.org@localhost>]

Hello,

On Tue, 02 Apr 2019 16:10:58 +0900
Tetsuya Isaki <isaki%pastel-flower.jp@localhost> wrote:

> 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;
>   }

Will do.

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

Ok.

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

The power-of-two thing was my guess, it used to return 0x1ffc so each
block would contain only whole 16bit/stereo samples. Not sure if the
hardware ( specifically, the codec ) actually needs that, the docs are
kinda fuzzy and the chip is primarily an ISDN controller. When things
changed the last time around this stopped working, 0x1000 did work, so
I left it at that.

> 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 for the explanation, I will adapt and report back.

have fun
Michael