From: Takashi S. <o-t...@sa...> - 2013-06-07 12:16:21
|
Clemens, > 4. 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-t...@sa... (Jun 3 2013 20:18), Clemens Ladisch wrote: > o-t...@sa... 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. > > > 4. 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 |