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

[Clemens Ladisch <clemens@ladisch.de>]

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