From mboxrd@z Thu Jan 1 00:00:00 1970 From: Takashi Iwai Subject: Re: [PATCH v4 00/10] audio timestamping evolutions Date: Mon, 02 Feb 2015 12:03:34 +0100 Message-ID: References: <1422662163-7391-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 4C9502604DB for ; Mon, 2 Feb 2015 12:03:35 +0100 (CET) In-Reply-To: <1422662163-7391-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, 30 Jan 2015 17:55:53 -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 patches. They look almost good to me. There are a few minor coding-style issues, but the implementation details appear good enough. I can merge at least the first four patches as an improvement of the current code base. The rest API change needs more reviews. I'll take a closer look at them later, but I think the new API design is almost acceptable as is. thanks, Takashi > > A corresponding set of patches is available for alsa-lib. > > V2 changes: > > trigger_tstamp: > trigger_tstamp_latched, pending redefined as bool > trigger_tstamp_latched reset in snd_pcm_pre_start() > > audio_ts_config, report: > keep separate structure but use different bitfields for in and out. > use u32 instead of __u32, add comments that these structures are internal > COMPAT backwards compatible mode, uses WALL_CLOCK/LINK for HDAudio > playback and DEFAULT (hw_ptr) everywhere else > > INFO bits: > reclaimed 32-bits from hw_params, renamed as info_ext > moved all timestamp info to info_ext > > snd_pcm_status: > read only 32-bit audio_tstamp_data, ignore all other fields > > V3/4: > Addressed feedback from Jaroslav: > no change to STATUS ioctl, new functionality introduced in STATUS_EXT > ioctl with r/w params. > bumped PCM protocol for detection on STATUS_EXT in userspace > used 32-bit word for accuracy report, no mantissa/exponent packing > rolled back info_ext changes, all INFO fields remain in same word > > Merged comments from Liam (code simplifications) > fixed packing > > Added driver_tstamp field in case there is a delay in passing the > tstamp and audio_tstamp over IPC. > > > > Pierre-Louis Bossart (10): > ALSA: core: don't override timestamp unconditionally > ALSA: core: allow for trigger_tstamp snapshot in .trigger > ALSA: hda: read trigger_timestamp immediately after starting DMA > ALSA: usb: update trigger timestamp on first non-zero URB submitted > ALSA: core: selection of audio_tstamp type and accuracy reports > ALSA: core: pass audio tstamp config from userspace > ALSA: core: pass audio tstamp config from userspace in compat mode > ALSA: core: replace .wall_clock by .get_time_info > ALSA: hda: replace .wallclock by .get_time_info > ALSA: bump PCM protocol to 2.0.13 > > Documentation/sound/alsa/timestamping.txt | 200 ++++++++++++++++++++++++++++++ > include/sound/pcm.h | 67 +++++++++- > include/uapi/sound/asound.h | 36 +++++- > sound/core/pcm_compat.c | 36 +++++- > sound/core/pcm_lib.c | 88 ++++++++----- > sound/core/pcm_native.c | 58 ++++++++- > sound/pci/hda/hda_controller.c | 43 +++++-- > sound/usb/pcm.c | 9 ++ > 8 files changed, 478 insertions(+), 59 deletions(-) > create mode 100644 Documentation/sound/alsa/timestamping.txt > > -- > 1.9.1 > > _______________________________________________ > Alsa-devel mailing list > Alsa-devel@alsa-project.org > http://mailman.alsa-project.org/mailman/listinfo/alsa-devel >