[pulseaudio-discuss] [PATCH]: High-definition audio pass-through support

[Arun Raghavan]

On Tue, 2011-11-22 at 00:49 -0700, Kelly Anderson wrote:
> 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.

The pa_format_info and format negotiation are meant to handle exactly
this sort of thing. So we'd either only expose DTS and not DTS-HD if
it's not in the ELD, or if there are bitrate limitations that can be
extracted from the ELD, we could even expose a supported bitrate range
in sink formats. Clients would then need to set the bitrate of the
stream, and if it exceeds this range, PA will know it can't support that
particular format.

So in practice, a client might send in multiple formats, one for DTS-HD,
one for DTS (which I assume is DTS core) and one for PCM, and PA would
pick the "best" of these based on what the sink supports.

> 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.

Okay, so we do need to pick the channel count and sample rate based on
the actual formats coming and open the sink correctly. Possibly we can
extend the rate updates we have to do a full-fledged sample spec update
fpr the passthrough case (and switch back when going to "raw" mode).

That said, it /would/ be nice to be able to get rid of the profiles and
just open the device for the number of channels we want. The problem is
we'd be limited to the same restrictions as with updating the sample
rate -- it would only work when no stream is running.

-- Arun