On Mon, Apr 13, 2009 at 11:26 PM, Andy Walls <awalls@xxxxxxxxx> wrote: > On Tue, 2009-03-31 at 06:02 -0400, Brandon Jenkins wrote: >> >> >> >> Corey and Brandon, >> >> >> >> I found a race condition between the cx driver and the CX23418 firmware. >> >> I have a patch that mitigates the problem here: >> >> >> >> http://linuxtv.org/hg/~awalls/cx18/rev/9f5f44e0ce6c >> >> >> >> I think the final form of the patch could be better. However, this >> >> patch essentially eliminated any artifacts I was getting playing back >> >> digital TV. I also had positive results running mplayer without the >> >> "-cache" command line for both digital and analog captures. >> >> >> >> I haven't tested on a single processor machine, nor in a multicard >> >> setup, but things looked good enough that I thought it ready for test by >> >> others. >> >> >> >> Let me know if it helps or not. >> >> >> >> Regards, >> >> Andy >> >> > >> Andy, >> >> Based on continued discussions it seems you're still exploring things. >> I can tell you that the analog captures are still exhibiting >> artifacts. I'll get to some of the HD captures tonight. >> >> Brandon > > Brandon and Corey, > > I have a series of changes to improve performance of the cx18 driver in > delivering incoming buffers to applications. Please test the code here > if you'd like: > > http://linuxtv.org/hg/~awalls/cx18-perf/ > > These patches remove all the sleeps from incoming buffer handling > (unless your system starts getting very far behind, in which case a > fallback strategy starts letting sleeps happen again). > > > If you still have performance problems, there is one more patch I can > add, that avoids some sleeps in the new work handler threads that pass > empty buffers back out to the firmware. A copy of that patch is here: > > http://linuxtv.org/hg/~awalls/cx18/rev/b42156ceee11 > > > > The trade-off I had to make with all these patches was to have the > cx18-driver prefer to "spin" rather than "sleep" when waiting for a > resource (i.e. the capture stream buffer queues), while handling > incoming buffers. This makes the live playback much nicer, but at the > expense of CPU cycles and perhaps total system throughput for other > things. I'd be interested in how a multicard multistream capture fares. > > > > BTW, the above cx18-perf repo is missing a very small patch to fix a > recent bug with line-in audio not working. If you need line-in audio to > work during testing, a patch is in the main v4l-dvb repo already: > > http://linuxtv.org/hg/v4l-dvb/rev/d19938a76e7a > > > Regards, > Andy > > Andy, I apologize for the delay in this email. I have been fighting an issue with lirc which has preoccupied my time (it is amazing how ticked the family gets when they can't watch TV!) I have mitigated that issue and have been running your updated drivers for a couple of days with marked improvement. I am seeing some messages in dmesg (normal?) and I have attached it along with lspci, lsusb, and lsmod. The majority of our recordings have been making use of the digital connection with OTA ATSC. Also, because of my reduced tuner control issues (lirc) I have not run any simultaneous captures with the HDPVR active. The system is running Ubuntu Jaunty RC1 9.04 fully patched and kernel - Linux sagetv-server 2.6.28-11-server #42-Ubuntu SMP Fri Apr 17 02:45:36 UTC 2009 x86_64 GNU/Linux I use SageTV for PVR which uses the drivers in 32-bit compatible mode. Brandon
Attachment:
info.tgz
Description: GNU Zip compressed data
