On Wed, 2015-02-25 at 19:43 +0100, Georg Chini wrote:
> ---
> Â src/modules/module-loopback.c | 5 +++++
>  src/pulse/sample.c            | 5 ++++-
> Â 2 files changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/src/modules/module-loopback.c b/src/modules/module-loopback.c
> index d22afb5..7474ef2 100644
> --- a/src/modules/module-loopback.c
> +++ b/src/modules/module-loopback.c
> @@ -1039,6 +1039,11 @@ int pa__init(pa_module *m) {
> Â Â Â Â Â Â Â Â Â goto fail;
> Â Â Â Â Â }
> Â
> +Â Â Â Â if (ss.rate < 4000 || ss.rate > PA_RATE_MAX) {
> +Â Â Â Â Â Â Â Â pa_log("Invalid rate specification, valid range is 4000 Hz to %i Hz", PA_RATE_MAX);
> +Â Â Â Â Â Â Â Â goto fail;
> +Â Â Â Â }
> +
I pushed this change...
> Â Â Â Â Â if (pa_modargs_get_value(ma, "format", NULL))
> Â Â Â Â Â Â Â Â Â format_set = true;
> Â
> diff --git a/src/pulse/sample.c b/src/pulse/sample.c
> index 1331c72..69ac83f 100644
> --- a/src/pulse/sample.c
> +++ b/src/pulse/sample.c
> @@ -106,7 +106,10 @@ int pa_sample_format_valid(unsigned format) {
> Â }
> Â
> Â int pa_sample_rate_valid(uint32_t rate) {
> -Â Â Â Â return rate > 0 && rate <= PA_RATE_MAX;
> +Â Â Â Â /* The extra 1% is due to module-loopback: it temporarily sets
> +Â Â Â Â Â * a higher-than-nominal rate to get rid of excessive buffer
> +Â Â Â Â Â * latency */
> +Â Â Â Â return rate > 0 && rate <= PA_RATE_MAX * 101 / 100;
...but I left this one out. The two changes fix two separate issues, so
they should be in separate patches.
Making pa_sample_rate_valid() accept values above PA_RATE_MAX isn't
very nice, but I can see how it's better than the current behaviour,
which probably can cause the daemon to crash. Alexander mentioned in
IRC that he'd prefer doing the adaptive resampling inside module-
loopback rather than using pa_sink_input_set_rate(), and this change
demonstrates one good reason for that. I'm not asking you to implement
that change, but it certainly would be nice.
--Â
Tanu
