[alsa-devel] [RFC - AAF PCM plugin 3/5] aaf: Implement Playback mode support

Takashi Sakamoto o-takashi at sakamocchi.jp
Mon Sep 3 03:24:58 CEST 2018


Hi,

On Sep 1 2018 08:18, Guedes, Andre wrote:
>> I have another concern of buffering in a perspectives of delay of
>> task
>> scheduling.
>>
>> The interval of task scheduling for this plugin is decided mainly by
>> the value of 'frames_per_pkt', given by users. In your documentation,
>> the value is 6[1]. Of cource this is an example but in this case the
>> interval is calculated as 125us at 48.0kHz. In my opinion, task
>> scheduling in Linux kernel brings deadline misses for the interval,
>> in most cases such as major Linux distribution on usual personal
>> computers. When considering about the fact that recent motherboards
>> implements Intel I210/220 series, it's better to care for the low-
>> level
>> realtime systems, in my opinion.
> 
> Agreed.
> 
> To mitigate this scheduling issue, a follow-up patchset will extend the
> plugin to leverage the ETF qdisc [1] which will be available on next
> kernel release. The idea is: instead of sending one AVTP packet at
> every interval, the plugin will send several AVTP packets at once,
> configuring their Tx time accordingly, so it can "sleep" for longer
> periods of time. The goal is to ease on task scheduling by
> offloading  packet transmissions to the NIC.

A feature to queue packets with a transmission timing is mandatory for
applications to implement this kind of time-awareness packet
transmission protocol on general purpose operating system which has less
guarantees of its real-time capability.

In a case of IEC 61882-1/6 on IEEE 1394 bus, controllers of 1394 OHCI[1]
allows applications to queue several packets to corresponding
isochronous cycle. As a result, the controller can transfer each packet
at each isochronous cycle.

 From my curiousity, would I ask you to explain about usage of the
ETF 'qdisk' for this kind of applications? How relevant hardware
guarantees timing of transmission for queued packets? Or network stack
on Linux kernel govern the transmission timing in the proposed
patchset?[2].

[1] 1394 Open Host Controller Interface Specification Release 1.1 (2000, 
Promoters of the 1394 Open HCI)
http://download.microsoft.com/download/1/6/1/161ba512-40e2-4cc9-843a-923143f3456c/ohci_11.pdf
[2] [PATCH v2 net-next 00/14] Scheduled packet Transmission: ETF
https://marc.info/?l=linux-netdev&m=153065819412748


Thanks

Takashi Sakamoto


More information about the Alsa-devel mailing list