[alsa-devel] ALC892 optical SPDIF not working

[Takashi Iwai]

At Sat, 7 Aug 2010 10:11:16 +0200,
Manuel Lauss wrote:
> 
> On Thu, Aug 05, 2010 at 10:11:18PM +0200, Takashi Iwai wrote:
> > At Thu, 5 Aug 2010 20:52:28 +0200,
> > Manuel Lauss wrote:
> > > 
> > > On Mon, Aug 02, 2010 at 06:03:32PM +0200, Takashi Iwai wrote:
> > > > At Mon, 02 Aug 2010 10:02:48 +0200,
> > > > I wrote:
> > > > > 
> > > > > At Sun, 1 Aug 2010 01:32:23 +0200,
> > > > > Manuel Lauss wrote:
> > > > > > 
> > > > > > > > >> Is there a way to insert an initial playback delay?  Under linux, the
> > > > > > > > >> first 2-2.5 seconds
> > > > > > > > >> of anything played are just silence; on windows audible playback
> > > > > > > > >> starts immediately.
> > > > > > > > >
> > > > > > > > > It's the time for synchronization your digital receiver takes, I guess.
> > > > > > > > > Maybe changing SPDIF status makes it resync, which happens at each
> > > > > > > > > opening / closing the stream.
> > > > > > > > 
> > > > > > > > Yes, seems so. I've found a workaround in meantime.
> > > > > > > 
> > > > > > > Could you elaborate on the workaround please, so others having this
> > > > > > > issue know it.
> > > > > > 
> > > > > > My receiver allows to mix analog and digital inputs; with analog mix
> > > > > > enabled it syncs immediately.
> > > > > 
> > > > > Just wondering whether the patch below helps?
> > > > > 
> > > > > It's just a proof-of-concept, and it's not safe for multiple streams.
> > > > > If this works, we can move on the improvement of the stream assignment.
> > > > 
> > > > ... and the below is the patch.  If the previous patch worked, try
> > > > this instead of the previous one.
> > > 
> > > 
> > > Tested with mplayer.  The initial 2-2.5sec silence is still there (on every
> > > invocation of mplayer), but seeking now works as it should (previously
> > > there was 2 sec silence too).  Disabling codec pm doesn't help.
> > 
> > OK, it's a slight improvement.  Now the question is why it still happens
> > at each invocation of mplayer.  Assuming that it's no power-save, one
> > possible explanation is the call of azx_stream_reset() in prepare.
> > But, then this should happen at each seek, too.
> > 
> > Could you put some printk's and check whether AC_VERB_SET_CHANNEL_STREAMID
> > and/or AC_VERB_GET_STREAM_FORMAT verbs are executed at each time or
> > properly cached?
> 
> Something new in the dmesg:
> 
> hda_codec: ALC892: BIOS auto-probing.
> ALSA hda_codec.c:337: hda_codec: connection list not available for 0x1f
> ALSA device list:
>   #0: HDA ATI SB at 0xfe024000 irq 16
> 
> 
> I added a few printks (see patch below).  This is the output generated
> at every invocation of mplayer:
> 
> S1: p->stream_tag 00000000 stream_tag 00000005 p->channel_id 0 channel_id 0
> S2: oldval 0 newval 50
> S3: p->format_id 0 format 49
> S4: oldval 0 newval 50
> S1: p->stream_tag 00000000 stream_tag 00000005 p->channel_id 0 channel_id 0
> S2: oldval 0 newval 50
> S3: p->format_id 0 format 49
> S4: oldval 0 newval 50
> S1: p->stream_tag 00000000 stream_tag 00000005 p->channel_id 0 channel_id 0
> S2: oldval 0 newval 50
> S3: p->format_id 0 format 49
> S4: oldval 0 newval 50
> S1: p->stream_tag 00000000 stream_tag 00000005 p->channel_id 0 channel_id 0
> S2: oldval 0 newval 50
> S3: p->format_id 0 format 49
> S4: oldval 0 newval 50
> S1: p->stream_tag 00000000 stream_tag 00000005 p->channel_id 0 channel_id 0
> S2: oldval 0 newval 50
> S3: p->format_id 0 format 49
> S4: oldval 0 newval 50

There was one line missing in my previous patch, which was fixed in
the sound git tree now.  But it's irrelevant with this reset issue,
and I can't observe the behavior with analog outputs on my machine
unless power-saving is set.

Did you disable power-saving?  On many machines, the HD-audio driver
is powered down after one or two seconds of the PCM close.  Then the
driver must reset the stream/format tags at the next open.


Takashi