On 11/21/2011 10:35 PM, Arun Raghavan wrote:
Hi Kelly, others,
Sorry I'm late on this thread -- was travelling over the weekend.
On Mon, 2011-11-21 at 17:00 -0700, Kelly Anderson wrote:
On 11/21/2011 03:23 PM, Colin Guthrie wrote:
'Twas brillig, and Kelly Anderson at 21/11/11 11:08 did gyre and gimble:
[...]
I'm still confused at this terminology. 8 channel playback and
pass-through are very different things.
pass-through requires you to open a pipe at a particular bandwidth that
matches
the data that you are passing through. DTS-core and Dolby digital will fit
in a 2-channel@48K pipe. DTS-HD variations do not fit in the
2-channel/48K pipe
and therefore I have to open up a bigger pipe, so my code opens an
8-channel@192K pipe.
As far as channel mapping goes, pass-through doesn't care. The "real"
channel mapping is all handled by the receiver.
Is this 8 channel HDMI setup any different to an 8 channel analog one?
If so using the term passthrough is very wrong.
If my receiver supports DTS-HD natively, then enabling pass-through mode
is totally possible. A digital profile (even in 2ch mode) will happily
stitch to taking 8ch DTS encoded data. I'm not specifically sure about
DTS-HD encoding and whether it can be packaged up in packed format we
accept for passthrough data, but I'm sure Arun or Pierre can comment
more about the technical bits.
Pass-through is all about the "bandwidth" requirements. Opening the device
in 8 channels is also a "trigger" for hbr mode, as per the email I
linked from
March.
Initially I thought it would be nice if PulseAudio would take care of all of
the details, meaning that all I would have to do was trigger pass-through
mode on and start throwing raw DTS(-HD) packets at it. PulseAudio
would then zero fill and do the conversions to get the data to the receiver.
The problem with that would be, that I'd have to do it one way for Pulse
and another for Alsa.
As it is now. My code works equally well with Pulse or Alsa, since I'm
doing
all of the packet conversions.
One thing I'll say for sure is that we really do not want applications
to call the likes of pa_context_set_card_profile_by_name(). It's a very
bad idea for the application to second guess the routing policy and poke
too hard at the underlying system. xbmc might be a bit of a special case
here, but IMO it's still not appropriate. You either have a 8ch setup
that you use all the time (which should still be able to jump into pass
through mode if needed) or you don't. It shouldn't switch on-demand.
Switching 2/8 channel modes is a requirement for pass-through to work
with all of the different formats that come into play.
Yes, I realized when I wrote it, that it didn't line up with
PulseAudio's conceptual model.
That's the rub....PulseAudio doesn't line up properly with the
conceptual model
necessary to handle the variations of data that need to be passed to the
reciever
in pass-through mode.
PulseAudio is based on a model that lines up well with analog
configurations.
I.e. I have a 5.1 speaker setup, so that's what I want to configure the
sink
to accept.
When in pass-through mode, Pulse shouldn't care a bit about channel
mapping because the receiver becomes the ultimate arbiter of what goes
where. In my receiver's setup, I tell it the physical layout of my
speakers.
So in my case I have a 5.1 system and my receiver knows that. If I
pass-through
a DTS-HD stream that has 7.1 or 5.1 sound, the receiver does the appropriate
thing in both cases.
We may want to write a system that can route things and change profiles
at the PA end when appropriate (i.e. switch to a 2ch profile when
playing 2ch streams and switch to 8ch profile when playing 8ch stream)
but this routing decision is something that should definitely happen at
the PA end, not in individual apps.
I agree whole-heartedly. But of course someone has to crack some eggs
to make an omelette. It'll be easy change my code when Pulse can handle
this more effectively.
I'm happy to discuss the rationale with you on IRC, but it's partially
covered by my recent comments about routing and priority lists, but
really goes beyond that. I appreciate your commits will work with your
setup but it's really not a universally portable solution that could be
upstreamed IMO.
Pretty much the only thing I was looking for was the 7.1 mapping, within the
confines of PulseAudio's current implementation it works.
Okay, so how passthrough mode is supposed to work (which is more recent
than when you started your effort on this using the
PA_STREAM_PASSTHROUGH way) is as follows:
1. You use the new "extended" API during stream creation and tell PA
what format you want. We don't have support for any high bitrate formats
at the moment since I have no hardware that can do it, but I'm happy to
add the bits you need if you can test and let me know how it's working.
Pulse will have to switch channel count as well as frequency for full
pass-through
support to work. Here's a dump of my eld, and if you notice on Dolby TrueHD
it supports 8@192K. That's the only combination that will get us enough
bandwidth to handle Dolby TrueHD.
If Pulse could parse the eld data
/proc/asound/card?/eld\#?.0 and make available through the api which
channel/frequency
combinations are valid for a particular format, the client code could
make smart decisions such as deciding to strip DTS-core from A DTS-HD
stream. That would of course create a dependency on PulseAudio
so maybe it's better to let the client handle the decision making so
clients will still work on native Alsa.
monitor_present 1
eld_valid 1
monitor_name TX-SR608
connection_type HDMI
eld_version [0x2] CEA-861D or below
edid_version [0x3] CEA-861-B, C or D
manufacture_id 0xcb3d
product_id 0xa62
port_id 0x20000
support_hdcp 0
support_ai 0
audio_sync_delay 0
speakers [0x4f] FL/FR LFE FC RL/RR RLC/RRC
sad_count 8
sad0_coding_type [0x1] LPCM
sad0_channels 2
sad0_rates [0x1ee0] 44100 48000 88200 176400 192000 384000
sad0_bits [0xe0000] 16 20 24
sad1_coding_type [0x1] LPCM
sad1_channels 8
sad1_rates [0x1ee0] 44100 48000 88200 176400 192000 384000
sad1_bits [0xe0000] 16 20 24
sad2_coding_type [0x2] AC-3
sad2_channels 8
sad2_rates [0xe0] 44100 48000 88200
sad2_max_bitrate 640000
sad3_coding_type [0x7] DTS
sad3_channels 8
sad3_rates [0xc0] 48000 88200
sad3_max_bitrate 1536000
sad4_coding_type [0x9] DSD (One Bit Audio)
sad4_channels 6
sad4_rates [0x40] 48000
sad5_coding_type [0xa] E-AC-3/DD+ (Dolby Digital Plus)
sad5_channels 8
sad5_rates [0xc0] 48000 88200
sad6_coding_type [0xb] DTS-HD
sad6_channels 8
sad6_rates [0x1ec0] 48000 88200 176400 192000 384000
sad7_coding_type [0xc] MLP (Dolby TrueHD)
sad7_channels 8
sad7_rates [0x1480] 88200 192000
2. PA will open the device with the required sample spec required to
support the format you have given. To be honest, I didn't consider the
problem of bumping up the channel count since I assumed this would
mostly just be handled by driving up the sample rate up to 192/384kHz
with a stereo config. Would this work as well?
Back in March I started down that path, but it just isn't enough. BTW,
the kernel
hasn't even been patched to handle 384K yet. Pretty minor patch to
change that,
but it's not done yet.
3. I've left the IEC61937 payloading up to clients. This actually means
that there will be fewer changes to players that already support PA for
PCM and/or ALSA for passthrough. Hopefully whatever framework the player
is using provides the payloading (ffmpeg and gstreamer do).
If the sample rate scaling way of doing it won't work, we do need to
revisit how to handle the profile switching. I definitely don't think
that belongs in the client.
Yes, the payloading is best left to the client code.
It seems everyone is in agreement that switching profiles doesn't belong in
the client.
It might be nice if the pass-through code wasn't dependent on the profile
at all. I believe the profile really only makes sense in the context of
pcm data.
Regards,
Arun
_______________________________________________
pulseaudio-discuss mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
_______________________________________________
pulseaudio-discuss mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
