* SPDIF audio / non-audio bit @ 2008-08-14 14:48 Ben Stanley 2008-08-14 15:19 ` Takashi Iwai 0 siblings, 1 reply; 6+ messages in thread From: Ben Stanley @ 2008-08-14 14:48 UTC (permalink / raw) To: alsa-devel 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: SPDIF audio / non-audio bit 2008-08-14 14:48 SPDIF audio / non-audio bit Ben Stanley @ 2008-08-14 15:19 ` Takashi Iwai 2008-08-15 14:45 ` Ben Stanley 0 siblings, 1 reply; 6+ messages in thread From: Takashi Iwai @ 2008-08-14 15:19 UTC (permalink / raw) To: Ben Stanley; +Cc: alsa-devel 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: SPDIF audio / non-audio bit 2008-08-14 15:19 ` Takashi Iwai @ 2008-08-15 14:45 ` Ben Stanley 2008-08-15 14:59 ` Takashi Iwai 0 siblings, 1 reply; 6+ messages in thread From: Ben Stanley @ 2008-08-15 14:45 UTC (permalink / raw) To: Takashi Iwai; +Cc: alsa-devel 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. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: SPDIF audio / non-audio bit 2008-08-15 14:45 ` Ben Stanley @ 2008-08-15 14:59 ` Takashi Iwai 2008-08-15 15:56 ` Ben Stanley 0 siblings, 1 reply; 6+ messages in thread From: Takashi Iwai @ 2008-08-15 14:59 UTC (permalink / raw) To: Ben Stanley; +Cc: alsa-devel 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: SPDIF audio / non-audio bit 2008-08-15 14:59 ` Takashi Iwai @ 2008-08-15 15:56 ` Ben Stanley 2008-08-15 16:01 ` Takashi Iwai 0 siblings, 1 reply; 6+ messages in thread From: Ben Stanley @ 2008-08-15 15:56 UTC (permalink / raw) To: Takashi Iwai; +Cc: alsa-devel 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. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: SPDIF audio / non-audio bit 2008-08-15 15:56 ` Ben Stanley @ 2008-08-15 16:01 ` Takashi Iwai 0 siblings, 0 replies; 6+ messages in thread From: Takashi Iwai @ 2008-08-15 16:01 UTC (permalink / raw) To: Ben Stanley; +Cc: alsa-devel 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2008-08-15 16:01 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2008-08-14 14:48 SPDIF audio / non-audio bit Ben Stanley 2008-08-14 15:19 ` Takashi Iwai 2008-08-15 14:45 ` Ben Stanley 2008-08-15 14:59 ` Takashi Iwai 2008-08-15 15:56 ` Ben Stanley 2008-08-15 16:01 ` Takashi Iwai
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.