On Wed, Jul 29, 2020 at 1:31 AM Pierre-Louis Bossart
wrote:
>
>
>
> On 7/28/20 12:02 PM, Lu, Brent wrote:
> >>
> >> So if there are already quirks in atom machine drivers to change the period
> >> size, why is this patch necessary?
> >>
> >
> > The story is: google implemented the constraint but
On 7/28/20 12:02 PM, Lu, Brent wrote:
So if there are already quirks in atom machine drivers to change the period
size, why is this patch necessary?
The story is: google implemented the constraint but doesn't know why it works
so asked us to explain. After checking the two counters I
>
> So if there are already quirks in atom machine drivers to change the period
> size, why is this patch necessary?
>
The story is: google implemented the constraint but doesn't know why it works
so asked us to explain. After checking the two counters I realized the increase
of
ring buffer
On 7/27/20 9:28 PM, Lu, Brent wrote:
All the Atom firmware assumes data chunks in multiples of 1ms (typically 5,
10 or 20ms). I have never seen anyone use 256 frames, that's asking for
trouble really.
it's actually the same with Skylake and SOF in most cases.
Is this a 'real' problem or a
>
> All the Atom firmware assumes data chunks in multiples of 1ms (typically 5,
> 10 or 20ms). I have never seen anyone use 256 frames, that's asking for
> trouble really.
>
> it's actually the same with Skylake and SOF in most cases.
>
> Is this a 'real' problem or a problem detected by the
On 7/26/20 11:08 AM, Brent Lu wrote:
The ring buffer counter runs faster than hardware counter if the
period size in hw_param is larger than 240. Although the differce is
not much (around 2k frames), it causes false underrun in CRAS
sometimes because it's using 256 frames as period size in
6 matches
Mail list logo
