PCM Devices which have the BATCH flag set update the PCM pointeronly with
period size granularity. Using timer based scheduling does not haveany
advantage in this mode. For one devices which have that flag setusually
update the position pointer in software after getting the period interrupt.So
disabling the period interrupt is not possible for this kind ofdevices.
Furthermore writing to or reading from the buffer slice for thecurrent
period is not possible since the position inside the buffer is not known. On the other hand the tsched algorithm seems to get easily confused for this kindof
hardware, which results in garbled audio output. This typically means that timer based scheduling needs to be manually disabled on systems with suchdevices.
Auto disabling tsched in this case allows these systems to run withthe
default configuration.If the playback position is reported in steps instead of monotonic
increasing ?
does this mean that you also need to increase rewind_safeguard to one
period
or modifiy snd_pcm_rewindable ?
Yes that makes sense. The safeguard should probably be 1.5 periods or 1 period + fixed value, since it will always take some time from when the hardware reaches the next period to when userspace is notified about this.
I'm unfortunately not that familiar with pulseaudio. Maybe there is a better way to fix this problem then to disable tsched. If anybody wants to recreate the issue it can easily be emulated by applying the following patch to your kernel:
does all alsa drivers with SNDRV_PCM_INFO_PATCH update the playback/capture position in period interrupt ?
usb-audio seem update when each URB send/receive (in 1ms intervals)
ymfpci driver also update hwptr in 5ms interval but no SNDRV_PCM_INFO_PATCH and no constraint in period time must be interval of 5 ms
the rewind_safeguard is affected by the size of FIFO buffer as you cannot rewind any data in FIFO buffer of DSP/ sound controller