From: Darren A. <dar...@gm...> - 2013-07-22 07:24:46
|
On 22/07/2013, Jonathan Woithe <jw...@ju...> wrote: > Hi Darren > > Apologies for the silence over the weekend: our phone line at home has > died, > taking DSL with it. :-( > > First up, thanks for taking on the ProjectMix and its protocol. Feel free > to continue posting to ffado-devel if you need feedback or assistance with > anything. > I definitely will do! As I've said, I'm no firewire expert, and could use all the help I can get! I'm kind of just learning as I go with this one. >> On 19 July 2013 15:28, Darren Anderson <dar...@gm...> wrote: >> > When starting the dbus server, it obviously then tried to use the BeBoB >> > driver for the device, which resulted in a lot of errors. FCP >> > transaction >> > failed, it then couldn't configure the channels. Basically anything >> > that >> > could go wrong did. >> > >> > Guess it's back to the drawing board. I'm going to have a play around >> > with >> > this to see if I can't managed to get it working even a little. I'll >> > let >> > you know how it goes on. > > That's interesting. Unless there's something amiss with the FFADO BeBoB > driver this would indicate that they do almost everything with > vendor-specific extensions. > I have a theory that this may be something to do with the initialization routine, as opposed to a problem with streaming. I plan on doing some tests with AMDTP later to try to work this out. > On Fri, Jul 19, 2013 at 05:29:56PM +0100, Darren Anderson wrote: >> Okay, not meaning to spam the mailing list ... > > It's all useful information, so it's not spam. :-) > >> Managed to analyze the firewire bus with Perisoft Bus Hound. > > That is a useful tool to get going. However, as you've noted on your wiki > page (http://subversion.ffado.org/wiki/projectmix) it only captures the > first few bytes of a transaction. While this is often acceptable for > control packets (which tend to be small) it is limiting when working with > iso data packets. > It definitely is a big problem. I have no doubt that if I could capture all of the ISOC transactions that my work would be far simpler. At the minute I'm left with guesswork, or even more tedious: writing a filter driver for Windows (which I am currently looking at, and it may prove helpful to the project in the future). > If you haven't already had a look at it, you might like to view a talk I > did > on this general subject at Linux.conf.au in 2011: "Playing with fire: > protocol analysis techniques for the Firewire bus". URL to the video is > > > http://blip.tv/linuxconfau/playing-with-fire-protocol-analysis-techniques-for-the-firewire-bus-4711189 > > Slides are still available from here: > > > http://www.atrad.com.au/~jwoithe/lca2011/lca2011_firewire_analysis_talk.pdf > Thanks! I'll definitely have a look when I get home from work! > I should also note that I've seen what subsequently seem to be ordering > issues in the results sent to me by others from the free version of > bushound. I suspect it might be a cut-paste issue, but I thought I'd > mention it in case you observed something along these lines which didn't > make sense. > >> I just observed a few basic operations. Things such as when the device >> initially communicates with the Windows driver. Sending and receiving >> audio. Changing volume and sample rate. > > Yes, that is certainly the best way to proceed. > >> Also, I'm pretty sure it is BeBoB, the first thing that it sends over the >> Firewire bus is the string "bridgeCo". > > I agree - this strongly suggests this to be the case. > > Regarding the audio streaming format you mention on the wiki, it may be > that > the device more or less follows AMDTP and that therefore there won't be a > lot of work needed on that aspect of the device's functionality. This may > become apparent once you have a better handle on the control side of things. > > Once you know how to control the device experiments with streaming can > proceed. > >> https://www.dropbox.com/s/tmyidxjjypqqoeg/projectmix-dump.zip > > To keep things self-contained it might be good to attach this zip to the > wiki page. > > Regarding the embrionic defines on the wiki dev page, don't forget to add > LL > to all the 64-bit identifiers to keep various compilers quiet. > > Also, feel free to post the configuration entry for the ProjectMix so we > can > add it to the configuration file (at least so we can document the > vendor/device IDs). > I agree, probably a better idea to keep it all self contained. I never bothered with the LLs on the 64-bit identifiers, as my compiler wasn't bothered. However I will make a note to do that today. > You mentioned that you're implementing a new driver for this device. Keep > in mind that once we have a better handle on the device it might prove > useful to merge it into the BeBoB framework - probably as a subclass. This > will be especially the case if it turns out the AMDTP streaming code can be > used more or less as-is. Given that the ProjectMix is BeBoB based I expect > the subclass approach will ultimately be workable. However, if for some > reason things really are done totally differently for the ProjectMix then a > separate driver might be needed. In any case, while determining the > details > of the device a dedicated driver is definitely justifiable. > Yeah, however it was just easier for the purposes of hacking and playing about with it to have a clean driver with no other code for different cards. In the long term (if I get it working) I'll try to integrate it into BeBoB, then submit the code for review. > Regards > jonathan > Regards, Darren |