ALSA sample rate conversion and general performance improvements.

[James Courtier-Dutton <James@superbug.co.uk>]

Hi,

I have had some conversations with various people regarding some general
problems some audio developers have with the current ALSA sound model.
One of the biggest problems with the current ALSA model is the sample
rate converters. When discussing them here some time ago, the problem
centered around the need for a timer interrupt being needed for the
application period boundaries, where the hardware might be running at
48000Hz, and the application is trying to play a 44100Hz PCM stream.
This is essentially needed so that the poll() calls work in the
application correctly.

Here is an idea on how to fix it and also slightly improve performance.
Some general aims:
1) any ioport access to the sound card is slow and should be avoided
whenever possible.
2) where to get the 44100Hz timer from if the hardware is doing 48000Hz.

What about doing the following?:
We implement a general timer in the alsa core based on something like
gettimeofday(). I.e A high resolution timer.
Each time a period interrupt happens, the current hw pointer is read,
and recorded along with the current value of the timer.
This could be used a bit like NTP to correct the generally timer rate.
This gives us a general high resolution timer corrected to mirror the
PCM clock on the sound card.
Then, from this high resolution timer, we could derive any rate
interrupt we need for really excellent sample rate conversion, and sub
sample accurate DAC/ADC positioning.
One could then read the DAC/ADC positioning really quickly by just
reading the high resolution timer, instead of accessing IO Ports on the
sound card hardware.
This would also be a fairly minor change, as none of the current kernel
sound card hw drivers would need changing. We would just have to
slightly modify the period_elapsed callback to do a gettimeofday() call
as well as it's current hw_pointer read.

If we then made the correction factor for the high resolution timer
available to user space, user space would then not even need to read the
current hw position, as it could perfectly predict it itself using the
gettimeofday() and correction factor.

This would reduce the amount of calls to the read_hw_pointer function in
the low level sound card hardware driver, and therefore improve performance.

Any comments?

James


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642