[alsa-devel] include/uapi/firewire.h for other firewire drivers
Takashi Sakamoto
o-takashi at sakamocchi.jp
Fri Oct 25 16:54:12 CEST 2013
Clemens,
Thanks for your quick reply.
> When a control panel wants to change several settings, it should not
> need to establish a CMP connection just to be able to prevent the driver
> from starting streaming at the same time.
There is no need to establish connection. The control panel just check
the value of "peer-to-peer connection counter" field in iPCR/oPCR.
But anyway, it's better to give an easy way via the interface. I agree.
> When this is possible, the kernel FireWire framework should be extended
> to allow the driver to prevent FFADO from using the device. However, it
> would be hard for the kernel to differentiate between FFADO and some
> control panel, so I guess FFADO should be changed to not attach to
> a device that already has a kernel driver.
I'm not a developer for Juju so cannot have any idea for kernel land at
all. But for FFADO, I can put your idea as my future commitment.
> For Fireworks devices, applications will need to send EFC commands, but
> will not be able to allocate the same 0xecc080000000 address, so the
> driver needs a SEND_EFC ioctl. (That's the same reason why snd-dice has
> DICE_NOTIFICATION.)
Now I understand the reason DICE_NOTIFICATION exists. Dice also have the
similar issue as Fireworks has. For EFC, I'm willing to keep FFADO using
"EFC over AVC" but I found this is not enough for some models with
latest firmware.
Well, you said "The primary purpose is to support control panel/mixer".
But this interface can also be good for prevention of conflict with
FFADO driver. I wonder why you mention this first. Are there any thoughts?
Thanks
Takashi Sakamoto
More information about the Alsa-devel
mailing list