[pulseaudio-discuss] [PATCH 4/8] sink, source: Fix default and alternate rate assertions

Tanu Kaskinen tanu.kaskinen at linux.intel.com
Mon Aug 12 03:27:13 PDT 2013


On Mon, 2013-08-12 at 09:20 +0200, David Henningsson wrote:
> On 08/09/2013 08:57 AM, Tanu Kaskinen wrote:
> > ---
> >  src/pulsecore/sink.c   | 4 ++--
> >  src/pulsecore/source.c | 4 ++--
> >  2 files changed, 4 insertions(+), 4 deletions(-)
> > 
> > diff --git a/src/pulsecore/sink.c b/src/pulsecore/sink.c
> > index a4ad21a..ae6ae8f 100644
> > --- a/src/pulsecore/sink.c
> > +++ b/src/pulsecore/sink.c
> > @@ -1412,8 +1412,8 @@ bool pa_sink_update_rate(pa_sink *s, uint32_t rate, bool passthrough) {
> >          return false;
> >  
> >      if (!passthrough) {
> > -        pa_assert(default_rate % 4000 || default_rate % 11025);
> > -        pa_assert(alternate_rate % 4000 || alternate_rate % 11025);
> > +        pa_assert((default_rate % 4000 == 0) || (default_rate % 11025 == 0));
> > +        pa_assert((alternate_rate % 4000 == 0) || (alternate_rate % 11025 == 0));
> 
> Looks correct, even though I don't understand why we need these
> constraints in the first place. (Why can't we just allow any sample rate
> as default or alternate?)

I don't know. I would guess that this is a simple way to optimize
multiple common cases (anything that is divisible by 4000 or 11025),
while the general solution would be to optimize only two cases (the
exact default and alternate rates).

-- 
Tanu



More information about the pulseaudio-discuss mailing list