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

[David Henningsson]

On 2014-10-01 17:11, Peter Meerwald wrote:
> Hello,
>
>> 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.
>
> here is my benchmarking, I'm not super-confident in the results
>
> similar to Alexander, I am seeing an assertion immediately:
> pulseaudio[2071]: Assertion 'frames > 0' failed at modules/alsa/alsa-sink.c:651, function mmap_write(). Aborting.


Sorry for the long delay,

I've been trying to figure out why this assertion happens, but I'm not 
sure why.

> not loading the suspend-on-idle module didn't help, instead I patched
> -            if (!after_avail && frames == 0)
> +            if (frames == 0)
>                   break;
> immediately before the assert(); not sure if this is correct
>
> snd_pcm_mmap_begin() which is called by pa_alsa_safe_mmap_begin()
> explicitly states that frames may be set to 0 if no buffer is full -- so I
> think 0 should NOT lead to an assertion

Agreed; anything ALSA returns, sensible or not, should not lead to 
assertions. If not sensible we should try to recover or something else. 
So I also think the assertion is wrong.

The question is how the buffer can be full in this case, because we're 
after_avail, which means that we just checked avail and noticed that 
there was enough space to write something.

> I don't understand the meaning of after_avail; in
> if (!after_avail && (int) sframes == -EAGAIN)
> down a few lines, after_avail is always false!?

That indeed looks like a bug.

> anyway, above patch might have fixed the issue and I was able to do some
> measurements on a beagleboard (ARMv7, OMAP3, TPS65950 PMIC audio),
> Linux kernel 3.7 and PA shortly before the srbchannel patches...
>
> I am using htop and look at the CPU% for the alsa-sink thread while doing
> paplay -v -v --latency-msec=20 audio_at_32KHz.wav (hardware is doing 32KHz
> as well, so no resampling)
>
> --latency-msec influences the measurement I lot, I think lower values are
> more interesting, using 20msec to stress the CPU a bit
>
> without the patch, I get about 17% CPU
> with the patch, I get about 15.8% CPU
>
> using perf top -p <pid of alsa-sink thread> when playing back for 10sec or
> so:
>
> with patch:
>       3.22%  [kernel]               [k] snd_pcm_status
>
> without patch:
>       3.95%  [kernel]               [k] snd_pcm_hwsync

Interesting. Since the number of calls for every wakeup should be at 
least cut in half, this indicates that a single call to snd_pcm_status 
is more expensive than a call to snd_pcm_hwsync.

> an observation: the latency as reported by paplay fluctuates more with the
> patch than without, but no hard numbers (yet)

Interesting, there shouldn't be much difference here either.

As pulseaudio likes to change latency itself sometimes, are you sure 
that the resulting ALSA sink latency remained the same during all times 
(no dump up due to underruns, or similar)?

-- 
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic