Almost two weeks ago we imported tvtime into our source repository. My initial plan was to import in the current CVS, pull in all the distro patches, fixup the VBI, add ALSA audio, and then spin a release. Well, I seem to have gotten a bit stuck on the ALSA audio.
It would appear that my attempts to make lipsync work properly, which requires low latency, have exposed bugs in various drivers. My original efforts with the HVR-950 exposed a kernel panic, which Douglas Landgraf was kind enough to offer to debug. To stay on track, I switched over to my HVR-950q, and was seeing a condition where underruns would stall the capture stream, which wouldn’t restart again until closing the PCM device and reopening it.
While I originally thought this was a bug in my tvtime code, some analysis of the usb-snd-audio driver suggests that it’s another kernel bug, where the prepare() callback is deactivating the URBs, but nothing ever reactivates them again. In other words, the driver works when it is initially triggered, but if anything causes the prepare() callback to be run (such as an underrun), the driver never recovers.
I’m in the process of installing alsa-driver 1.0.21 from CVS. If all goes well, I should be able to nail down the problem in the driver and get back to tvtime development.
Who would have thought that I would get stalled because both tuners I happened to use for testing had driver bugs?
Kevin
The truth is, driver development is at a level of complexity that most of us userland programmers would need years to be able to understand half of what is going on.
I think that I speak on behalf of users of tvtime and your drivers when I say: keep up the good work!!! And “taking too long” is always relative. We could be waiting forever for someone to fix those, or even worse, try to fix by ourselves.
Hello Alfonso,
It’s certainly interesting to cross onto the other side of the fence and get a firsthand look at the crap userland developers trying to write V4L applications have to go through due to buggy drivers. It seems that in many cases, the driver authors appear to be completely detached from how the devices are actually used in real applications, and therefore they operate under the assumption that their work is done the first time that they run “azap/mplayer” and see a TV picture.
It’s hard not to feel like the doctor who comes down with cancer and only then realizes how screwed up the United States healthcare system is.
Devin
Heh, Murphy’s Law in action. Wanna bet you’ll encounter even more obstacles before you eventually succeed?
But anyway, thank you for tackling this. A modernized tvtime, without the need to futz around with sox and stuff, will be great.
I wonder how mrec did it. He had a version of tvtime with audio support and it worked. Unfortunately he also removed this when he removed his driver code.
I specifically asked Markus if I could incorporate his code for the ALSA device reading, and he said “no”. He has however, given permission to incorporate his code for software rendering.
Also, in fairness, I think the bulk of my problems are not with userland tvtime code so much as discovering how buggy the drivers are. I had a hacked up version of the ALSA “latency.c” example working inside of a couple of hours.
Devin