On Mon, Jun 21, 2010 at 1:16 PM, Colin Guthrie <gmane at colin.guthr.ie> wrote:
> 'Twas brillig, and Tanu Kaskinen at 21/06/10 18:35 did gyre and gimble:
>> Didn't Coling specifically ask proposals NOT involving passthrough?
>
> Yup :), and as I was heading home today I thought of a good example: games!
>
> Sadly Jens beat me to posting it here :D
>
> But I think games are a very specific case and while it's not a primary
> case, it's one to be considered. I think the passthrough case is likely
> the most important (especially in the short-term), but perhaps
> approaching the design with the non-passthrough case in mind will allow
> for a cleaner overall implementation? (I really don't know enough about
> how it will flow through PA to say this for sure - so just a thought... :))
Thanks everyone for your comments. I don't really disagree with any of
them, there are just some details where we are not in sync.
Looks like we want to have the following supported:
1. multichannel data (including but not limited to ac3/dts) -> decode
-> downmix -> spdif/hdmi stereo
pros: works for all platforms even if receiver doesn't have decoder or
is limited to stereo (eg. some TVs)
cons: requires decoder license on device, multichannel info lost
works with iec-stereo profile
2. multichannel data (including but not limited to ac3/dts) -> decode
-> mix -> reencode with a52 -> IEC formating -> spdif passthrough
pros: allows for all formats to be supported
cons: power, MHz, complexity, patents/licensing cost
works with iec958-ac3-surround-51
3. multichannel data (including but not limited to ac3/dts) -> decode
-> mix -> hdmi multichannel
not supported for now, there isn't a digital profile with multichannel
PCM output.
4. ac3/dts data -> IEC formatting -> spdif/hdmi passthrough
pros: limited activity on the source, power-efficient, no patent
requirements on source
cons: no mixing, formats limited to the ones supported by receiver and
IEC standards.
doesn't work for now. I would probably make sense to add a different
profile that would be selected by the user if the receiver can handle
such data.
Now that I understand what the a52 plugins does, in hindsight I should
have kept it. No reason to remove it.
One thing that's pretty clear: the following profile cannot work
[Mapping iec958-surround-40]
device-strings = iec958:%f
channel-map = front-left,front-right,rear-left,rear-right
priority = 1
SPDIF is stereo only, this one isn't possible unless encoding takes place.
The other issue is that using iec958 isn't great. On my laptop in some
cases the receiver fails to detect AC3 data, it always works when
using the hardware device.
The only cases where you absolutely want to use the iec plugin is if
you want to select a non-default output or set consumer/user bits,
i.e. "iec958:{CARD=1,AES0=0x0f,AES1=0xff,AES2=0x00,AES3=0x00}"
Given that this is a profile, it would be hard to pass these AES bits
and it would be quite a challenge to guess which non-default card
would need to be used. Plus most receiver just ignore these bits given
their general lack of reliability, and use the audio payload to
synchronize and extract the required information.
And if you look at the a52 code you will see that there isn't any
mandatory dependency on iec958. You can connect the a52 plugin
straight to the pcm hardware device (which is what I am also doing).
Along the same lines, HDMI should be handled in a similar manner, on
most platforms this is going show as a different card.
Overall I'd rather use some ENV variable or a field in daemon.conf to
set which digital output to use rather than hard-code 'iec958' in
profiiles
Feedback welcome.
Cheers
- Pierre
