Triode wrote:
> There is a change in that it will now resample by exception using the
> same logic as upsampling - i.e. to the max sync sample rate if no other
> params are given. Is this causing a problem. If so we can review if
> this should be to the minimum sync sample rate?
>
> The operation of the -r option is now as follows:
> -r X : X is the max sample rate, believe all sample rates below this are
> supported [this list you see is the set of rates known to squeezelite]
> -r X-Y : X is the min sample rate and Y the max supported by the device,
> all known rates between these two are believed to work
> -r A, B, C : rates A B and C are supported
>
> Note that the -r options do not probe the device as they are also
> intended to be used when the device is not present at squeezelite
> startup. To probe the actual device support don't use the -r option.
>
> How about the smallest sync sample rate for resample by exception?
>
> Edit: I've changed it back to lowest sync rate - note this is now on
> master not output branch.
I do like the "lowest sync rate" strategy that you finally selected. I
can't say that your previous choice of max synchronous rate was a
problem per se, but since this was resampling by exception and not by
rule, it seems like doing the least resampling possible while preferring
synchronous resampling is both elegant and proportional to the problem
being solved.
Everything is working well, except for a small twist: When specifying
the range of allowed sample rates, I have to do it backwards rather than
the way you described in the quoted post (which corresponds to the help
text). In other words, I had to use -r 384000-44100 to get the desired
effect. Reading the code as you have it in main.c, this behavior
corresponds to how you've coded it and commented it, but not how you've
documented it.
Code:
--------------------
} else {
// optstr is <max>-<min> or <max>, extract rates from test rates within this
range
unsigned ref[] TEST_RATES;
char *maxstr = next_param(optarg, '-');
char *minstr = next_param(NULL, '-');
unsigned max = maxstr ? atoi(maxstr) : ref[0];
unsigned min = minstr ? atoi(minstr) : 0;
--------------------
I can imagine that from a coding point of view, you didn't want the
meaning of the first parameter "maxstr" to be altered by the existence
or not of the optional second parameter. However, the human habit of
writing number ranges in ascending order is hard to break...
Thanks again for truly amazing work you do.
----------------------
"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
