On Wed, Nov 04, 2009 at 06:54:36PM +0800, David Härdeman wrote: > On Tue, November 3, 2009 15:09, Wu Fengguang wrote: > > This is interesting. In my ALSA tests on YAMAHA RX1800: > > (1) 6 channels light up on "speaker-test -c6" > > (2) 2 channels light up on playing normal music > > (3) when not playing anything, 2 channels remain light up > > (4) need to double check the "pause" case > > > > So you mean Windows 7 always light up 6 channels for cases (2) and (3), > > besides case (1)? (under your 5.1 speaker config) > > Yes, once I've configured a 5.1 speaker setup (using the control panel in > Windows 7), 6 channels are indicated on the receiver and it stays that way > for all cases (1) - (4) you mentioned. OK, thanks. > >> The windows driver also has some interesting registry entries referring > >> to > >> "SilentStream" and "VCFG", the latter probably referring to the VCFG bit > >> in the digital converter control reg in section 7.3.3.9 of the HDA > >> spec). > > > > Yeah, it's interesting to have some "SilentStream": > > > > V (Validity): This bit affects the "Validity flag," bit[28] > > transmitted in each subframe, and enables the S/PDIF > > transmitter to maintain connection during error or mute > > conditions. > > Is that flag transmitted over HDMI as well? Might need to check more docs > but perhaps you already know the answer? Yes, an uncompressed HDMI is send in an IEC 60958-3 compliant stream, which is defined in "IEC 60958-3 Digital Audio Interface - Part 3: Consumer Applications, First Edition, 1999". Obviously the windows Intel HDMI driver can reuse this SPDIF feature :) > >> Also, it's interesting to note that when I am playing a working audio > >> sample under Linux, then pause and resume playing (using the UI > >> controls), > >> there are no hiccups and no initial silence when the player resumes > >> (from > >> a quick reading of the code, the audio infoframe should still be > >> transmitted, only DMA of audio data is stopped when pcm is paused). > > > > Good catch! > > > > The stop/start of a playback involves many operations - including the > > AC_VERB_SET_CHANNEL_STREAMID which seem to directly related to the 0.5s > > lost samples problem. > > I agree that changing the STREAMID (and perhaps STREAM_FORMAT) seems to > cause the lost samples. > > I haven't tried your latest patchset yet, I've been busy testing some > other approaches and reading Intel docs (the HDA spec is spread over quite > a lot of docs by now). > > In particular I found this document interesting: > http://download.intel.com/design/chipsets/hdaudio/HDA015-B.pdf > > >From page 11, first paragraph: > > KeepAlive (Keep Alive Enable): this bit is applicable only to > digital converter widget that is associated (selected by) an > Output Digital Pin Widget. This bit allows for software > programmed control of S/P-DIF, HDMI and Display Port interfaces > to continue to provide clocking information to an attached device. > Many such digitally connected audio devices can take more than one > second to start playing audio after the clock has stopped, which > occurs for example when the Converter and/or Digital Pin Widget > is placed into a low power state or even just when a stream is > stopped for S/P-DIF. > > Which describes the problems we're seeing pretty accurately. > > Unfortunately, the DG45FC HDMI codec doesn't support KeepAlive (I just > tested by hacking the driver to set that bit and also checked that EPSS is > reported as zero), but it's still an indication of what needs to be done > (keep the codec alive basically). Yes, I confirmed that EPSS=0 on my G45. > I'm still investigating if it would be possible to create something > similar to the sticky-infoframe patch but for stream id and stream format > as well (meaning that they'll stay valid after device close). > > azx_init_stream() from sound/pci/hda/hda_intel.c seems to indicate that > the stream_id chosen for the HDMI codec will remain static for as long as > the module is loaded, so I think it should be possible in theory. Right. > As a test I've commented out all the code in > snd_hda_codec_cleanup_stream() from sound/pci/hda/hda_codec.c (meaning > that the STREAMID will not be set to zero when the audio application > closes the device, which should still be ok as the stream id is not reused > and the DMA for that stream is still stopped). > > It actually fixed my silence for the duration of a track problem but there > is still silence in the beginning of new tracks. > > That's not that surprising though, there is still a new STREAMID and > STREAM_FORMAT being written when the device is reopened and that seems to > be enough to upset the HDMI codec for half a second, but it looks > promising. Good to know that :) > Next up I'll see if I can get the driver to cache the values of STREAMID > and STREAM_FORMAT and only change them when they actually change without > having to make extensive changes outside of patch_intelhdmi. > > Anyways, I wouldn't push the fake-audio-infoframe (refer-to-stream-header > during device close) patches upstream yet, they might just paper over the > real problem by forcing the receiver to reset some state when a new track > starts. OK. Thanks, Fengguang ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Alsa-user mailing list Alsa-user@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/alsa-user
