SPDIF audio / non-audio bit

SPDIF audio / non-audio bit

[Ben Stanley]

Dear alsa-devel,

I recently advised this list of some problems I experienced with the
SPDIF audio / non-audio bit being set inappropriately while using the
ca0106 driver [1]. Seeing as I got no replies, I am trying again.

When playing AC3 encoded streams (Dolby Digital, DTS), the SPDIF
non-audio bit is set. Otherwise, for PCM streams, the SPDIF is set to
audio.

Could someone explain to me what part of the software is responsible for
correctly setting the SPDIF audio / non-audio bit? Is it
* alsa-driver
* alsa-lib
* application  ?

It seems to me that currently some applications (MythTV, xine) set it
correctly, but most other applications ignore it. So if it is set to
non-audio (because for example MythTV crashed before re-setting it to
audio), then all applications that are not aware of the setting have
their audio broken.

Could someone set me straight here so that I can try to produce a
permanent fix for this?

Thanks,
Ben Stanley.

[1] http://thread.gmane.org/gmane.linux.alsa.devel/54398/focus=55188

Re: SPDIF audio / non-audio bit

[Takashi Iwai]

At Fri, 15 Aug 2008 00:48:41 +1000,
Ben Stanley wrote:
> 
> Dear alsa-devel,
> 
> I recently advised this list of some problems I experienced with the
> SPDIF audio / non-audio bit being set inappropriately while using the
> ca0106 driver [1]. Seeing as I got no replies, I am trying again.
> 
> When playing AC3 encoded streams (Dolby Digital, DTS), the SPDIF
> non-audio bit is set. Otherwise, for PCM streams, the SPDIF is set to
> audio.
> 
> Could someone explain to me what part of the software is responsible for
> correctly setting the SPDIF audio / non-audio bit? Is it
> * alsa-driver
> * alsa-lib
> * application  ?

It's application, basically.  The app can let alsa-lib set the default
values, though.

> It seems to me that currently some applications (MythTV, xine) set it
> correctly, but most other applications ignore it. So if it is set to
> non-audio (because for example MythTV crashed before re-setting it to
> audio), then all applications that are not aware of the setting have
> their audio broken.

Some drivers have the independent PCM IEC958 status bits while many
have only the default IEC958 status bits.  In the former case, the
driver resets automatically the status bits after closing the PCM
stream.  Your case is the latter one, which doesn't reset.  In this
case, usually alsa-lib takes the old setting back.  But when the
program crashes (or aborted unexpectedly), the new setting is kept
even after that, as you described in the above.

> Could someone set me straight here so that I can try to produce a
> permanent fix for this?

You can change the status easily via iecset program in alsa-utils.

Maybe it's safer to have an independent PCM iec958 setting on all
drivers.  But this requires the change in alsa-lib (system) config,
i.e. it may cause an incompatibility with older alsa-lib configs.
This is an only drawback, I think.


Takashi

Re: SPDIF audio / non-audio bit

[Ben Stanley]

On Thu, 2008-08-14 at 17:19 +0200, Takashi Iwai wrote:
> Some drivers have the independent PCM IEC958 status bits while many
> have only the default IEC958 status bits.  In the former case, the
> driver resets automatically the status bits after closing the PCM
> stream.  Your case is the latter one, which doesn't reset.  In this
> case, usually alsa-lib takes the old setting back.  But when the
> program crashes (or aborted unexpectedly), the new setting is kept
> even after that, as you described in the above.

Could you please clarify 
'independent PCM IEC958 status bits' vs 
'default IEC958 status bits', 
perhaps by pointing out some drivers implementing each type?
> 
> > Could someone set me straight here so that I can try to produce a
> > permanent fix for this?
> 
> You can change the status easily via iecset program in alsa-utils.
I note here that iecset does not accept --device=hw:0,1 for example. Any
reason for this?
> 
> Maybe it's safer to have an independent PCM iec958 setting on all
> drivers.  But this requires the change in alsa-lib (system) config,
> i.e. it may cause an incompatibility with older alsa-lib configs.
> This is an only drawback, I think.
I will try to figure this out after I have validated and submitted my
44100Hz patch for ca0106.

Ben.

Re: SPDIF audio / non-audio bit

[Takashi Iwai]

At Sat, 16 Aug 2008 00:45:33 +1000,
Ben Stanley wrote:
> 
> 
> On Thu, 2008-08-14 at 17:19 +0200, Takashi Iwai wrote:
> > Some drivers have the independent PCM IEC958 status bits while many
> > have only the default IEC958 status bits.  In the former case, the
> > driver resets automatically the status bits after closing the PCM
> > stream.  Your case is the latter one, which doesn't reset.  In this
> > case, usually alsa-lib takes the old setting back.  But when the
> > program crashes (or aborted unexpectedly), the new setting is kept
> > even after that, as you described in the above.
> 
> Could you please clarify 
> 'independent PCM IEC958 status bits' vs 
> 'default IEC958 status bits', 
> perhaps by pointing out some drivers implementing each type?

Run the following:
	grep -r 'IEC958.*PCM_STREAM' sound/pci

These drivers have "IEC958 Playback PCM Stream" controls.  These
controls are assigned to PCM streams, and changed individually from
the "IEC958 Playback Default" control.  When the PCM stream is closed,
it's back to the status of "IEC958 Playback Default".


> > > Could someone set me straight here so that I can try to produce a
> > > permanent fix for this?
> > 
> > You can change the status easily via iecset program in alsa-utils.
> I note here that iecset does not accept --device=hw:0,1 for example. Any
> reason for this?

Because it's invalid.  The --device option is for a control device,
not for a PCM device.  If you want to change the secondary control
(i.e. "IEC958 Playback Default" with index=1), pass "-n 1" to iecset.


Takashi

Re: SPDIF audio / non-audio bit

[Ben Stanley]

On Fri, 2008-08-15 at 16:59 +0200, Takashi Iwai wrote:
> At Sat, 16 Aug 2008 00:45:33 +1000,
> Ben Stanley wrote:
> > Could you please clarify 
> > 'independent PCM IEC958 status bits' vs 
> > 'default IEC958 status bits', 
> > perhaps by pointing out some drivers implementing each type?
> 
> Run the following:
> 	grep -r 'IEC958.*PCM_STREAM' sound/pci
> 
> These drivers have "IEC958 Playback PCM Stream" controls.  These
> controls are assigned to PCM streams, and changed individually from
> the "IEC958 Playback Default" control.  When the PCM stream is closed,
> it's back to the status of "IEC958 Playback Default".
> 
Thanks for the info.
> 
> > > You can change the status easily via iecset program in alsa-utils.
> > I note here that iecset does not accept --device=hw:0,1 for example. Any
> > reason for this?
> 
> Because it's invalid.  The --device option is for a control device,
> not for a PCM device.  If you want to change the secondary control
> (i.e. "IEC958 Playback Default" with index=1), pass "-n 1" to iecset.
> 
um, that doesn't work either.

mythtv@mythtv:~$ iecset -D=hw:0 -n 1 audio on
iecset: invalid option -- n
Usage: iecset [options] [cmd arg...]
Options:
    -D device   specifies the control device to use
    -c card     specifies the card number to use (equiv. with -Dhw:#)
    -x          dump the dump the AESx hex code for IEC958 PCM
parameters
    -i          read commands from stdin
Commands:
    professional (common)
    off = consumer mode, on = professional mode
    audio (common)
    on = audio mode, off = non-audio mode
    rate (common)
    sample rate in Hz
    emphasis (common)
    0 = none, 1 = 50/15us, 2 = CCITT
    lock (prof.)
    off = rate unlocked, on = rate locked
    sbits (prof.)
    sample bits 2 = 20bit, 4 = 24bit, 6 = undef
    wordlength (prof.)
    0=no, 2=22-18bit, 4=23-19bit, 5=24-20bit, 6=20-16bit
    category (consumer)
    0-0x7f
    copyright (consumer)
    off = non-copyright, on = copyright
    original (consumer)
    off = 1st-gen, on = original

I see that I have alsa-utils 1.0.15-3ubuntu2 (from ubuntu 8.04). Perhaps
my version is too old?

I will use my clunky old method for now, but I would like to clear up
this iecset issue.

Ben.

Re: SPDIF audio / non-audio bit

[Takashi Iwai]

At Sat, 16 Aug 2008 01:56:14 +1000,
Ben Stanley wrote:
> 
> On Fri, 2008-08-15 at 16:59 +0200, Takashi Iwai wrote:
> > At Sat, 16 Aug 2008 00:45:33 +1000,
> > Ben Stanley wrote:
> > > Could you please clarify 
> > > 'independent PCM IEC958 status bits' vs 
> > > 'default IEC958 status bits', 
> > > perhaps by pointing out some drivers implementing each type?
> > 
> > Run the following:
> > 	grep -r 'IEC958.*PCM_STREAM' sound/pci
> > 
> > These drivers have "IEC958 Playback PCM Stream" controls.  These
> > controls are assigned to PCM streams, and changed individually from
> > the "IEC958 Playback Default" control.  When the PCM stream is closed,
> > it's back to the status of "IEC958 Playback Default".
> > 
> Thanks for the info.
> > 
> > > > You can change the status easily via iecset program in alsa-utils.
> > > I note here that iecset does not accept --device=hw:0,1 for example. Any
> > > reason for this?
> > 
> > Because it's invalid.  The --device option is for a control device,
> > not for a PCM device.  If you want to change the secondary control
> > (i.e. "IEC958 Playback Default" with index=1), pass "-n 1" to iecset.
> > 
> um, that doesn't work either.
> 
> mythtv@mythtv:~$ iecset -D=hw:0 -n 1 audio on
> iecset: invalid option -- n
> Usage: iecset [options] [cmd arg...]
> Options:
>     -D device   specifies the control device to use
>     -c card     specifies the card number to use (equiv. with -Dhw:#)
>     -x          dump the dump the AESx hex code for IEC958 PCM
> parameters
>     -i          read commands from stdin
> Commands:
>     professional (common)
>     off = consumer mode, on = professional mode
>     audio (common)
>     on = audio mode, off = non-audio mode
>     rate (common)
>     sample rate in Hz
>     emphasis (common)
>     0 = none, 1 = 50/15us, 2 = CCITT
>     lock (prof.)
>     off = rate unlocked, on = rate locked
>     sbits (prof.)
>     sample bits 2 = 20bit, 4 = 24bit, 6 = undef
>     wordlength (prof.)
>     0=no, 2=22-18bit, 4=23-19bit, 5=24-20bit, 6=20-16bit
>     category (consumer)
>     0-0x7f
>     copyright (consumer)
>     off = non-copyright, on = copyright
>     original (consumer)
>     off = 1st-gen, on = original
> 
> I see that I have alsa-utils 1.0.15-3ubuntu2 (from ubuntu 8.04). Perhaps
> my version is too old?

Yep.


Takashi