Mailing List Archive

On Sun, 2009-07-19 at 18:40 +0530, Ravi A wrote:
>
> Andy Walls wrote:
> > On Sat, 2009-07-18 at 21:31 -0400, Andy Walls wrote:
> >
> >> On Sun, 2009-07-19 at 06:53 +0530, Ravi A wrote:
> >>
> >
> >
> >>>>
> >>>>
> >>> Hi Andy,
> >>>
> >>> I just checked, it still has the same problem. Just to verify, I went
> >>> back to the 82a264ea2784 version again and that is smooth. Maybe you can
> >>> decide to leave out the cx25840 changes after testing on your PVR150
> >>> too, to double confirm.
> >>>
> >> I just think I figured out the problem. The I2S master clock has to be
> >> running at 384 clocks per sample. My computations are ensuring it's 384
> >> clock per sample for Broadcast decoder (TV tuner audio) output, and 256
> >> clocks per sample on Line in I2S input. The reason I did this was that
> >> on the input side of the CX2584x the decoder uses 384 and the I2S input
> >> uses 256. This is likely the problem.
> >>
> >> I'll figure out new numbers and try again.... maybe tomorrow. :)
> >>
> >
> > OK, I lied. The latest change for the cx25840 module is at
> >
> > http://linuxtv.org/hg/~awalls/ivtv
> >
> > I haven't tested it, but I will have to to make sure Tuner audio still
> > works. Please test line in audio if you can.
> >
> > (now I'm going to bed...really...)
> >
> > regards,
> > Andy
> >
> >
>
> Hi Andy,
>
> You were right on time for me to test it as soon as I woke up :)
> This version seems much better. The skip/jump has gone away!

Good to hear.

> However I
> notice some video/audio dropouts after a few seconds of playing, and the
> "too many video packets in buffer" messages too. The good news is, the
> 82a264ea2784 version is also showing these dropouts - I am certain it
> was smooth before, so a bit puzzled as to why I am seeing these dropouts
> now!

It's likely a system level issue. Is there any device sharing the same
PCI interrupt line as the CX23416 with a linux driver attached to it.

$ cat /proc/interrupts

If ivtv is sharing an interrupt with a linux device driver that doesn't
always respond promptly, that would be a source of dropped buffers.

That's just a first guess. There could be other factors.



> But anyway the latest PLL VCO change version seems same as earlier
> versions now. I have not compared with 32KHz audio sampling yet though.
OK.


> Do let me know if there is anything I can check to eliminate or isolate
> the driver settings as the cause for the audio/video dropouts.

1. Blacklist/unload any module that's sharing the PCI interrupt with the
CX23416

or

2. Move the CX23416 card to another slot so that it gets a different
interrupt line.




> The
> machine itself and components are fast and I am able to play 1080p video
> from local disks smoothly.
>
> It might help if there can be another independent testing on this version.

Yes, that was my plan for today.

I also wanted to look at the WM8379 configuration today.

Unfortunately my wife just informed my that we have a non-trivial amount
of water leaking in the laundry room, so I'll likely be spending the day
fixing whatever is broken.

Regards,
Andy

> Regards
> Ravi



_______________________________________________
ivtv-devel mailing list
ivtv-devel@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-devel

Andy Walls wrote:
> On Sun, 2009-07-19 at 18:40 +0530, Ravi A wrote:
>
>> Andy Walls wrote:
>>
>>> On Sat, 2009-07-18 at 21:31 -0400, Andy Walls wrote:
>>>
>>>
>>>> On Sun, 2009-07-19 at 06:53 +0530, Ravi A wrote:
>>>>
>>>>
>>>
>>>
>>>>>>
>>>>>>
>>>>>>
>>>>> Hi Andy,
>>>>>
>>>>> I just checked, it still has the same problem. Just to verify, I went
>>>>> back to the 82a264ea2784 version again and that is smooth. Maybe you can
>>>>> decide to leave out the cx25840 changes after testing on your PVR150
>>>>> too, to double confirm.
>>>>>
>>>>>
>>>> I just think I figured out the problem. The I2S master clock has to be
>>>> running at 384 clocks per sample. My computations are ensuring it's 384
>>>> clock per sample for Broadcast decoder (TV tuner audio) output, and 256
>>>> clocks per sample on Line in I2S input. The reason I did this was that
>>>> on the input side of the CX2584x the decoder uses 384 and the I2S input
>>>> uses 256. This is likely the problem.
>>>>
>>>> I'll figure out new numbers and try again.... maybe tomorrow. :)
>>>>
>>>>
>>> OK, I lied. The latest change for the cx25840 module is at
>>>
>>> http://linuxtv.org/hg/~awalls/ivtv
>>>
>>> I haven't tested it, but I will have to to make sure Tuner audio still
>>> works. Please test line in audio if you can.
>>>
>>> (now I'm going to bed...really...)
>>>
>>> regards,
>>> Andy
>>>
>>>
>>>
>> Hi Andy,
>>
>> You were right on time for me to test it as soon as I woke up :)
>> This version seems much better. The skip/jump has gone away!
>>
>
> Good to hear.
>
>
>> However I
>> notice some video/audio dropouts after a few seconds of playing, and the
>> "too many video packets in buffer" messages too. The good news is, the
>> 82a264ea2784 version is also showing these dropouts - I am certain it
>> was smooth before, so a bit puzzled as to why I am seeing these dropouts
>> now!
>>
>
> It's likely a system level issue. Is there any device sharing the same
> PCI interrupt line as the CX23416 with a linux driver attached to it.
>
> $ cat /proc/interrupts
>
> If ivtv is sharing an interrupt with a linux device driver that doesn't
> always respond promptly, that would be a source of dropped buffers.
>
> That's just a first guess. There could be other factors.
>
>
>
>
>> But anyway the latest PLL VCO change version seems same as earlier
>> versions now. I have not compared with 32KHz audio sampling yet though.
>>
> OK.
>
>
>
>> Do let me know if there is anything I can check to eliminate or isolate
>> the driver settings as the cause for the audio/video dropouts.
>>
>
> 1. Blacklist/unload any module that's sharing the PCI interrupt with the
> CX23416
>
> or
>
> 2. Move the CX23416 card to another slot so that it gets a different
> interrupt line.
>
>
>
>
>
>> The
>> machine itself and components are fast and I am able to play 1080p video
>> from local disks smoothly.
>>
>> It might help if there can be another independent testing on this version.
>>
>
> Yes, that was my plan for today.
>
> I also wanted to look at the WM8379 configuration today.
>
> Unfortunately my wife just informed my that we have a non-trivial amount
> of water leaking in the laundry room, so I'll likely be spending the day
> fixing whatever is broken.
>
> Regards,
> Andy
>
>
>> Regards
>> Ravi
>>
>
>
>

Hi Andy,

The card was sharing an IRQ with a USB controller. I disabled USB from
BIOS and ensured the card gets dedicated IRQ. But the problem still
persists. It is also pretty consistent now, despite several reboots and
tweaked settings I could not get rid of it. I am inclined to think the
clock settings or whatever else in the card may not be fully alright
yet. Your testing should be able to confirm - but ofcourse we will wait
for you to patch the laundry room pipes before patching any more code!

Also I checked with 32KHz audio sampling frequency - there was some
strong weird tone shifting.

Regards
Ravi



_______________________________________________
ivtv-devel mailing list
ivtv-devel@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-devel

On Mon, Jul 20, 2009 at 1:39 AM, Ravi A<asvravi@gmail.com> wrote:
>>>>
>>>
>>> Hi Andy,
>>>
>>> You were right on time for me to test it as soon as I woke up :)
>>> This version seems much better. The skip/jump has gone away!
>>
>> Good to hear.
>>
>>
>>>
>>> However I notice some video/audio dropouts after a few seconds of
>>> playing, and the "too many video packets in buffer" messages too. The good
>>> news is, the 82a264ea2784 version is also showing these dropouts - I am
>>> certain it was smooth before, so a bit puzzled as to why I am seeing these
>>> dropouts now!
>>>
>>
>> It's likely a system level issue.  Is there any device sharing the same
>> PCI interrupt line as the CX23416 with a linux driver attached to it.
>>
>> $ cat /proc/interrupts
>>
>> If ivtv is sharing an interrupt with a linux device driver that doesn't
>> always respond promptly, that would be a source of dropped buffers.
>>
>> That's just a first guess.  There could be other factors.
>>
>>
>>
>>
>>>
>>>  But anyway the latest PLL VCO change version seems same as earlier
>>> versions now. I have not compared with 32KHz audio sampling yet though.
>>>
>>
>> OK.
>>
>>
>>
>>>
>>> Do let me know if there is anything I can check to eliminate or isolate
>>> the driver settings as the cause for the audio/video dropouts.
>>>
>>
>> 1. Blacklist/unload any module that's sharing the PCI interrupt with the
>> CX23416
>>
>> or
>>
>> 2. Move the CX23416 card to another slot so that it gets a different
>> interrupt line.
>>
>>
>>
>>
>>
>>>
>>>  The machine itself and components are fast and I am able to play 1080p
>>> video from local disks smoothly.
>>>
>>> It might help if there can be another independent testing on this
>>> version.
>>>
>>
>> Yes, that was my plan for today.
>>
>> I also wanted to look at the WM8379 configuration today.
>>
>> Unfortunately my wife just informed my that we have a non-trivial amount
>> of water leaking in the laundry room, so I'll likely be spending the day
>> fixing whatever is broken.
>> Regards,
>> Andy
>>
>>
>>>
>>> Regards
>>> Ravi
>>>
>>
>>
>>
>
> Hi Andy,
>
> The card was sharing an IRQ with a USB controller. I disabled USB from BIOS
> and ensured the card gets dedicated IRQ. But the problem still persists. It
> is also pretty consistent now, despite several reboots and tweaked settings
> I could not get rid of it. I am inclined to think the clock settings or
> whatever else in the card may not be fully alright yet. Your testing should
> be able to confirm - but ofcourse we will wait for you to patch the laundry
> room pipes before patching any more code!
>
> Also I checked with 32KHz audio sampling frequency - there was some strong
> weird tone shifting.
>
> Regards
> Ravi
>
>
>

Hi Andy,

I did some more testing comparing the patches. The dropouts appear to
be because of the VCO related patches. The versions before the VCO
center frequency patch do not show this issue. I was mislead earlier
(into thinking all the versions had the dropouts) as I was just doing
an unload and load to move across versions - this does not seem to be
clean, the register writes may not be completely reset. If I do a cold
boot in between, then with pre-VCO version I am able to see that there
are no dropouts. I also checked the patches you submitted to the
staging repository and there seem to be no dropouts with this too.

I will continue to do more testing to double-check. Let me know if you
think the above is reasonable.

Regards
Ravi

_______________________________________________
ivtv-devel mailing list
ivtv-devel@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-devel

On Fri, 2009-07-24 at 03:32 +0530, Ravi A wrote:
> On Mon, Jul 20, 2009 at 1:39 AM, Ravi A<asvravi@gmail.com> wrote:
> >>>>
> >>>
> >>> Hi Andy,
> >>>
> >>> You were right on time for me to test it as soon as I woke up :)
> >>> This version seems much better. The skip/jump has gone away!
> >>
> >> Good to hear.
> >>
> >>
> >>>
> >>> However I notice some video/audio dropouts after a few seconds of
> >>> playing, and the "too many video packets in buffer" messages too. The good
> >>> news is, the 82a264ea2784 version is also showing these dropouts - I am
> >>> certain it was smooth before, so a bit puzzled as to why I am seeing these
> >>> dropouts now!
> >>>
> >>
> >> It's likely a system level issue. Is there any device sharing the same
> >> PCI interrupt line as the CX23416 with a linux driver attached to it.
> >>
> >> $ cat /proc/interrupts
> >>
> >> If ivtv is sharing an interrupt with a linux device driver that doesn't
> >> always respond promptly, that would be a source of dropped buffers.
> >>
> >> That's just a first guess. There could be other factors.
> >>
> >>
> >>
> >>
> >>>
> >>> But anyway the latest PLL VCO change version seems same as earlier
> >>> versions now. I have not compared with 32KHz audio sampling yet though.
> >>>
> >>
> >> OK.
> >>
> >>
> >>
> >>>
> >>> Do let me know if there is anything I can check to eliminate or isolate
> >>> the driver settings as the cause for the audio/video dropouts.
> >>>
> >>
> >> 1. Blacklist/unload any module that's sharing the PCI interrupt with the
> >> CX23416
> >>
> >> or
> >>
> >> 2. Move the CX23416 card to another slot so that it gets a different
> >> interrupt line.
> >>
> >>
> >>
> >>
> >>
> >>>
> >>> The machine itself and components are fast and I am able to play 1080p
> >>> video from local disks smoothly.
> >>>
> >>> It might help if there can be another independent testing on this
> >>> version.
> >>>
> >>
> >> Yes, that was my plan for today.
> >>
> >> I also wanted to look at the WM8379 configuration today.
> >>
> >> Unfortunately my wife just informed my that we have a non-trivial amount
> >> of water leaking in the laundry room, so I'll likely be spending the day
> >> fixing whatever is broken.
> >> Regards,
> >> Andy
> >>
> >>
> >>>
> >>> Regards
> >>> Ravi
> >>>
> >>
> >>
> >>
> >
> > Hi Andy,
> >
> > The card was sharing an IRQ with a USB controller. I disabled USB from BIOS
> > and ensured the card gets dedicated IRQ. But the problem still persists. It
> > is also pretty consistent now, despite several reboots and tweaked settings
> > I could not get rid of it. I am inclined to think the clock settings or
> > whatever else in the card may not be fully alright yet. Your testing should
> > be able to confirm - but ofcourse we will wait for you to patch the laundry
> > room pipes before patching any more code!
> >
> > Also I checked with 32KHz audio sampling frequency - there was some strong
> > weird tone shifting.
> >
> > Regards
> > Ravi
> >
> >
> >
>
> Hi Andy,
>
> I did some more testing comparing the patches. The dropouts appear to
> be because of the VCO related patches. The versions before the VCO
> center frequency patch do not show this issue. I was mislead earlier
> (into thinking all the versions had the dropouts) as I was just doing
> an unload and load to move across versions - this does not seem to be
> clean, the register writes may not be completely reset. If I do a cold
> boot in between, then with pre-VCO version I am able to see that there
> are no dropouts. I also checked the patches you submitted to the
> staging repository and there seem to be no dropouts with this too.
>
> I will continue to do more testing to double-check. Let me know if you
> think the above is reasonable.


Ravi,

I'm going to leave the cx25840 module alone for now. I really don't
have time to chase problems with changing the VCO operation and it
wasn't needed to get your card working (AFAICT).

My pull reuqest only include the changes needed for you card (so far)
and the PARTSNIC tuner.

So what's left? You said you had some noisy/weak audio right? I'll try
to add the v4l2-dbg support to the wm8739 module sometime this weekend.
I'm essentially going to mimic the implementation in the cs5345 module.
That way, you'll be able to experiment with wm8739 settings.

Regards,
Andy

> Regards
> Ravi



_______________________________________________
ivtv-devel mailing list
ivtv-devel@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-devel

Andy Walls wrote:

Hi Andy, I did some more testing comparing the patches. The dropouts appear to be because of the VCO related patches. The versions before the VCO center frequency patch do not show this issue. I was mislead earlier (into thinking all the versions had the dropouts) as I was just doing an unload and load to move across versions - this does not seem to be clean, the register writes may not be completely reset. If I do a cold boot in between, then with pre-VCO version I am able to see that there are no dropouts. I also checked the patches you submitted to the staging repository and there seem to be no dropouts with this too. I will continue to do more testing to double-check. Let me know if you think the above is reasonable.

Ravi, I'm going to leave the cx25840 module alone for now. I really don't have time to chase problems with changing the VCO operation and it wasn't needed to get your card working (AFAICT). My pull reuqest only include the changes needed for you card (so far) and the PARTSNIC tuner. So what's left? You said you had some noisy/weak audio right? I'll try to add the v4l2-dbg support to the wm8739 module sometime this weekend. I'm essentially going to mimic the implementation in the cs5345 module. That way, you'll be able to experiment with wm8739 settings. Regards, Andy

Regards Ravi

Hi Andy,

Thanks.

Yes, the VCO change was not needed for me to use my card.

About the audio, it is not too bad, but it could be made much better if the gain in WM8739 is increased. Currently it does not seem to be using the full scale range of the ADC, and besides, there is attenuation on the board too, so the final output is pretty low. Increasing the WM8739 volume should help to boost the SNR a lot. I can experiment with the settings once you add the WM8739 support.

The other issue I am seeing is the Composite input quality which I mentioned sometime back. There are jagged edges in red/yellow and sometimes white edges. Moving text is very jagged too. I think it may have something to do with the internal de-interlacing in the card, but I have no clue. I plan to try some register settings tomorrow. The S-Video input does not seem to have this problem and gives crystal clear picture.

Regards
Ravi

On Mon, 2009-07-27 at 11:09 +0530, Ravi A wrote:
>
>
> Andy Walls wrote:
> > > Hi Andy,
> > >
> > > I did some more testing comparing the patches. The dropouts appear to
> > > be because of the VCO related patches. The versions before the VCO
> > > center frequency patch do not show this issue. I was mislead earlier
> > > (into thinking all the versions had the dropouts) as I was just doing
> > > an unload and load to move across versions - this does not seem to be
> > > clean, the register writes may not be completely reset. If I do a cold
> > > boot in between, then with pre-VCO version I am able to see that there
> > > are no dropouts. I also checked the patches you submitted to the
> > > staging repository and there seem to be no dropouts with this too.
> > >
> > > I will continue to do more testing to double-check. Let me know if you
> > > think the above is reasonable.
> > >
> >
> >
> > Ravi,
> >
> > I'm going to leave the cx25840 module alone for now. I really don't
> > have time to chase problems with changing the VCO operation and it
> > wasn't needed to get your card working (AFAICT).
> >
> > My pull reuqest only include the changes needed for you card (so far)
> > and the PARTSNIC tuner.
> >
> > So what's left? You said you had some noisy/weak audio right? I'll try
> > to add the v4l2-dbg support to the wm8739 module sometime this weekend.
> > I'm essentially going to mimic the implementation in the cs5345 module.
> > That way, you'll be able to experiment with wm8739 settings.
> >
> > Regards,
> > Andy
> >
> >
> > > Regards
> > > Ravi
> > >
> >
> >
> >
>
> Hi Andy,
>
> Thanks.
>
> Yes, the VCO change was not needed for me to use my card.
>
> About the audio, it is not too bad, but it could be made much better
> if the gain in WM8739 is increased. Currently it does not seem to be
> using the full scale range of the ADC, and besides, there is
> attenuation on the board too, so the final output is pretty low.
> Increasing the WM8739 volume should help to boost the SNR a lot. I can
> experiment with the settings once you add the WM8739 support.

Ravi,

Please test the latest patch at

http://linuxtv.org/hg/~awalls/ivtv

it adds a secondary set of user controls for manipulating the WM8739
audio controls via v4l2-ctl. You will see controls named
"secondary_volume", "secondary_mute", etc.

Hans,

If these control settings are usable for Ravi, can you please comment on
the patch. It was the simplest way I could think of to effect the
change in a very generic way, that should work for any ivtv card. But
looking at it, I get the sense it could possibly be improved.

> The other issue I am seeing is the Composite input quality which I
> mentioned sometime back. There are jagged edges in red/yellow and
> sometimes white edges. Moving text is very jagged too. I think it may
> have something to do with the internal de-interlacing in the card, but
> I have no clue. I plan to try some register settings tomorrow. The
> S-Video input does not seem to have this problem and gives crystal
> clear picture.

I don't have any thought on this at the moment. Life got busy recently.


Regards,
Andy

>
> Regards
> Ravi
>
>
>
>


_______________________________________________
ivtv-devel mailing list
ivtv-devel@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-devel

Andy Walls wrote:
> On Mon, 2009-07-27 at 11:09 +0530, Ravi A wrote:
>
>> Andy Walls wrote:
>>
>>>> Hi Andy,
>>>>
>>>> I did some more testing comparing the patches. The dropouts appear to
>>>> be because of the VCO related patches. The versions before the VCO
>>>> center frequency patch do not show this issue. I was mislead earlier
>>>> (into thinking all the versions had the dropouts) as I was just doing
>>>> an unload and load to move across versions - this does not seem to be
>>>> clean, the register writes may not be completely reset. If I do a cold
>>>> boot in between, then with pre-VCO version I am able to see that there
>>>> are no dropouts. I also checked the patches you submitted to the
>>>> staging repository and there seem to be no dropouts with this too.
>>>>
>>>> I will continue to do more testing to double-check. Let me know if you
>>>> think the above is reasonable.
>>>>
>>>>
>>> Ravi,
>>>
>>> I'm going to leave the cx25840 module alone for now. I really don't
>>> have time to chase problems with changing the VCO operation and it
>>> wasn't needed to get your card working (AFAICT).
>>>
>>> My pull reuqest only include the changes needed for you card (so far)
>>> and the PARTSNIC tuner.
>>>
>>> So what's left? You said you had some noisy/weak audio right? I'll try
>>> to add the v4l2-dbg support to the wm8739 module sometime this weekend.
>>> I'm essentially going to mimic the implementation in the cs5345 module.
>>> That way, you'll be able to experiment with wm8739 settings.
>>>
>>> Regards,
>>> Andy
>>>
>>>
>>>
>>>> Regards
>>>> Ravi
>>>>
>>>>
>>>
>>>
>> Hi Andy,
>>
>> Thanks.
>>
>> Yes, the VCO change was not needed for me to use my card.
>>
>> About the audio, it is not too bad, but it could be made much better
>> if the gain in WM8739 is increased. Currently it does not seem to be
>> using the full scale range of the ADC, and besides, there is
>> attenuation on the board too, so the final output is pretty low.
>> Increasing the WM8739 volume should help to boost the SNR a lot. I can
>> experiment with the settings once you add the WM8739 support.
>>
>
> Ravi,
>
> Please test the latest patch at
>
> http://linuxtv.org/hg/~awalls/ivtv
>
> it adds a secondary set of user controls for manipulating the WM8739
> audio controls via v4l2-ctl. You will see controls named
> "secondary_volume", "secondary_mute", etc.
>
> Hans,
>
> If these control settings are usable for Ravi, can you please comment on
> the patch. It was the simplest way I could think of to effect the
> change in a very generic way, that should work for any ivtv card. But
> looking at it, I get the sense it could possibly be improved.
>
>
>> The other issue I am seeing is the Composite input quality which I
>> mentioned sometime back. There are jagged edges in red/yellow and
>> sometimes white edges. Moving text is very jagged too. I think it may
>> have something to do with the internal de-interlacing in the card, but
>> I have no clue. I plan to try some register settings tomorrow. The
>> S-Video input does not seem to have this problem and gives crystal
>> clear picture.
>>
>
> I don't have any thought on this at the moment. Life got busy recently.
>
>
> Regards,
> Andy
>
>
>> Regards
>> Ravi
>>
>>
>>
>>
>>
>
>

Hi Andy,

Thanks for your help on this. Being able to set these as secondary
controls is a good idea! Unfortunately I am on travel for about a week,
so I can get to test this only towards the end of next week. Will report
back to you on these settings as soon as I return.

Regards
Ravi





_______________________________________________
ivtv-devel mailing list
ivtv-devel@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-devel

Andy Walls wrote:

Ravi, I'm going to leave the cx25840 module alone for now. I really don't have time to chase problems with changing the VCO operation and it wasn't needed to get your card working (AFAICT). My pull reuqest only include the changes needed for you card (so far) and the PARTSNIC tuner. So what's left? You said you had some noisy/weak audio right? I'll try to add the v4l2-dbg support to the wm8739 module sometime this weekend. I'm essentially going to mimic the implementation in the cs5345 module. That way, you'll be able to experiment with wm8739 settings. Regards, Andy

Hi Andy, Thanks. Yes, the VCO change was not needed for me to use my card. About the audio, it is not too bad, but it could be made much better if the gain in WM8739 is increased. Currently it does not seem to be using the full scale range of the ADC, and besides, there is attenuation on the board too, so the final output is pretty low. Increasing the WM8739 volume should help to boost the SNR a lot. I can experiment with the settings once you add the WM8739 support.

Ravi, Please test the latest patch at http://linuxtv.org/hg/~awalls/ivtv"]http://linuxtv.org/hg/~awalls/ivtv it adds a secondary set of user controls for manipulating the WM8739 audio controls via v4l2-ctl. You will see controls named "secondary_volume", "secondary_mute", etc. Hans, If these control settings are usable for Ravi, can you please comment on the patch. It was the simplest way I could think of to effect the change in a very generic way, that should work for any ivtv card. But looking at it, I get the sense it could possibly be improved.

The other issue I am seeing is the Composite input quality which I mentioned sometime back. There are jagged edges in red/yellow and sometimes white edges. Moving text is very jagged too. I think it may have something to do with the internal de-interlacing in the card, but I have no clue. I plan to try some register settings tomorrow. The S-Video input does not seem to have this problem and gives crystal clear picture.

I don't have any thought on this at the moment. Life got busy recently. Regards, Andy

Hi Andy,

I returned from my travel, and could test the latest patch today. I could see and control the secondary volume successfully. It was best at full setting (65535) with minimal noise/hiss and no distortion had yet set in with a standard line input source.

The issue of choppy audio is still there maybe because this patch still has the VCO changes. One thing I observed, this choppiness is present only in mplayer and vlc, it is smooth in MythTV. However MythTV does report buffer underrun errors on the mythfrontend stdout every once in a while, although that does not seem to affect its actual sound output noticeably. The 82a264ea2784 patch audio was just fine even in mplayer and vlc, and no buffer underrun reports in MythTV.

As for the video artifacts, I played around with the comb filter settings, but could not find any settings that made it better .

Regards
Ravi