[alsa-devel] IEC switch issues
If I play my AC3 data on my HDAudio/SPDIF output using the hw:0,1 device, I can use alsamixer/amixer to mute/unmute.
[ume@plb PassThough]$ amixer cset numid=12 on numid=12,iface=MIXER,name='IEC958 Playback Switch' ; type=BOOLEAN,access=rw------,values=1 : values=on [ume@plb PassThough]$ amixer cset numid=12 off numid=12,iface=MIXER,name='IEC958 Playback Switch' ; type=BOOLEAN,access=rw------,values=1 : values=off
Now if I use the iec958: plugin, I can't control the mute switch any longer: [ume@plb PassThough]$ amixer cset numid=12 off amixer: Control default element write error: Operation not permitted
[ume@plb PassThough]$ amixer cset numid=12 on amixer: Control default element write error: Operation not permitted
What could possibly cause this issue? the IEC plugin relies on the device 1, am I missing something here? Thanks for your help - Pierre
pl bossart napsal(a):
If I play my AC3 data on my HDAudio/SPDIF output using the hw:0,1 device, I can use alsamixer/amixer to mute/unmute.
[ume@plb PassThough]$ amixer cset numid=12 on numid=12,iface=MIXER,name='IEC958 Playback Switch' ; type=BOOLEAN,access=rw------,values=1 : values=on [ume@plb PassThough]$ amixer cset numid=12 off numid=12,iface=MIXER,name='IEC958 Playback Switch' ; type=BOOLEAN,access=rw------,values=1 : values=off
Now if I use the iec958: plugin, I can't control the mute switch any longer: [ume@plb PassThough]$ amixer cset numid=12 off amixer: Control default element write error: Operation not permitted
[ume@plb PassThough]$ amixer cset numid=12 on amixer: Control default element write error: Operation not permitted
What could possibly cause this issue? the IEC plugin relies on the device 1, am I missing something here? Thanks for your help
- Pierre
Hi Pierre,
Check the config files in /usr/share/alsa/cards, probably HDA-Intel.conf in your case, specifically the hooks section of its iec958 device definition. It reads:
hooks.0 { type ctl_elems hook_args [ { name "IEC958 Playback Default" lock true preserve true value [ $AES0 $AES1 $AES2 $AES3 ] } { name "IEC958 Playback Switch" lock true preserve true value true } ] }
You can play with the "lock" directive.
Best regards,
Pavel.
pl bossart wrote:
If I play my AC3 data on my HDAudio/SPDIF output using the hw:0,1 device, I can use alsamixer/amixer to mute/unmute.
Now if I use the iec958: plugin, I can't control the mute switch any longer:
Muting an AC-3 stream would require encoding a stream of silent PCM samples (no data is not the same as silence); therefore, the iec958 plugin disallows muting.
Regards, Clemens
2010/6/23 Clemens Ladisch clemens@ladisch.de
pl bossart wrote:
If I play my AC3 data on my HDAudio/SPDIF output using the hw:0,1 device, I can use alsamixer/amixer to mute/unmute.
Now if I use the iec958: plugin, I can't control the mute switch any
longer:
Muting an AC-3 stream would require encoding a stream of silent PCM samples (no data is not the same as silence); therefore, the iec958 plugin disallows muting.
Regards, Clemens
Does it mean that rewind is not allowed too ?
If I play my AC3 data on my HDAudio/SPDIF output using the hw:0,1 device, I can use alsamixer/amixer to mute/unmute.
Now if I use the iec958: plugin, I can't control the mute switch any longer:
Muting an AC-3 stream would require encoding a stream of silent PCM samples (no data is not the same as silence); therefore, the iec958 plugin disallows muting.
Actually the problem happens also with plain PCM rendered on the iec958 device.There's no way to use the IEC switch. So why do we have an S/PDIF switch in the first place? If it cannot be used when you sent IEC-formatted data (be that PCM or AC3-formatted data), then why bother? Allowing for mute doesn't have any impact on functionality, and it prevents the user from muting with alsamixer or a gui. I find this silly, or I am missing something.
pl bossart wrote:
If I play my AC3 data on my HDAudio/SPDIF output using the hw:0,1 device, I can use alsamixer/amixer to mute/unmute.
Now if I use the iec958: plugin, I can't control the mute switch any longer:
Muting an AC-3 stream would require encoding a stream of silent PCM samples (no data is not the same as silence); therefore, the iec958 plugin disallows muting.
Actually the problem happens also with plain PCM rendered on the iec958 device.There's no way to use the IEC switch. So why do we have an S/PDIF switch in the first place?
Because the hardware has this switch; the driver just exposes all hardware features.
If it cannot be used when you sent IEC-formatted data (be that PCM or AC3-formatted data), then why bother?
Some codecs allow looping back the ADC output to the SPDIF transmitter. In these cases, disabling the SPDIF transmitter might be useful.
Regards, Clemens
Actually the problem happens also with plain PCM rendered on the iec958 device.There's no way to use the IEC switch. So why do we have an S/PDIF switch in the first place?
Because the hardware has this switch; the driver just exposes all hardware features.
Then why not use it if it is supported by the hardware? Usually we use software as a workaround for hw limitations, not software to prevent use of hardware features.
Some codecs allow looping back the ADC output to the SPDIF transmitter. In these cases, disabling the SPDIF transmitter might be useful.
I am not sure I understand how your remark is related to the problem I reported. Yes disabling SPDIF whenever needed is a must. And no there's no risk with enabling the IEC switch when rendering on the iec958 device. I have IEC-formatted data, with C,U,V,P bits and preambles, this could not possibly be sent to anything else than the digital output. Again the IEC switch is functionally equivalent to a mute, and it shows as such in alsamixer with the MM symbol: the data keeps being rendered, only the receiver doesn't detect valid data (no sync detected) and will go to silence with an appropriate ramp. For AC3 passthrough, the filter history will be reset when the sync is lost, and that will cause an implicit fade-out/fade-in in addition to the PCM ramp. There is no need as you asserted to send zeroes instead. Removing the 'lock true' in /usr/share/alsa/cards/HDA-Intel.conf h works just fine to enable IEC controls. Thanks Pavel for the pointer. I suggest we modify this to remove artificial functionality limitations.
participants (4)
-
Clemens Ladisch -
Pavel Hofman -
pl bossart -
Raymond Yau