Re: pcm parameters, digital output ...

[Johannes Berg <johannes@sipsolutions.net>]

[-- Attachment #1: Type: text/plain, Size: 1983 bytes --]

On Fri, 2006-03-31 at 12:47 +0200, Jaroslav Kysela wrote:

> It's information for user space applications. The driver, of course, 
> ignores the extra bits, but the application should be able to determine 
> which bits are really send physically over IEC958 interface. Some Cirrus 
> Logic chips supports only limited iec958 channel status bits and these 
> bits are even different for pro and consumer modes.

Well there are 192 bits in either case so I don't see your point? If the
mask says that the consumer/pro mode bit cannot be set, then the meaning
is clear by asking the device once for the bits and seeing whether pro
is on or not, and if it is settable then the application knows which it
set or can also ask whether it is set or not.
I don't see what more information the app could get from having a pro
mask and a con mask. Or is there hardware that changes the allowed mask
with the setting of pro/con mode??

> Basically, I'm against to create these new formats, because the data 
> organization is exactly same as for standard PCM samples. All what we 
> require is to set a non-audio flag somewhere for the data stream.

Right. But it needs to be within the stream info, not out-of-band with
the iec control like you suggested.

> I would create SNDRV_PCM_SUBFORMAT_NONAUDIO and add subformat 
> bitmask handling to struct snd_pcm_hardware. Also, note that applications
> passing AC3 or other compressed streams should set this subformat. To 
> provide backward compatibility, we should create a hack for the iec958 
> device in alsa-lib configuration which sets this subformat value when
> AES0 contains the non-audio bit. The mechanism for handling the extra 
> iec958 parameters would remain same - using the control interface.

That makes sense. Essentially, I'm happy if I can use the same stream
and tell during prepare() if compressed audio is going to be sent or
not. That's pretty much all that matters to me.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]