At Fri, 30 Mar 2007 18:57:39 +0200, Dominique Dumont wrote:
Dag Lem dag@nimrod.no writes:
Did you try my workaround cookbook?
- Turn off IEC958 in alsamixer.
- Play and interrupt a 44.1kHz PCM with aplay.
- Turn on IEC958 in alsamixer.
- 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