> On May 22, 2007, at 12:04 PM, Hans Verkuil wrote:
>
>>> On May 22, 2007, at 3:26 AM, Hans Verkuil wrote:
>>>
>>>>> On May 19, 2007, at 2:14 PM, Hans Verkuil wrote:
>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> I would appreciate it if people could start testing the latest
>>>>>> ivtv on
>>>>>> the 0.10 branch, available here:
>>>>>
>>>>> Excellent! Always looking forward to some new & improved code.
>>>>>
>>>>>> The current driver has a problem with copying data from the MPEG
>>>>>> card to
>>>>>> memory that are done using PIO instead of DMA (for good reasons).
>>>>>> Unfortunately PIO accesses are slow, so too much time is spent
>>>>>> inside
>>>>>> the interrupt handler. This can lead to missing clock ticks and
>>>>>> problems with remotes (key hits that are missed).
>>>>>
>>>>> The missing ticks have certainly gone away. My clock keeps up just
>>>>> fine while making recordings now.
>>>>>
>>>>>> However, I did not have much time to test it thoroughly, so I'd
>>>>>> very
>>>>>> much appreciate it if people could start testing this and report
>>>>>> whether or not any new problems were introduced.
>>>>>
>>>>> Well, as it seems, I am still having the same problems (on PPC)
>>>>> with
>>>>> the radio patch that was posted a while back. Regressing that patch
>>>>> from the 0.10 branch yields a perfectly stable and usable ivtv
>>>>> subsystem and machine.
>>>>>
>>>>> To recap on what happened post-radio patch, if I'm recording
>>>>> with the
>>>>> PVR-350 and try to use the xdriver (on the 350's TV-out) for some
>>>>> mplayer -xv playback, the screen will go black and there will be
>>>>> audio for a second, then mplayer crashes. Here's some more info on
>>>>> what mplayer (and X) complain about:
>>>>
>>>> Are you recording the radio or TV? If recording from TV, did you
>>>> do a
>>>> radio capture earlier or was radio not used at all?
>>>
>>> Radio was not used at all; I've never configured a program to use it.
>>
>> Weird. Please test the following: load the driver (so that you are
>> certain
>> it is cleanly started and not used by any program), then tune to a
>> frequency using ivtv-tune or v4l2-ctl and capture something using 'cat
>> /dev/video0 >x.mpg'. Is this capture correct or also corrupt?
>
> This produces a correct MPEG2 capture.
>
>> If the mpeg is correct, then please use ivtv-radio to access the
>> radio (it
>> probably is even enough to just do 'cat /dev/radio' and break it off).
>> Once done using the radio, try to capture video again. If it is now
>> wrong,
>> then it is likely to be caused by the radio patch.
>
> I then used `ivtv-radio -s` to get a list of all the available
> channels, and the entire system hung. Curiously, if I reload the
> driver then run `ivtv-radio -s` before anything else, it doesn't hang.
>
> Let me know if there's anything else I can do,
Can you test whether just changing the audio sampling frequency using
'v4l2-ctl -c audio_sampling_frequency=0' will also cause problems? So just
run this and check if capturing from the TV (no radio involved in this
test) will work or not. I'm wondering if there is an endian problem when
the sampling freq. is changed. This code is now called for radio as well,
so any endian problem is now triggered when using the radio.
Explicitly changing the sampling freq. should trigger such a bug for any
ivtv version (with or without the radio patch).
I looked through the code and didn't see any obvious endianness problem,
but this test should reveal whether there are any or not.
Regards,
Hans
_______________________________________________
ivtv-devel mailing list
[email protected]
http://ivtvdriver.org/mailman/listinfo/ivtv-devel
