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

[Takashi Iwai]

At 03 Apr 2007 18:24:17 +0200,
Dag Lem wrote:
> 
> Takashi Iwai <tiwai at suse.de> writes:
> 
> [...]
> 
> > Well, I don't remember whether 44kHz worked on my test system, and
> > currently I cannot test right now.
> 
> OK. This means that currently we don't know for sure whether the frame
> rate problem is specific to Realtek chips. Do you know of anyone who
> is likely to have tested 44.1kHz over S/PDIF?

No, I hope someone will answer on ML.

> > 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.
> 
> As far as I can tell the IEC958 rate setting (as reported by iecset)
> is not used for anything. Which IHMO is good, as it would only
> complicate things. If I'm mistaken and it *is* used for something,
> then it would likely cause problems.

iecset can't show any rate information because the bits aren't handled
at all in the driver.  The only question is whether the codec chip
really handles or not.

> > 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?
> 
> Correct, the receiver detects a 48kHz frame rate, regardless of the
> frame rate setting in the ALC882M digital converter (NID 0x06). What I
> am trying to do is actually PCM at 44.1kHz, and the ALC88M is not
> cooperating. I have also tried 96kHz and 192kHz without success -
> whatever I do the S/PDIF frame rate is locked at 48kHz. If I connect a
> CD player to the receiver, the receiver detects 44.1kHz as expected.
> 
> The resulting sound is quite unpleasant. I believe missing samples are
> simply repeated to convert from 44.1kHz to 48kHz (I have some hands-on
> experience with resampling and the harshness in high-pitched sounds
> leads me to this conclusion).
> 
> Thanks again, I hope these problems can be resolved. I'll test your
> patch tomorrow.

You can try also iec958 alsa-lib plugin.
Define a PCM like below in ~/.asoundrc:

pcm.spdif44 {
	type iec958
	slave {
		pcm {
			type hw
			card 0
			device 1
			# whatever you like
		}
		format IEC958_SUBFRAME_LE
	}
	# the below should be corrected with 44.1kHz rates
	status [ 0x04 0x92 0x10 0x02 ]
}

This plugin then will convert samples to 32bit SPDIF frames, send to
the specified slave PCM.

Now play 2channel 16bit samples via this device:
	% aplay -Dspdif44 any-44khz-samples.wav

Currently, the status bits won't be changed dynamically via sample
rate, so you have to define it beforehand in asoundrc.  I'll fix it
later if this approach somehow works...

Maybe you should try the above first with 48kHz (and copy the proper
status bits).  Of course, make sure that you're using the latest
alsa-lib.


Takashi