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. 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? 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. Regards, Arun
