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. >> 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? >> 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). 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. 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. 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. Regards, David ------------------------------------------------------------------------------ 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
