SNDRV_PCM_INFO_BATCH

SNDRV_PCM_INFO_BATCH

[David Henningsson]

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.

-- 
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic

Re: SNDRV_PCM_INFO_BATCH

[Takashi Iwai]

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

Re: SNDRV_PCM_INFO_BATCH

[Clemens Ladisch]

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?

For your purposes, it means that the pointer accuracy is likely to be
worse than that of other sound cards.

There should be a mechanism to report the actual granularity.


Regards,
Clemens