On Fri, 27 Jul 2007 22:16:44 +0200 (CEST) Jaroslav Kysela <perex@xxxxxxx> 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. _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
