Re: [PATCH v3 2/2] ASoC: Intel: Add period size constraint on strago board

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





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 this constraint, what actually
happens?  If the driver gives the period size alignment, wouldn't CRAS
choose 240?

It won't. Without the constraint it becomes 432. Actually CRAS does not set
period size specifically so the value depends on the constraint rules.

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?

[   52.011146] sound pcmC1D0p: hw_param
[   52.011152] sound pcmC1D0p:   ACCESS 0x1
[   52.011155] sound pcmC1D0p:   FORMAT 0x4
[   52.011158] sound pcmC1D0p:   SUBFORMAT 0x1
[   52.011161] sound pcmC1D0p:   SAMPLE_BITS [16:16]
[   52.011164] sound pcmC1D0p:   FRAME_BITS [32:32]
[   52.011167] sound pcmC1D0p:   CHANNELS [2:2]
[   52.011170] sound pcmC1D0p:   RATE [48000:48000]
[   52.011173] sound pcmC1D0p:   PERIOD_TIME [9000:9000]
[   52.011176] sound pcmC1D0p:   PERIOD_SIZE [432:432]
[   52.011179] sound pcmC1D0p:   PERIOD_BYTES [1728:1728]
[   52.011182] sound pcmC1D0p:   PERIODS [474:474]
[   52.011185] sound pcmC1D0p:   BUFFER_TIME [4266000:4266000]
[   52.011188] sound pcmC1D0p:   BUFFER_SIZE [204768:204768]
[   52.011191] sound pcmC1D0p:   BUFFER_BYTES [819072:819072]
[   52.011194] sound pcmC1D0p:   TICK_TIME [0:0]

Regards,
Brent



Takashi





[Index of Archives]     [ALSA User]     [Linux Audio Users]     [Pulse Audio]     [Kernel Archive]     [Asterisk PBX]     [Photo Sharing]     [Linux Sound]     [Video 4 Linux]     [Gimp]     [Yosemite News]

  Powered by Linux