JackOfAll wrote: > I have views, but I need to think some more before I start airing them. > ;) The "several cans of worms in your near future" warning LED has > already started to flash..... > > But immediate thought..... > > Needs to be a way of specifying the exception behaviour. ie. resample to > the closest rate, resample to the closest sync sample rate, resample to > the closest sync sample rate preferring up/down sampling.
At risk of speaking out-of-turn, my suggestion is to avoid over-proliferation of options if we can. I can't imagine wanting to down-sample when an available up-sample option is available on the selected DAC. Given that this is a kind of get-out-of-jail card, having an abundance of options to do so is less important (to me, at least) than having one sane option that works. If I try to find one sane rule, this is my best shot: if native sample rate is not available, resample to closest sync sample rate preferring up, or failing that resample to the nearest async rate preferring up, or failing that resample to the nearest async sample rate -tolerating- down, since we must. (The unifying principle I am trying to adopt is minimum loss of information.) Automatic fallback to plughw isn't working for me at the moment, which is a temporary situation (I hope) that we shouldn't allow to drive the intended functionality of squeezelite for everyone. However, I suspect that squeezelite's libsoxr resampling is of higher quality than the ALSA plughw defaults, so it might still be worth doing at some point. ---------------------- "Dreamer, easy in the chair that really fits you..." ------------------------------------------------------------------------ dsdreamer's Profile: http://forums.slimdevices.com/member.php?userid=12588 View this thread: http://forums.slimdevices.com/showthread.php?t=99395 _______________________________________________ unix mailing list [email protected] http://lists.slimdevices.com/mailman/listinfo/unix
