[alsa-devel] SPDIF audio / non-audio bit
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
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
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.
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
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.
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
participants (2)
-
Ben Stanley -
Takashi Iwai