[MPlayer-dev-eng] [PATCH] Support for QNX: QSA audio and Photon GUI.

Mike Gorchak mike.gorchak.qnx at gmail.com
Wed Feb 6 20:19:50 CET 2013

> Why are you still doing such overcomplicated logic for the fallback?

User must get the best output format what hardware supports. For
example, many vos perform floatle fallback right to s16le, which is
not optimal, almost all HDA codecs support 32/24 bit samples. Some vos
doing 44100<->48000 fallback which is not a best solution, because
resampling is performed. Why it needed if hardware can support similar
sample rates, which will not require total rediscretization? There are
many videos with 96000Hz/88200Hz audio, so if 44100 will be selected
in audio with 96000Hz format (or 88200 to 48000), total resampling
will be used. I'm trying to avoid this.

> I can't see how anyone would be able to figure out if it really does
> anything sensible in absolutely all cases.
> For example is this line really as intended?
>>                     qsa_rate = qsa_rate_fallback(rate);
> My guess was that the argument should be qsa_rate.

yes and no :) My fault, I will fix it. First check must be performed
with rate argument while others with qsa_rate.

> Also in
>>                 if (channels != 0) {
>>                     try_again = 1;
>>                 } else {
> shouldn't the else be unreachable since we break out of the loop
> when channels becomes 0?

I agree.

> I was really serious when I suggested to fall back to a few "will
> always work" formats.
> Generally just trying S16_NE and 48000 and 44100 will cover almost
> anything.

I answered above.

> Btw. is it intentional that you don't update cpars.buf.block.frag_size
> when you change the fallback format?

You are right better to set them to a new format. Anyway QSA uses its
own algorithm to split buffer into the frags, which is almost
uncontrollable from the user side.

> The problem with that is that ao_data.outburst absolutely should be a
> multiple of the sample size (as in channels*format_bits/8) and you
> calculate that based on it.

I'm calculating it based on resulted buffer layout (frag size and
frags amount) which are 100% multiple of sample size.

More information about the MPlayer-dev-eng mailing list