From mboxrd@z Thu Jan 1 00:00:00 1970 From: James Courtier-Dutton Subject: ALSA sample rate conversion and general performance improvements. Date: Wed, 29 Mar 2006 00:24:20 +0100 Message-ID: <4429C5A4.7@superbug.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-path: Sender: alsa-devel-admin@lists.sourceforge.net Errors-To: alsa-devel-admin@lists.sourceforge.net List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , List-Archive: To: alsa-devel List-Id: alsa-devel@alsa-project.org 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