From mboxrd@z Thu Jan 1 00:00:00 1970 From: Takashi Iwai Subject: Re: [PATCH v6 0/7] audio timestamping evolutions Date: Fri, 20 Feb 2015 17:39:06 +0100 Message-ID: References: <1423862049-4073-1-git-send-email-pierre-louis.bossart@linux.intel.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 75551260597 for ; Fri, 20 Feb 2015 17:39:07 +0100 (CET) In-Reply-To: <1423862049-4073-1-git-send-email-pierre-louis.bossart@linux.intel.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: Pierre-Louis Bossart Cc: alsa-devel@alsa-project.org List-Id: alsa-devel@alsa-project.org At Fri, 13 Feb 2015 15:14:02 -0600, Pierre-Louis Bossart wrote: > > This series of patches was inspired by recent threads on the alsa > mailing list, as well issues detected with existing and upcoming > hardware: > > 1. there was a request from the PulseAudio community to get more > information from drivers to make rewinds safer. While the conclusion > was that it's nearly impossible for a driver developer to provide this > information, there are however ways to assess the granularity of the > hw_ptr updates using timestamping capabilities, and indirectly > understand how safe rewinds might be. > > 2. There was also a request to add a start_at capability based either > on system hr timers or a wall clock, which requires a means to expose > both types of information to applications. Rather than adding new sets > of timestamps, it is suggested the new start_at functionality relies > on the new definition provides by these patches > > 3. For new hardware, there is a neeed to let low-level drivers > handle timestamping instead of having the ALSA core do > it. Similarly there is a need to let the low-level driver update > the initial estimate for the trigger timestamp if there are > delays to start a stream (eg. with USB) > > These patches try to provide an answer to these multiple needs by > building on the work done two years ago to expose wall clock > information to applications. The evolution is to let application > select which audio timestamp they are interested in, track the delay > and drifts between recurring measurements and get, when possible, an > idea of the accuracy of the underlying hardware. A backwards compatible mode > is provided in case userspace doesn't provide any timestamp selection (results > based on HDAudio wallclock for playback, hw_ptr in all other cases). > > The first 4 patches are corrections for misses in the way the system > and trigger timestamps are handled, and the last 6 provide the > additional audio timestamping selection. A second batch is planned to > enable hardware capabilities in a low-level drivers. Thanks for the revised patches. I now took them locally to topic/timestamp branch of sound git tree, but it's not merged yet to master or for-next. Unless any objection comes up, I'm going to merge after 3.20-rc1 is released (as it's targeted for 3.21). > A corresponding set of patches is available for alsa-lib. Could you repost the alsa-lib patches? I'm going to queue and push out when the patches are really merged in the kernel side. Takashi