pcm parameters, digital output ...

pcm parameters, digital output ...

[Johannes Berg]

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

On Mon, 2006-03-27 at 17:37 +0200, Takashi Iwai wrote:

> It's hard to restrict parameters on demands (although theoretically
> it's possible).  We usually provide two different devices, one for
> the normal i/o and another for the digital i/o, to avoid such
> conflicts.
> 
> The apps that send to the digital data would choose "spdif" or
> whatever appropriate PCM name, and the system will reroute it.

I thought about this a bit more now...

Just FYI, the codec chip I'm working against is capable of generating
digital out and analog out at the same time, so I'd rather not create
two PCMs because then you'd have the problem that for one, only one of
the two can be active at the same time, and secondly, when the analog
output is active, the same data can also go out of the spdif port. Which
is a bit icky, and definitely hard to understand. Hence, I'd rather not
create extra streams for this.

I've been browsing the source for this and have a few questions:

What is the point in having "Con Mask", "Pro Mask" and just "Mask"?
Doesn't "Mask" subsume the other two, and in the "Pro Mask" the consumer
mode bit cannot be set (which ac97 seems to still allow...)? Just has me
puzzled.
Anyway, that isn't really the point.

Looking at the ac97 api, it specifies the SPDIF controls as part of the
mixer. Shouldn't those rather be tied to a specific PCM?

I think that there isn't much we can do without breaking everything. I
think it'd probably be best to add a new "pcm" format for the compressed
data. The current ac3play is using 16bit signed little endian pcm data
(SND_PCM_FORMAT_S16_LE), which is not really what it is sending, it
isn't sending PCM data at all.
Something like SND_PCM_FORMAT_SPDIF_NONPCM would be fine. Then
applications would use that to announce that they're sending non-pcm
data down the 'pcm' device...

Now note that there's a problem with old applications: using
SND_PCM_FORMAT_S16_LE they would, after adding
SND_PCM_FORMAT_SPDIF_NONPCM, assert that they are indeed sending PCM
data, which my driver would actually allow the user o play on the analog
output then, if it relies on he application telling the truth using
SND_PCM_FORMAT_SPDIF_NONPCM. But I don't think there's any better
choice.

If I were to rewrite this (as you hinted an another mail), I'd rename
the 'pcm' devices to 'datapump' devices and make the format parameter
actually two related parameters: data type (pcm/non-pcm), and data
format (word size etc.), where the data format is a sub-type of the data
type so to speak.
Note that currently, the only non-pcm data types would be U16_LE and
U16_BE (if the hardware does byteswaps), so it might be sufficient to
define SND_DATA_FORMAT_NONPCM_16_LE and SND_DATA_FORMAT_NONPCM_16_BE
(signedness isn't relevant in this case), and keep the current
SND_PCM_FORMAT_S16_LE as SND_DATA_FORMAT_PCM_S16_LE in the same format
parameter.

However, then the space in the 64 bits of 'format' would be nearing
being used up once some more non-pcm formats are defined, though that
should only be relevant for future hardware since the spdif bitstream is
defined via the spdif mask controls.

johannes

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

Re: pcm parameters, digital output ...

[Jaroslav Kysela]

On Wed, 29 Mar 2006, Johannes Berg wrote:

> What is the point in having "Con Mask", "Pro Mask" and just "Mask"?
> Doesn't "Mask" subsume the other two, and in the "Pro Mask" the consumer
> mode bit cannot be set (which ac97 seems to still allow...)? Just has me
> puzzled.
> Anyway, that isn't really the point.

The mask is R/O variable and the bit definitions are different for 
consumer and pro modes, so the driver can describe exactly which bits are 
supported for these two different modes.

> Looking at the ac97 api, it specifies the SPDIF controls as part of the
> mixer. Shouldn't those rather be tied to a specific PCM?

AC97 code is probably not a good example. The "shift" to specific PCM 
device is not implemented there. Look to snd_ice1712_spdif_build_controls
in ice1712.c . This code is good.

> I think that there isn't much we can do without breaking everything. I
> think it'd probably be best to add a new "pcm" format for the compressed
> data. The current ac3play is using 16bit signed little endian pcm data
> (SND_PCM_FORMAT_S16_LE), which is not really what it is sending, it
> isn't sending PCM data at all.
> Something like SND_PCM_FORMAT_SPDIF_NONPCM would be fine. Then
> applications would use that to announce that they're sending non-pcm
> data down the 'pcm' device...

I'm not sure, if we need a new format when we have information from the 
control elements, that the stream is not PCM encoded. But on other hand, 
these formats can be used with some conversion layers in alsa-lib 
for handling of these streams and prevent extra things like resampling, 
volume processing etc.

Also, there is a possibility to use subformat value (which is not used 
so far for S16_LE/BE formats) for the non-pcm stream specification.

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SUSE Labs


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

Re: pcm parameters, digital output ...

[Johannes Berg]

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

On Thu, 2006-03-30 at 16:51 +0200, Jaroslav Kysela wrote:

> The mask is R/O variable and the bit definitions are different for 
> consumer and pro modes, so the driver can describe exactly which bits are 
> supported for these two different modes.

Yes, I know, I just don't see why there are different modes. If the chip
has different modes, shouldn't the driver be able to switch between them
based on the consumer bit in the actual iec958 values it gets from
userspace?

> AC97 code is probably not a good example. The "shift" to specific PCM 
> device is not implemented there. Look to snd_ice1712_spdif_build_controls
> in ice1712.c . This code is good.

Hmm, ok. Did you read my earlier discussion about why I do *not* want a
shift to a specific pcm device?

> I'm not sure, if we need a new format when we have information from the 
> control elements, that the stream is not PCM encoded. But on other hand, 
> these formats can be used with some conversion layers in alsa-lib 
> for handling of these streams and prevent extra things like resampling, 
> volume processing etc.

Aha, good point, I could use the iec958 bits to determine the mode. But
that's out-of-band information, so it is not too nice to rely on it
imho.
And exactly like you say, resampling etc. cannot be done on compressed
information.

> Also, there is a possibility to use subformat value (which is not used 
> so far for S16_LE/BE formats) for the non-pcm stream specification.

I'm not too familiar with these internals :)

What I'm currently doing is defining for each codec what kind of
transfer formats it supports, see 
http://johannes.sipsolutions.net/gitweb.cgi?p=snd-aoa.git;a=blob;h=e3ca7a269906ceb41b411afcad14c54f4a181588;hb=4e1bc0b35020b3b1cac87f60cb67671e2c9a801e;f=aoa/codecs/onyx/snd-aoa-codec-onyx.c#l430

Then the generic framework cuts that down to whatever is usable() at the
moment depending on the selection of the iec958 and analog mute mixer
elements. Hence there you can see what I'd like to do with a new format
(which I called SNDRV_PCM_FMTBIT_COMPRESSED_16BE for now).

johannes

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

Re: pcm parameters, digital output ...

[Jaroslav Kysela]

On Thu, 30 Mar 2006, Johannes Berg wrote:

> On Thu, 2006-03-30 at 16:51 +0200, Jaroslav Kysela wrote:
> 
> > The mask is R/O variable and the bit definitions are different for 
> > consumer and pro modes, so the driver can describe exactly which bits are 
> > supported for these two different modes.
> 
> Yes, I know, I just don't see why there are different modes. If the chip
> has different modes, shouldn't the driver be able to switch between them
> based on the consumer bit in the actual iec958 values it gets from
> userspace?

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.

> > AC97 code is probably not a good example. The "shift" to specific PCM 
> > device is not implemented there. Look to snd_ice1712_spdif_build_controls
> > in ice1712.c . This code is good.
> 
> Hmm, ok. Did you read my earlier discussion about why I do *not* want a
> shift to a specific pcm device?

Note that controls might be changed (removed, added) at runtime, but it's 
not preferred, because the logic for applications is more complicated.

At least alsa-lib must have configuration for your iec958 device which 
correctly handles the iec958 channel status bits. And this configuration 
will describe which controls should be used.

> > I'm not sure, if we need a new format when we have information from the 
> > control elements, that the stream is not PCM encoded. But on other hand, 
> > these formats can be used with some conversion layers in alsa-lib 
> > for handling of these streams and prevent extra things like resampling, 
> > volume processing etc.
> 
> Aha, good point, I could use the iec958 bits to determine the mode. But 
> that's out-of-band information, so it is not too nice to rely on it 
> imho. And exactly like you say, resampling etc. cannot be done on 
> compressed information.
> 
> > Also, there is a possibility to use subformat value (which is not used 
> > so far for S16_LE/BE formats) for the non-pcm stream specification.
> 
> I'm not too familiar with these internals :)
> 
> What I'm currently doing is defining for each codec what kind of
> transfer formats it supports, see 
> http://johannes.sipsolutions.net/gitweb.cgi?p=snd-aoa.git;a=blob;h=e3ca7a269906ceb41b411afcad14c54f4a181588;hb=4e1bc0b35020b3b1cac87f60cb67671e2c9a801e;f=aoa/codecs/onyx/snd-aoa-codec-onyx.c#l430
> 
> Then the generic framework cuts that down to whatever is usable() at the
> moment depending on the selection of the iec958 and analog mute mixer
> elements. Hence there you can see what I'd like to do with a new format
> (which I called SNDRV_PCM_FMTBIT_COMPRESSED_16BE for now).

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.

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.

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SUSE Labs


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

Re: pcm parameters, digital output ...

[Johannes Berg]

[-- 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 --]

Re: pcm parameters, digital output ...

[Jaroslav Kysela]

On Fri, 31 Mar 2006, Johannes Berg wrote:

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

Yes, it's exactly what I'm talking about.

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

Ok, I will try to add this feature. If someone else have objections 
against this implementation, please, speak now.

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SUSE Labs


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

Re: pcm parameters, digital output ...

[Johannes Berg]

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

On Fri, 2006-03-31 at 13:38 +0200, Jaroslav Kysela wrote:
> > 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??
> 
> Yes, it's exactly what I'm talking about.

Ok. Then it makes sense. Sorry for not getting it.

> > 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.
> 
> Ok, I will try to add this feature. If someone else have objections 
> against this implementation, please, speak now.

Cool, thanks, let me know if you want me to take a look at anything.

johannes

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