At Tue, 04 Mar 2014 15:20:08 +0100, David Henningsson wrote: > > So, PulseAudio removed timer scheduling for drivers with > SNDRV_PCM_INFO_BATCH, and released 5.0. Meanwhile, USB drivers still > have SNDRV_PCM_INFO_BATCH, so this leads to performance regressions for > USB sound cards. > > The question remains - what does SNDRV_PCM_INFO_BATCH really mean? > > In the documentation, we have this: > "int snd_pcm_hw_params_is_batch (const snd_pcm_hw_params_t *params) > Check, if hardware does double buffering for data transfers for given > configuration." > > What PulseAudio was looking for was more something like "what accuracy > does the pointer callback give us". When we asked this question at the > latest audio meeting, SNDRV_PCM_INFO_BATCH was given as the answer, i e, > if this flag is set, pointer callback have no more accuracy than period > boundaries. At least that's how I understood it. > > So, either the documentation for snd_pcm_hw_params_is_batch is correct, > in which case PulseAudio should revert the tsched patch. Or the answer > given at the audio meeting was correct, in which case we need to fix the > USB driver to stop sending the SNDRV_PCM_INFO_BATCH flag. The flag is being used in the sense explained in the previous audio meeting -- the data transfer granularity isn't fine enough but aligned to the period size (or less). So its meaning is more generic, and the double-buffer is one of such cases. And, it's correct to set this flag for USB-audio. USB-audio can't transfer the data contiguously but only via packets, thus the update granularity is also limited. Although it can provide the actual played position as "delay", the point where you can write the data (i.e. avail) is updated only in period size order. Takashi
