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.
In kernel sources, sound/pci/hda/hda_controller.c mentions SNDRV_PCM_INFO_BLOCK_TRANSFER. However, sub-period rewinds work fine on this driver, and the avail granularity is something like 64 bytes.
This is hardware specific feature which is essential for timer based scheduling.
Even snd-usb-audio use a default number of packets for larger period size, it is still need to change to use small period size for lowest latency
snd-hda-intel also set has .periods_max=32 which force driver not to use small period size when application use maximum buffer size , it still cannot adjust latency dynamically
HDA is a very typical PCI controller; if this flag were correct here, pretty much _every_ driver would need it.
Well, there are more PCI drivers with this flag than without it. So it
looks like a "typical error".
aep@aep-haswell /usr/src/linux/sound $ grep -l
SNDRV_PCM_INFO_BLOCK_TRANSFER `grep -rl SNDRV_PCM_INFO_MMAP_VALID pci` | wc -l
48 aep@aep-haswell /usr/src/linux/sound $ grep -L
SNDRV_PCM_INFO_BLOCK_TRANSFER `grep -rl SNDRV_PCM_INFO_MMAP_VALID pci` | wc -l
15
I guess I should write a program that tests sub-period rewinds and post
it to the list.
Some (older) HDA controllers have problems with position reporting (with workarounds in the drivers), but those problems are with the timing, not with the granularity.
As far as I can see, snd-hda-intel should just drop this flag.
http://lxr.free-electrons.com/ident?i=SNDRV_PCM_INFO_BLOCK_TRANSFER
SNDRV_PCM_INFO_BLOCK_TRANSFER is not present in those ISA sound cards which use io ports to transfer data
Why do alsa-time-test.c use
if (cap == 0) r = snd_pcm_sw_params_set_avail_min(pcm, swparams, 1); else r = snd_pcm_sw_params_set_avail_min(pcm, swparams, 0); assert(r == 0);
What is oss wakeup point ?
snd_pcm_sw_params_set_avail_min
This is similar to setting an OSS wakeup point. The valid values for 'val' are determined by the specific hardware. Most PC sound cards can only accept power of 2 frame counts (i.e. 512, 1024, 2048).
Why sw_params use hardhware specific value ?
Can this value set to grsnularity which is smaller than period size since the function silently force avail_min not less than period size ?