Clemens,
- clock source handling
I want to discuss about this issue in this mail.
I've never concerned about this synchronization so it took me a bit time to understand what you said...
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). This is for consumer use.
But I have no idea when playback starts. Do you have any idea?
Regards
Takashi Sakamoto o-takashi@sakamocchi.jp
(Jun 3 2013 20:18), Clemens Ladisch wrote:
o-takashi@sakamocchi.jp wrote:
Currently this driver module support just PCM/MIDI kernel streaming via ALSA interfaces. So there are some issues about this driver. 1.whether adding each PCM devices for analog and digital interface
ALSA drivers should reflect the actual hardware design as much as possible; conversions should be done in user space by alsa-lib.
If analog and digital channels are part of the same AMDTP stream, then that is how the PCM device should look like. (This is also how other drivers like ice1712 work.)
There are other functions to describe and label channels. (And when I say "there are", I actually mean "there will be, eventually". ;-)
2.where the codes for device control like volume, routing and etc are
The idea was to let the kernel driver handle only the actual streaming (and everything else necessary for that, such as device enumeration, sample rate, and clock source management), and let user space handle everything else.
Volume and routing do not affect the streaming part in any way, so the kernel driver should not bother to implement them.
- clock source handling
AMDTP itself was designed for consumer devices, where streaming is in only one direction, and where the receiving device always synchronizes to the playback device; this is the equivalent of the "SYT Match" clock source.
This is how the existing drivers (isight, firewire-speakers) work.
However, for full duplex and other clock sources, streaming becomes more complicated. When in "SYT match" mode, the playback stream should be running even when only a capture PCM device is open. In all other modes, the PC must synchronize to the device, so the capture stream must be running when _any_ PCM/MIDI stream is open (and, of course, the capture packets must be used to determine when to send packets).
Regards, Clemens