[alsa-devel] PulseAudio and SNDRV_PCM_INFO_BATCH

[Raymond Yau]

>>
>> Hi folks,
>> I'd like to bring this one up again, since we are currently in the
>> sub-optimal position of forcing ~100 ms latency on USB devices. The
>> original thread is here --
>>
http://mailman.alsa-project.org/pipermail/alsa-devel/2013-December/069666.html
>>
>> I see two flags that are possibly of consequence here:
>> SNDRV_PCM_INFO_BATCH and SNDRV_PCM_INFO_BLOCK_TRANSFER. I'm not sure
>> what these mean -- the documentation mentions "double buffering" for
>> the batch flag, and just that the block transfer means "block
>> transfer". :-)
>>
>> We've spoken about batch meaning either transfers in period size
>> chunks, or some fixed chunk size. It seems that it would make more
>> sense for it to mean the former, and block transfer to mean the
>> latter.
>>
>> So I guess the first thing that would be nice to have is a clear
>> meaning of these two flags. With this done, we could potentially get
>> to the API to report the transfer size from the driver.
>
>
> Yeah, the meaning of those flags is somewhat fuzzy and may have changed
over time as well. Here is my understanding of the flags, might not
necessarily be 100% correct.
>
> SNDRV_PCM_INFO_BLOCK_TRANSFER means that the data is copied from the user
accessible buffer in blocks of one period. Typically these kinds of devices
have some dedicated audio memory that is not accessible via normal memory
access and a DMA is setup to copy data from main memory to the dedicated
memory. This DMA transfers the data from the main memory to the dedicated
memory in chunks of period size. But otherwise the controller might still
be capable of reporting a accurate pointer position down to the
sample/frame level.
>
> So SNDRV_PCM_INFO_BLOCK_TRANSFER is mainly important for rewind handling
and devices with that flag set might need additional headroom since the
data up to one period after the pointer position has already been copied to
the dedicated memory and hence can no longer be overwritten.
>
> SNDRV_PCM_INFO_BATCH on the other hand has become to mean that the device
is only capable of reporting the audio pointer with a coarse granularity.
Typically this means a period sized granularity, but there are some other
cases as well.
>

DSP_CAP_REALTIME bit tells if the device/operating system supports precise
reporting of output pointer position using SNDCTL_DSP_GETxPTR. Precise
means that accuracy of the reported playback pointer (time) is around few
samples. Without this capability the playback/recording position is
reported using precision of one fragment.

DSP_CAP_BATCH bit means that the device has some kind of local storage for
recording and/or playback. For this reason the information reported by
SNDCTL_DSP_GETxPTR is very inaccurate.

Are those alsa cap have the similar meaning of those oss cap ?