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