Discussion:
[pulseaudio-discuss] avoid-resampling -> avoid-processing
Arun Raghavan
2018-09-19 12:29:57 UTC
Permalink
Hello,
I'm thinking that we should change the avoid resampling flag on sinks to instead be avoid processing -- the idea being that we try not just to reconfigure to a given sample rate, but for the entire sample spec (and eventually channel map as well, once the reconfiguration patches are updated to address Tanu's comments).

The rationale is that I'd like to avoid having one more aspect of configuration, and the use-case to avoid resampling almost certainly applies to at least bit depth (16 <-> 24, usually) at least, and at that point, why not everything.

We could provide more fine-grained control (avoid-resampling/-remapping/-conversion/-channel-mix), but I don't see the benefit of this, so I figure a more overarching option is more likely to be useful.

Would be nice to hear people's thoughts on this.

Cheers,
Arun
Sangchul Lee
2018-09-21 11:03:47 UTC
Permalink
Post by Arun Raghavan
I'm thinking that we should change the avoid resampling flag on sinks to instead be avoid processing -- the idea being that we try not just to reconfigure to a given sample rate, but for the entire sample spec (and eventually channel map as well, once the reconfiguration patches are updated to address Tanu's comments).
The rationale is that I'd like to avoid having one more aspect of configuration, and the use-case to avoid resampling almost certainly applies to at least bit depth (16 <-> 24, usually) at least, and at that point, why not everything.
We could provide more fine-grained control (avoid-resampling/-remapping/-conversion/-channel-mix), but I don't see the benefit of this, so I figure a more overarching option is more likely to be useful.
I agree with that. Although the pending patches(sorry to tanu, I'll
update soon that with applying your last comments :)) address
bit-depth within enabling 'avoid-resampling' option, I also think
changing the name to any other one is better than now.
(avoid-processing, avoid-resampler, or another one).

Regards,
Sangchul
Arun Raghavan
2018-09-21 13:17:02 UTC
Permalink
Post by Sangchul Lee
Post by Arun Raghavan
I'm thinking that we should change the avoid resampling flag on sinks to instead be avoid processing -- the idea being that we try not just to reconfigure to a given sample rate, but for the entire sample spec (and eventually channel map as well, once the reconfiguration patches are updated to address Tanu's comments).
The rationale is that I'd like to avoid having one more aspect of configuration, and the use-case to avoid resampling almost certainly applies to at least bit depth (16 <-> 24, usually) at least, and at that point, why not everything.
We could provide more fine-grained control (avoid-resampling/-remapping/-conversion/-channel-mix), but I don't see the benefit of this, so I figure a more overarching option is more likely to be useful.
I agree with that. Although the pending patches(sorry to tanu, I'll
update soon that with applying your last comments :)) address
bit-depth within enabling 'avoid-resampling' option, I also think
changing the name to any other one is better than now.
(avoid-processing, avoid-resampler, or another one).
One question -- in avoid-resampling mode, we have a lower bound on the sample rate (as the lowest of default and alternate sample rate). Should we do the same thing for channels, or let the channel count be as low as 1 if the media is so configured?

I have a mild leaning towards the latter as a sanity check.

Cheers,
Arun
Arun Raghavan
2018-09-21 13:39:22 UTC
Permalink
Post by Arun Raghavan
Post by Sangchul Lee
Post by Arun Raghavan
I'm thinking that we should change the avoid resampling flag on sinks to instead be avoid processing -- the idea being that we try not just to reconfigure to a given sample rate, but for the entire sample spec (and eventually channel map as well, once the reconfiguration patches are updated to address Tanu's comments).
The rationale is that I'd like to avoid having one more aspect of configuration, and the use-case to avoid resampling almost certainly applies to at least bit depth (16 <-> 24, usually) at least, and at that point, why not everything.
We could provide more fine-grained control (avoid-resampling/-remapping/-conversion/-channel-mix), but I don't see the benefit of this, so I figure a more overarching option is more likely to be useful.
I agree with that. Although the pending patches(sorry to tanu, I'll
update soon that with applying your last comments :)) address
bit-depth within enabling 'avoid-resampling' option, I also think
changing the name to any other one is better than now.
(avoid-processing, avoid-resampler, or another one).
One question -- in avoid-resampling mode, we have a lower bound on the
sample rate (as the lowest of default and alternate sample rate). Should
we do the same thing for channels, or let the channel count be as low as
1 if the media is so configured?
I have a mild leaning towards the latter as a sanity check.
Rethinking this, I think we should have a lower-bound defined by the sample-spec as a whole.

-- Arun
Tanu Kaskinen
2018-09-24 08:58:22 UTC
Permalink
Post by Arun Raghavan
Post by Arun Raghavan
Post by Sangchul Lee
Post by Arun Raghavan
I'm thinking that we should change the avoid resampling flag on sinks to instead be avoid processing -- the idea being that we try not just to reconfigure to a given sample rate, but for the entire sample spec (and eventually channel map as well, once the reconfiguration patches are updated to address Tanu's comments).
The rationale is that I'd like to avoid having one more aspect of configuration, and the use-case to avoid resampling almost certainly applies to at least bit depth (16 <-> 24, usually) at least, and at that point, why not everything.
We could provide more fine-grained control (avoid-resampling/-remapping/-conversion/-channel-mix), but I don't see the benefit of this, so I figure a more overarching option is more likely to be useful.
I agree with that. Although the pending patches(sorry to tanu, I'll
update soon that with applying your last comments :)) address
bit-depth within enabling 'avoid-resampling' option, I also think
changing the name to any other one is better than now.
(avoid-processing, avoid-resampler, or another one).
One question -- in avoid-resampling mode, we have a lower bound on the
sample rate (as the lowest of default and alternate sample rate). Should
we do the same thing for channels, or let the channel count be as low as
1 if the media is so configured?
I have a mild leaning towards the latter as a sanity check.
Rethinking this, I think we should have a lower-bound defined by the sample-spec as a whole.
What do you mean by "the sample-spec"? pa_core.default_sample_spec?
Using that as a lower bound for everything seems reasonable to me.
--
Tanu

https://www.patreon.com/tanuk
https://liberapay.com/tanuk
Tanu Kaskinen
2018-09-23 11:52:22 UTC
Permalink
Post by Arun Raghavan
Hello,
I'm thinking that we should change the avoid resampling flag on sinks
to instead be avoid processing -- the idea being that we try not just
to reconfigure to a given sample rate, but for the entire sample spec
(and eventually channel map as well, once the reconfiguration patches
are updated to address Tanu's comments).
The rationale is that I'd like to avoid having one more aspect of
configuration, and the use-case to avoid resampling almost certainly
applies to at least bit depth (16 <-> 24, usually) at least, and at
that point, why not everything.
We could provide more fine-grained control (avoid-resampling/-
remapping/-conversion/-channel-mix), but I don't see the benefit of
this, so I figure a more overarching option is more likely to be
useful.
Would be nice to hear people's thoughts on this.
Having an "avoid-processing" option is a good idea. I'm not sure what
your proposal is for the old "avoid-resampling" option in daemon.conf.
I'd like to keep that separate, so that it only affects sample rate
conversion. The next best alternative would be to deprecate the option
and make it an alias for avoid-processing, and log a warning if it's
used in daemon.conf, with a message that tells the user to use avoid-
processing instead, and if the user actually wants to only disable
sample rate conversions, they should contact us so that we can bring
back the old option.
--
Tanu

https://www.patreon.com/tanuk
https://liberapay.com/tanuk
Sangchul Lee
2018-09-26 11:45:31 UTC
Permalink
Post by Tanu Kaskinen
Post by Arun Raghavan
We could provide more fine-grained control (avoid-resampling/-
remapping/-conversion/-channel-mix), but I don't see the benefit of
this, so I figure a more overarching option is more likely to be
useful.
Would be nice to hear people's thoughts on this.
Having an "avoid-processing" option is a good idea. I'm not sure what
your proposal is for the old "avoid-resampling" option in daemon.conf.
I'd like to keep that separate, so that it only affects sample rate
conversion.
I understood the backward compatibility you said. Do I need to modify
the patch expanding bit-depth("Consider sample format for
avoid-resampling/passthrough") with the new 'avoid-processing' option?
(I might upload a patch to the gitlab next time.)

Regards,
Sangchul.
Arun Raghavan
2018-09-27 03:30:31 UTC
Permalink
Post by Sangchul Lee
Post by Tanu Kaskinen
Post by Arun Raghavan
We could provide more fine-grained control (avoid-resampling/-
remapping/-conversion/-channel-mix), but I don't see the benefit of
this, so I figure a more overarching option is more likely to be
useful.
Would be nice to hear people's thoughts on this.
Having an "avoid-processing" option is a good idea. I'm not sure what
your proposal is for the old "avoid-resampling" option in daemon.conf.
I'd like to keep that separate, so that it only affects sample rate
conversion.
I understood the backward compatibility you said. Do I need to modify
the patch expanding bit-depth("Consider sample format for
avoid-resampling/passthrough") with the new 'avoid-processing' option?
(I might upload a patch to the gitlab next time.)
I've got a bunch of changes waiting on top of hte existing passthrough test MR. You probably should work off that. I've got the changes at https://gitlab.freedesktop.org/arun/pulseaudio/tree/reconfigure

Cheers,
Arun
Sangchul Lee
2018-09-27 05:43:52 UTC
Permalink
Post by Arun Raghavan
Post by Sangchul Lee
Post by Tanu Kaskinen
Post by Arun Raghavan
We could provide more fine-grained control (avoid-resampling/-
remapping/-conversion/-channel-mix), but I don't see the benefit of
this, so I figure a more overarching option is more likely to be
useful.
Would be nice to hear people's thoughts on this.
Having an "avoid-processing" option is a good idea. I'm not sure what
your proposal is for the old "avoid-resampling" option in daemon.conf.
I'd like to keep that separate, so that it only affects sample rate
conversion.
I understood the backward compatibility you said. Do I need to modify
the patch expanding bit-depth("Consider sample format for
avoid-resampling/passthrough") with the new 'avoid-processing' option?
(I might upload a patch to the gitlab next time.)
I've got a bunch of changes waiting on top of hte existing passthrough test MR. You probably should work off that. I've got the changes at https://gitlab.freedesktop.org/arun/pulseaudio/tree/reconfigure
I checked commits on your local branch including replacing the option
name. It will be great to have the previous option with some logs for
guide according to the "The next best alternative" of tanu's opinion.

And for now, I'll share V3 of "Consider sample format.." patch without
changing the name via email soon.

Regards,
Sangchul.
Arun Raghavan
2018-10-15 04:29:02 UTC
Permalink
Post by Sangchul Lee
Post by Arun Raghavan
Post by Sangchul Lee
Post by Tanu Kaskinen
Post by Arun Raghavan
We could provide more fine-grained control (avoid-resampling/-
remapping/-conversion/-channel-mix), but I don't see the benefit of
this, so I figure a more overarching option is more likely to be
useful.
Would be nice to hear people's thoughts on this.
Having an "avoid-processing" option is a good idea. I'm not sure what
your proposal is for the old "avoid-resampling" option in daemon.conf.
I'd like to keep that separate, so that it only affects sample rate
conversion.
I understood the backward compatibility you said. Do I need to modify
the patch expanding bit-depth("Consider sample format for
avoid-resampling/passthrough") with the new 'avoid-processing' option?
(I might upload a patch to the gitlab next time.)
I've got a bunch of changes waiting on top of hte existing passthrough test MR. You probably should work off that. I've got the changes at https://gitlab.freedesktop.org/arun/pulseaudio/tree/reconfigure
I checked commits on your local branch including replacing the option
name. It will be great to have the previous option with some logs for
guide according to the "The next best alternative" of tanu's opinion.
And for now, I'll share V3 of "Consider sample format.." patch without
changing the name via email soon.
I've implemented this feedback, some automated tests, and other review comments in:

https://gitlab.freedesktop.org/pulseaudio/pulseaudio/merge_requests/24

Cheers,
Arun
Tanu Kaskinen
2018-10-25 14:33:58 UTC
Permalink
Post by Arun Raghavan
Post by Sangchul Lee
Post by Arun Raghavan
Post by Sangchul Lee
Post by Tanu Kaskinen
Post by Arun Raghavan
We could provide more fine-grained control (avoid-resampling/-
remapping/-conversion/-channel-mix), but I don't see the benefit of
this, so I figure a more overarching option is more likely to be
useful.
Would be nice to hear people's thoughts on this.
Having an "avoid-processing" option is a good idea. I'm not sure what
your proposal is for the old "avoid-resampling" option in daemon.conf.
I'd like to keep that separate, so that it only affects sample rate
conversion.
I understood the backward compatibility you said. Do I need to modify
the patch expanding bit-depth("Consider sample format for
avoid-resampling/passthrough") with the new 'avoid-processing' option?
(I might upload a patch to the gitlab next time.)
I've got a bunch of changes waiting on top of hte existing passthrough test MR. You probably should work off that. I've got the changes at https://gitlab.freedesktop.org/arun/pulseaudio/tree/reconfigure
I checked commits on your local branch including replacing the option
name. It will be great to have the previous option with some logs for
guide according to the "The next best alternative" of tanu's opinion.
And for now, I'll share V3 of "Consider sample format.." patch without
changing the name via email soon.
https://gitlab.freedesktop.org/pulseaudio/pulseaudio/merge_requests/24
It's a bit unclear to me what the relationship between this MR and
"[PATCH v3] alsa-sink/source, sink, source: Consider sample format for
avoid-resampling/passthrough" is. Do you two have a common
understanding about which should be reviewed first?
--
Tanu

https://www.patreon.com/tanuk
https://liberapay.com/tanuk
Sangchul Lee
2018-10-26 05:37:43 UTC
Permalink
Post by Tanu Kaskinen
Post by Arun Raghavan
Post by Sangchul Lee
Post by Arun Raghavan
Post by Sangchul Lee
Post by Tanu Kaskinen
Post by Arun Raghavan
We could provide more fine-grained control (avoid-resampling/-
remapping/-conversion/-channel-mix), but I don't see the benefit of
this, so I figure a more overarching option is more likely to be
useful.
Would be nice to hear people's thoughts on this.
Having an "avoid-processing" option is a good idea. I'm not sure what
your proposal is for the old "avoid-resampling" option in daemon.conf.
I'd like to keep that separate, so that it only affects sample rate
conversion.
I understood the backward compatibility you said. Do I need to modify
the patch expanding bit-depth("Consider sample format for
avoid-resampling/passthrough") with the new 'avoid-processing' option?
(I might upload a patch to the gitlab next time.)
I've got a bunch of changes waiting on top of hte existing passthrough test MR. You probably should work off that. I've got the changes at https://gitlab.freedesktop.org/arun/pulseaudio/tree/reconfigure
I checked commits on your local branch including replacing the option
name. It will be great to have the previous option with some logs for
guide according to the "The next best alternative" of tanu's opinion.
And for now, I'll share V3 of "Consider sample format.." patch without
changing the name via email soon.
https://gitlab.freedesktop.org/pulseaudio/pulseaudio/merge_requests/24
It's a bit unclear to me what the relationship between this MR and
"[PATCH v3] alsa-sink/source, sink, source: Consider sample format for
avoid-resampling/passthrough" is. Do you two have a common
understanding about which should be reviewed first?
This single patch is the last commit of my patch series for expanding
'avoid-' functionalities including checking with supported sample
formats/rates and resetting hw param. And I think it is still needed
even if the arun's MR which is wider rage - function parameter
extension, channel-map things, renaming and null-sink modification -
is merged. So I'd like to ask you to review this patch first(I think
it is almost done..) and then rebase arun's MR 'if possible'.

Regards,
Sangchul.
Arun Raghavan
2018-10-26 07:52:10 UTC
Permalink
Post by Sangchul Lee
Post by Tanu Kaskinen
Post by Arun Raghavan
Post by Sangchul Lee
Post by Arun Raghavan
Post by Sangchul Lee
Post by Tanu Kaskinen
Post by Arun Raghavan
We could provide more fine-grained control (avoid-resampling/-
remapping/-conversion/-channel-mix), but I don't see the benefit of
this, so I figure a more overarching option is more likely to be
useful.
Would be nice to hear people's thoughts on this.
Having an "avoid-processing" option is a good idea. I'm not sure what
your proposal is for the old "avoid-resampling" option in daemon.conf.
I'd like to keep that separate, so that it only affects sample rate
conversion.
I understood the backward compatibility you said. Do I need to modify
the patch expanding bit-depth("Consider sample format for
avoid-resampling/passthrough") with the new 'avoid-processing' option?
(I might upload a patch to the gitlab next time.)
I've got a bunch of changes waiting on top of hte existing passthrough test MR. You probably should work off that. I've got the changes at https://gitlab.freedesktop.org/arun/pulseaudio/tree/reconfigure
I checked commits on your local branch including replacing the option
name. It will be great to have the previous option with some logs for
guide according to the "The next best alternative" of tanu's opinion.
And for now, I'll share V3 of "Consider sample format.." patch without
changing the name via email soon.
https://gitlab.freedesktop.org/pulseaudio/pulseaudio/merge_requests/24
It's a bit unclear to me what the relationship between this MR and
"[PATCH v3] alsa-sink/source, sink, source: Consider sample format for
avoid-resampling/passthrough" is. Do you two have a common
understanding about which should be reviewed first?
This single patch is the last commit of my patch series for expanding
'avoid-' functionalities including checking with supported sample
formats/rates and resetting hw param. And I think it is still needed
even if the arun's MR which is wider rage - function parameter
extension, channel-map things, renaming and null-sink modification -
is merged. So I'd like to ask you to review this patch first(I think
it is almost done..) and then rebase arun's MR 'if possible'.
I'm happy to rebase my work on top of this.

Regards,
Arun

Continue reading on narkive:
Loading...