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.
+ /* + * Make sure the period to be multiple of 1ms to align the + * design of firmware. Apply same rule to buffer size to make + * sure alsa could always find a value for period size + * regardless the buffer size given by user space. + */ + snd_pcm_hw_constraint_step(substream->runtime, 0, + SNDRV_PCM_HW_PARAM_PERIOD_SIZE, 48); + snd_pcm_hw_constraint_step(substream->runtime, 0, + SNDRV_PCM_HW_PARAM_BUFFER_SIZE, 48);
Regards, Brent
[ 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