On Tue, Apr 20, 2010 at 4:55 PM, sdaau <sd@xxxxxxxxxx> wrote: > Hi guys, > > Thanks so much for your quick and prompt answers! > >> >> A usb serial audio device? Huh? That doesn't sound correct at all. >> > > Nope, I'm aware it doesn't :) But, again - I'm trying to learn more about > sound drivers, and since I have an FT232 based device, I took it up as a > learning challenge to have this device appear as a sound-card - and possibly > be able to play back/capture data received from FT232 on PC speakers. > > Even from my very limited understanding, I get that is generally not a good > plan - since FT232 supports only bulk transport, and I understand for > streaming data I'd want isochronous. But if I could get the device to appear > as a soundcard, and play back some data received from FT232 - even with > drops/retransmits and such - my learning goal is achieved :) > >> >> What exacly are you trying to do here that you would need to modify both >> of these drivers? >> >> >> I'm missing the connection between these two drivers. >> > > Well, I tried first by building based on usb-skeleton, and indeed I could > both read and write data to FT232 - but only after I executed stty (that is, > ftdi_open) using the original ftdi_sio (and then I could modprobe -r the > original ftdi_sio, and load my usb-skeleton). > > As I realized building on usb-skeleton will probably not be trivial, I > thought about using ftdi_sio.c itself as a base - and allowing its functions > (like probe and shutdown) to first handle all usb-serial related stuff - and > then call other functions that will handle ALSA side of things. > > >> >> The problem is you can't have 2 drivers binding to the same usb >> interface, which is what you are doing here. Bad things happen as you >> have seen :) >> > > Thanks for this - its good to have this confirmed :) > > I thought that I could "run away" from this, by keeping only the ftdi_sio.c > base as a "real" module (i.e. with #include <linux/module.h> and > <linux/kernel.h>) - the other .c file simply has functions copypasted from > usbaudio.c (starting from _probe and _disconnect, and adding all needed > functions until it builds, while commenting, say, MIDI). But obviously it is > not that easy :) > > Maybe I could best explain what I want to do through an example. > > Say the FT232 continuously sends 8 bit data - a 'sawtooth' from 0 to 255. > > Then with a normal ftdi_sio, I could have a flow like this: > > 1) Plug in USB - _probe runs, /dev/ttyUSB0 appears > 2) Run 'stty 115200 < /dev/ttyUSB0' - _open runs, baudrate is set > 3) Run 'cat /dev/ttyUSB0' - _read* runs, data is pushed via tty, and we are > getting 0x00, 0x01, .. 0xFF, 0x00 ... etc in terminal. > > With 'my' driver, I'd like the following flow to happen: > > 1) Plug in USB - _probe runs, /dev/ttyUSB0 appears and new card shows in > /dev/sndstat > 2) Run 'stty 115200 < /dev/ttyUSB0' - _open runs, baudrate is set - and pcm > buffers are prepared > 3) Run Audacity, select the new card, and click record - _read runs, and as > soon as data is ready to be sent to tty, it is also copied to PCM buffers > (with appropriate casting i.e. from 8bit to 16bit); and hopefully the file > recorded in Audacity is then the "stream" (well, bulk messages data) sent by > FT232. > > >>> [...] but its not even a variable :) >> >> Yes it is, it's a variable otherwise you would not be able to reference >> it :) >> > > Heh, indeed, sorry for my hastened thought :) What I meant is that, we have: > static void ftdi_shutdown(struct usb_serial *serial) > and that function gets "somehow" transparently called by the system, and > *serial is passed by the system (well, usb-serial.c, I'm guessing) - it is > not something declared in ftdi_sio.c or .h, for instance. > > But then, I guess I could set a break at ftdi_shutdown and then watch, say, > *interface = serial->interface :) > > >> >> You must be using a rather old kernel. ftdi_shutdown hasn't existed >> since 2.6.30. >> > > Indeed I am: > uname -r: 2.6.28-18-generic > cat /etc/issue: Ubuntu 9.04 \n \l > > >> Serial drivers like ftdi_sio aren't supposed to use the interface's >> driver_data field. However, that doesn't matter: If the driver_data >> field had not been set to NULL then it would contain a pointer to the >> usb_serial structure -- and ftdi_sio_shutdown() is already provided >> with such a pointer as its argument. >> >> Since usb-serial already uses the interface's driver_data field for its >> own purposes, you must not store audio data there too. >> >>> So these are the questions I have: >>> >>> - Is there an easy/obvious reason, why this pointer is reset at >>> _shutdown, that I'm missing? >> >> Yes: Because you're not supposed to be using the pointer. >> > > Thanks so much for this explanation - it would otherwise have taken me quite > a lot to reach a similar conclusion :) > > >>> - How could I debug this? Ideally, I'd like to put a watch on >>> usb_serial->interface->dev->driver_data and see when it changes (and >>> what changes it) - but its not even a variable :) >> >> There's nothing to debug; I can tell you where the pointer is set to >> NULL. In usb-serial.c, near the start of usb_serial_disconnect() >> you'll see: >> >> usb_set_intfdata(interface, NULL); >> >> That's what does it. >> > > And even more, thanks for this - although logical for me now, I wouldn't > have easily thought, that I should take a look at usb-serial again. > > The thing is - for the ALSA side of things, I tried to reuse usbaudio code > (and it uses ->driver_data), and I didn't think it would interfere with > usb-serial -- precisely because I saw ftdi_sio was not really making a use > of it. > > >> >> You could just use kdb if you like assembly language. >> >> I don't know if it was present in 2.6.30, but in more recent kernels >> you can look through samples/hw_breakpoint. >> > > Thanks for the info, very useful !! > > > Well, thanks again for the great answers - I guess I need to take a step > back, and possibly rethink my strategy, but at least now I have a better > idea of what to focus on :) Btw, if there are more examples related to what > I'm trying to do, I'd love to hear about 'em :) > > Best regards, > Cheers! Hello! Is this being done for fun? (Which I can certainly understand!) Or is it being done as a part of a requirement for school work? I ask this because during the time that I've been associated with Linux, going on about eleven years now I have encountered some unusual applications. And as it happens yours is one of the better ones. Would it be possible to try out your last known working code solution here? ----- Gregg C Levine gregg.drwho8@xxxxxxxxx "This signature fought the Time Wars, time and again." -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
