At Sun, 26 Jul 2009 23:21:50 -0700, Shane W wrote:

On Mon, Jul 27, 2009 at 08:07:40AM +0200, Takashi Iwai wrote:

...

At Sun, 26 Jul 2009 10:32:10 -0700, Shane W wrote:

...

I did some digging in the drivers to try and find the source of this problem. Note that I am really not familiar with this stuff. It appears to be here: hda_codec.c void snd_hda_codec_setup_stream(...) ... snd_hda_codec_write(codec, nid, 0, AC_VERB_SET_CHANNEL_STREAMID,

Introducing a delay after this point fixes the issue but it's around a full second so that's obviously not a solution. Could we not cache the current format and only do this when the format changes rather than on every device open?

The format itself is kept. But the stream tag and channel assignment are assigned dynamically at each open. Thus, this call has to be reset at each open, at least.

...

For testing, I tried doing this though and disabling the set_streamid, 0 call in snd_codec_cleanup() but it still missed those first samples. Is there somewhere else I need to be looking?

Does it happen without dmix, too?

Yeah, with and without dmix it still misses the first bit.

OK. I just thought of a possibility of dmix bug. Good to know that it's not :)

The only way it doesn't is if I have another program open the device and sleep, then have the samples play. Actually, an open isn't sufficient, it has to go and set the playback parameters as well.

It's logical since the stream and format ids are assigned dynamically first after the stream is set up.

One another problem is that we currently call azx_stream_reset() in each prepare callback in hda_intel.c. This was newly added because keeping the format id without resetting caused some other serious errors. Maybe this can be optimized for specific hardwares, e.g. skipping the unneeded reset for HDMI/SPDIF.

Takashi