Hi all, To answer your requests, I could add a new boolean option in the config file. If this option is False (default), nothing changes compared to now. If this option is True, available hardware rates are used for the stream opening the sink (behavior of this patch) I think this an acceptable effort for audiophile/hi-res/whatever to switch this. And if it's improved/appreciated over time, it will be easy to make it the default behavior. Best regards, Erwan Le vendredi 09 décembre 2016 à 13:37 +0200, Tanu Kaskinen a écrit : > On Thu, 2016-12-08 at 11:32 +0530, Arun Raghavan wrote: > > > > On Fri, 2 Dec 2016, at 05:31 PM, Tanu Kaskinen wrote: > > > On Sun, 2016-11-27 at 22:27 +0100, Erwan JACQ wrote: > > > > You can use the default-sample-rate/alternate-sample-rate config values > > > > as minimal sample rates. > > > > > > Yes, using default-sample-rate as the minimum seems reasonable. I'm not > > > sure what to do with alternate-sample-rate. We can't just remove it, > > > unless you also change pa_config_parse() to not stop parsing when it > > > encounters unknown options, because we need to handle old configuration > > > files. (Doing that pa_config_parse() change would be very welcome, by > > > the way.) I suppose we can parse the option, but not use it anywhere > > > (and log a warning that the option was ignored). > > > > > > > So if you input a 8kHz audio stream, you resample it to 48kHz or 44.1kHz > > > > rather than let it to go 8Khz. > > > > > > > > I attached my patches. > > > > They just remove the limitation that the desired sample rate should be > > > > either default-sample-rate or alternate-sample-rate when the sink is > > > > opened. This was just a quick hack as I don't know pulseaudio source code at > > > > all. Feel free to discuss or modify them :) > > > > > > > > The resulting behavior is the following: > > > > > > > > New audio stream 88200Hz -> sink & source at 88200Hz > > > > Adding a stream at 441000Hz -> sink & source don't change their sample > > > > rate (still 88200Hz so). The additionnal stream is thus resampled to > > > > 88200Hz > > > > > > > > Shutdown sink, New audio stream at 441000Hz -> sink & source at 44100Hz > > > > > > > > Shutdown sink, New audio stream at 8000Hz -> sink & source at 44100Hz > > > > because there seems to be a lower limit (maybe 8Khz is not in the > > > > supported rates of the sound card :D ). > > > > > > I wonder if we should keep some of the special handling of rates that > > > are divisible by 8000 or 11025 (so we'd prefer 48000 Hz over 44100 Hz > > > if the requested rate was 8000 Hz). Probably that's not very important. > > > > Just as a note, this can also have an adverse effect in the opposite > > direction. If you have one stream at 192 kHz (paused), all streams will > > get upsampled to 192 kHz, increasing CPU usage and the amount of data > > we're moving around. > > > > To me, the sensible approach is to leave the default behaviour as is, > > and add a audiophile/hi-res/whatever mode which tries to play back files > > with as little resampling/conversion as possible (including not > > downsampling 24-bit audio, etc.). > > If you have hardware that can play 192 kHz audio and you have audio > content with that high rate, I think the chances are that you actually > want to use that rate. This is based on my gut feeling (no research) > that both hardware and audio content with high sample rate support are > still rare, so if you have them, you had to spend effort to find them. > Also, it's not common to have 192 kHz streams paused, and even when > that happens, I don't think the CPU use increase will usually be a > problem. > > That said, I don't really care very much. I'm also fine with having > different rate selection modes. In fact, there's one additional mode > that I want to preserve: forcing a specific rate. That's currently > possible by setting default-sample-rate and alternate-sample-rate to > the same value, but the proposed change doesn't seem to allow this. >
