From: Pieter P. <pi...@jo...> - 2011-03-12 13:44:30
|
Hi Clemens, First of all, thanks for your work on the kernel space driver. It seems that you're finally taking on what everyone has been waiting for. I should have some spare time over the next months and will probably be more active with respect to FFADO. I was wondering what the best allocation of effort would be, and I came to the conclusion that testing the kernel streaming drivers with all devices I have over here is probably the most helpful thing. So please keep me updated, I would be very happy if finally a reliable and more easy to use set of drivers for firewire devices would be available. With respect to the kernelspace/userspace dilemma I think that Linus' arguments are very valid, so we probably should focus on how to fit the device control in to the ALSA/fw-cdev API's. With respect of AV/C controllable devices, would it be possible to use a device-specific configuration file of some sort? I'm thinking something along the lines of: - kernel space implements the minimal set of commands: * needed to control an AV/C device (e.g. sample rate) * required to figure out the minimal set of parameters that uniquely define the current config of the device - config files for all devices we have access to can be provided, after all they don't tend to change. - a userspace device discovery tool is available to generate the config file for arbitrary other devices. FFADO is doing something like this bebob devices to avoid re-discovering them each time (can take up to 30 seconds). An ID is calculated based upon the current samplerate / sync / channel config and if that ID is found in the cache we load the device representation from the file. http://subversion.ffado.org/browser/trunk/libffado/src/bebob/bebob_avdevice.cpp#L669 Is this a realistic & acceptable solution? Thanks again for your efforts, Pieter On 03/11/2011 09:39 AM, Clemens Ladisch wrote: > Jonathan Woithe wrote: >> Clemens Ladisch wrote: >>> As for future drivers: RME and MOTU drivers cannot reuse the AMDTP >>> code, but should otherwise be similar to the Fireworks/DICE drivers. >> >> So I guess the sensible thing for me to do here is to use either the >> Fireworks or DICE drives as a sort of guide when implementing RME/MOTU >> support. That sounds fine to me. Do you have any feeling as to when these >> drivers might be in a condition which gives me a reasonably accurate idea of >> how things should be structured? > > I estimate I'll have something next week, in a git repo. > > > Regards, > Clemens > > ------------------------------------------------------------------------------ > Colocation vs. Managed Hosting > A question and answer guide to determining the best fit > for your organization - today and in the future. > http://p.sf.net/sfu/internap-sfd2d > _______________________________________________ > FFADO-devel mailing list > FFA...@li... > https://lists.sourceforge.net/lists/listinfo/ffado-devel > |
From: Damien Z. <dam...@gm...> - 2011-03-13 01:06:14
|
Hi Clemens, I have noticed in particular that some devices do not follow the current FFADO standard of syncing on the receive stream, and the device I am working on at the moment requires some dummy data be sent to the playback stream before it will initiate the receive stream. Please keep this in mind when coding the iso routines for non-avc devices. Thanks for your great efforts, Damien |
From: Clemens L. <cl...@la...> - 2011-03-14 16:57:26
|
Pieter Palmers wrote: > [...] > With respect to the kernelspace/userspace dilemma I think that Linus' > arguments are very valid, so we probably should focus on how to fit the > device control in to the ALSA/fw-cdev API's. > > With respect of AV/C controllable devices, would it be possible to use a > device-specific configuration file of some sort? > > I'm thinking something along the lines of: > - kernel space implements the minimal set of commands: > * needed to control an AV/C device (e.g. sample rate) Changing the sample rate might be quite complex if there are dependencies between multiple plugs, so it might be a good idea to leave this to user space. > * required to figure out the minimal set of parameters > that uniquely define the current config of the > device > - config files for all devices we have access to can be provided, after > all they don't tend to change. > - a userspace device discovery tool is available to generate the config > file for arbitrary other devices. And what is the interface between the kernel driver and the config file? Are you proposing that the driver gets from user space a list of commands which it can execute later, when needed? Regards, Clemens |
From: Pieter P. <pi...@jo...> - 2011-03-16 15:20:16
|
On 03/14/2011 05:59 PM, Clemens Ladisch wrote: > Pieter Palmers wrote: >> [...] >> With respect to the kernelspace/userspace dilemma I think that Linus' >> arguments are very valid, so we probably should focus on how to fit the >> device control in to the ALSA/fw-cdev API's. >> >> With respect of AV/C controllable devices, would it be possible to use a >> device-specific configuration file of some sort? >> >> I'm thinking something along the lines of: >> - kernel space implements the minimal set of commands: >> * needed to control an AV/C device (e.g. sample rate) > > Changing the sample rate might be quite complex if there are > dependencies between multiple plugs, so it might be a good idea > to leave this to user space. If we don't have to respond to ALSA API's that change the samplerate this is possible. Note that even for complex plug configurations there is usually one command that changes the samplerate for all plugs. There are not that many devices (if any) that can deal with multiple samplerates, and hence the subset of possible states is pretty low in real life. > >> * required to figure out the minimal set of parameters >> that uniquely define the current config of the >> device >> - config files for all devices we have access to can be provided, after >> all they don't tend to change. >> - a userspace device discovery tool is available to generate the config >> file for arbitrary other devices. > > And what is the interface between the kernel driver and the config > file? I have no idea, how is this kind of stuff done in other kernel drivers? Surely there has to be some kind of solution to this class of problems. It looks a bit similar to loading firmware to me, except for the fact that you might not want the commands for the entire set of devices loaded into kernel space memory. If there is a standard way to trigger firmware load on hotplug events, it might be possible to re-present the commands to the driver when a new device is plugged in. The driver can then copy the relevant commands into it's memory space and discard all commands for devices that are not connected to the bus. > Are you proposing that the driver gets from user space a list of > commands which it can execute later, when needed? I guess it basically comes down that, yes. I think it's pretty realistic in real-world cases. There is a bit of combinatorial explosion (nrates * nsyncmodes * nchannel_modes * ...) but to the extent that it becomes problematic. In the end most of the complexity is in the generic discovery code, once that's available the actual commands required to change a setting are pretty simple. I'm just wondering how we can avoid introducing an extra kernel <-> userspace API as much as possible, as I tend to agree with the remarks on kernel-devel that it will probably make life harder on the long run. In the end of course this idea is just another incarnation of a kernel-userspace API, but maybe one that can be kept stable and backward compatible as we only have to keep the "format" compatible, not the content. Regards, Pieter Palmers |
From: Clemens L. <cl...@la...> - 2011-03-16 16:34:16
|
Pieter Palmers wrote: > On 03/14/2011 05:59 PM, Clemens Ladisch wrote: >> Pieter Palmers wrote: >>> [...] >>> With respect of AV/C controllable devices, would it be possible to use a >>> device-specific configuration file of some sort? >>> >>> I'm thinking something along the lines of: >>> - kernel space implements the minimal set of commands: >>> * needed to control an AV/C device (e.g. sample rate) >>> * required to figure out the minimal set of parameters >>> that uniquely define the current config of the >>> device >>> - config files for all devices we have access to can be provided, after >>> all they don't tend to change. >>> - a userspace device discovery tool is available to generate the config >>> file for arbitrary other devices. >> >> And what is the interface between the kernel driver and the config >> file? > > I have no idea, how is this kind of stuff done in other kernel drivers? Not at all. :-) > Surely there has to be some kind of solution to this class of problems. > It looks a bit similar to loading firmware to me, except for the fact > that you might not want the commands for the entire set of devices > loaded into kernel space memory. Usually, devices are self-describing, and/or the driver has much code to handle device-specific quirks. The worst example I know is the discovery of USB Audio v2 devices; this code is a mess, and it's incomplete. I don't know of any devices where the driver doesn't know, by itself, how to handle the device. > [...] > In the end of course this idea is just another incarnation of a > kernel-userspace API, but maybe one that can be kept stable and backward > compatible as we only have to keep the "format" compatible, not the content. APIs can be designed for better forward and backward compatibility, but any actually usable change or extension in the API requires matching changes in the implementations of both sides of the API, regardless of the actual techniques used for the API. I think the cleanest solution is similar to the design of all the other FW audio drivers, i.e., the kernel driver is able to read the current configuration of the device (as far as it needs to know), but most configuration changes are done by a separate component. Regards, Clemens |
From: Clemens L. <cl...@la...> - 2011-03-31 06:42:20
|
Stefan Richter wrote: > two things about <sound/firewire.h>: > > - Somebody just registered a 'H' F1 ioctl number in > Documentation/ioctl/ioctl-number.txt. Thanks for noticing this. Fortunately, my API is not yet 'official'. > - The structs for read() and ioctl() operations contain unsigned int at > the moment. 64 bit kernels will therefore have to have compat > handlers to support 32 bit userland. This can --- and to my > understanding should --- be avoided by only using types whose size and > alignment are the same on 32 bit and 64 bit variants of an > architecture. I _am_ using types whose size and alignment are the same on any architecture. Regards, Clemens |
From: Stefan R. <st...@s5...> - 2011-03-31 07:07:12
|
On Mar 31 Clemens Ladisch wrote: > Stefan Richter wrote: > > This can --- and to my > > understanding should --- be avoided by only using types whose size and > > alignment are the same on 32 bit and 64 bit variants of an > > architecture. > > I _am_ using types whose size and alignment are the same on any > architecture. Indeed. 00:20 was not a well-chosen time for ABI review. -- Stefan Richter -=====-==-== --== ===== http://arcgraph.de/sr/ |