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

[Anssi Hannula]

pl bossart kirjoitti maanantai, 2. elokuuta 2010 06:18:35:
> > 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.
> 
> Could we require that the user sets the channel status bits (with the
> AESx controls) in case this is compressed. The driver would then make
> an informed decision to use HBR packets instead of regular PCM 8-ch
> layout2?

Indeed, the non-audio flag (AES0 & 0x02) could be used for this.

It seems the only always-available way to set those is as parameters in the 
device string, correct?

Will it always be reset after the user closes the device?

> At any rate, supporting such formats entails changes to higher levels
> of the audio stack, for example gstreamer/alsasink would need
> additional caps. Changes are not limited to the alsa driver I guess.

Yes.
We are in the process of adding support in ffmpeg for the TrueHD-in-IEC61937 
muxing and after that I'll add support into XBMC for using that functionality.

Looked at gstreamer, it seems to only have ac3-in-iec61937 support currently. 
However, I'd guess gstreamer would additionally need some ways to 1) detect if 
HBR is supported, and 2) detect if the connected receiver supports the 
specific codec..

-- 
Anssi Hannula