My wife finally found Jaws 2 on the network, I’m calling the day a success even before it’s started. :)
It’s a 12 mile drive to work, time to go.
Oops, 34Mbps wasn't right. It turns out I was dropping a buffer. Fixed. Now the digital cable bitrate is running correctly at 38Mbps. Yeah!
I took a 30 second snapshot and analyzed the stream in some tools that we use in the QA lab. It's completely clean. Sweet. No corruption, better than I'd expected.
-PID--FREQ-----BANDWIDTH-BANDWIDTH-
0000 3 p/s 0 kb/s 5 kbit
04f0 3 p/s 0 kb/s 5 kbit
0520 4928 p/s 904 kb/s 7411 kbit
0521 130 p/s 23 kb/s 196 kbit
0529 3 p/s 0 kb/s 5 kbit
052f 14 p/s 2 kb/s 22 kbit
0590 2 p/s 0 kb/s...
Digital cable is working. Hmm, I should say -- limping along very nicely!
The driver's now streaming transport packets reliably into the kernel demux. Here's a quick dump from dvbtraffic showing the DTV packet stats PID by PID. I need to take some transport recordings for analysis.
-PID--FREQ-----BANDWIDTH-BANDWIDTH-
0000 2 p/s 0 kb/s 4 kbit
04f0 2 p/s 0 kb/s 4 kbit
0520 3312 p/s 608 kb/s 4981 kbit
0521 124 p/s 22 kb/s 186 kbit
0529 2 p/s 0 kb/s 4 kbit
052f 12 p/s 2 kb/s 19 kbit
0590 3 p/s 0 kb/s 5 kbit
0620 4617...
Saturday was a fruitful day, a 10 hour stint on the HVR-2250 driver. The DMA port is mostly working and largely understood. What exactly does this mean? Well, the PCI buffers and associated lists have been correctly configured and placed into the DMA’s configuration registers. When I press the ‘big green button’ and start streaming the driver is stable. I see transport packets arriving during the interrupt handler. Soooo, it’s alive.
…. but not quite. Isn’t their always a catch?
I’m not seeing consistently full buffers. For sure over the next...
I posted a series of questions to the linux-media@vger.kernel.org mailing list, related to advanced codec types and some odd-ball issues we’re likely to have with V4L2 and the HVR-22xx driver.
Why not jump in and give us your feedback!
Left brain: "Remember last year how you said that switching the args around in your saa7164_writel() macros was a great idea?"
Homer brain: "Yes"
Left brain: "Remember how you've been trying to debug weird DMA hangs?"
Homer brain: "Yes"
Left brain: "You've been writing the wrong values to the wrong locations! You IDIOT!"
(brief pause)
Homer brain: "Touche!"
If I had $1 for every time someone downloaded this file from my site: http://steventoth.net/linux/xc5000/HVR-12x0-14x0-17x0_1_25_25271_WHQL.zip I'd have $20k and be able to support and/or sponsor a large number of other LinuxTV.org developer projects.
I'm actually pretty shocked by the numbers, aren't you?
A few words for everyone interested in the HVR-2250 project, before I head out to work.
I spent the evening triple checking that I was programming both encoders correctly, but I’m still experiencing a full system hang on 64 (and now 32bit) systems…. Which probably means my triple check is flawed, doh! I need to go back to a windows debugger and compare values. I’ve been here before during the cx23885 driver project. I spent a week, maybe more, chasing down a less than obvious bug. I know this feeling, it just takes patience and perseverance.
More updates for you in a day or two.
So the driver’s at the point where you can issue azap -r and the tuner and demod locks, you get the correct status. The DMA engine is primed and set to run, then the hardware locks up. I’m starting to thing the DMA issue is related to fact I’m running 64 bit O/S. Time to install 32bit on a spare disk.