Post by Ross BencinaIt is easy to argue that PortAudio should offer this capability
It is indeed so... I will not.
It is even easier for me not to argue that, that, per se, my point was *not*
to add resampling capabilities in PortAudio.
My point was, per se, to enhance PortAudio's JACK support.
I am not playing with words. If the goal is different, the issues that need to
be addressed are different.
For sure if the goal is to add resampling capabilities, then all the issues
you enumerate are true questions.
But, If adding resampling capability proceeds from the need to make JACK's
support useful, then, one thinks of resampling as a solution to a specific
need => in this particular case, resampling is to be seen as a default
solution, some kind of fallback.
And the first quality of a fallback is to KISS !
=> Lowest possible power, lowest possible cost, resampling solution !
It's a bit like the case when a device is not specified ! If some code claims
ALSA support then it will naturally select ALSA's default and neither return
ENODEV nor fire some sophisticated algorithm searching for some self-supposed
best possible device.
Post by Ross BencinaWe have
argued successfully for 10 years to keep it out of PortAudio.
Geee !! Pardon me. I had not imagined I would wake a ten years old sea-snake
up !
Post by Ross BencinaThere are a few of good arguments against PortAudio including resampling
code: the best is that the choice of resampling quality is highly dependent
on the application.
I totally disagree with this :
The final quality (the only one that, at the end
of the day, matters) is *totally* depending on the end user who is supposed to
know what he does. (Particularily if he his using JACK)
When I define the sampling rate of my jackd instance, I am aware that the
output of any source on a different sample rate will get degraded.
If I do care about the quality of a given source, I make so the sample rates
match period !
If I don't make so that sample rates match, then It *means* that I do not care
about quality from this source compared with other jackd's clients.
=> True aesthetic in this matter is entirely governed by technical
compatibility and coherence not by the intrinsic qualities of the component.
Resampling quality is, in this particular case, second. A very accessory,
incidental question, even from the application point of view.
BTW PortAudio devs are, as far as I can read in pa_front.c perfectly in
accordance with this philosophy :
"defaultHighOutputLatency is used below instead of defaultLowOutputLatency
because it is more important for the default stream to work reliably than it
is for it to work with the lowest latency"
Post by Ross BencinaWe have trouble enough deciding how to convert ints to floats, and
resampling algorithm design has so many more degrees of freedom.
I can understand and appreciate this perfectly on a project leader point of
view and would even be ready to share it if I had shared your troubles.
Post by Ross BencinaWhy not just use libsamplerate in your client? I can pretty much guarantee
this will be easier than hacking PortAudio.
Indeed ! I had simply imagined that implementing in PortAudio would
be helpful to others apps. That's the purpose of a library isn't it ?
Post by Ross Bencina- We definitely wouldn't agree to using libsamplerate, its licence is not
compatible with PortAudio's.
Fair enough. This is once more perfectly understandable as well as sensible on
a project leader point of view.
Post by Ross BencinaAnother argument against it is that I can't see a reason why this
functionality can't be implemented just as easily in the client.
For sure it can be. And, as it seems I am the only one interested in this and
as I get a unique existing PortAudio based application, this is probably what
I will do.
But, in this case, (IMHO) PortAudio is not very helpful :
Why do we need to wait for the callback sequence to be rolling, to discover
that the samplerates do not match ?
I read that ValidateOpenStreamParameters "Checks for absurd sample rates".
As far as JACK is concerned, a sample rate different from JACK's sampling rate
sounds (IMHO) as "absurd" as a samplerate > 200.000 ! It just won't work
either !
Why cannot we get informed that paInvalidSampleRate as soon as the return of
the Pa_OpenStream call ?
This would be far more convenient from an application point of view.
(BTW... while this is not convenient from an application point of view, I
would have done the same programming within PortAudio... if... I had had the
intention to resample later on...)
Post by Ross Bencina- We don't have to provide high-quality resampler implementations
Fair enough. Once again my intention was not regarding a high quality
resampling feature, but was regarding a low power low cost fallback solution
enabling true JACK support from PortAudio.
Post by Ross BencinaI hope what I've written
above gives some impression of why I think that.
Absolutely and I thank you very much for this.
All this makes sense and your position is understandable and sensible from a
project's lead point of view.
Thank you all for your answers and thanks to all those who develop and
maintain PortAudio.
Regards,
aCOSwt