[alsa-devel] Proposal for more reliable audio DMA.

[Jon Smirl]

On Wed, Jun 24, 2009 at 12:28 PM, Mark
Brown<broonie at opensource.wolfsonmicro.com> wrote:
> On 24 Jun 2009, at 17:07, Jon Smirl <jonsmirl at gmail.com> wrote:
>
>> Trying to directly expose the ring buffer to the app seems like a good
>>
>> way to avoid a copy, but it isn't achieving that. pulse is not
>> decoding audio straight into the ring buffer, it decodes first and
>> then copies into the buffer. Pulse is using the timers to estimate the
>> destination for the copy.  Move this copy down into the drivers, the
>> drivers know the correct destination for the copy.
>
> Pulse isn't just doing straight playback, a large part of what it's there
> for is to do software mixing. When you have multiple sources active pulse is
> going to be forced to do the copy as part of the mixing process so putting
> that bit of the buffer management in kernel won't help in the way you think
> it does. Part of what's going on here is that the kernel code is trying to
> give userspace access to the data for as long as possible.
>

Does this work as a use case?

Pulse is playing music in the background.  A game want to do a laser blast.

Pulse has already sent a buffer into kernel for the background music.
Pulse makes a new buffer that contains the background mixed with the laser.
It sends this new buffer into the kernel and says play with minimum latency.

The problem is knowing which sample in the background music to start
mixing the low latency laser blast into. ALSA will need to know this
index to figure out where to switch onto the replacement buffer. This
offset is dynamic and it depends on how much work pulse is doing.

So you need two things. An estimate of the current playing sample and
an estimate of the system latency to know where to start mixing.

Estimating the current sample can be done accurately by using a high
frequency, free running counter. Drift can be compensated for by
recording the count when the hardware accurately knows what sample it
is on. Knowing how many samples to delay before mixing is a function
of app latency and it needs to be measured in a feedback loop.

I'm starting to think the OSS model is right and mixing belongs in the kernel

-- 
Jon Smirl
jonsmirl at gmail.com