[pulseaudio-discuss] snd_pcm_avail no reliable

[Arun Raghavan]

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.