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.
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