[pulseaudio-discuss] [RFC PATCH] alsa-sink: Reduce hardware pointer update syscalls

[Laurențiu Nicola]

If nobody tried it, I might test the patch on my USB DAC. The problem is
that I'm not sure what's the best way to benchmark the playback. Do you
have some tips on that?

Laurentiu

On Mon, Sep 29, 2014, at 15:16, David Henningsson wrote:
> 
> 
> On 2014-09-26 23:20, Pierre-Louis Bossart wrote:
> > On 9/24/14, 1:17 AM, David Henningsson wrote:
> >>
> >>
> >> On 2014-09-23 22:34, Pierre-Louis Bossart wrote:
> >>> On 9/18/14, 2:13 AM, David Henningsson wrote:
> >>>> Calling snd_pcm_avail/delay causes a syscall to the kernel, which
> >>>> communicates with the audio hardware, and can therefore be expensive
> >>>> on some cards.
> >>>>
> >>>> By only updating this value after a sleep and after unusual events,
> >>>> we can reduce calls to update the hardware pointer.
> >>>> In particular, if a write goes well, we will now assume that the
> >>>> buffer has been filled up, instead of re-asking the hardware that
> >>>> this is actually the case.
> >>>
> >>> You can reduce the number of syscall by using snd_pcm_status, which
> >>> provides all the information at once. I thought I contributed a patch
> >>> for this long back.
> >>
> >> I believe that patch is in - pa_alsa_safe_delay uses snd_pcm_status
> >> internally. But there are other calls as well, one to pa_alsa_safe_avail
> >> and the other one just to get a timestamp.
> >>
> >>> Making assumptions on how the write went is problematic in my opinion,
> >>> and there can be a case where you want to write more data while awake if
> >>> there is enough room. Maybe this ought to be split in two parts for
> >>> testing/bisecting.
> >>
> >> When the code decides to fill up, it's always less than half in the
> >> buffer and it fills it completely up.
> >>
> >> If filling up the buffer itself takes so long time that the buffer
> >> becomes more than half empty, then we have serious issues anyway (and in
> >> extension, the risk of us being killed for spending too much time in RT
> >> context seems pretty high).
> >>
> >> Or, if I'm misunderstanding you, could you give a real world example
> >> where it would be important to continue writing even though the buffer
> >> was successfully filled up?
> >
> > It's the same issues as with rewinds. You think you filled up the buffer
> > 'successfully', but you don't control the hardware. by the time you
> > finish generating all the data needed the hardware might have consumed
> > some samples, your buffer is no longer full, therefore your sleep time
> > is no longer accurate.
> 
> Ah, now I get it - the problem is not that the buffer might become half 
> empty, the problem is that you might estimate to sleep too long, so your 
> process time is effectively cut in half: if you previously had problems 
> with process times > 20 ms, you can now potentially have problems with 
> process times > 10 ms.
> 
> I doubt this is a blocker, as this will resolve itself naturally since 
> the potential underruns that might occur will just cause the process 
> time to increase, but it's a very valid point and worthy some thought in 
> case this patch will ever be v2.
> 
> (Still waiting for somebody to report back that it's actually making a 
> difference - otherwise I won't fix anything that isn't broken.)
> 
> -- 
> David Henningsson, Canonical Ltd.
> https://launchpad.net/~diwic
> _______________________________________________
> pulseaudio-discuss mailing list
> pulseaudio-discuss at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss