From mboxrd@z Thu Jan 1 00:00:00 1970 From: Takashi Iwai Subject: Re: HD-audio runtime->delay accounting Date: Fri, 21 Sep 2012 14:22:01 +0200 Message-ID: References: <505C5AAB.8050607@canonical.com> Mime-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mx2.suse.de (cantor2.suse.de [195.135.220.15]) by alsa0.perex.cz (Postfix) with ESMTP id 1C8DF265D46 for ; Fri, 21 Sep 2012 14:22:02 +0200 (CEST) In-Reply-To: <505C5AAB.8050607@canonical.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: alsa-devel-bounces@alsa-project.org Sender: alsa-devel-bounces@alsa-project.org To: David Henningsson Cc: alsa-devel@alsa-project.org, "Heasley, Seth" , Pierre-Louis Bossart List-Id: alsa-devel@alsa-project.org At Fri, 21 Sep 2012 14:16:43 +0200, David Henningsson wrote: > > On 09/21/2012 01:59 PM, Takashi Iwai wrote: > > Hi, > > > > recently Pierre questioned about the validity of COMBO positioning > > mode, and it turned out that the position reporting can be handled > > better if we take the difference between LPIB and DMAPOS as > > runtime->delay. (In short, LPIB points the position where the data fed > > to the codec, and DMAPOS points the data fetched to DMA.) > > > > We cooked up a test patch below and it seems working well on a few > > machines I've tested. I think we might have still chance to put this > > into 3.7, as this would be a good improvement. The patch below is a > > combined work of two fixes: fixing the better stream start by always > > using SSYNC bit, and adjusting the position and runtime->delay. > > Interesting. A quick question: is this affecting playback, recording, or > both? The runtime->delay is calculated for both directions, so if apps take account of runtime->delay, both directions are affected. If apps check only hw_ptr, it'll be only the playback. Now hw_ptr of playback points DMAPOS with the compensation of runtime->delay when this new mode is used. > > Of course, the biggest question is the test coverage. > > David, could you check whether this doesn't break so much on (some) > > machines you can test? Of course, if any other people can test it, > > it'll be a great help, too. > > > > The patch should be applied to the latest sound.git tree master > > branch, but it should be applicable (and easily resolvable) for older > > versions. > > Against sound master: > > patching file sound/pci/hda/hda_intel.c > Hunk #2 succeeded at 1987 (offset -17 lines). > Hunk #3 succeeded at 2012 (offset -17 lines). > Hunk #4 succeeded at 2044 (offset -17 lines). > Hunk #5 succeeded at 2144 (offset -17 lines). > Hunk #6 succeeded at 3426 (offset -104 lines). > Hunk #7 succeeded at 3490 (offset -104 lines). > > > The patch extends this new mode only for recent Intel > > chips, just to be sure. > > I don't think I have much such hardware here. But I've made DKMS package > for easy testing by others. If you're running Ubuntu 12.04, you can just > install this package, reboot, and test: > > http://people.canonical.com/~diwic/temp/alsa-hda-dkms-ssync-delay_0.1_all.deb That's great. thanks, Takashi