Re: [PATCH 0/8] [RFC] new driver for Echo Audio's Fireworks based devices

[Clemens Ladisch <clemens@ladisch.de>]

Takashi Sakamoto wrote:
> Actually Fireworks supports severarl clock source, "Internal", "SYT
> Match", "Word", "S/PDIF", "ADAT1", "ADAT2". Then there is two options,
> one is for SYT match and another is for the others.
>
> SYT match:
> PC is a clock master to transmit SYT in CIP. So receive stream require
> transmit stream in advance.
>
> The others:
> Device is a clock master and PC should generate SYT for transmit
> stream from SYT in receive stream.
>
>> (and, of course, the capture packets must be used to determine
>> when to send packets).
>
> To achieve this, we need to change calculate_syt() or add new function
> to amdtp.c. I think it's enough to generate outgoing SYT from incoming
> SYT with TRANSFER_DELAY (479.17 micro seconds).

We want the playback stream to behave like the capture stream, and the
SYT is interpreted relative to the frame in which the packet is actually
transferred, so what the driver has to do is this:
1) compute the offset between the frame where the capture packet was
   received and its SYT;
2) compute the frame where the playback packet will be sent (i.e., add
   the queue length to the current frame);
3) add the offset to that frame.

The SYT field wraps around after 2 ms, so the corresponding capture/
playback SYT values will be identical only if the queue length is
a multiple of 2 ms.


But there is another thing: the driver has to choose whether a packet to
send contains SYT_INTERVAL samples or is a NO-DATA packet.

In SYT Match mode, the driver just checks whether enough samples are
available for that frame.

In the other modes, the driver must copy the packet type from the
capture stream, i.e., when it receives a NO-DATA packet, it submits
a NO-DATA packet, and when it receives a data packet, it submits a data
packet.  This implies that the queueing of playback packets happens not
in the playback packet completion callback, but in the *capture* packet
completion callback.

> But I have no idea when playback starts. Do you have any idea?

Playback packets can be submitted only when we already have a running
capture stream with its packet completion callbacks.  (This is similar
to starting playback in the SYT Match case, where the driver submits
a bunch of skip packets so that the playback packet completion
callbacks arrive with the correct timing.)


Regards,
Clemens