linux-kernel - Re: [very-RFC 0/8] TSN driver for the kernel

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <5760C84C.40408@sakamocchi.jp>
Date:	Wed, 15 Jun 2016 12:15:24 +0900
From:	Takashi Sakamoto <o-takashi@...amocchi.jp>
To:	alsa-devel@...a-project.org
Cc:	netdev@...r.kernel.org, Henrik Austad <henrik@...tad.us>,
	linux-kernel@...r.kernel.org, Arnd Bergmann <arnd@...aro.org>,
	alsa-devel@...r.kernel.org, linux-media@...r.kernel.org
Subject: Re: [very-RFC 0/8] TSN driver for the kernel

Hi Richard,

 > On Mon, Jun 13, 2016 at 01:47:13PM +0200, Richard Cochran wrote:
 >> 3. ALSA support for tunable AD/DA clocks.  The rate of the Listener's
 >>    DA clock must match that of the Talker and the other Listeners.
 >>    Either you adjust it in HW using a VCO or similar, or you do
 >>    adaptive sample rate conversion in the application. (And that is
 >>    another reason for *not* having a shared kernel buffer.)  For the
 >>    Talker, either you adjust the AD clock to match the PTP time, or
 >>    you measure the frequency offset.
 >>
 >> I have seen audio PLL/multiplier chips that will take, for example, a
 >> 10 kHz input and produce your 48 kHz media clock.  With the right HW
 >> design, you can tell your PTP Hardware Clock to produce a 10000 PPS,
 >> and you will have a synchronized AVB endpoint.  The software is all
 >> there already.  Somebody should tell the ALSA guys about it.

Just from my curiosity, could I ask you more explanation for it in ALSA 
side?

The similar mechanism to synchronize endpoints was also applied to audio 
and music unit on IEEE 1394 bus. According to IEC 61883-1/6, some of 
these actual units can generate presentation-timestamp from header 
information of 8,000 packet per sec, and utilize the signal as sampling 
clock[1].

There's much differences between IEC 61883-1/6 on IEEE 1394 bus and 
Audio and Video Bridge on Ethernet[2], especially for synchronization, 
but in this point of transferring synchnization signal and time-based 
data, we have the similar requirements of software implementations, I think.

My motivation to join in this discussion is to consider about to make it 
clear to implement packet-oriented drivers in ALSA kernel-land, and 
enhance my work for drivers to handle IEC 61883-1/6 on IEEE 1394 bus.

 >> I don't know if ALSA has anything for sample rate conversion or not,
 >> but haven't seen anything that addresses distributed synchronized
 >> audio applications.

In ALSA, sampling rate conversion should be in userspace, not in kernel 
land. In alsa-lib, sampling rate conversion is implemented in shared 
object. When userspace applications start playbacking/capturing, 
depending on PCM node to access, these applications load the shared 
object and convert PCM frames from buffer in userspace to mmapped 
DMA-buffer, then commit them.

Before establishing a PCM substream, userspace applications and 
in-kernel drivers communicate to decide sampling rate, PCM frame format, 
the size of PCM buffer, and so on. (see snd_pcm_hw_params() and 
ioctl(SNDRV_PCM_IOCTL_HW_PARAMS)). Thus, as long as in-kernel drivers 
know specifications of endpoints, userspace applications can start PCM 
substreams correctly.

[1] In detail, please refer to specification of 1394TA I introduced:
http://www.spinics.net/lists/netdev/msg381259.html
[2] I guess that IEC 61883-1/6 packet for Ethernet-AVB is a mutant from 
original specifications.

Regards

Takashi Sakamoto