On Mon, 10 Dec 2018 11:22:01 +0100, Takashi Iwai wrote: > > On Sat, 08 Dec 2018 02:55:43 +0100, > Andre Guedes wrote: > > > > Hi all, > > > > This patch series provides some follow-up improvements to the AVTP Audio > > Format (AAF) plugin. The highlight of this series is the implementation of > > a transmission offload mechanism which improves the plugin performance > > considerably. Details are provided in the following paragraphs. > > > > Currently, the AVTPDU transmission interval is controlled by the AAF plugin, in > > software. At every timer expiration, the plugin transmits one AVTPDU. This has > > some implications in terms of task scheduling. For instance, in class A > > streams, AVTPDUs are transmitted at every 125 us which means the application > > task should be scheduled-in at every 125 us. In a general purpose Linux system, > > such scheduling interval can be hard to cope with in the long-run. > > > > To mitigate that issue, this series introduces a transmission offload mechanism > > that leverages the SO_TXTIME sockopt and ETF qdisc features recently introduced > > to kernel 4.19. Instead of sending one AVTPDU at every timer expiration, the > > plugin sends several AVTPDUs at once to the kernel, configuring their Tx time > > so the transmission interval is maintained. The kernel can then offload packet > > transmission to the hardware (if the network controller supports it), providing > > more transmission time accuracy. This offloading mechanism enables the > > application to sleep for longer times, easing on task scheduling. > > > > To illustrate the improvements provided by this series, I ran a before-after > > experiment. The experiment setup consisted in 2 PCs with Intel i210 card > > connected back-to-back running an up-to-date Archlinux with kernel 4.19.4. I > > ran 'aplay' for 5 minutes on one PC and captured the AVTPDUs on the other PC. > > The metric under evaluation is the transmission interval and it is measured by > > checking the 'time_delta' information from ethernet frames captured at the > > receiving side. If you're interested in reproducing the experiments, let me > > know and I can share my helper scripts. > > > > The table below shows the experiment outcome for a Class A, stereo, 16-bit > > sample, 48 kHz stream. The unit is nanoseconds. > > > > | Mean | Stdev | Min | Max | Range | > > -------+--------+---------+---------+---------+---------+ > > Before | 125000 | 1154 | 75311 | 172144 | 96833 | > > After | 125000 | 18 | 124960 | 125048 | 88 | > > > > > > Before this patchset, the transmission interval mean is equal to the optimal > > value (Class A stream -> 125 us interval), and it is kept the same after the > > patchset. However, the dispersion measurements had improved considerably, > > meaning the system is consistently transmitting AVTPDUs at the correct > > interval. > > > > Finally, to help the review process, here follows a quick summary of the > > patches within this series: > > * PATCH 1: fixes a type in the plugin documentation. > > * PATCH 2: enables the user to configure the presentation time > > tolerance. > > * PATCH 3-5: refactor the code in order to land the offload mechanism > > code smoothly. > > * PATCH 6-7: implement the transmission offload mechanism. > > > > This series can also be found in my alsa-plugins tree in github [1]. > > > > Regards, > > > > Andre > > > > [1] https://github.com/aguedes/alsa-plugins > > > > Andre Guedes (7): > > doc: Fix typo in AAF doc > > aaf: Add presentation time tolerance > > aaf: Refactor AVTPDU transmission routines > > aaf: Refactor AVTPDU reception routines > > aaf: Refactor timeout routines > > aaf: Tx multiple AVTPDUs per media clock tick > > aaf: AVTPDU transmission periodicity > > Applied all patches now. Thanks. BTW, while building libavtp for 32bit x86, the unit test failed: The build log is found at https://build.opensuse.org/package/live_build_log/home:tiwai/libavtp/openSUSE_Factory/i586 x86_64 seems working, so it must be specific to 32bit arch. Takashi _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
