[alsa-devel] Hidden rate conversion, and Alsa configuration

stan stanl at cox.net
Fri Jul 27 22:48:11 CEST 2007

On Fri, 27 Jul 2007 22:16:44 +0200 (CEST)
Jaroslav Kysela <perex at suse.cz> wrote:

> On Fri, 27 Jul 2007, stan wrote:
> > I really want to avoid rate resampling if I can, while format
> > conversion has to occur somewhere in order to match the hardware in
> > most cases.  I assume that any format conversion alsa does
> > is at least as good as one I would do myself.  While the rate
> Not really. If application knows all things, the final code might be
> much more optimized. Alsa-lib has all plugins universal (thus mostly 
> unoptimized). For example - attenuation + sample conversion can be 
> implemented together, but alsa-lib has two plugins - it means two 
> iteration over same data.

I'll have to do some thinking about the tradeoffs of coding time against
throughput optimization.
> > resampling can introduce throughput issues and inaccuracies in the
> > sound stream.
> I answered this numerous times on this list. We have a function to
> notify the plugins that resampling should be avoided - it's 
> snd_pcm_hw_params_set_rate_resample().

Sorry for the repeat.  Once I see it, I remember seeing it before.

> hw:x,y,z 		- native device without any conversions
> plughw:x,y,z		- device trying to do all conversions for
> applications 
> default			- default device with
> all conversions (mostly pointing to plughw:x,y,z)
> And yes, plugin doing all conversions is named "plug". So anywhere
> where "plug" plugin is used, other plugins - including the rate
> plugin - can be dynamically inserted to satisfy application
> requirements.
> 						Jaroslav

Thanks for your answers Jaroslav, that clears it up for me.

More information about the Alsa-devel mailing list