[Portaudio] Poor latency with PulseAudio via ALSA using PortAudio

[Dmitry Kostjuchenko]

Hello RJ,

As promissed I came up with a new revised solution for an Alsa interface regarding non-MMAPed hardcoded host 
buffer size. 

So in patest_sine I achieved good latency which is correctly set to the device now. While studying Alsa code I 
found out that latency calculations were depending on user buffer size!!! that is incorrect and setting latency 
wouldn't lead to a real result due to these wrong calculations.

So I arrived to something like that for example:
PaAlsaStreamComponent_InitialConfigure: device MMAP SND_PCM_ACCESS_MMAP_INTERLEAVED: NO
PaAlsaStreamComponent_InitialConfigure: device MMAP SND_PCM_ACCESS_MMAP_NONINTERLEAVED: NO
PaAlsaStreamComponent_InitialConfigure: device can MMAP: NO
PaAlsaStreamComponent_DetermineFramesPerBuffer: frames per user-buffer     = 64
PaAlsaStreamComponent_DetermineFramesPerBuffer: suggested latency          = 0.004000
PaAlsaStreamComponent_DetermineFramesPerBuffer: suggested host buffer size = 176
PaAlsaStreamComponent_DetermineFramesPerBuffer: device period minimum      = 16
PaAlsaStreamComponent_DetermineFramesPerBuffer: device period maximum      = 174763
PaAlsaStreamComponent_DetermineFramesPerBuffer: host buffer period         = 48
PaAlsaStream_Configure: Playback period size: 48, latency: 0.004354

As you can see setting suggested latency from outside to for example 4ms leads to a 4.354ms actual device 
latency. I used forward aligning to 16 bytes for the host buffer, thus these 0.354ms were added.

PaAlsaStreamComponent_InitialConfigure: device MMAP SND_PCM_ACCESS_MMAP_INTERLEAVED: NO
PaAlsaStreamComponent_InitialConfigure: device MMAP SND_PCM_ACCESS_MMAP_NONINTERLEAVED: NO
PaAlsaStreamComponent_InitialConfigure: device can MMAP: NO
PaAlsaStreamComponent_DetermineFramesPerBuffer: frames per user-buffer     = 64
PaAlsaStreamComponent_DetermineFramesPerBuffer: suggested latency          = 1.004000
PaAlsaStreamComponent_DetermineFramesPerBuffer: suggested host buffer size = 44276
PaAlsaStreamComponent_DetermineFramesPerBuffer: device period minimum      = 16
PaAlsaStreamComponent_DetermineFramesPerBuffer: device period maximum      = 174763
PaAlsaStreamComponent_DetermineFramesPerBuffer: host buffer period         = 11072
PaAlsaStream_Configure: Playback period size: 11072, latency: 1.004263

Here I set latency to 1.004 seconds and got 1.004263 seconds of actual device latency. User buffer in these 2 
examples is the same - 64 frames.

All this will affect MMAPed devices as well.

I guess now PA Alsa interface behaves as per PA's specification. Also tested patest_read_write_wire, it works ok 
as well.

Could you please carry out test with Mixxx to check if all works well and you get correct latency set and etc. Then 
I will commit a patch to PA SVN with changes.

Patched file here: http://rapidshare.com/files/394460335/pa_linux_alsa.zip.html

Would appreciate your kind feedback.

Best regards,
Dmitry.
 
Quoting RJ Ryan <rryan at mit.edu>:
> Hello all, 

> I'm a developer for Mixxx and I've noticed an issue with the ALSA backend. When I use the 'pulse' device that is 
a fake ALSA device which uses PulseAudio, the latency that I achieve is very high compared to my normal ALSA 
device. I looked into the code and found these lines in pa_linux_alsa.c: 

> /* non-mmap mode needs a reasonably-sized buffer or it'll stutter */ 
> if( !self->canMmap && framesPerHostBuffer < 2048 ) 
>     framesPerHostBuffer = 2048; 

> So even when Mixxx was requesting host buffer sizes lower than 2048, it was being reset to 2048. At 44.1khz, 
this results in a minimum latency of 46ms, which produces a very poor user experience for us. When I remove 
these lines, the 'pulse' ALSA device performs very well and a latency of 2ms is easily achievable by my modest 
Core 2 Duo laptop CPU and integrated sound card. Additionally, this allows us to integrate well with standard Linux 
desktop distributions which use PulseAudio, where otherwise we had to suggest the use of pasuspender to 
achieve good latency. Does anybody have any insight to why the 'pulse' device does not stutter at low frames-per-
buffer, despite not being an mmap-able device?  

> Thanks, 
> RJ Ryan 



-------------------------
iAuxSoft: Middleware SDK
[http://www.iauxsoft.com]