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
