<p><br>
> > >> > >> ><br>
> > >> > >> > below is what the terminate shows when running pcm_avail.c<br>
> > >> > >> ><br>
> > >> > >> > uid=0 gid=1007@nutshell:/ # alsactl_test<br>
> > >> > >> > min_period_size: 8 frames, dir: 0<br>
> > >> > >> > Playback hwparams: FIFO size is 8<br>
> > >> > >> > Hardware PCM card 0 'rsnd-dai.0-dirana3.0' device 0 subdevice 0<br>
> > >> > >> > Its setup is:<br>
> > >> > >> > stream : PLAYBACK<br>
> > >> > >> > access : RW_INTERLEAVED<br>
> > >> > >> > format : S16_LE<br>
> > >> > >> > subformat : STD<br>
> > >> > >> > channels : 2<br>
> > >> > >> > rate : 48000<br>
> > >> > >> > exact rate : 48000 (48000/1)<br>
> > >> > >> > msbits : 16<br>
> > >> > >> > buffer_size : 4096<br>
> > >> > >> > period_size : 1024<br>
> > >> > >> > period_time : 21333<br>
> > >> > >> > tstamp_mode : NONE<br>
> > >> > >> > period_step : 1<br>
> > >> > >> > avail_min : 1024<br>
> > >> > >> > period_event : 0<br>
> > >> > >> > start_threshold : 1024<br>
> > >> > >> > stop_threshold : 4096<br>
> > >> > >> > silence_threshold: 0<br>
> > >> > >> > silence_size : 0<br>
> > >> > >> > boundary : 1073741824<br>
> > >> > >> > appl_ptr : 0<br>
> > >> > >> > hw_ptr : 0<br>
> > >> > >> > Playing silence<br>
> > >> > >> > Available: 0, loop iteration: 0<br>
> > >> > >> > Available: 1024, loop iteration: 1469<br>
> > >> > >> > Available: 2048, loop iteration: 5609<br>
> > >> > >> > Available: 3072, loop iteration: 9667<br>
> > >> > >> ><br>
> > >> > >> > All I got is just the 4 lines.<br>
> > >> > >><br>
> > >> > >> If your sound card only increment hw_ptr only at interrupt occur, you<br>
> > >> > >> need to increase default_rewind_safeguard from 256 bytes to your<br>
> > >> > >> selected period size<br>
> > >> > ><br>
> > >> > ><br>
> > >> > > No. PulseAudio, in timer-scheduling mode, does not use periods at all. You need to change the driver so that it reports SNDRV_PCM_INFO_BATCH, so that PulseAudio does not try to use this mode.<br>
> > >> > ><br>
> > >> > ><br>
> > >> > >><br>
> > >> > >> This mean that your sound card won't work with timer scheduling or<br>
> > >> > >> dynamic latency, you can only archieve low latency by decrease period size<br>
> > >> > >> Why do pulseaudio enable timer scheduling when most sound card use IRQ ?<br>
> > >> > ><br>
> > >> > ><br>
> > >> > > Because most broken sound cards driver authors forget to report SNDRV_PCM_INFO_BATCH?<br>
> > >> ><br>
> > >> > Why pulseaudio rely on the flag if your program can find out the granulatity ?<br>
> > >><br>
> > >> AFAIK, there isn't a way to figure out granularity. Having this would be nice as we could be more intelligent about our tsched behaviour.<br>
> > ><br>
> > ><br>
> > > There is not only no way to query granularity, in some cases it is simply unknown. As for my approach (of measuring it directly), I currently think (but do not insist) that it is not suitable for inclusion into PulseAudio, because it is based on using a silent "test sound", busy-looping and repeatedly querying the position until it plays out. This would be unreliable if there is an unrelated CPU usage spike, and I think that busy-looping in general is not welcome.<br>
> ><br>
> > <a href="https://bugs.freedesktop.org/show_bug.cgi?id=86262#c19">https://bugs.freedesktop.org/show_bug.cgi?id=86262#c19</a><br>
> ><br>
> > Seem hwptr of snd-usb-audio are not that bad around 240 to 288 frames (less than period size) but not as good as snd-hda-intel 32 frames or oxygen 8 frames <br>
> ><br>
> > How accurate do pulseaudio need to use timer base scheduling ?<br>
><br>
> Our current safety margin on rewinds is 256 bytes or higher. If you can confirm the USB audio max update size as being in the few hundred frames range, we might be able to quirk this for now (till we have a better mechanism, as is being discussed on alsa-devel).<br></p>
<p>Do the result of those two usb audio devices mean that pcm_available.c need to use period time instead of period size for those usb audio and firewire ?</p>