From: Jonathan W. <jw...@ph...> - 2011-02-25 00:31:55
|
Hi Damien > Through reverse engineering some fw packets, I was able to figure out > the register required to set the sample rate of the Digidesign 003 and > the possible values with their corresponding rates. It supports 44100 > 48000 88200 and 96000. > I was also able to read the config rom using ffado and got the vendor > id and other stats. Awesome. > I have hacked together a semi-working 'driver/configuration' using the > motu configuration files in ffado and added support for the 003 to > enable setting of the sample rate using ffado-test. Ok, so this gives you a proof of concept. What we probably need to do now is set up a framework in trunk which permits development of a digi driver. There's little point in shoe-horning this into any of the existing drivers because the digi hardware is likely to be quite different. We can however use one of the existing drivers as a template of sorts. I'm happy to do this in the next day or so for you. One question though: while you yourself have the 003, I am tempted to name the driver more generically - say, "digi" or "digidesign", or even "avid" since they now own Digidesign. This the provides a logical place to add support for the other digi hardware if/when that becomes feasible. What do you think? > I am unsure how to enable the audio streams and would like to know if > I should bother capturing some iso packets using nosy. There's really two different issues here. The first is how to enable audio streams while the second is the question of the format of the data being sent to/from the hardware. Based on all other interfaces it's almost certain that you'll have audio data mixed with other side-channel data, the latter possibly including MIDI, control and timestamp information. To work out how to start and stop the audio streaming you'll have to use nosy to capture the async packets sent when a supported OS starts and stops the audio playback. From this you can deduce the protocol required. A trap to be aware of is that the device streaming is not necessarily started when you hit "play" and stopped when you hit "stop". Instead playback may be started when the playback application is started, and it might only stop seconds after the playback application is exitted. Therefore it takes a bit of experimentation to work out how things are driven. None of this has any bearing on the ffado driver - you just need to know how the supported OS does things so you know you're capturing the correct packets. > Will that tell me how to enable the streams? Iso packets won't help you work out how to start streaming, but capturing them will allow you to work out the format used to transport audio (and other) data to and from the device. > Also, it appears that the device does all the routing in hardware, so the > config is very simple. Regarding the internal routing, this is a common trait with modern firewire audio devices. I would however presume that there's an application on supported OSs which allow you to control this routing (most devices include an app which is modeled on the traditional mixer concept)? If this is the case, then the control of the onboard routing also forms a component of the control protocol, and in time you'll have to deduce how this is done in the same way that you approached the setting of the sample rate. All such control is almost certainly done using aysnc packets. So while the configuration required to get audio in and out of the device may be simple, there may be more to it when it comes to total control of the device. Certainly the protocol may be conceptually simple, but there still may be many registers which need identifying. > I don't even know if it has separate streams for > each channel or if it multiplexes all the data down one stream and relies > on software to decode it.... i guess iso packets will tell me that? Yes, these packets will tell you this. It is almost certain that there is a single stream in each direction with all data multiplexed onto that. I do not personally know of any audio device which doesn't do it this way and in most cases it makes no technical sense to split the data in any way. By the way, it *may* be a good idea to probe the device at least superficialy before starting to work too much on a driver. That way you have some idea as to how the device is controlled and this can dictate how you structure the driver. Stefan Richter then wrote: > On Feb 25 Damien Zammit wrote: > > I am unsure how to enable the audio streams and would like to know if > > I should bother capturing some iso packets using nosy. > > Will that tell me how to enable the streams? > > Some stream formats carry state information, but I don't think that there > are stream formats which carry control requests. I don't know of any which carry control requests from the PC to the device in the iso data stream. However, some devices do provide extensive device status feedback in the iso data stream. Regards jonathan |
From: Jonathan W. <jw...@ph...> - 2011-02-25 00:39:19
|
Hi Clemens > Libraw1394 uses raw1394's convention of cycle numbers always being less > than one second, i.e., in the range 0..7999. Yeah, and that very issue has bitten me in the past at least under the old stack. From what I recall the old stack's kernel driver actually carries 2 bits for a seconds field and includes these in the comparison when working out if it's time to start or not. If this wasn't taken into account one could see a delay of up to 4 seconds before the iso streaming was started (at least on the transmit side). In my case the solution at the time was to instruct the kernel to start things immediately (by passing -1 as the start cycle). I'm not actually certain that the old stack's behaviour was correct here, but since I had a workaround for my problem (and because the old stack is deprecated anyway) I didn't bother to analyse the issue any further. Could the issue you've addressed be the cause for some of the FFADO startup glitches under the new stack that we've been seeing lately (I don't know enough about non-MOTU non-RME drivers to determine if it is significant or not)? Regards jonathan |
From: Clemens L. <cl...@la...> - 2011-02-25 07:54:50
|
Jonathan Woithe wrote: > > Libraw1394 uses raw1394's convention of cycle numbers always being less > > than one second, i.e., in the range 0..7999. > > Yeah, and that very issue has bitten me in the past at least under the old > stack. From what I recall the old stack's kernel driver actually carries 2 > bits for a seconds field and includes these in the comparison when working > out if it's time to start or not. [...] > I'm not actually certain that the old stack's behaviour was correct here, The old stack (and now libraw1394 with the new stack) takes the seconds bits from the current cycle timer, so there is a race when the cycler counter is wrapping around, i.e., the programmed start time is either zero to one or one to two seconds in the future. > Could the issue you've addressed be the cause for some of the FFADO startup > glitches under the new stack that we've been seeing lately? If FFADO doesn't expect the actual packet times to be off by a few seconds, this is possible. I'd expect the DICE fix to haver a bigger effect, though. I'd think that ultimately, FFADO shouldn't try to use the new stack through the libraw1394 API. Regards, Clemens |
From: Jonathan W. <jw...@ph...> - 2011-02-26 10:02:42
|
Clemens wrote: > The old stack (and now libraw1394 with the new stack) takes the seconds > bits from the current cycle timer, so there is a race when the cycler > counter is wrapping around, i.e., the programmed start time is either > zero to one or one to two seconds in the future. Yep, that makes sense given what I've been seeing. > > Could the issue you've addressed be the cause for some of the FFADO startup > > glitches under the new stack that we've been seeing lately? > > If FFADO doesn't expect the actual packet times to be off by a few > seconds, this is possible. I'd expect the DICE fix to haver a bigger > effect, though. This be the batching fix? I've just read the tail-end of that discussion and I tend to agree. I'll do some more reading and run some more tests here at some point soon, but certainly if there was unintended delays through libraw1394 it *may* explain some of the very strange issues I've seen from time to time with MOTU and (more recently) RME devices. > I'd think that ultimately, FFADO shouldn't try to use the new stack > through the libraw1394 API. True, I think most of us probably think that. However, at present that's what it does so I guess we've got to make the best of it for the moment. Regards jonathan |
From: Euan de K. <eu...@de...> - 2011-02-26 14:16:25
|
Hi Jonathan, I would like to get a copy of the libraw1394 that has these recent patches, is there an accessible repository out there. Or even a Tar ball that's up to date. I have a copy of git://git.kernel.org/pub/scm/libs/ieee1394/libraw1394.git but this is only current to November 2010. >From what I can see the only other sources are based on the whole kernel tree. Regards, Euan. On Sat, 2011-02-26 at 20:32 +1030, Jonathan Woithe wrote: > Clemens wrote: > > The old stack (and now libraw1394 with the new stack) takes the seconds > > bits from the current cycle timer, so there is a race when the cycler > > counter is wrapping around, i.e., the programmed start time is either > > zero to one or one to two seconds in the future. > > Yep, that makes sense given what I've been seeing. > > > > Could the issue you've addressed be the cause for some of the FFADO startup > > > glitches under the new stack that we've been seeing lately? > > > > If FFADO doesn't expect the actual packet times to be off by a few > > seconds, this is possible. I'd expect the DICE fix to haver a bigger > > effect, though. > > This be the batching fix? I've just read the tail-end of that discussion > and I tend to agree. I'll do some more reading and run some more tests here > at some point soon, but certainly if there was unintended delays through > libraw1394 it *may* explain some of the very strange issues I've seen from > time to time with MOTU and (more recently) RME devices. > > > I'd think that ultimately, FFADO shouldn't try to use the new stack > > through the libraw1394 API. > > True, I think most of us probably think that. However, at present that's > what it does so I guess we've got to make the best of it for the moment. > > Regards > jonathan > > ------------------------------------------------------------------------------ > Free Software Download: Index, Search & Analyze Logs and other IT data in > Real-Time with Splunk. Collect, index and harness all the fast moving IT data > generated by your applications, servers and devices whether physical, virtual > or in the cloud. Deliver compliance at lower cost and gain new business > insights. http://p.sf.net/sfu/splunk-dev2dev > _______________________________________________ > FFADO-devel mailing list > FFA...@li... > https://lists.sourceforge.net/lists/listinfo/ffado-devel |
From: Jonathan W. <jw...@ph...> - 2011-02-27 07:33:55
|
Hi Euan > I would like to get a copy of the libraw1394 that has these recent > patches, is there an accessible repository out there. Or even a Tar ball > that's up to date. There is but I don't have the details to hand right now. I'll check this up in the next day or so and get back to you. I also want to grab an updated libraw1394 (or just apply the latest couple of relevant patches) because I suspect it may help with some of the strangeness I've been seeing with RME devices in particular. Unless someone else responds beforehand, I'll try to get back to you in a day or so. Regards jonathan |
From: Stefan R. <st...@s5...> - 2011-02-26 14:40:06
|
On Feb 26 Euan de Kock wrote: > I would like to get a copy of the libraw1394 that has these recent > patches, is there an accessible repository out there. Or even a Tar ball > that's up to date. > > I have a copy of > git://git.kernel.org/pub/scm/libs/ieee1394/libraw1394.git but this is > only current to November 2010. This is current. To try the new patches, you can for example do this: $ git checkout -b mine master (Creates and switches to a new branch called mine which is identical with master.) Save the two e-mails "[PATCH libraw1394] fix start_on_cycle on firewire-core" by Clemens, Thu, 24 Feb 2011 17:34:10 +0100 http://article.gmane.org/gmane.linux.kernel.firewire.devel/14805/raw and "Re: [FFADO-user] DICE and FFADO with Juju" by Clemens on Fri, 25 Feb 2011 08:48:22 +0100 http://article.gmane.org/gmane.linux.kernel.firewire.devel/14811/raw somewhere. $ git am ~/email1 ~/email2 (Applies and commits each patch.) $ make $ sudo make install -- Stefan Richter -=====-==-== --=- ==-=- http://arcgraph.de/sr/ |
From: Jonathan W. <jw...@ph...> - 2011-02-27 07:34:51
|
Hi Stefan > > I have a copy of > > git://git.kernel.org/pub/scm/libs/ieee1394/libraw1394.git but this is > > only current to November 2010. > > This is current. To try the new patches, you can for example do this: > : Thanks for the git suggestions. It saves me looking it up. :-) Regards jonathan |
From: Euan de K. <eu...@de...> - 2011-02-28 12:43:42
|
Thanks for this Stefan, this was really helpful. Regards, Euan. On Sat, 2011-02-26 at 15:39 +0100, Stefan Richter wrote: > On Feb 26 Euan de Kock wrote: > > I would like to get a copy of the libraw1394 that has these recent > > patches, is there an accessible repository out there. Or even a Tar ball > > that's up to date. > > > > I have a copy of > > git://git.kernel.org/pub/scm/libs/ieee1394/libraw1394.git but this is > > only current to November 2010. > > This is current. To try the new patches, you can for example do this: > > $ git checkout -b mine master > (Creates and switches to a new branch called mine which is identical with > master.) > > Save the two e-mails > "[PATCH libraw1394] fix start_on_cycle on firewire-core" > by Clemens, Thu, 24 Feb 2011 17:34:10 +0100 > http://article.gmane.org/gmane.linux.kernel.firewire.devel/14805/raw > and > "Re: [FFADO-user] DICE and FFADO with Juju" > by Clemens on Fri, 25 Feb 2011 08:48:22 +0100 > http://article.gmane.org/gmane.linux.kernel.firewire.devel/14811/raw > somewhere. > > $ git am ~/email1 ~/email2 > (Applies and commits each patch.) > $ make > $ sudo make install |
From: Jonathan W. <jw...@ph...> - 2011-02-26 11:44:00
|
Hi Adrian Knoth wrote: > > I have hacked together a semi-working 'driver/configuration' using > > the motu configuration files in ffado and added support for the 003 > > to enable setting of the sample rate using ffado-test. > > Why do you think it's like motu? I don't think he does. It was more a report of an informal proof of concept thing he did to prove that his idea about the protocol was correct. For development of the actual driver in trunk I have already proposed the creation of a separate driver for the digi systems because I suspect they will prove to be quite different to anything else out there. > > Also, it appears that the device does all the routing in hardware, > > According to ticket #318, it has a Xilinx Spartan2-FPGA. RME cards also > use such an FPGA (the slightly newer S3) to do zero latency monitoring > (read: hardware routing). Correct (although the RMEs as you say use a Spartan 3). However, even if the same FPGA is used the firmware is guaranteed to be completely different, so there's almost no chance of there being any common ground in the way RME and digidesign control their onboard mixers. > > so the config is very simple. I don't even know if it has separate > > You think so? ;) The problem starts when you have to figure out how to > address this hardware mixer. Indeed. It should be said that in most cases the concept is quite simple. What makes for a lot of work is the need to identify what is often a few hundred registers and what they do. Usually there are patterns which make things predictable, but discovering all this does take time and a methodical approach. > > streams for each channel or if it multiplexes all the data down one > > stream and relies on software to decode it.... i guess iso packets > > will tell me that? > > They will. According to ticket #318, the device uses the well-known > stuff like CIP headers, IEC 61883 (maybe AMDTP streaming?) and so on. I *think* that's only a suspicion at present - there's nothing in that ticket which confirms this at the moment. Obviously if it is true it will make things easier. > Don't give up. ;) Indeed - as you can tell there are several people on the list who will be very happy to give suggestions as they are able. Regards jonathan |
From: Adrian K. <ad...@dr...> - 2011-02-25 11:18:36
|
On 02/25/11 01:31, Jonathan Woithe wrote: > To work out how to start and stop the audio streaming you'll have to use > nosy to capture the async packets sent when a supported OS starts and stops > the audio playback. From this you can deduce the protocol required. A trap > to be aware of is that the device streaming is not necessarily started when > you hit "play" and stopped when you hit "stop". Instead playback may be > started when the playback application is started, and it might only stop > seconds after the playback application is exitted. On a side node: on Windows, the Alesis driver starts streaming as soon as you plug in the device. Technically, there are a few async packets which configure the device and finally enable iso streaming. So depending on the Windows/OSX driver, it might be necessary to capture the very first traffic after connecting the device. Cheers |