[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