At Thu, 06 Sep 2007 16:30:17 +0200, Markus Korber wrote: > > Takashi Iwai schrieb: > > At Thu, 06 Sep 2007 07:52:37 +0200, > > Markus Korber wrote: > >> [...] > >> Now, what is an application allowed to send and what not? For example, > >> could an application only send 1024 l/r samples and is the driver > >> responsible for buffering the data? Or must it obey the announced > >> period_size and *always* provide 2048 l/r samples? > > > > No, as mentioned, the app is free to send any size in general. When > > the period size is filled up, basically it's supposed to be playable. > > But, the procedure "fill the whole buffer then start" is the most > > robust way. > > > > The period size is the minimal chunk size that controls the poll > > frequency. So, it's natural to send in this size. It's no > > requirement but a common use case. > > Thus, is it possible to buffer the data in ALSA before sending them to > the driver, in such a way, that the driver always receives period_size > samples, regardless of what the application sends to ALSA? And how > would I configure ALSA for such a setup? No, it's NOT guaranteed. The application may behave in a very wrong manner. The point is that it's driver's responsibility to check whether the data filled is OK or not. The ALSA framework is not a style like "fill -> wakeup -> process". Instead, the data transfer is done asynchronously, and the driver is woken up via irq (or whatever). Takashi _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
