Hi all
I tried using a smaller period_size (about 1/16 of hwbuf_size),
snd_pcm_avail returned a better value.
But cpu usage moved from 1% to 4%, since we are using it in a
automotive, we don`t care about power saving, I think it is acceptable.
But I`m not sure if there is any other down side about "time based
scheduling" ?
BR,
Lixin
å?¨ 2015å¹´06æ??09æ?¥ 15:15, 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.
> _______________________________________________
> pulseaudio-discuss mailing list
> pulseaudio-discuss at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
