Dne So 5. ledna 22:37:47, Clemens Ladisch napsal(a): > David Kačerek wrote: > > ... to prevent pointless and counterproductive resampling > > Resampling happens only when needed. And how can it be counterproductive? > > To check whether resampling is done, use aplay with the -v option. > > > If I play a 882000Hz track in mpd I can see in a performance monitor it > > uses significantly more CPU when "speexrate_best" is set in comparison > > with the bare "speexrate" so I guess mpd respects my > > "defaults.pcm.rate_converter" value. But when played the same track in > > mplayer the CPU load is the same regardless of the > > "defaults.pcm.rate_converter" value used. > > mplayer explicitly disables ALSA's resampler (if enabled) and uses its own. > > > Moreover when mplayer is started with "-af-adv force=3" parameter to > > disable internal resampling playing of such a track is stopped with > > an error even though "alsa" or "alsa:device=hw=0.0" is set as the audio > > output. > > The "hw" device goes straight to the hardware, without software resampling. > For resampling to be possible, you'd need to use "plughw" or the default > "default" device. > > > Regards, > Clemens Hi Clemens: "Resampling happens only when needed. And how can it be counterproductive?" Unfortunatelly, with dmix or pulse the resampling happens always when the stream's frequency is different from the one specified in dmix or pulse even though my sound card does support the original sample rate so it only needlessly drains the power of the cpu and degrades audio quality. I know it's by design that way so multiple steams can be played at one time (cause a sound card can accept streams of only the same sample rate at one time) and their volume can be controlled independently but I prefer the exclusive access to the sound device as it produces the best sound possible (maybe arguable but I take the risk of uncertainty for having clear conscience that i've done everything I could for having the best sound possible). "The "hw" device goes straight to the hardware, without software resampling. For resampling to be possible, you'd need to use "plughw" or the default "default" device." I tried to run mplayer with "-ao alsa:device=plughw=0.0", "-ao alsa", "-ao alsa:device=default" and "-ao alsa:device=plughw" but it always drains only 2% of CPU no matter what value of "defaults.pcm.rate_converter" in asound.conf is used while playing the same 88200Hz track in mpd yields in ~22% CPU usage so the speexrate_best algorithm is definitely used there. However when having mpd sending the stream to the hw:0,0 instead of plugwh device the cpu usage drops to the 2% (as in mplayer) so mpd works as you describe. But the above mentioned mplayer just can't seem to use the speexrate_best no matter what... "mplayer explicitly disables ALSA's resampler (if enabled) and uses its own" So is there a way to make mplayer respect "defaults.pcm.rate_converter" or force it to use speexrate_best or samplerate_best some other way? Thanks! ------------------------------------------------------------------------------ Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122912 _______________________________________________ Alsa-user mailing list Alsa-user@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/alsa-user
