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?
thanks,
Takashi