On Mon, May 30, 2011 at 05:28:52PM +0200, sdaau wrote:
It could just be an option to the existing ftdi_sio driver that is enabled somehow for a specific device, right?
Well, I wish it was so - but unfortunately, it is not that way currently.
The thing is, I'm not really an expert in programming, and even less in kernel drivers. So, for the time that I had at my disposal, the only thing I could have done is try to understand ALSA driver architecture a bit better - while the USB part is completely "abstracted".
What I mean by that, is that the main driver file (ftdi_sio-audard.c) is first and foremost a copy of ftdi_sio.c from 2.6.32 kernel; then it includes a 'snd_ftdi_audard.h' file, which is here not a traditional header; it simply contains additional functions which 'add' the ALSA interface to ftdi_sio.c.
Finally, the two architectures are connected, such that the ftdi's callbacks also call the ALSA related callbacks, in particular:
- ftdi_sio's ftdi_process_packet (raised on incoming USB data) calls
ALSA-related audard_xfer_buf function (and so the audio capture direction is handled)
- ALSA related snd_card_audard_pcm_timer_function calls ftdi_sio's
ftdi_write function (which controls outgoing USB data - and so the audio playback direction is handled).
I've just posted a diff on the SVN repository between the current ftdi_sio-audard.c and the original ftdi_sio.c from kernel 2.6.32:
http://sdaaubckp.svn.sourceforge.net/viewvc/sdaaubckp/audard/snd_ftdi_audard...
... the link should show syntax coloring, so it maybe gets easier to see what's going on there.
Care to email it? That way we can review it here and see how to structure it.
In essence, this driver keeps everything ftdi_sio has (so you still get a /dev/ttyUSB0; you can still 'cat' from or 'echo' to this device node as usual) - except that, additionally, data is passed also to the ALSA-related memory structures (i.e. the dma_area of a particular ALSA substream).
Initially, I really wanted to essentially keep ftdi_sio as is, so that I wouldn't have to worry about changes to its code; but as the ALSA interface requires new functions, I couldn't find a way how to selectively #include these functions based on a driver option. One could use #defines, maybe, but that's still compile-time handling, not run-time handling. And so, I decided to focus instead on problems that I had a chance of solving (such as wrapping data for the ALSA ring buffers). And just today I discovered that the driver needs a couple of changes, that were implemented in ftdi_sio.c since 2.6.32, so that it would compile for 2.6.38 (I have now added comments related to this is the source file up on SVN).
However, if there is some sort of a tutorial/guide (or even a specific existing driver file example) that I could refer to, so as to turn the current architecture into an option-based one, such that I avoid messing with ftdi_sio.c directly -- I'd definitely love to try and do that; so please let me know if there is some sort of a recommended reading for this.
I don't think there is a "tutorial" for something like this, but we would be glad to help you out here to do this.
So, care to post the code here?
thanks,
greg k-h