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 at 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 at 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 at 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 > pulseaudio-discuss at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
