[alsa-devel] How to handle HBR pass-through? (new PCM_FORMAT?)

[Anssi Hannula]

Hi all!

Passing through compressed audio via a digital link (S/PDIF, HDMI) is done by 
encapsulating the audio in a constant-bitrate IEC-61937 format, which is then 
passed to alsa as a normal 16bit PCM stream.

However, there is a new complication: Codecs that require an iec60958 frame 
rate higher than 192kHz (currently TrueHD/MLP and DTS-HD) need to be 
transmitted in HDMI (note that these can't be transmitted in normal S/PDIF at 
all) in a slightly different way.

The transmission via HDMI is essentially the same as transmission of 8-channel 
PCM stream with sample rate of iec60958_frame_rate/4 (e.g. 192kHz for TrueHD), 
with the samples inside a HBR packet instead of standard audio sample packet.

What this means is that if just the needed HBR bits are set in the audio 
driver, one can play back e.g. TrueHD by passing the IEC-61937 stream to ALSA 
as 192kHz 8-channel 16-bit PCM data; of course normal 8-channel PCM playback 
wouldn't work anymore then. So the driver would need to know if this is 8-
channel PCM or 8-channel compressed audio.

Which brings us to my question: How should the user be able to do this, i.e. 
inform the driver whether this is 8-channel PCM data or compressed audio data?


One easy option would be to have a separate IEC61937_HBR format in ALSA which 
could be used for IEC-61937 streams represented as 8x 16-bit channels.

If that would be considered too specific, we could add a more generic IEC61937 
format, which is the same as above except that "normal" ( = "2 channel") 
IEC-61937 streams could be used as well. However, as normal IEC-61937 streams 
can be used with S/PDIF as well, we'd AFAICS need to add such format bit to 
all S/PDIF drivers or have a no-op converter to the more widely supported 16-
bit PCM format.
Technically, I guess, IEC61937 data should be considered 8-bit or 32-bit 
(which is the amount of data in a single IEC-60958 frame) 1-channel stream, 
but that would mean the needed sample rate values would be far higher, which 
would be confusing since 16-bit PCM samples would not be supported at those 
rates.

Another possible option could be to have some ALSA device flag like AESx now 
are (I'm not sure how those are handled, maybe it wouldn't work).

Or maybe we should have SND_PCM_SUBFORMAT_IEC61937 or 
SND_PCM_SUBFORMAT_NONPCM?

What should be done?

-- 
Anssi Hannula