[alsa-devel] iec958 switch uneffective while playing ac3 stream

[Takashi Iwai]

At Fri, 30 Mar 2007 18:57:39 +0200,
Dominique Dumont wrote:
> 
> Dag Lem <dag at nimrod.no> writes:
> 
> > Did you try my workaround cookbook?
> >
> > 1. Turn off IEC958 in alsamixer.
> > 2. Play and interrupt a 44.1kHz PCM with aplay.
> > 3. Turn on IEC958 in alsamixer.
> > 4. Play AC3 stream.
> 
> Yes ! It works !
> 
> Now I have a lead ( and a trace of all verbs sent to the codec).
> 
> > I have also read while googling that the "WAV volume" in Windows
> > drivers must be set to max in order for S/PDIF output to work. I
> > assume this is the same as PCM volume in ALSA.
> 
> Currently, it works while PCM is at 82 (according to alsamixer)

Hm, I thought AC3 should have worked as it is.
A possible problem is in the case that other apps already occupied the
stream.  Currently, the digital output is automatically assigned
together when an analog output is opened.  This is because most of
users want to output the "audio" data to SPDIF output without hustle
if they have a receiver.  When trying to open the dedicated SPDIF for
AC3, then it fails because the digital stream was already opened by
the process for analog streams.

Or, it's simply some missing setup by apps.  The app sending the
non-audio streams like AC3 over SPDIF is supposed to set up the IEC958
status bits appropriately at opening the stream.  The IEC958 bits can
be passed via arguments for the "spdif" (or "iec958") PCM.  For
example, ac3dec in alsa-tools openes like

	plug:iec958:{AES0 0x.. AES1 0x..... AES3 0x..}

where the hex numbers represent status bits.  These numbers can be
shown via iecset utility with -x option.  So, you can check via iecset
whether the parameters are set up properly when you start an app
accessing SPDIF.


Takashi