On Sat, 2014-10-25 at 22:57 +0200, Max Kellermann wrote: > On 2014/10/25 22:21, Steven Newbury <[email protected]> wrote: > > I that case the sample spec will have PA_SAMPLE_INVALID as its > > format > > type, which will cause the stream open to fail*. This can happen > > for > > example if the sample rate is out of range for a given format, > > where > > the pa_sample_spec_valid() will reject the sample spec. > > I don't like that, because MPD should already know it has failed - > and > instead of passing the known-to-be-invalid format specification to > Pulse, it should realize it has failed and bail out immediately. That should be pretty easy to do.
> > Anyway, why the complicated probing code at all? What is the > advantage over Ian's simpler solution? > Did Ian's patch make it to the mailing list? I haven't seen it. Perhaps it is overly complicated. My thinking was to give pulse a chance validate the sample spec and fall back to something else, I was thinking I should extend it to include sample rates too, but that would increase the complexity further. There does need to be at the least some mapping between mpd supported formats and pulse supported formats due to incompatibilities like 8- bit signed versus unsigned, and DSD. That means there at least needs to be a fallback for those cases, and really it should be smart enough to down-sample an incompatible high quality stream to the highest suitable format and up-sample a low quality stream to the closest comparable pulse spec. I've only specifically accounted for the DSD case and let the probing code take care of 8-bit. That could be improved and simplified if its the only important case.
signature.asc
Description: This is a digitally signed message part
_______________________________________________ mpd-devel mailing list [email protected] http://mailman.blarg.de/listinfo/mpd-devel
