Thread: Multi-channel receive
Brought to you by:
aeb,
bencollins
Menu
▾
▴
linux1394-user
|
From: Chris Wj <chr...@gm...> - 2012-03-29 16:52:01
|
Hey all. I am trying to figure out the best way to perform a multi-channel receive using the raw interface. The data is coming from a single device (custom, not common audio/video), but does not have to be joined together. The packet size is around 8K as well, so I have to use the new driver so I am not limited by the kernel pagesize. Basically, I want to listen and read from 2 channels (0 and 1) and process their data separately. Can I set up 2 threads with 2 distinct handles to read from the same device but different channels? I'm new to Firewire development so apologies if these are simple questions. Thanks much, Chris |
|
From: Clemens L. <cl...@la...> - 2012-03-29 18:36:38
|
Chris Wj wrote: > I am trying to figure out the best way to perform a multi-channel > receive using the raw interface. Please note that the controller has a special mode to receive the packets of multiple channels into one buffer, called multi-channel reception. And the interface of the _old_ stack is called raw1394. (The new stack's API doesn't have its own name; just call it Juju. :-) > Basically, I want to listen and read from 2 channels (0 and 1) and > process their data separately. Can I set up 2 threads with 2 distinct > handles to read from the same device but different channels? Yes. (The API does not require multiple threads.) Regards, Clemens |
|
From: Chris Wj <chr...@gm...> - 2012-03-29 19:17:56
|
On Thu, Mar 29, 2012 at 2:36 PM, Clemens Ladisch <cl...@la...> wrote: > Chris Wj wrote: > > I am trying to figure out the best way to perform a multi-channel > > receive using the raw interface. > > Please note that the controller has a special mode to receive the > packets of multiple channels into one buffer, called multi-channel > reception. And the interface of the _old_ stack is called raw1394. > (The new stack's API doesn't have its own name; just call it Juju. :-) > > > Basically, I want to listen and read from 2 channels (0 and 1) and > > process their data separately. Can I set up 2 threads with 2 distinct > > handles to read from the same device but different channels? > > Yes. (The API does not require multiple threads.) > > > Regards, > Clemens > Clemens, thanks for the response. I very much appreciate it. So it seems like in my case, I will not want to use the multi-channel reception as I am expecting 2 distinct sets of data from the different channels even though it is from the same device, correct? If this is the case, can I use libraw1394? I noticed that the libraw1394 code does not implement multi-channel reception yet. This caused me to believe that I may not be able to use it for my use case. -Chris |
|
From: Clemens L. <cl...@la...> - 2012-03-29 19:20:48
|
Chris Wj wrote: > So it seems like in my case, I will not want to use the multi-channel > reception Yes; you just want to receive multiple channels. :) > can I use libraw1394? Yes. Regards, Clemens |
|
From: Chris Wj <chr...@gm...> - 2012-03-29 19:47:56
|
On Thu, Mar 29, 2012 at 3:20 PM, Clemens Ladisch <cl...@la...> wrote: > Chris Wj wrote: > > So it seems like in my case, I will not want to use the multi-channel > > reception > > Yes; you just want to receive multiple channels. :) > > > can I use libraw1394? > > Yes. > > With the new firewire-core (Juju) modules, I am no longer limited by the system's pagesize, correct? I am expecting S800 8K packets and the page size of the x86_64 system is set to 4K. > > Regards, > Clemens > While I will not use it, I am curious about the multi-channel receive mode. Is it part of a specification? Is it basically creating a single contiguous buffer from the data from multiple channels? Best, Chris |
|
From: Stefan R. <st...@s5...> - 2012-03-29 23:50:24
|
On Mar 29 Chris Wj wrote: > With the new firewire-core (Juju) modules, I am no longer limited by the > system's pagesize, correct? I am expecting S800 8K packets and the page > size of the x86_64 system is set to 4K. This should indeed work. IIRC there are libdc1394 users who do actually capture video streams with packets larger than 4 kiB. So our software supports that, but be warned that Texas Instruments controllers will not work for you. They have a too small isochronous reception FIFO and will inevitably give you corruption due to dropped (or maybe incomplete?) packets. You are going to need Agere FW643E or FW643E2 controllers for this; they have suitably large FIFOs. Also make sure that the two simultaneous streams won't overuse the available bus bandwidth. Here are two tables with the constraints: http://damien.douxchamps.net/ieee1394/libdc1394/v2.x/faq/#How_can_I_work_out_the_frame_rate_from_the_packet_size E.g. if you divided the overall isochronous bandwidth of an S800 bus equally between two streams and keep a constant data rate throughout each cycle, each stream's packets could be at most 75 MiB/s / 2 * 125 µs = 4.8 kiB large. But I suppose the designer of the device and of its stream format took this into account. > While I will not use it, I am curious about the multi-channel receive mode. > Is it part of a specification? Is it basically creating a single contiguous > buffer from the data from multiple channels? It is defined by OHCI-1394 v1.1 and also by its predecessor OHCI-1394 v1.0. https://ieee1394.wiki.kernel.org/ has a page with links to various specifications, among them "1394 Open Host Controller Interface Specification" vulgo OHCI-1394 which is available at no cost. Multi-channel IR DMA is a variant of buffer-fill IR DMA. You find it described in sections 10.2.1 and 10.6.1 of the spec. In your initial post you wrote that you want to process the two streams separately and possibly in two threads. Multi-channel IR DMA is not a good choice for this since the controller would just stuff all packets (of all streams to which this DMA is told to listen to) into the reception buffer in order of arrival. An application like yours would have to separate the streams again before or during processing. >> I noticed that the libraw1394 code does not implement multi-channel >> reception yet. The fact that libraw1394 does not implement multi-channel reception via the current firewire kernel drivers is just a libraw1394 bug of the fixable, missing-feature kind. When multi-channel reception was implemented in the firewire kernel drivers, I started to write the matching libraw1394 code but got distracted at 33 % completion. That said, libraw1394 is generally not recommended for new development. This is not mant as a general deprecation of libraw1394; it will be available and maintained for as long as there is FireWire support on Linux. But libraw1394's API is lower-level than necessary and than desirable in almost any application domain. Sure enough, the alternative which would be the <linux/firewire-cdev.h> API, being an ioctl(2)/read(2) based API, is naturally ugly and low-level too, but it nevertheless is actually higher-level than <libraw1394/raw1394.h> in a few respects. On the other hand, <linux/firewire-cdev.h> may provide more control than <libraw1394/raw1394.h> to those who are keen on more control. -- Stefan Richter -=====-===-- --== ====- http://arcgraph.de/sr/ |
|
From: Chris Wj <chr...@gm...> - 2012-03-30 18:10:35
|
On Thu, Mar 29, 2012 at 7:50 PM, Stefan Richter <st...@s5...>wrote: > On Mar 29 Chris Wj wrote: > > With the new firewire-core (Juju) modules, I am no longer limited by the > > system's pagesize, correct? I am expecting S800 8K packets and the page > > size of the x86_64 system is set to 4K. > > This should indeed work. IIRC there are libdc1394 users who do actually > capture video streams with packets larger than 4 kiB. > > So our software supports that, but be warned that Texas Instruments > controllers will not work for you. They have a too small isochronous > reception FIFO and will inevitably give you corruption due to dropped (or > maybe incomplete?) packets. > > Oh man... I just went back and checked and my host controller has the Texas Instruments TSB82AA2 chip! It is the Data Optic 1394b PCI Express Controller. Do you foresee me having to get a new controller? How big of an issue do you think this will be for me? > You are going to need Agere FW643E or FW643E2 controllers for this; they > have suitably large FIFOs. > |
|
From: Stefan R. <st...@s5...> - 2012-03-31 11:37:03
|
On Mar 30 Chris Wj wrote: > On Thu, Mar 29, 2012 at 7:50 PM, Stefan Richter > <st...@s5...>wrote: > > This should indeed work. IIRC there are libdc1394 users who do actually > > capture video streams with packets larger than 4 kiB. > > > > So our software supports that, but be warned that Texas Instruments > > controllers will not work for you. They have a too small isochronous > > reception FIFO and will inevitably give you corruption due to dropped (or > > maybe incomplete?) packets. > > > Oh man... I just went back and checked and my host controller has the Texas > Instruments TSB82AA2 chip! It is the Data Optic 1394b PCI Express > Controller. Do you foresee me having to get a new controller? How big of an > issue do you think this will be for me? From what I have heard, TSB82AA2 is useless for high-bandwidth video. Of course, isochronous transmissions are about guaranteed data rate and limited latency but without delivery guarantee in the first place (in contrast to asynchronous transactions with guaranteed delivery but no bandwidth guarantee and (almost) unlimited latency). Though video folks appreciate it if delivery failures occur rarely or not at all. But with TSB82AA2, large 1394b isochronous packets reportedly result in corruptions of practically every video frame, IIRC. Extrapolating from those reports to the application that you described, I suspect that you would get corruptions to an intolerable extent too. Hence be prepared to have to look for an Agere FW643E(2) based card. IOI, Point Grey Research, Unibrain and maybe others offer such cards. -- Stefan Richter -=====-===-- --== ===== http://arcgraph.de/sr/ |
|
From: Clemens L. <cl...@la...> - 2012-03-31 13:00:27
|
Stefan Richter wrote: > From what I have heard, TSB82AA2 is useless for high-bandwidth video. ISO receive FIFO size (if the datasheets can be trusted): TSB82AA: 2 KB FW643E: 8 KB However, the controller begins writing the data to memory as soon as the first byte has been recveived; this is not a limit on the packet size but just a means to handle delays on the PCI and memory buses. > Hence be prepared to have to look for an Agere FW643E(2) based card. It would also be possible to use multiple controllers, so that each channel's packets can occpuy an entire FIFO. (There are adapters with two or three controller chips on one card.) However, it's likely that one good controller is enough for you. Regards, Clemens |
|
From: Clemens L. <cl...@la...> - 2012-03-30 07:06:47
|
Stefan Richter wrote: > Chris Wj wrote: >>> I noticed that the libraw1394 code does not implement multi-channel >>> reception yet. > > The fact that libraw1394 does not implement multi-channel reception via > the current firewire kernel drivers is just a libraw1394 bug of the > fixable, missing-feature kind. Well, there is the slight problem that the Juju IR buffer-fill code has the same problem that the old AR code had, i.e., if a packet has been split over three or more descriptors, the controller is not required to update the middle descriptor(s), so the descriptor parsing loop just stops. This might be easier to trigger because applications can submit buffers smaller than a page. Regards, Clemens |
|
From: Stefan R. <st...@s5...> - 2012-03-30 07:37:16
|
On Mar 30 Clemens Ladisch wrote: > Well, there is the slight problem that the Juju IR buffer-fill code has > the same problem that the old AR code had, i.e., if a packet has been > split over three or more descriptors, the controller is not required to > update the middle descriptor(s), so the descriptor parsing loop just > stops. This might be easier to trigger because applications can submit > buffers smaller than a page. Sigh. Thanks for the report. -- Stefan Richter -=====-===-- --== ====- http://arcgraph.de/sr/ |
|
From: Chris Wj <chr...@gm...> - 2012-03-30 17:41:58
|
On Fri, Mar 30, 2012 at 3:09 AM, Clemens Ladisch <cl...@la...> wrote: > Stefan Richter wrote: > > Chris Wj wrote: > >>> I noticed that the libraw1394 code does not implement multi-channel > >>> reception yet. > > > > The fact that libraw1394 does not implement multi-channel reception via > > the current firewire kernel drivers is just a libraw1394 bug of the > > fixable, missing-feature kind. > > Well, there is the slight problem that the Juju IR buffer-fill code has > the same problem that the old AR code had, i.e., if a packet has been > split over three or more descriptors, the controller is not required to > update the middle descriptor(s), so the descriptor parsing loop just > stops. This might be easier to trigger because applications can submit > buffers smaller than a page. > > Is this problem applicable only to multi-channel receive mode? > > Regards, > Clemens > > > ------------------------------------------------------------------------------ > This SF email is sponsosred by: > Try Windows Azure free for 90 days Click Here > http://p.sf.net/sfu/sfd2d-msazure > _______________________________________________ > mailing list Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linux1394-user > |
|
From: Clemens L. <cl...@la...> - 2012-03-30 17:52:47
|
Chris Wj wrote: > On Fri, Mar 30, 2012 at 3:09 AM, Clemens Ladisch <cl...@la... <mailto:cl...@la...>> wrote: > Well, there is the slight problem that the Juju IR buffer-fill code has > the same problem that the old AR code had, i.e., if a packet has been > split over three or more descriptors, the controller is not required to > update the middle descriptor(s), so the descriptor parsing loop just > stops. This might be easier to trigger because applications can submit > buffers smaller than a page. > > Is this problem applicable only to multi-channel receive mode? Yes, normal reception with one channel per context works fine. Regards, Clemens |
Thanks for helping keep SourceForge clean.
X