> > 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 > > > >
