Got it! Thank you very much. There are many drivers has this problem. yuhsuan On Sat, Aug 4, 2018 at 2:31 AM Takashi Iwai <tiwai@xxxxxxx> wrote: > On Fri, 03 Aug 2018 19:24:05 +0200, > Yu-hsuan Hsu wrote: > > > > Sorry for my unclear question. The device usually provide the range of > > period_size to us, such as 16 to 1024 (We can get it from > > snd_pcm_hw_params_get_period_size_min and max). It means we can choose > > period_size 16 for this hardware device. However, the device only > consumes > > 40 frames at each time. > > It only issue IRQ after it consumes 40 frames. My > > question is, whether it can support period_size 16 as it said? Or it need > > to change the range of period_size it provides. > > In that case, allowing period_size = 16 is obviously wrong. > The practical minimum of period size is 40. This must be set up via > either snd_pcm_hardware or some hw_constraints. > > > Takashi > > > > > Thank you for your patience and assistance. > > > > yuhsuan > > > > > > On Fri, Aug 3, 2018 at 6:14 PM Takashi Iwai <tiwai@xxxxxxx> wrote: > > > > > On Fri, 03 Aug 2018 12:04:34 +0200, > > > Yu-hsuan Hsu wrote: > > > > > > > > For example, we can set period_size 32 to one device. But the device > > > > consumes 40 frames each time. Can we said it support period_size 32? > I > > > > found many devices have this situation. > > > > > > The question remains: how can the hardware issue an IRQ of period size > > > 32 while it can consume 40 frames at each time? > > > > > > As you asked in the first post, the period size is the size where the > > > hardware notifies the update. Your description above doesn't match > > > with the definition... > > > > > > > > > Takashi > > > > > > > > > > > On Fri, Aug 3, 2018 at 4:30 PM Takashi Iwai <tiwai@xxxxxxx> wrote: > > > > > > > > > On Fri, 03 Aug 2018 10:09:30 +0200, > > > > > Yu-hsuan Hsu wrote: > > > > > > > > > > > > Thank for your answer! > > > > > > > > > > > > The other question is if we set period_size to N, but the frames > it > > > > > > consumes once is 5N. > > > > > > > > > > Then the assumption is wrong. How the hardware can issue an IRQ > at N > > > > > consumption while it processes for 5N in once? > > > > > > > > > > > > > > > Takashi > > > > > > > > > > > Can it said it supports period_size N? How do we check > > > > > > whether the period_size can be set correctly? > > > > > > > > > > > > On Fri, Aug 3, 2018 at 3:31 PM Takashi Iwai <tiwai@xxxxxxx> > wrote: > > > > > > > > > > > > > On Fri, 03 Aug 2018 08:28:37 +0200, > > > > > > > Yu-hsuan Hsu wrote: > > > > > > > > > > > > > > > > Hi all, > > > > > > > > > > > > > > > > I have a question about the period we set in hw_params. I > found > > > > > different > > > > > > > > boards may have different explanations about it. I have two > > > guesses > > > > > about > > > > > > > > its meaning. > > > > > > > > > > > > > > > > 1. The period_size is the size of each hardware's > consumption. > > > If we > > > > > set > > > > > > > > period size to N, the pcm will consume N frames each time. > > > > > > > > > > > > > > > > 2. The period_size is the size to control when hardware call > > > > > interrupt. > > > > > > > If > > > > > > > > we set period size to N, the pcm consume frames in its step. > > > When the > > > > > > > > number of frames it consumes more than N, it will call > interrupt. > > > > > > > > > > > > > > 2 is the correct answer. > > > > > > > > > > > > > > > > > > > > > HTH, > > > > > > > > > > > > > > Takashi > > > > > > > > > > > > > > > We can use snd_pcm_avail function to check the real available > > > frames > > > > > in > > > > > > > > the device. If guess 1 is correct, the size of consumption > > > should be > > > > > > > fixed. > > > > > > > > Else, setting period_size is nothing to do with hardware's > > > > > > > > consumption. I've checked some boards and found that each > board > > > has > > > > > > > > different behavior (Most of them meet guess 2). I'm confuse > which > > > > > one is > > > > > > > > correct. Thanks! > > > > > > > > _______________________________________________ > > > > > > > > Alsa-devel mailing list > > > > > > > > Alsa-devel@xxxxxxxxxxxxxxxx > > > > > > > > http://mailman.alsa-project.org/mailman/listinfo/alsa-devel > > > > > > > > > > > > > > > > > > > > > [2 <text/html; UTF-8 (quoted-printable)>] > > > > > > > > > > > > > > > [2 <text/html; UTF-8 (quoted-printable)>] > > > > > > > > > [2 <text/html; UTF-8 (quoted-printable)>] > > > _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
