linux1394-devel Mailing List for IEEE 1394 for Linux (Page 535)
Brought to you by:
aeb,
bencollins
You can subscribe to this list here.
2000 |
Jan
|
Feb
|
Mar
(39) |
Apr
(154) |
May
(172) |
Jun
(237) |
Jul
(127) |
Aug
(135) |
Sep
(193) |
Oct
(175) |
Nov
(173) |
Dec
(148) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2001 |
Jan
(161) |
Feb
(225) |
Mar
(193) |
Apr
(158) |
May
(179) |
Jun
(292) |
Jul
(146) |
Aug
(134) |
Sep
(185) |
Oct
(190) |
Nov
(149) |
Dec
(161) |
2002 |
Jan
(186) |
Feb
(236) |
Mar
(254) |
Apr
(207) |
May
(189) |
Jun
(182) |
Jul
(202) |
Aug
(155) |
Sep
(149) |
Oct
(449) |
Nov
(191) |
Dec
(108) |
2003 |
Jan
(174) |
Feb
(242) |
Mar
(243) |
Apr
(255) |
May
(202) |
Jun
(290) |
Jul
(237) |
Aug
(178) |
Sep
(101) |
Oct
(153) |
Nov
(144) |
Dec
(95) |
2004 |
Jan
(162) |
Feb
(278) |
Mar
(282) |
Apr
(152) |
May
(127) |
Jun
(138) |
Jul
(94) |
Aug
(63) |
Sep
(64) |
Oct
(150) |
Nov
(102) |
Dec
(197) |
2005 |
Jan
(102) |
Feb
(172) |
Mar
(89) |
Apr
(158) |
May
(139) |
Jun
(160) |
Jul
(288) |
Aug
(89) |
Sep
(201) |
Oct
(92) |
Nov
(190) |
Dec
(139) |
2006 |
Jan
(121) |
Feb
(204) |
Mar
(133) |
Apr
(134) |
May
(91) |
Jun
(226) |
Jul
(122) |
Aug
(101) |
Sep
(144) |
Oct
(141) |
Nov
|
Dec
|
2023 |
Jan
(19) |
Feb
(1) |
Mar
(5) |
Apr
(5) |
May
(33) |
Jun
(17) |
Jul
|
Aug
|
Sep
(3) |
Oct
(1) |
Nov
(5) |
Dec
(40) |
2024 |
Jan
(26) |
Feb
(14) |
Mar
(26) |
Apr
(46) |
May
(17) |
Jun
(47) |
Jul
(23) |
Aug
(72) |
Sep
(33) |
Oct
|
Nov
|
Dec
|
From: Erik W. <om...@cs...> - 2000-04-28 20:36:35
|
For anyone looking at/working on libdv, please subscribe to the libdv-dev sourceforge list, so we can keep everything together in one place. There's a lot of stuff happening to libdv right now, and it'll help a lot if everyone knows what everyone else is working on. To subscribe: http://lists.sourceforge.net/mailman/listinfo/libdv-dev TIA, Omega Erik Walthinsen <om...@cs...> - Staff Programmer @ OGI Quasar project - http://www.cse.ogi.edu/DISC/projects/quasar/ Video4Linux Two drivers and stuff - http://www.cse.ogi.edu/~omega/v4l2/ __ / \ SEUL: Simple End-User Linux - http://www.seul.org/ | | M E G A Helping Linux become THE choice _\ /_ for the home or office user |
From: Stefan L. <lu...@be...> - 2000-04-28 20:22:13
|
I think there is something wrong with color conversion in libdv. The value of impact[3] is calculated but never used. From documentation of Brooktree Bt848 p. 41 color conversion should be: R = 1.164(Y - 16) + 1.596(Cr - 128)i G = 1.164(Y - 16) - 0.813(Cr - 128) - 0.391(Cb - 128) B = 1.164(Y - 16) + 2.018(Cb -128) So impact values should be calculated the following way impact[0] = 409 * cr; impact[1] = 100 * cb; impact[2] = 208 * cr; impact[3] = 516 * cb; Finally I had to exchange R and B value assignment to get good colors. - This is only checked with a PAL datastream. - My display works with 16 bit color depth. The following patch includes these modification for both YUV411 and YUV420. -- mfg Stefan Lucke (lu...@be...) |
From: Andreas M. <and...@iv...> - 2000-04-28 19:07:37
|
On Fri, Apr 28, 2000 at 05:29:58PM +0200, Andreas Bombe wrote: > S200 = unsupported Sony proprietary chip on Vaio > S400 = Sony or other OHCI chip on Vaio Makes sense to me. Thanks for the clarification. |
From: Andreas B. <and...@mu...> - 2000-04-28 16:14:54
|
On Tue, Apr 25, 2000 at 08:14:57PM +1000, Sebastien Rougeaux wrote: > > I have updated the API for the direct iso dma to user space feature > that is available for the ohci driver. Previously the buffer filling > was running continuously in the driver, and the user app was only > waiting for irq generated for each frame. The problem was doing so > you could easily create synchronization problems. Now the user app > has to queue the buffers for each frame. If the user app can not keep > up with the framerate, the dma context will wait until fresh buffers > are queued. It is very similar to the video4linux API. Is there anything special about this DMA? I guess it just does header stripping instead of giving the complete packet like libraw does. Strictly seen it's also not DMA to user space but having kernel buffers mapped to user space (what I intended to do for libraw once I figure it out and get to it). What I have problems with is that it duplicates a lot of bttv code, something Linus probably will also complain about. Plus, from my understanding, the bttv code handles a lot of cases which are not required for OHCI hardware. What I have in mind for better iso receiving is something like a manager part in the subsystem handing out chunks of 64kB (or something, should be tunable) contiguous mem to the hardware drivers which receive iso packets into those. When the remaining space in the chunk is too small for more packets, the driver tells the subsystem and gets a new chunk. The filled chunks have then a soft and a hard reference count. The soft count indicates that someone is interested in the contained data at all (otherwise it could just as well be freed immediately). The hard count indicates that it must not be freed at this time (e.g. it's mapped to user space by raw1394 currently). If a limit is reached or memory gets low the oldest chunks with soft references but no hard refs can be freed (i.e. packets get lost). > /* queue the buffers for frame acquisition */ > for (i=0;i<v.nb_buffers;i++) { > w.buffer=i; > if (ioctl(fd,VIDEO1394_QUEUE_BUFFER,&w)==-1) { > perror("VIDEO1394_QUEUE_BUFFER"); > return -1; } > } ^ In case anyone wondered there was a missing closing brace there. -- Andreas E. Bombe <and...@mu...> DSA key 0x04880A44 http://home.pages.de/~andreas.bombe/ http://linux1394.sourceforge.net/ |
From: Andreas B. <and...@mu...> - 2000-04-28 16:14:39
|
On Thu, Apr 27, 2000 at 07:42:57PM +0200, Andreas Micklei wrote: > Has anyone tried this before? Can anyone confirm if this chipset is OHCI > compliant at all? The i-link port is supposed to be S200. Windows reports a > Sony CXD1947A i.Link[1394] PCI Host Controller. This seems to be the proprietary Sony chip then. Since there are no OHCI chips not supporting S400 and the proprietary Sony chip only supports S200 to my knowledge, could we use that as a distinction between supported and unsupported Vaios? S200 = unsupported Sony proprietary chip on Vaio S400 = Sony or other OHCI chip on Vaio Or does someone know of different configurations? -- Andreas E. Bombe <and...@mu...> DSA key 0x04880A44 http://home.pages.de/~andreas.bombe/ http://linux1394.sourceforge.net/ |
From: Manfred W. <e95...@st...> - 2000-04-28 16:11:42
|
Hi! Since the 1394 cycle time register provides a very accurate clock, it would be a perfect means for synchronisation purposes. I would like to use it for synchronisation of the video and audio frames of a DVB stream. But there is one big problem. If I liked to present a frame at a given cycle time T, I would have to use a code like this: quadlet_t buf; do raw1394_read(rawhandle, 0xffc0 | raw1394_get_local_id(handle), CSR_CYCLE_TIME, 4, &buf); while (T > buf); presentFrame(); The problem is, that this is busy waiting and therefore very cpu consuming. So it would be nice, if we could find a way to register something to get an information, when a given cycle time is reached. My idea is to register a callback funktion for that purpose. Consider this example: int timestamp_reached; int timer_callback() { timestamp_reached=1; return 0; } ... raw1394_set_cycletime_handler(rawhandle, T, timer_callback); timestamp_reached=0; while (!timestamp_reached) raw1394_loop_iterate(rawhandle); presentFrame(); I believe that this would be cleaner, because raw1394_loop_iterate is - afaik - blocking, and therefore this would not be busy waiting. So my question is, if it is possible to implement something like "raw1394_set_cycletime_handler" in the example above or something similar (another way would be not to register a callbackfunction, but just the address of a variable which will be incremented, when libraw receives the message, that the time was reached). And if it is possible, can you imagine to implement it in the near future? I think, that would be a really nice feature. Manfred Weihs |
From: Alastair M. <ala...@aj...> - 2000-04-28 15:49:24
|
Well, I fixed the last (?) silly bug in my audio routines so that at least 16-bit 48khz data plays (and can be written to disk) properly. (Recording a 1khz tone and observing my decoded output in a program that displayed the waveform was very helpful). The latest is posted at http://www.ajwm.net/backfire/dv_audio/ Note that although the code is there to handle PAL, it needs a table of offsets to be filled in for that to work. But it does work with NTSC. The above URL also has a modified version of playdv.c that plays back the sound (kind of strangely if your system can't keep up a real time framerate), and a simple standalone program that just plays back the audio from a .dv file. Erik Walthinsen wrote: > > On Wed, 26 Apr 2000, Alastair Mayer wrote: > > > If anyone has a copy of this, could they summarize the relevant details > > sufficient for me to add decoding for 32kHz/12-bit and 44.1kHz/16-bit > > which it allows? > > Ack, I left it at work. I'll summarize it as compared to 314M when I get > into work tomorrow. If you get a chance to do this, it'd be great, thanks. > Did you happen to try your code on pond.dv, from > ftp.libdv.sourceforge.net? It claims to be a 314M-compliant stream, and > should be 48kHz/16-bit (captured from Canon Elura), though every couple > dozen frames it changes to a 61834 stream for a frame, according to the > APT field. I'm confused on that one, anyone have an idea why that would > be? Yes, but something is wrong. My code reports a lot of invalid audio blocks from pond.dv (which may well be my code, but it works fine on the data from my Sony TRV-103) and what audio it does decode comes out as short noise bursts. -- Alastair |
From: Daniel K. <dan...@st...> - 2000-04-28 10:04:25
|
On Thu, 27 Apr 2000, Andreas Micklei wrote: > Has anyone tried this before? Can anyone confirm if this chipset is OHCI > compliant at all? The i-link port is supposed to be S200. Windows reports a > Sony CXD1947A i.Link[1394] PCI Host Controller. The 1947A isn't OHCI compatible but a proprietary chipset. Someone had posted a few links to Sony's documentation to the list: http://www.sel.sony.com/semi/PDF/CXD1947Q.pdf http://www.sel.sony.com/semi/PDF/CXD1944R.pdf http://www.sel.sony.com/semi/ieee1394.html That's about all there is. Daniel. -- GNU/Linux Audio Mechanics - http://www.glame.de GPG Key ID 89BF7E2B - http://www.keyserver.net |
From: Sebastien R. <Seb...@sy...> - 2000-04-27 23:29:23
|
>>>>> "Arne" == Arne Schirmacher <ar...@sc...> writes: Arne> I wanted to modify my dvgrab code, but dvgrab uses libraw 0.6, no direct Arne> dma available there :-( [ yet? :-) ] Sorry for the confusion. I might not have been explicit enough. Direct user space dma and libraw are completely independent (for the moment). You use libraw to initialize the camera (everything you did before, except you do not need the iso_handler, and you DO NOT use raw1394_start_iso_rcv() nor the raw1394_loop_iterate(). Then you use /dev/ohci1394 as a frame grabbing device, following the instructions I have given in my previous announcement. I have already two successful users for this feature ;-), so it should work. Feel free to ask any question you might have, -- Sebastien Rougeaux RSISE, The Australian National University |
From: Arne S. <ar...@sc...> - 2000-04-27 18:42:51
|
I wanted to modify my dvgrab code, but dvgrab uses libraw 0.6, no direct dma available there :-( [ yet? :-) ] Arne -----Original Message----- From: Sebastien Rougeaux [SMTP:Seb...@sy...] Sent: Wednesday, April 26, 2000 1:08 AM To: ar...@sc... Cc: and...@mu...; lin...@li... Subject: Re: My wishlist entry If I may suggest, you should try the new direct dma to user space feature I have announced the other day for the ohci driver. You can set the buffer size to the size of your dv encoded frame at run-time (it even does multi-buffering), and you save quite a bit of CPU time (the ohci hardware does frame sync and packet header/trailer stripping for you)... Definitely a must use for video acquisition, and I would welcome any feedback on it ;-) -- Sebastien Rougeaux RSISE, The Australian National University |
From: Andreas M. <and...@iv...> - 2000-04-27 17:50:31
|
Hi, today I had the opportunity to try the Linux1394 subsystem on a Sony VAIO PCG-C1F. Unfortunately the driver failed to detected the 1394 chipset. lspci reports a Sony unknown device 8009, so I added a { PCI_VENDOR_ID_SONY, PCI_DEVICE_ID_TI_OHCI1394_LV22 } to ohci1394.c, but still I had no success. Has anyone tried this before? Can anyone confirm if this chipset is OHCI compliant at all? The i-link port is supposed to be S200. Windows reports a Sony CXD1947A i.Link[1394] PCI Host Controller. Together with gscanbus the VAIO would be a handy 1394 debugging tool. ;-) ciao... Andreas Micklei |
From: Bruce M. <br...@tr...> - 2000-04-27 03:06:45
|
On Wed, 26 Apr 2000, Andreas Micklei wrote: Andreas, Thanks for the response, I was certainly going to address the functionality covered first. I really want to understand more before coding but I must admit that I have pulled the avc code from gscanbus. I intend to provide at least the simpleavc levels of service. I would like to include avc functions from the C++ of k-3d. I would however like to include sufficient functionality so that complete dvcam (ultimate end, really) support is available. My moves now are: 1. autoconf support (for which I will look at libraw1394) 2. iterative development for target app attempting to abstract api. The name will be libavc1394 and will rely on libraw1394. The specification document (1996/8/13) is: (http://www.1394ta.org/Download/Technology/Specifications/1394_AVC.pdf) Is there any libraw1394 documentation out there or is that an open item? functionality in rough order of implementation 0. immediate transactions. 1.5. device query operations. 1. stop/play(speeds)/wind/record/pause. 2. deferred transaction management. 4. date and timecode operations. 5. seek operations. 6. plug, mic and analog audio stuff (dunno much here) Input? Bruce. > Hi, > > On Tue, Apr 25, 2000 at 11:23:00PM -0400, Bruce McDonald wrote: > > I'm new here so go easy. I am very interested in developing a dvcam tape > > scanning application that produces a batch capture list on output (at the > > very least). I am approaching this from the bottom-up so I am trying to > > abstract the AV/C & libraw funcations into a "libavc". I have noticed > > that gscanbus & and the sdpavc (from k-3d) both have their own api's (not > > in library form). I need to redo this existing overlap, so a library > > might be useful. > > I thought this to and actually I am planning to seperate the AV/C code from > gscanbus into a seperate library. However it would just be a libsimpleavc, so > just go ahead and build a "real" AV/C library if you need it. I would happily > adopt it for gscanbus and focus on something else. > > My simple AV/C implementation is quite handy for sending a command to a device > and receiving the response code. However I have not spent a single thought on > how to deal with input- / output-plugs and the whole issue of isochronous > stream management. This would probably be the hardest part of a real AV/C > implementation (and personally, I realy don't need that at the moment). > > > 0. Is the name, libavc, correct, or would libavc1394 (or other > > variant) be more correct? > > Both are correct. I would prefer libavc1394 because a beginner can than > easily figure out which parts belong to 1394. > > > 1. Would it be useful to develop a libavc which would implement the AV/C > > command set on top of libraw1394 in a standard way? > > Certainly. > > > (as an aside:- I tend to prefer C/asm for systems work and OO [c++/Java] > > languages for applications, so libavc would, most likely, be a C library) > > A C library would probably the best basis. A C++ / Java library on top of the > C library, or even better a CORBA binding would be nice to have later on. :-) > > Btw.: Can someone please put a gateway between the mailinglists at eclipt and > sourceforge, or shut down the list at eclipt completely? It is quite confusing > to have two seperate lists for the same subject. > > bye... > Andreas Micklei > |
From: Andreas B. <and...@mu...> - 2000-04-27 01:18:55
|
On Wed, Apr 26, 2000 at 10:25:47PM +0200, Manfred Weihs wrote: > My fix was to add the following line to the function raw1394_start_lock > (I added it as line 82 in the file readwrite.c of libraw1394): > > req->misc=extcode; > > Now it works. I suggest to add this to cvs, too. Oh, thanks. Good that it works now :-) -- Andreas E. Bombe <and...@mu...> DSA key 0x04880A44 http://home.pages.de/~andreas.bombe/ http://linux1394.sourceforge.net/ |
From: Manfred W. <e95...@st...> - 2000-04-26 21:27:22
|
Since the lock-compare_swap transaction obviously did not work, I used a packet analyzer today to have a lock at the lock packets and found out, that the extended tcode was not filled out correctly (it contained 0 whereas it should contain 2 [which I used as the extcode argument of raw1394lock]) My fix was to add the following line to the function raw1394_start_lock (I added it as line 82 in the file readwrite.c of libraw1394): req->misc=extcode; Now it works. I suggest to add this to cvs, too. Manfred Weihs |
From: Maxim S. S. <ma...@st...> - 2000-04-26 20:57:49
|
> you could easily create synchronization problems. Now the user app > has to queue the buffers for each frame. If the user app can not keep > up with the framerate, the dma context will wait until fresh buffers > are queued. It is very similar to the video4linux API. This is the same as MS stack does, though MS does not support it for umode apps - only for other kmode drivers. Max |
From: Erik W. <om...@cs...> - 2000-04-26 19:05:39
|
On Wed, 26 Apr 2000, Alastair Mayer wrote: > If anyone has a copy of this, could they summarize the relevant details > sufficient for me to add decoding for 32kHz/12-bit and 44.1kHz/16-bit > which it allows? Ack, I left it at work. I'll summarize it as compared to 314M when I get into work tomorrow. Did you happen to try your code on pond.dv, from ftp.libdv.sourceforge.net? It claims to be a 314M-compliant stream, and should be 48kHz/16-bit (captured from Canon Elura), though every couple dozen frames it changes to a 61834 stream for a frame, according to the APT field. I'm confused on that one, anyone have an idea why that would be? Erik Walthinsen <om...@cs...> - Staff Programmer @ OGI Quasar project - http://www.cse.ogi.edu/DISC/projects/quasar/ Video4Linux Two drivers and stuff - http://www.cse.ogi.edu/~omega/v4l2/ __ / \ SEUL: Simple End-User Linux - http://www.seul.org/ | | M E G A Helping Linux become THE choice _\ /_ for the home or office user |
From: <Ale...@ne...> - 2000-04-26 18:41:08
|
I am trying to build a simple async message passing application as the infrastructure for my project. I have two 1394 cards and I am trying to put one transmitting task on one card and one receiving task on the other card and have them exchange messages. So far I haven't succeeded in doing this with the libraw reads/writes. Also, MAKEDEV does not create 1394 drivers on my system's /dev directory. Can someone please send me some guidelines? Thanks, Alex. |
From: Alastair M. <ala...@aj...> - 2000-04-26 17:32:48
|
Help? I spent the last couple of days trying to figure out why my sound decoding routines for capture DV video weren't working properly. My bad, I was using the SMPTE 314 standard, which only expects audio at 48kHz, 16bit. Turns out the samples I was using are 12-bit, 32kHz, which is a legal IEC 61834 coding. (I'm still having a bit of trouble with my camcorder now set to 16-bit, but that's a different issue.) But I only have a copy of SMPTE-314 -- $34 I didn't mind paying, but not another $236 for a copy of IEC 61834-2, which has the description of other possible encoding. If anyone has a copy of this, could they summarize the relevant details sufficient for me to add decoding for 32kHz/12-bit and 44.1kHz/16-bit which it allows? Otherwise I guess I'll just tweak my code to reject anything it doesn't recognize (ie non-SMPTE 314) and let someone else take it from there. (If anyone wants to look at what's there so far, there's a copy at http://www.ajwm.net/backfire/dv_audio/ - it doesn't have changes I made last night and it needs work, but there it is.) -- Alastair |
From: Andreas M. <mi...@fo...> - 2000-04-26 08:56:19
|
Hi, On Tue, Apr 25, 2000 at 11:23:00PM -0400, Bruce McDonald wrote: > I'm new here so go easy. I am very interested in developing a dvcam tape > scanning application that produces a batch capture list on output (at the > very least). I am approaching this from the bottom-up so I am trying to > abstract the AV/C & libraw funcations into a "libavc". I have noticed > that gscanbus & and the sdpavc (from k-3d) both have their own api's (not > in library form). I need to redo this existing overlap, so a library > might be useful. I thought this to and actually I am planning to seperate the AV/C code from gscanbus into a seperate library. However it would just be a libsimpleavc, so just go ahead and build a "real" AV/C library if you need it. I would happily adopt it for gscanbus and focus on something else. My simple AV/C implementation is quite handy for sending a command to a device and receiving the response code. However I have not spent a single thought on how to deal with input- / output-plugs and the whole issue of isochronous stream management. This would probably be the hardest part of a real AV/C implementation (and personally, I realy don't need that at the moment). > 0. Is the name, libavc, correct, or would libavc1394 (or other > variant) be more correct? Both are correct. I would prefer libavc1394 because a beginner can than easily figure out which parts belong to 1394. > 1. Would it be useful to develop a libavc which would implement the AV/C > command set on top of libraw1394 in a standard way? Certainly. > (as an aside:- I tend to prefer C/asm for systems work and OO [c++/Java] > languages for applications, so libavc would, most likely, be a C library) A C library would probably the best basis. A C++ / Java library on top of the C library, or even better a CORBA binding would be nice to have later on. :-) Btw.: Can someone please put a gateway between the mailinglists at eclipt and sourceforge, or shut down the list at eclipt completely? It is quite confusing to have two seperate lists for the same subject. bye... Andreas Micklei |
From: Sebastien R. <Seb...@sy...> - 2000-04-25 23:47:29
|
>1- I browsed the source code very quickly and didn't find > anything whatever the level (ohci1394, ieee1394 or raw1394) > Is this the same for pcilynx and aic5800? That's normal, no support yet for ohci. >2- I'd like to know if there is somebody already in charge of > writing such iso writing function. > If so, I'd like to know how I can contribute (coding, > debugging,...) although I am very busy as everybody there;-) AFAIK, nobody is working on this for the ohci driver. I would welcome any patch/suggestion people may have. >4- I was also wondering why this feature was missing: is there > any tricky issues? I have not really looked into it yet. I don't think it would be that difficult, but I have other priorities right now. -- Sebastien Rougeaux RSISE, The Australian National University |
From: Sebastien R. <Seb...@sy...> - 2000-04-25 23:20:47
|
>>>>> "Jun" == Jun Sun <jul...@ya...> writes: >> NOTE 1: the driver is probably not safe for SMP machines (will do that >> later). It might also not be wise to share the device /dev/ohci1394 between >> several threads/processes. >> Jun> I am lost a little bit. How does this driver relate to libraw? The direct dma to user space feature bypass libraw (at least for the moment). So you use libraw to send 1394 commands to your camera, and you use the /dev/ohci1394 device to initialize/receive video frames. Jun> If the answer is yes, I wonder if any behavior is modified. For example, Jun> if both processes listen for the same iso channel, will they both get the Jun> data? If you use libraw to get iso data, then I guess yes data are duplicated. For direct iso-dma to user space, no. A same Iso channel cannot be listened by two separate dma contexts (except if you have 2 cards in the box I think), so there can be only one destination in memory for one iso channel. -- Sebastien Rougeaux RSISE, The Australian National University |
From: Sebastien R. <Seb...@sy...> - 2000-04-25 23:15:13
|
>>>>> "Arne" == Arne Schirmacher <ar...@sc...> writes: Arne> A command line option for the buffer size is all *I* would like to Arne> have. No need for any automatism though. As long as this feature is not Arne> there, I simply edit the source and recompile, but not all Linux users Arne> are capable of doing that (which is perfectly okay, not everybody is a Arne> programmer nor wants to install the many, many MBytes of developer Arne> related files and learn how to use it). Arne> My opinion is, if we want mainstream Linux users with slow systems using Arne> the Linux 1394 system for DV, then we need a command line option for the Arne> buffer size or another way to set the size. If I may suggest, you should try the new direct dma to user space feature I have announced the other day for the ohci driver. You can set the buffer size to the size of your dv encoded frame at run-time (it even does multi-buffering), and you save quite a bit of CPU time (the ohci hardware does frame sync and packet header/trailer stripping for you)... Definitely a must use for video acquisition, and I would welcome any feedback on it ;-) -- Sebastien Rougeaux RSISE, The Australian National University |
From: Manfred W. <e95...@st...> - 2000-04-25 21:19:39
|
Andreas Bombe wrote: > It made it better for me. I guess it does help, but just not enough > for you. It seems to be a symptom of interrupts not being served fast > enough. Do you probably have some drivers running that take a lot of > irq time (e.g. vesa fb)? Otherwise the data copying might really > overload your system. I do not use vesa fb. But maybe the reason could be the high data rate on that iso channel. I am receiving a complete MPEG 2 transport stream, which is iirc about 50 MBit/s. And the complete data is copied again in user space to the buffers of my software (which is not very efficient; I will improve that sometime in future), and a part of the data (which is intended to be decoded) is copied once again. Maybe there are too many copies (and the discussion about "DMA to userspace" tells me that copying the data could obviously cause performance problems). And since I also do some decoding, there is really high load on my system. This might be the reason. Manfred Weihs |
From: Andreas B. <and...@mu...> - 2000-04-25 19:56:55
|
On Tue, Apr 25, 2000 at 03:31:32PM +0200, ACCARIE Jean-Paul wrote: > I'd like to know what is the current situation concerning > iso write function: > 1- I browsed the source code very quickly and didn't find > anything whatever the level (ohci1394, ieee1394 or raw1394) > Is this the same for pcilynx and aic5800? It seems simple to implement iso sending for the PCILynx hardware. I guess OHCI isn't that hard either. > 2- I'd like to know if there is somebody already in charge of > writing such iso writing function. > If so, I'd like to know how I can contribute (coding, > debugging,...) although I am very busy as everybody there;-) I'd do the PCILynx part anyway. > 3- Is there somebody here who already coded some basic implementation > even if it has not been registered within CVS and that could be > taken as a basis? The subsystem supports different types of packets to send (iso is one of them), but e.g. PCILynx just assumes async packets. The hardware part should be implemented first and be tested. > 4- I was also wondering why this feature was missing: is there > any tricky issues? Management and allocation of resources (and reallocation after bus reset). While I'm implementing GUID collecting here I found out it's not that hard to do subsystem initiated transactions (i.e. transactions which were not requested by a process). -- Andreas E. Bombe <and...@mu...> DSA key 0x04880A44 http://home.pages.de/~andreas.bombe/ http://linux1394.sourceforge.net/ |
From: Andreas B. <and...@mu...> - 2000-04-25 19:56:02
|
On Tue, Apr 25, 2000 at 10:12:24AM -0700, Jun Sun wrote: > > > > > NOTE 1: the driver is probably not safe for SMP > > machines (will do that > > later). It might also not be wise to share the > > device /dev/ohci1394 > > between several threads/processes. > > > > I am lost a little bit. How does this driver relate > to libraw? libraw doesn't yet have zero copy of iso packets. > As a separate question, can the libraw be shared by > multiple processes or multiple threads? One libraw1394 handle must not be shared by multiple processes or threads, apart from that it can be used in multithreaded programs. > If the answer is yes, I wonder if any behavior is > modified. For example, if both processes listen for > the same iso channel, will they both get the data? Yes. -- Andreas E. Bombe <and...@mu...> DSA key 0x04880A44 http://home.pages.de/~andreas.bombe/ http://linux1394.sourceforge.net/ |