On Tue, October 20, 2009 23:43, Shane W wrote: > I know this has come up before but can't we not start/stop > the infoframe if the sample format on the new track is the > same as the old. I mean playing an album, you're gonna get > 44100, 2ch s16le 95% of the time so that would atleast > cause the problem to appear much less. Looking at the HDMI spec, the only case where the infoframe is likely to change is where you change the number of channels (all other fields are set to zero - refer to stream header), so the infoframe is likely to still be valid even if you first play a 44.1kHz, 2ch s16le clip followed by a 96kHz, 2ch s32le clip (for example). And I'm guessing this approach might fix the problems I'm seeing as well...I'll try writing a test patch. Fengguang, note that if you do change the sizeof(ai) call in hdmi_fill_audio_infoframe that I mentioned, it seems that a 14-byte struct will be written to a 13-byte DIP buffer and I'm not sure if that will cause the packet byte index to wrap to zero (meaning that the first byte of the buffer will be overwritten with the last byte of the struct). Still not sure why the buffer is 13 bytes though... -- David Härdeman ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ Alsa-user mailing list Alsa-user@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/alsa-user
