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

Takashi Iwai tiwai at suse.de
Tue Apr 3 16:29:36 CEST 2007


At 03 Apr 2007 12:26:52 +0200,
Dag Lem wrote:
> 
> Takashi Iwai <tiwai at suse.de> writes:
> 
> [...]
> 
> > 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.
> 
> Thanks for taking an interest in this.
> 
> I've been scratching my head here for a while, and we seem to have
> initialization problems with the Realtek ALC88x chips (mine is marked
> ALC882M). One workaround for AC3/DTS, as mentioned in today's reply to
> Dominique, is to turn the IEC958 switch off, start playing, then turn
> the IEC958 switch on while playing. Opening the (first) stream while
> the IEC958 switch is on simply doesn't work - the connected amplifier
> doesn't detect the AC3/DTS stream.
> 
> The more serious problem, for which I have no workaround, is that it
> doesn't seem to be possible to lock the S/PDIF output frame rate to
> anything but 48kHz. I am using hw:0,1 and not the default device
> (which resamples to 48kHz). Can you confirm that it is possible to
> achieve e.g. 44.1kHz frame rate over S/PDIF using the HDA driver
> (using any chip)?

Well, I don't remember whether 44kHz worked on my test system, and
currently I cannot test right now.

The HD-audio DIGI_CONVERT* verb itself has no rate information but it
contains only a part of IEC958 status bits.  It seems that the rate is
referred from the setting of the corresponding audio output widget.

In your case, your receiver doesn't recognize if it's 44kHZ?  What
about audio (PCM) samples via 44.1kHz over SPDIF?  I assume the driver
doesn't produce any error but you see the problem in the receiver
side, right?

In theory, we can switch to use the raw 32bit SPDIF frames and let
alsa-lib convert it.  But I'd like to fix the current code rather than
this way if possible.

> Do you happen to have any contacts at Realtek who may be able to sort
> out the S/PDIF frame rate problem? I tried contacting Realtek, but the
> reply I got unfortunately didn't answer any of my questions.

I don't think we have no contact regarding this...


Takashi


More information about the Alsa-devel mailing list