Pierre-Louis Bossart 於
2020年8月13日 週四 下午8:57寫道：
>
>
>
> On 8/13/20 3:45 AM, Takashi Iwai wrote:
> > On Thu, 13 Aug 2020 10:36:57 +0200,
> > Yu-Hsuan Hsu wrote:
> >>
> >> Lu, Brent 於 2020年8月13日 週四 下午3:55寫道：
> >>>
> >>
> >> CRAS calls snd_pcm_hw_params_set_buffer_size_max() to use as large
On 8/13/20 3:45 AM, Takashi Iwai wrote:
On Thu, 13 Aug 2020 10:36:57 +0200,
Yu-Hsuan Hsu wrote:
Lu, Brent 於 2020年8月13日 週四 下午3:55寫道：
CRAS calls snd_pcm_hw_params_set_buffer_size_max() to use as large
buffer as possible. So the period size is an arbitrary number in
different platforms.
On Thu, 13 Aug 2020 10:36:57 +0200,
Yu-Hsuan Hsu wrote:
>
> Lu, Brent 於 2020年8月13日 週四 下午3:55寫道：
> >
> > > > >
> > > > > CRAS calls snd_pcm_hw_params_set_buffer_size_max() to use as large
> > > > > buffer as possible. So the period size is an arbitrary number in
> > > > > different platforms.
Lu, Brent 於 2020年8月13日 週四 下午3:55寫道：
>
> > > >
> > > > CRAS calls snd_pcm_hw_params_set_buffer_size_max() to use as large
> > > > buffer as possible. So the period size is an arbitrary number in
> > > > different platforms. Atom SST platform happens to be 256, and CML
> > > > SOF platform is 1056
> > >
> > > CRAS calls snd_pcm_hw_params_set_buffer_size_max() to use as large
> > > buffer as possible. So the period size is an arbitrary number in
> > > different platforms. Atom SST platform happens to be 256, and CML
> > > SOF platform is 1056 for example.
> >
> > ok, but earlier in this
Pierre-Louis Bossart 於
2020年8月13日 週四 上午12:38寫道：
>
>
>
> On 8/12/20 11:08 AM, Lu, Brent wrote:
> >>>
> >>> I also wonder what's really missing, too :)
> >>>
> >>> BTW, I took a look back at the thread, and CRAS seems using a very
> >>> large buffer, namely:
> >>> [ 52.434791] sound pcmC1D0p:
On 8/12/20 11:08 AM, Lu, Brent wrote:
I also wonder what's really missing, too :)
BTW, I took a look back at the thread, and CRAS seems using a very
large buffer, namely:
[ 52.434791] sound pcmC1D0p: PERIOD_SIZE [240:240]
[ 52.434802] sound pcmC1D0p: BUFFER_SIZE [204480:204480]
> >
> > I also wonder what's really missing, too :)
> >
> > BTW, I took a look back at the thread, and CRAS seems using a very
> > large buffer, namely:
> > [ 52.434791] sound pcmC1D0p: PERIOD_SIZE [240:240]
> > [ 52.434802] sound pcmC1D0p: BUFFER_SIZE [204480:204480]
>
> yes, that's 852
On 8/12/20 9:55 AM, Takashi Iwai wrote:
On Wed, 12 Aug 2020 16:46:40 +0200,
Pierre-Louis Bossart wrote:
After doing some experiments, I think I can identify the problem more precisely.
1. aplay can not reproduce this issue because it writes samples
immediately when there are some space in
On Wed, 12 Aug 2020 16:46:40 +0200,
Pierre-Louis Bossart wrote:
>
>
> >> After doing some experiments, I think I can identify the problem more
> >> precisely.
> >> 1. aplay can not reproduce this issue because it writes samples
> >> immediately when there are some space in the
After doing some experiments, I think I can identify the problem more precisely.
1. aplay can not reproduce this issue because it writes samples
immediately when there are some space in the buffer. However, you can
add --test-position to see how the delay grows with period size 256.
aplay
On Wed, 12 Aug 2020 09:43:22 +0200,
Yu-Hsuan Hsu wrote:
>
> Takashi Iwai 於 2020年8月12日 週三 下午2:58寫道：
> >
> > On Wed, 12 Aug 2020 08:53:42 +0200,
> > Yu-Hsuan Hsu wrote:
> > >
> > > Takashi Iwai 於 2020年8月12日 週三 下午2:14寫道：
> > > >
> > > > On Wed, 12 Aug 2020 05:09:58 +0200,
> > > > Yu-Hsuan Hsu
Takashi Iwai 於 2020年8月12日 週三 下午2:58寫道：
>
> On Wed, 12 Aug 2020 08:53:42 +0200,
> Yu-Hsuan Hsu wrote:
> >
> > Takashi Iwai 於 2020年8月12日 週三 下午2:14寫道：
> > >
> > > On Wed, 12 Aug 2020 05:09:58 +0200,
> > > Yu-Hsuan Hsu wrote:
> > > >
> > > > Mark Brown 於 2020年8月12日 週三 上午1:22寫道：
> > > > >
> > > > >
On Wed, 12 Aug 2020 08:53:42 +0200,
Yu-Hsuan Hsu wrote:
>
> Takashi Iwai 於 2020年8月12日 週三 下午2:14寫道：
> >
> > On Wed, 12 Aug 2020 05:09:58 +0200,
> > Yu-Hsuan Hsu wrote:
> > >
> > > Mark Brown 於 2020年8月12日 週三 上午1:22寫道：
> > > >
> > > > On Tue, Aug 11, 2020 at 11:54:38AM -0500, Pierre-Louis Bossart
Takashi Iwai 於 2020年8月12日 週三 下午2:14寫道：
>
> On Wed, 12 Aug 2020 05:09:58 +0200,
> Yu-Hsuan Hsu wrote:
> >
> > Mark Brown 於 2020年8月12日 週三 上午1:22寫道：
> > >
> > > On Tue, Aug 11, 2020 at 11:54:38AM -0500, Pierre-Louis Bossart wrote:
> > >
> > > > > constraint logic needs to know about this DSP
On Wed, 12 Aug 2020 05:09:58 +0200,
Yu-Hsuan Hsu wrote:
>
> Mark Brown 於 2020年8月12日 週三 上午1:22寫道：
> >
> > On Tue, Aug 11, 2020 at 11:54:38AM -0500, Pierre-Louis Bossart wrote:
> >
> > > > constraint logic needs to know about this DSP limitation - it seems like
> > > > none of this is going to
Mark Brown 於 2020年8月12日 週三 上午1:22寫道：
>
> On Tue, Aug 11, 2020 at 11:54:38AM -0500, Pierre-Louis Bossart wrote:
>
> > > constraint logic needs to know about this DSP limitation - it seems like
> > > none of this is going to change without something new going into the
> > > mix? We at least need a
On Tue, Aug 11, 2020 at 11:54:38AM -0500, Pierre-Louis Bossart wrote:
> > constraint logic needs to know about this DSP limitation - it seems like
> > none of this is going to change without something new going into the
> > mix? We at least need a new question to ask about the DSP firmware I
> >
... Why only 240? That's the next logical question.
If you have a clarification for it, it may be the rigid reason to
introduce such a hw constraint.
According to Brent, the DSP is using 240 period regardless the
hw_param. If the period size is 256, DSP will read 256 samples each
time but
On Tue, Aug 11, 2020 at 05:35:45PM +0800, Yu-Hsuan Hsu wrote:
> Takashi Iwai 於 2020年8月11日 週二 下午4:39寫道：
> > ... Why only 240? That's the next logical question.
> > If you have a clarification for it, it may be the rigid reason to
> > introduce such a hw constraint.
> According to Brent, the DSP
Takashi Iwai 於 2020年8月11日 週二 下午4:39寫道：
>
> On Tue, 11 Aug 2020 10:25:22 +0200,
> Yu-Hsuan Hsu wrote:
> >
> > Takashi Iwai 於 2020年8月11日 週二 下午3:43寫道：
> > >
> > > On Tue, 11 Aug 2020 04:29:24 +0200,
> > > Yu-Hsuan Hsu wrote:
> > > >
> > > > Lu, Brent 於 2020年8月11日 週二 上午10:17寫道：
> > > > >
> > > > >
On Tue, 11 Aug 2020 10:25:22 +0200,
Yu-Hsuan Hsu wrote:
>
> Takashi Iwai 於 2020年8月11日 週二 下午3:43寫道：
> >
> > On Tue, 11 Aug 2020 04:29:24 +0200,
> > Yu-Hsuan Hsu wrote:
> > >
> > > Lu, Brent 於 2020年8月11日 週二 上午10:17寫道：
> > > >
> > > > >
> > > > > Sorry for the late reply. CRAS does not set the
Takashi Iwai 於 2020年8月11日 週二 下午3:43寫道：
>
> On Tue, 11 Aug 2020 04:29:24 +0200,
> Yu-Hsuan Hsu wrote:
> >
> > Lu, Brent 於 2020年8月11日 週二 上午10:17寫道：
> > >
> > > >
> > > > Sorry for the late reply. CRAS does not set the period size when using
> > > > it.
> > > > The default period size is 256,
On Tue, 11 Aug 2020 04:29:24 +0200,
Yu-Hsuan Hsu wrote:
>
> Lu, Brent 於 2020年8月11日 週二 上午10:17寫道：
> >
> > >
> > > Sorry for the late reply. CRAS does not set the period size when using it.
> > > The default period size is 256, which consumes the samples quickly(about
> > > 49627
> > > fps when
Lu, Brent 於 2020年8月11日 週二 上午10:17寫道：
>
> >
> > Sorry for the late reply. CRAS does not set the period size when using it.
> > The default period size is 256, which consumes the samples quickly(about
> > 49627
> > fps when the rate is 48000 fps) at the beginning of the playback.
> > Since CRAS
>
> Sorry for the late reply. CRAS does not set the period size when using it.
> The default period size is 256, which consumes the samples quickly(about 49627
> fps when the rate is 48000 fps) at the beginning of the playback.
> Since CRAS write samples with the fixed frequency, it triggers
Pierre-Louis Bossart 於
2020年8月10日 週一 下午11:03寫道：
>
>
>
> On 8/6/20 11:41 AM, Lu, Brent wrote:
> >>
> >> I don't get this. If the platform driver already stated 240 and 960
> >> samples why
> >> would 432 be chosen? Doesn't this mean the constraint is not applied?
> >
> > Hi Pierre,
> >
> > Sorry
On 8/6/20 11:41 AM, Lu, Brent wrote:
I don't get this. If the platform driver already stated 240 and 960 samples why
would 432 be chosen? Doesn't this mean the constraint is not applied?
Hi Pierre,
Sorry for late reply. I used following constraints in V3 patch so any period
which
aligns
>
> I don't get this. If the platform driver already stated 240 and 960 samples
> why
> would 432 be chosen? Doesn't this mean the constraint is not applied?
Hi Pierre,
Sorry for late reply. I used following constraints in V3 patch so any period
which
aligns 1ms would be accepted.
+ /*
On 8/3/20 11:33 PM, Lu, Brent wrote:
For avoid further misunderstanding: it's fine that CRAS *uses* such a short
period. It's often required for achieving a short latency.
However, the question is whether the driver can set *only* this value for
making it working. IOW, if we don't have
>
> For avoid further misunderstanding: it's fine that CRAS *uses* such a short
> period. It's often required for achieving a short latency.
>
> However, the question is whether the driver can set *only* this value for
> making it working. IOW, if we don't have this constraint, what actually
>
On Mon, 03 Aug 2020 18:45:29 +0200,
Lu, Brent wrote:
>
> > > Hi Takashi,
> > >
> > > I've double checked with google. It's a must for Chromebooks due to
> > > low latency use case.
> >
> > I wonder if there's a misunderstanding here?
> >
> > I believe Takashi's question was "is this a must to
> > Hi Takashi,
> >
> > I've double checked with google. It's a must for Chromebooks due to
> > low latency use case.
>
> I wonder if there's a misunderstanding here?
>
> I believe Takashi's question was "is this a must to ONLY accept 240 samples
> for the period size", there was no pushback on
On 8/3/20 8:00 AM, Lu, Brent wrote:
Again, is this fixed 240 is a must? Or is this also an alignment issue?
Hi Takashi,
I think it's a must for Chromebooks. Google found this value works
best with their CRAS server running on their BSW products. They
offered this patch for their own
> > >
> > > Again, is this fixed 240 is a must? Or is this also an alignment issue?
> > Hi Takashi,
> >
> > I think it's a must for Chromebooks. Google found this value works
> > best with their CRAS server running on their BSW products. They
> > offered this patch for their own Chromebooks.
>
>
On Sat, 01 Aug 2020 10:58:16 +0200,
Lu, Brent wrote:
>
> >
> > Again, is this fixed 240 is a must? Or is this also an alignment issue?
> Hi Takashi,
>
> I think it's a must for Chromebooks. Google found this value works best
> with their CRAS server running on their BSW products. They offered
>
> Again, is this fixed 240 is a must? Or is this also an alignment issue?
Hi Takashi,
I think it's a must for Chromebooks. Google found this value works best
with their CRAS server running on their BSW products. They offered this
patch for their own Chromebooks.
>
>
> thanks,
>
> Takashi
On Fri, 31 Jul 2020 14:26:05 +0200,
Brent Lu wrote:
>
> From: Yu-Hsuan Hsu
>
> The CRAS server does not set the period size in hw_param so ALSA will
> calculate a value for period size which is based on the buffer size
> and other parameters. The value may not always be aligned with Atom's
>
From: Yu-Hsuan Hsu
The CRAS server does not set the period size in hw_param so ALSA will
calculate a value for period size which is based on the buffer size
and other parameters. The value may not always be aligned with Atom's
dsp design so a constraint is added to make sure the board always has
39 matches
Mail list logo
