Questions to HDSP users

Questions to HDSP users

[Thomas Charbonnel]

Hi,

In the process of debuging the problems some hdsp users are 
experiencing, I reviewed almost every single line of code in the hdsp 
driver, and there are things in there that were inherited from the old 
rme9652 driver and that don't seem relevant anymore for the hdsp 
(particularly now that hdspmixer is there).
* Does anyone use the passthru control ? If not I would gladly remove it 
as it interferes with hdspmixer. Anyway everything it did can be done 
with hdspmixer or the Mixer control using a shell script.
* The current behaviour is that the driver cancels any 1:1 input to 
output routing when playback or capture is enabled. Not only this 
interferes with hdspmixer, but I find it rather confusing. Any objection 
to a change here also ?

I also realized communicating with RME that the firmware files we use in 
linux are not the same as those used in current versions of the windows 
and mac drivers. As a consequence people using dual boot systems should 
always power cycle their iobox when switching operating systems to 
prevent any problem (this is of particular importance to rev 0xa users).
This minor issue will be resolved shortly as I'm working on switching to 
those files for the linux driver. The new firmware files seem to be 
revision independant (but they do require a driver modification) and add 
support for disconnect mode (standalone operation of the iobox - I have 
it working here, it's awesome !)

Thomas




-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn

Re: Questions to HDSP users

[Jesse Chappell]

Thomas Charbonnel wrote on Wed, 28-Jan-2004:

 > In the process of debuging the problems some hdsp users are 
 > experiencing, I reviewed almost every single line of code in the hdsp 
 > driver, and there are things in there that were inherited from the old 
 > rme9652 driver and that don't seem relevant anymore for the hdsp 
 > (particularly now that hdspmixer is there).
 > * Does anyone use the passthru control ? If not I would gladly remove it 
 > as it interferes with hdspmixer. Anyway everything it did can be done 
 > with hdspmixer or the Mixer control using a shell script.
 > * The current behaviour is that the driver cancels any 1:1 input to 
 > output routing when playback or capture is enabled. Not only this 
 > interferes with hdspmixer, but I find it rather confusing. Any objection 
 > to a change here also ?

I never use it.... ++vote to get rid of it.  

And by the way, my hardware/software works completely fine (no
problems whatsoever):
  IBM ThinkPad A31  1.8 P4-M
  Cardbus HDSP/Multiface  rev 0xb
  kernel 2.4.21 , alsa 0.9.8

And while I have your attention, i've tried to get iec958 spdif
passthrough (non-audio AC3) working on the HDSP without success.
I created a HDSP.conf based on the RME9652.conf and got the device
properly opened using ac3dec -C , but no stream is passed (using
ADAT1 optical output, properly set as SPDIF in hdspconf).  Setting
the non-audio flag doesn't appear to have any effect.
It works fine as an output for regular PCM spdif operation.

Any ideas you or the other alsa gurus have would be most welcome.

jlc


-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn

Alsa handling of spdif bits (was Re: Questions to HDSP users)

[Thomas Charbonnel]

Jesse Chappell wrote :
> 
> And while I have your attention, i've tried to get iec958 spdif
> passthrough (non-audio AC3) working on the HDSP without success.
> I created a HDSP.conf based on the RME9652.conf and got the device
> properly opened using ac3dec -C , but no stream is passed (using
> ADAT1 optical output, properly set as SPDIF in hdspconf).  Setting
> the non-audio flag doesn't appear to have any effect.
> It works fine as an output for regular PCM spdif operation.
> 
> Any ideas you or the other alsa gurus have would be most welcome.
> 
> jlc
> 
> 

Hi Jesse,

I just had a look and here again there is code in the hdsp driver 
directly inherited form the rme9652 driver. There are two competing 
spdif bits handling mechanisms there, one hdsp specific dealing directly 
with the card registers, and one alsa generic. There clearly is a 
problem in that the spdif bits on the card are cleared on playback where 
they shouldn't. It would be easy to fix, but I guess that the alsa 
generic spdif bits handling code is here for some reason. Jaroslav or 
Takashi, could you explain to me how this is supposed to work with alsa 
? I guess there is a plan for a generic spdif bits control interface, 
but for now there seems to be nothing. Amixer doesn't even seem to 
handle this properly, or does it ?

Thomas




-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn

Re: Questions to HDSP users

[Justin Cormack]

On Wed, 2004-01-28 at 15:29, Thomas Charbonnel wrote:
> Hi,
> 
> In the process of debuging the problems some hdsp users are 
> experiencing, I reviewed almost every single line of code in the hdsp 
> driver, and there are things in there that were inherited from the old 
> rme9652 driver and that don't seem relevant anymore for the hdsp 
> (particularly now that hdspmixer is there).
> * Does anyone use the passthru control ? If not I would gladly remove it 
> as it interferes with hdspmixer. Anyway everything it did can be done 
> with hdspmixer or the Mixer control using a shell script.
> * The current behaviour is that the driver cancels any 1:1 input to 
> output routing when playback or capture is enabled. Not only this 
> interferes with hdspmixer, but I find it rather confusing. Any objection 
> to a change here also ?

I have never used it. ANything that simplifies the driver is good.

> I also realized communicating with RME that the firmware files we use in 
> linux are not the same as those used in current versions of the windows 
> and mac drivers. As a consequence people using dual boot systems should 
> always power cycle their iobox when switching operating systems to 
> prevent any problem (this is of particular importance to rev 0xa users).
> This minor issue will be resolved shortly as I'm working on switching to 
> those files for the linux driver. The new firmware files seem to be 
> revision independant (but they do require a driver modification) and add 
> support for disconnect mode (standalone operation of the iobox - I have 
> it working here, it's awesome !)

How does that work? You just set up the routing and it stays there while
the box has power?

justin




-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn

Re: Questions to HDSP users

[alsa-devel]

Quoting Thomas Charbonnel <thomas@undata.org>:

> Hi,
> 
> In the process of debuging the problems some hdsp users are 
> experiencing, I reviewed almost every single line of code in the hdsp
> 
> driver, and there are things in there that were inherited from the
> old 
> rme9652 driver and that don't seem relevant anymore for the hdsp 
> (particularly now that hdspmixer is there).

No objection from me on the proposed changes.  BTW, I am using an
HDSP9652 with a version of ALSA I got from CVS last August or so, and
haven't had any problems for what I'm doing (basic multichannel record
and playback, and some MIDI).




-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn

Re: Alsa handling of spdif bits (was Re: Questions to HDSP users)

[Takashi Iwai]

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

Hi,

sorry for the late reply - i overlooked this post.

At Thu, 29 Jan 2004 14:51:34 +0100,
Thomas Charbonnel wrote:
> 
> I just had a look and here again there is code in the hdsp driver 
> directly inherited form the rme9652 driver. There are two competing 
> spdif bits handling mechanisms there, one hdsp specific dealing directly 
> with the card registers, and one alsa generic. There clearly is a 
> problem in that the spdif bits on the card are cleared on playback where 
> they shouldn't. It would be easy to fix, but I guess that the alsa 
> generic spdif bits handling code is here for some reason. Jaroslav or 
> Takashi, could you explain to me how this is supposed to work with alsa 
> ? I guess there is a plan for a generic spdif bits control interface, 
> but for now there seems to be nothing. Amixer doesn't even seem to 
> handle this properly, or does it ?

there are ususally two controls for the IEC958 status bits,
"IEC958 Playback Default" and "IEC958 Playback PCM Stream".
the former defines the "default" iec958 status bits as it name
stands.  the latter control defines a temporary status of the opened
stream.  normally, the default value is inherited to the temp value at
the open callback, and the temp value will be lost when the PCM is
closed.  (hence, it doesn't make sense to store/restore "IEC958
Playback PCM Stream" with alsactl although it's harmless.)

these controls are often defined with IFACE = PCM.  thus, amixer
doesn't handle them unless you specify iface explicitly.
unfortuantely, not all drivers follow this rule and use IFACE = MIXER
because of ease of coding.  it's a source of confusion.

BTW, you can see/change the default IEC958 status via iecset program
in alsa-utils.


regarding Jesse's problem:
it looks like RME*.conf are broken.
does the attached patch work?


Takashi

[-- Attachment #2: Type: text/plain, Size: 1935 bytes --]

Index: alsa-lib/src/conf/cards/RME9636.conf
===================================================================
RCS file: /suse/tiwai/cvs/alsa/alsa-lib/src/conf/cards/RME9636.conf,v
retrieving revision 1.2
diff -u -r1.2 RME9636.conf
--- alsa-lib/src/conf/cards/RME9636.conf	25 Nov 2002 10:14:18 -0000	1.2
+++ alsa-lib/src/conf/cards/RME9636.conf	5 Feb 2004 14:27:28 -0000
@@ -53,6 +53,7 @@
 		type ctl_elems
 		hook_args [
 			{
+				interface PCM
 				name "IEC958 Playback PCM Stream"
 				lock true
 				value [ $AES0 $AES1 $AES2 $AES3 ]
Index: alsa-lib/src/conf/cards/RME9652.conf
===================================================================
RCS file: /suse/tiwai/cvs/alsa/alsa-lib/src/conf/cards/RME9652.conf,v
retrieving revision 1.2
diff -u -r1.2 RME9652.conf
--- alsa-lib/src/conf/cards/RME9652.conf	25 Nov 2002 10:14:18 -0000	1.2
+++ alsa-lib/src/conf/cards/RME9652.conf	5 Feb 2004 14:27:20 -0000
@@ -1,10 +1,10 @@
 #
-# Configuration for the RME9636
+# Configuration for the RME9652
 #
 
 <confdir:pcm/front.conf>
 
-RME9636.pcm.front.0 {
+RME9652.pcm.front.0 {
 	@args [ CARD ]
 	@args.CARD {
 		type string
@@ -18,7 +18,7 @@
 
 <confdir:pcm/iec958.conf>
 
-RME9636.pcm.iec958.0 {
+RME9652.pcm.iec958.0 {
 	@args [ CARD AES0 AES1 AES2 AES3 ]
 	@args.CARD {
 		type string
@@ -53,6 +53,7 @@
 		type ctl_elems
 		hook_args [
 			{
+				interface PCM
 				name "IEC958 Playback PCM Stream"
 				lock true
 				value [ $AES0 $AES1 $AES2 $AES3 ]
Index: alsa-lib/src/conf/cards/aliases.conf
===================================================================
RCS file: /suse/tiwai/cvs/alsa/alsa-lib/src/conf/cards/aliases.conf,v
retrieving revision 1.4
diff -u -r1.4 aliases.conf
--- alsa-lib/src/conf/cards/aliases.conf	27 Nov 2003 16:46:35 -0000	1.4
+++ alsa-lib/src/conf/cards/aliases.conf	5 Feb 2004 14:30:09 -0000
@@ -20,3 +20,4 @@
 au8810 cards.AU8810
 au8820 cards.AU8820
 au8830 cards.AU8830
+'H-DSP' cards.RME9652

Re: Alsa handling of spdif bits (was Re: Questions to HDSP users)

[Jesse Chappell]

 > regarding Jesse's problem:
 > it looks like RME*.conf are broken.
 > does the attached patch work?

Sorry, I had already created a new H-DSP.conf and figured out
it needed the 'interface PCM'.   I was able to use ac3dec -C to
open the device, and attempted to stream through it, but nothing
streamed.  

Standard PCM streaming and mixing works fine over the spdif. 
I have a feeling there is some strange interaction with the mixer's
normal operation and the special spdif modes.

An aside: this is also complicated because to open the device, the
channels item in the slave.pcm section must match the iobox in
use (multiface or digiface) which have differing channel counts.
So when we do get this working, it will be a problem to handle
both cases in a conf file.

jlc


-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn

Re: Alsa handling of spdif bits (was Re: Questions to HDSP users)

[Thomas Charbonnel]

Jesse Chappell wrote :
>  > regarding Jesse's problem:
>  > it looks like RME*.conf are broken.
>  > does the attached patch work?
> 
> Sorry, I had already created a new H-DSP.conf and figured out
> it needed the 'interface PCM'.   I was able to use ac3dec -C to
> open the device, and attempted to stream through it, but nothing
> streamed.  
> 
> Standard PCM streaming and mixing works fine over the spdif. 
> I have a feeling there is some strange interaction with the mixer's
> normal operation and the special spdif modes.
> 

So you should be able to do what you want using this iecset tool
Takashi mentioned :
iecset -c X audio off (where X is your card number)
After this command, when playback will be enabled (remember that with 
the current alsa model those bits are set on playback), the Non-Audio 
bit will be set properly (you should see it checked in hdspconf).
The 'alsa style' iec bits handling code in the driver
seems to be functional.
(BTW Takashi iecset -h says 'audio on' is non-audio and 'audio off' is 
audio but it seems to be the other way round, unless the hdsp driver is 
wrong here...)
The problem I see and I dislike with this is that iec bits are 
associated with playback. This is probably fine with most devices, but 
not with hardware that can do hardware routing, where you may want to 
route signal through the S/PDIF out with a certain bit combination - no 
playback is involved here. I believe a generic iec bits handling 
interface is a good thing, but is should not be affected by the card's 
status. Any comment on this Takashi ?

> An aside: this is also complicated because to open the device, the
> channels item in the slave.pcm section must match the iobox in
> use (multiface or digiface) which have differing channel counts.
> So when we do get this working, it will be a problem to handle
> both cases in a conf file.
> 

Not to mention that there is also a shift in the S/PDIF channels
position when the card changes speed mode...
Can the current configuration mechanism handle this properly ?
Similarly we would need different .conf files for the different hdsp
cards, but seeing Takashi's patch, it seems .conf files are associated
with a card using the generic driver name (here 'H-DSP'). Is there a way
to affect a .conf file to a specific submodel ?

Thomas





-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn

Re: Alsa handling of spdif bits (was Re: Questions to HDSP users)

[Takashi Iwai]

At Fri, 06 Feb 2004 12:22:08 +0100,
Thomas Charbonnel wrote:
> 
> (BTW Takashi iecset -h says 'audio on' is non-audio and 'audio off' is 
> audio but it seems to be the other way round, unless the hdsp driver is 
> wrong here...)

yep, fixed now on CVS :)

> The problem I see and I dislike with this is that iec bits are 
> associated with playback. This is probably fine with most devices, but 
> not with hardware that can do hardware routing, where you may want to 
> route signal through the S/PDIF out with a certain bit combination - no 
> playback is involved here. I believe a generic iec bits handling 
> interface is a good thing, but is should not be affected by the card's 
> status. Any comment on this Takashi ?

well, in that case, the put callback of "IEC958 Playback Default"
should change the corresponding register value immediately, too.


> > An aside: this is also complicated because to open the device, the
> > channels item in the slave.pcm section must match the iobox in
> > use (multiface or digiface) which have differing channel counts.
> > So when we do get this working, it will be a problem to handle
> > both cases in a conf file.
> > 
> 
> Not to mention that there is also a shift in the S/PDIF channels
> position when the card changes speed mode...
> Can the current configuration mechanism handle this properly ?

when the channel position changes dynamically according to the certain
state, it'd be difficult with the current config without addition...

> Similarly we would need different .conf files for the different hdsp
> cards, but seeing Takashi's patch, it seems .conf files are associated
> with a card using the generic driver name (here 'H-DSP'). Is there a way
> to affect a .conf file to a specific submodel ?

the easiest way is to change the driver name per model.
for example, emu10k1 driver provides "EMU10k1", "Audigy" and
"Audigy2" according to the model.


Takashi


-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn

Re: Alsa handling of spdif bits (was Re: Questions to HDSP users)

[Thomas Charbonnel]

Takashi Iwai wrote :
> At Fri, 06 Feb 2004 12:22:08 +0100,
> Thomas Charbonnel wrote:
> 
>>(BTW Takashi iecset -h says 'audio on' is non-audio and 'audio off' is 
>>audio but it seems to be the other way round, unless the hdsp driver is 
>>wrong here...)
> 
> 
> yep, fixed now on CVS :)
> 
> 
>>The problem I see and I dislike with this is that iec bits are 
>>associated with playback. This is probably fine with most devices, but 
>>not with hardware that can do hardware routing, where you may want to 
>>route signal through the S/PDIF out with a certain bit combination - no 
>>playback is involved here. I believe a generic iec bits handling 
>>interface is a good thing, but is should not be affected by the card's 
>>status. Any comment on this Takashi ?
> 
> 
> well, in that case, the put callback of "IEC958 Playback Default"
> should change the corresponding register value immediately, too.
>

Ok, but it seems this can't be done with iecset, so I'm back with my 
question concerning amixer : all the 'value' fields of IEC ctls show a 
question mark. Is this a problem with the driver ? If not what would be 
the syntax to access those ctls ?

> 
> 
>>>An aside: this is also complicated because to open the device, the
>>>channels item in the slave.pcm section must match the iobox in
>>>use (multiface or digiface) which have differing channel counts.
>>>So when we do get this working, it will be a problem to handle
>>>both cases in a conf file.
>>>
>>
>>Not to mention that there is also a shift in the S/PDIF channels
>>position when the card changes speed mode...
>>Can the current configuration mechanism handle this properly ?
> 
> 
> when the channel position changes dynamically according to the certain
> state, it'd be difficult with the current config without addition...
>

In case you plan to implement those additions, let me know if there is 
anything to adapt on the driver side.

> 
>>Similarly we would need different .conf files for the different hdsp
>>cards, but seeing Takashi's patch, it seems .conf files are associated
>>with a card using the generic driver name (here 'H-DSP'). Is there a way
>>to affect a .conf file to a specific submodel ?
> 
> 
> the easiest way is to change the driver name per model.
> for example, emu10k1 driver provides "EMU10k1", "Audigy" and
> "Audigy2" according to the model.
> 

Ok, this will be part of the driver update I'm working on ATM.

Thomas




-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn

Re: Alsa handling of spdif bits (was Re: Questions to HDSP users)

[Takashi Iwai]

At Fri, 06 Feb 2004 14:14:22 +0100,
Thomas Charbonnel wrote:
> 
> >>The problem I see and I dislike with this is that iec bits are 
> >>associated with playback. This is probably fine with most devices, but 
> >>not with hardware that can do hardware routing, where you may want to 
> >>route signal through the S/PDIF out with a certain bit combination - no 
> >>playback is involved here. I believe a generic iec bits handling 
> >>interface is a good thing, but is should not be affected by the card's 
> >>status. Any comment on this Takashi ?
> > 
> > 
> > well, in that case, the put callback of "IEC958 Playback Default"
> > should change the corresponding register value immediately, too.
> >
> 
> Ok, but it seems this can't be done with iecset,

hmm?  iecset will read/change "IEC958 Playback Default" (searching
both MIXER and PCM interfaces).
it doesn't change "IEC958 Playback PCM Stream", though.

>  so I'm back with my 
> question concerning amixer : all the 'value' fields of IEC ctls show a 
> question mark. Is this a problem with the driver ? If not what would be 
> the syntax to access those ctls ?

amixer doesn't handle IEC958 status properly.


> >>>An aside: this is also complicated because to open the device, the
> >>>channels item in the slave.pcm section must match the iobox in
> >>>use (multiface or digiface) which have differing channel counts.
> >>>So when we do get this working, it will be a problem to handle
> >>>both cases in a conf file.
> >>>
> >>
> >>Not to mention that there is also a shift in the S/PDIF channels
> >>position when the card changes speed mode...
> >>Can the current configuration mechanism handle this properly ?
> > 
> > 
> > when the channel position changes dynamically according to the certain
> > state, it'd be difficult with the current config without addition...
> >
> 
> In case you plan to implement those additions, let me know if there is 
> anything to adapt on the driver side.

sure.

anyway, we'll need to discuss the best way for this problem.
i'd like to avoid addition as much as possible.


Takashi


-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn

Re: Alsa handling of spdif bits (was Re: Questions to HDSP users)

[Thomas Charbonnel]

Takashi Iwai wrote :

> At Fri, 06 Feb 2004 14:14:22 +0100,
> Thomas Charbonnel wrote:
> 
>>>>The problem I see and I dislike with this is that iec bits are 
>>>>associated with playback. This is probably fine with most devices, but 
>>>>not with hardware that can do hardware routing, where you may want to 
>>>>route signal through the S/PDIF out with a certain bit combination - no 
>>>>playback is involved here. I believe a generic iec bits handling 
>>>>interface is a good thing, but is should not be affected by the card's 
>>>>status. Any comment on this Takashi ?
>>>
>>>
>>>well, in that case, the put callback of "IEC958 Playback Default"
>>>should change the corresponding register value immediately, too.
>>>
>>
>>Ok, but it seems this can't be done with iecset,
> 
> 
> hmm?  iecset will read/change "IEC958 Playback Default" (searching
> both MIXER and PCM interfaces).
> it doesn't change "IEC958 Playback PCM Stream", though.
>

Ok, sorry, it took me some time to get it. The problem then is that the 
hdsp driver does not implement this the proper way at the moment (and it 
should be broken also for rme9652 cards because the code comes from 
there). I will fix that soon.

> 
>> so I'm back with my 
>>question concerning amixer : all the 'value' fields of IEC ctls show a 
>>question mark. Is this a problem with the driver ? If not what would be 
>>the syntax to access those ctls ?
> 
> 
> amixer doesn't handle IEC958 status properly.
> 
> 

IIUC, this ctl is supposed to be used for example by DVD playing 
applications so that the fact they may temporary require the Non-Audio 
bit to be set for AC3 passthru does not interfere with the user settings ?
If so I'll keep this ctl and implement it properly.

Anyway thanks for clarifying, it was much needed :)
Thomas




-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn

Re: Alsa handling of spdif bits (was Re: Questions to HDSP users)

[Takashi Iwai]

At Fri, 06 Feb 2004 20:12:44 +0100,
Thomas Charbonnel wrote:
> 
> >> so I'm back with my 
> >>question concerning amixer : all the 'value' fields of IEC ctls show a 
> >>question mark. Is this a problem with the driver ? If not what would be 
> >>the syntax to access those ctls ?
> > 
> > 
> > amixer doesn't handle IEC958 status properly.
> > 
> > 
> 
> IIUC, this ctl is supposed to be used for example by DVD playing 
> applications so that the fact they may temporary require the Non-Audio 
> bit to be set for AC3 passthru does not interfere with the user settings ?

yes and no.  these bits are set as the parameters of PCM hook plugin.
you can open an spdif PCM with parameters like

	iec958:{AES0=XXX,AES1=XXX,AES2=XXX,AES3=XXX} 

to pass the proper status bits (this will change "IEC958 Plaback PCM
Stream" usually).  xine and mplayer pass these parameters at the open
time.

but my statement above means that amixer doesn't display/parse
correctly this data type (iec958).  it's just a missing feature of
amixer.  it'd be better if amixer handles it correctly.


> If so I'll keep this ctl and implement it properly.
> 
> Anyway thanks for clarifying, it was much needed :)

well, this should be more better documented.
(the patch to the doc is also welcome, BTW ;)


ciao,

Takashi


-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn