Re: How to handle HBR pass-through? (new PCM_FORMAT?)

[Takashi Iwai <tiwai@suse.de>]

At Mon, 2 Aug 2010 10:40:17 +0300,
Anssi Hannula wrote:
> 
> 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?

Right.

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

This is usually handled in alsa-lib.  But not in 100% guaranteed.

Some drivers have both "default" and "PCM" status bits -- the latter
is per PCM stream and re-initialized at each open/close.  But, many
drivers including HD-audio have only the former for simplicity.


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

Reusing the existing IEC958 status bits is OK for practical POV,
indeed.  This makes also compatible with the existing user-space stuff.

But I feel a bit uncertain when looking forward for future
development.  More discussions needed.


thanks,

Takashi