On 9 June 2015 at 12:38, Raymond Yau <superquad.vortex2 at gmail.com> wrote: >> > >> > >> >> > >> >> > >> > >> > >> > below is what the terminate shows when running pcm_avail.c >> > >> > >> > >> > uid=0 gid=1007 at nutshell:/ # alsactl_test >> > >> > min_period_size: 8 frames, dir: 0 >> > >> > Playback hwparams: FIFO size is 8 >> > >> > Hardware PCM card 0 'rsnd-dai.0-dirana3.0' device 0 subdevice 0 >> > >> > Its setup is: >> > >> > stream : PLAYBACK >> > >> > access : RW_INTERLEAVED >> > >> > format : S16_LE >> > >> > subformat : STD >> > >> > channels : 2 >> > >> > rate : 48000 >> > >> > exact rate : 48000 (48000/1) >> > >> > msbits : 16 >> > >> > buffer_size : 4096 >> > >> > period_size : 1024 >> > >> > period_time : 21333 >> > >> > tstamp_mode : NONE >> > >> > period_step : 1 >> > >> > avail_min : 1024 >> > >> > period_event : 0 >> > >> > start_threshold : 1024 >> > >> > stop_threshold : 4096 >> > >> > silence_threshold: 0 >> > >> > silence_size : 0 >> > >> > boundary : 1073741824 >> > >> > appl_ptr : 0 >> > >> > hw_ptr : 0 >> > >> > Playing silence >> > >> > Available: 0, loop iteration: 0 >> > >> > Available: 1024, loop iteration: 1469 >> > >> > Available: 2048, loop iteration: 5609 >> > >> > Available: 3072, loop iteration: 9667 >> > >> > >> > >> > All I got is just the 4 lines. >> > >> >> > >> If your sound card only increment hw_ptr only at interrupt occur, you >> > >> need to increase default_rewind_safeguard from 256 bytes to your >> > >> selected period size >> > > >> > > >> > > 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. >> > > >> > > >> > >> >> > >> This mean that your sound card won't work with timer scheduling or >> > >> dynamic latency, you can only archieve low latency by decrease period >> > >> size >> > >> Why do pulseaudio enable timer scheduling when most sound card use >> > >> IRQ ? >> > > >> > > >> > > Because most broken sound cards driver authors forget to report >> > > SNDRV_PCM_INFO_BATCH? >> > >> > Why pulseaudio rely on the flag if your program can find out the >> > granulatity ? >> >> 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. >> > > But in this case, alecandra `s program already indicate hw_ptr only > increment by period size which is not suitable to enable timer base > scheduling There are two cases: the first is that pointer updates happen at period size, which should imply the BATCH flag, and we just disable timer-based scheduling. The second case is that the pointer changes at some granularity >1 byte and we need to know what that value is to set up the sleep time and rewind safeguard etc. correctly if the value isn't "too high". > The result also indicate pulseaudio have to change default rewind safeguard > > What granularity do pulseaudio need for timer base scheduling ? Currently, it's what HDA gives us (which is byte-level precision?) > (e.g. sound card must report position better than 10ms processing time) It'll probably work for < rewind safety margin (the tsched sleep threshold is even larger). But that's a matter of luck, rather than being intentionally supported.
