From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757363Ab2IFKZ0 (ORCPT ); Thu, 6 Sep 2012 06:25:26 -0400 Received: from mail-bk0-f46.google.com ([209.85.214.46]:64579 "EHLO mail-bk0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753369Ab2IFKZZ (ORCPT ); Thu, 6 Sep 2012 06:25:25 -0400 Message-ID: <50487A0C.4080204@gmail.com> Date: Thu, 06 Sep 2012 12:25:16 +0200 From: Daniel Mack User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120717 Thunderbird/14.0 MIME-Version: 1.0 To: Takashi Iwai CC: Markus Trippelsdorf , Linus Torvalds , linux-kernel@vger.kernel.org, alsa-devel@alsa-project.org, Pierre-Louis Bossart Subject: Re: snd-usb: "delay: estimated 0, actual 352" References: <20120906060220.GA252@x4> <504843BA.2040808@gmail.com> <20120906065340.GA257@x4> <50484BEB.4020103@gmail.com> <20120906071757.GB257@x4> In-Reply-To: X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 06.09.2012 09:35, Takashi Iwai wrote: > At Thu, 6 Sep 2012 09:17:57 +0200, > Markus Trippelsdorf wrote: >> >> On 2012.09.06 at 09:08 +0200, Daniel Mack wrote: >>> On 06.09.2012 08:53, Markus Trippelsdorf wrote: >>>> On 2012.09.06 at 08:48 +0200, Takashi Iwai wrote: >>>>> At Thu, 06 Sep 2012 08:33:30 +0200, >>>>> Daniel Mack wrote: >>>>>> >>>>>> On 06.09.2012 08:02, Markus Trippelsdorf wrote: >>>>>>> On 2012.09.04 at 16:40 +0200, Takashi Iwai wrote: >>>>>>>> ---------------------------------------------------------------- >>>>>>>> Sound fixes for 3.6-rc5 >>>>>>>> >>>>>>>> There are nothing scaring, contains only small fixes for HD-audio and >>>>>>>> USB-audio: >>>>>>>> - EPSS regression fix and GPIO fix for HD-audio IDT codecs >>>>>>>> - A series of USB-audio regression fixes that are found since 3.5 kernel >>>>>>>> >>>>>>>> ---------------------------------------------------------------- >>>>>>>> Daniel Mack (4): >>>>>>>> ALSA: snd-usb: Fix URB cancellation at stream start >>>>>>>> ALSA: snd-usb: restore delay information >>>>>>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>>>>>> The commit fbcfbf5f above causes the following lines to be printed >>>>>>> whenever I start a new song: >>>>>> >>>>>> Copied Pierre-Louis Bossart - he wrote the code in 294c4fb8 which this >>>>>> patch (fbcfbf5f) brings back now. >>>>>> >>>>>>> delay: estimated 0, actual 352 >>>>>>> delay: estimated 353, actual 705 >>>>>>> >>>>>>> (44.1 * 8 = 352.8) >>>>>>> >>>>>>> This happens with an USB-DAC that identifies itself as "C-Media USB >>>>>>> Headphone Set". >>>>>> >>>>>> And you didn't you see these lines with 3.4? >>>>> >>>>> Maybe the difference of start condition? >>>>> >>>>> Markus, does the patch below fix anything? >>>> >>>> Unfortunately no. >>>> However reverting the following fixes the problem: >>>> >>>> commit 245baf983cc39524cce39c24d01b276e6e653c9e >>>> Author: Daniel Mack >>>> Date: Thu Aug 30 18:52:30 2012 +0200 >>>> >>>> ALSA: snd-usb: fix calls to next_packet_size >>>> >>> >>> No, this one certainly fixes a problem and does the right thing by >>> restoring the original code. >>> >>> If you wouldn't state that you didn't see the same effect with 3.4(!), >>> before the refactoring done in 3.5, I would believe the device is simply >>> slightly off in its feedback rate and the tighter delay code complains >>> about it while compensating, just as it did before. >>> >>> Are there any more than these two lines? And is audio working at all? Is >>> it distorted in any way? >> >> There are only these two lines (printed whenever sound starts). Audio is >> working just fine with no distortions. >> >> I did see similar lines before when the system load was very high >> (happend during "make check" when building glibc). >> >> Here is what Pierre-Louis wrote in November 2011: >> >> »This was supposed to be an informational message, I thought it was only >> enabled for debug. Regular users don't really need to know.« > > I guess the problem is that the new endpoint scheme doesn't count the > last_delay update unless the stream is triggered. In the old code, > retire_playback_urb is always called even before the trigger(START) is > set. And, there retire_playback_urb() does nothing but updating the > delay information. > > In the new code, retire_playback_urb is set only at > snd_usb_substream_playback_trigger(). Thus at the very first shot, > the delay account got confused. In that case, I'd say we can also safely remove the debug output then. Let's wait for Pierre-Louis' judgement here. Daniel