[alsa-devel] Master Plan on rewinding

Alexander E. Patrakov patrakov at gmail.com
Sun Sep 21 11:22:42 CEST 2014


18.09.2014 07:15, Raymond Yau wrote:
>
>  > > >
>  > > >>> What remains not fully understood for me is the claim that the
>  > > >>> information already exposed by every driver (in the form of the
> minimal
>  > > >>> period size) is not useful. I understand that two people are
> against
>  > > >>> this idea, so it must be bad. But I must understand why. Is it
> because
>  > > >>> the minimum period size reported by some drivers (which ones are
>  > > >>> suspected, if any?) may be a lie?
>
> Does this mean the granularity of most drivers are only one period since
> most of them cannot reporte the dma position in realtime  ?

I guess you are right.

>
> (e.g. pointer callback of Intel8x0 use a timeout loop to read the last
> valid index)
>
>    The safeguard will be two periods

Here I don't see how that can be right. Even if the position is updated 
at each period interrupt, we always know which period is currently 
playing. So the theoretical minimum safeguard is exactly one period. Add 
1 ms on top if you want to account for scheduler glitches.

>
> If some HDA have FIFO size of 192 bytes which is more than the minimum
> period bytes
>
> Should we limit the start threshold to FIFO threshold or FIFO size ?

I think that in this case it is a bug to report such small minimum 
period size.

> Does it need Brust length = 1 for those hda controller to support
> arbitrary period size ?
>
> Seem only some hda controller can trigger DMA transfer at 1/3 or 2/3
> FIFO buffer at different power states and report the dma position in
> pointer callback

I am not a specialist in HDA hardware.

> Does snd-oxygen provide this position with granularity which is less
> than the minimum period size ?

I have a friend with a Xonar card, will ask him to perform a test for 
you when he appears online.

-- 
Alexander E. Patrakov


More information about the Alsa-devel mailing list