[pulseaudio-discuss] snd_pcm_avail no reliable

[golden]

  Thanks all,

    Finally I`m using this way to get the available frames:

      static int32_t audio_pcm_avail(ni_mediahal_audio_dev_type type)
     {
         snd_pcm_sframes_t av1 = snd_pcm_avail(pcm);
         snd_pcm_uframes_t av2 = 0;
         snd_htimestamp_t ht;
         int err = snd_pcm_htimestamp(pcm, &av2, &ht);
         struct timespec t;
         clock_gettime(CLOCK_MONOTONIC, &t);
         int64_t curTime = (int64_t) (t.tv_sec) * 1000000000LL + t.tv_nsec;
         int64_t alsaTime = (int64_t) (ht.tv_sec) * 1000000000LL + 
ht.tv_nsec;
         //LOG_AUDIOIO("av1=%d, av2=%u, curTime=%lld, alsaTime=%lld 
err=%d", av1, av2, curTime, alsaTime, err);
         double timeDiff = (double)(curTime - alsaTime) * 0.000000001;
         int32_t diffFrames = (int32_t)(timeDiff * 
audio_dev_params[type].rate);
         //LOG_AUDIOIO("timeDiff=%g, frameDiff=%d, rate=%d", timeDiff, 
diffFrames, audio_dev_params[type].rate);
         if (diffFrames >= (int)audio_dev_params[type].period_size) {
             diffFrames = 0;
         }
         return av1 + diffFrames;
     }

     get the diff time of current time and alsa timestamp, than caculate 
the diff frames with sample rate.


在 2015年06月10日 19:42, Raymond Yau 写道:
>
>
> >> >
> >> > >>
> >> > >>
> >> > >>  >
> >> > >>  >   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.
> >
> >
> > 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.
>
> https://bugs.freedesktop.org/show_bug.cgi?id=86262#c19
>
> 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
>
> How accurate do pulseaudio need to use timer base scheduling ?
>
>
>
> _______________________________________________
> pulseaudio-discuss mailing list
> pulseaudio-discuss at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/pulseaudio-discuss/attachments/20150612/9bbaaa8b/attachment.html>