<div dir="ltr"><br><div class="gmail_extra"><br>
<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br><div><div class="h5">><br>
>     PCM Devices which have the BATCH flag set update the PCM pointer only with<br>
>     period size granularity. Using timer based scheduling does not have any<br>
>     advantage in this mode. For one devices which have that flag set usually<br>
>     update<br>
>     the position pointer in software after getting the period interrupt. So<br>
>     disabling the period interrupt is not possible for this kind of devices.<br>
>     Furthermore writing to or reading from the buffer slice for the current<br>
>     period<br>
>     is not possible since the position inside the buffer is not known. On<br>
>     the other<br>
>     hand the tsched algorithm seems to get easily confused for this kind of<br>
>     hardware, which results in garbled audio output. This typically means<br>
>     that timer<br>
>     based scheduling needs to be manually disabled on systems with such devices.<br>
>     Auto disabling tsched in this case allows these systems to run with the<br>
>     default<br>
>     configuration.<br>
><br>
><br>
> If the playback position is reported in steps instead of monotonic increasing ?<br>
><br>
> does this mean that you also need to increase rewind_safeguard to one period<br>
> or modifiy snd_pcm_rewindable ?<br>
<br>
<br>
</div></div>Yes that makes sense. The safeguard should probably be 1.5 periods or 1<br>
period + fixed value, since it will always take some time from when the<br>
hardware reaches the next period to when userspace is notified about this.<br>
<br>
I'm unfortunately not that familiar with pulseaudio. Maybe there is a better<br>
way to fix this problem then to disable tsched. If anybody wants to recreate<br>
the issue it can easily be emulated by applying the following patch to your<br>
kernel:<br>
<br></blockquote><br></div>does all alsa drivers with SNDRV_PCM_INFO_PATCH update the playback/capture position in period interrupt ? <br><br></div><div class="gmail_extra">usb-audio seem update when each URB send/receive (in 1ms intervals)<br>
<br></div><div class="gmail_extra">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 <br><br></div><div class="gmail_extra">the rewind_safeguard is affected by the size of FIFO buffer as you cannot rewind any data in FIFO buffer of DSP/ sound controller<br>
</div><div class="gmail_extra"><br></div></div>