Mailing List Archive: MythTV: Users

wintv-pvr-usb2 audio clipping [solved]

Index | Next | Previous | View Threaded

Rich.West at wesmo

Apr 23, 2012, 7:01 PM

Post #1 of 9 (754 views)
Permalink

wintv-pvr-usb2 audio clipping [solved]

I'm just tossing this out there in the event someone else bumps in to this.
IMHO, it's a bit of a "needle in a haystack" kind of solution.

If there is more of a "right" way to do this, I'm all ears. :)

-Rich

----
I replaced a PCI PVR-150 (still works, just need to free up a PCI slot) with
a WinTV-PVR-USB2. This is a straight-up replacement (pull card, move cables
over to USB device, adjust mythtv accordingly). Should be simple, one would
think.

I get video fine, but the problem is the audio. It's as if the audio is all
of the way up and now clipping.

Google searches were plentiful (15 tabs up at the moment), which confirm
this problem.
"For all hardware device types, there is a problem with distortion in the
audio when the volume is set too high. The pvrusb2 driver starts with the
volume set to the max, so you get the distortion....The workaround is easy:
lower the volume. Empirical testing here (on both types of devices) suggests
that right now 58000 is a good value for maximum gain distortion free
audio." along with another reference in the to the right value being 62000.

I scratched my head wondering just how to do that. None of the posts said how.

I found a hint here: http://www.isely.net/pvrusb2/usage.html

Down the page, under "sysfs Interface," there is a reference to ctl_volume
buried in the page. It looked promising.

So.. dig through the filesystem: /sys/class/pvrusb2/sn-xxxxxxx/ctl_volume
(where xxxxxxx is the serial number of your device). Look at the directly.
The only writable file is "cur_val" as you can't adjust the maximum here.
THAT file, the "cur_val" file, is you want to adjust.

I personally found that the following sounded better than 58000 (nearly no
clipping). I also dropped the line below in rc.local
echo 56000 > /sys/class/pvrusb2/sn-xxxxxxx/ctl_volume/cur_val

_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-users

gary.buhrmaster at gmail

Apr 23, 2012, 7:47 PM

Post #2 of 9 (727 views)
Permalink

Re: wintv-pvr-usb2 audio clipping [solved] [In reply to]

On Mon, Apr 23, 2012 at 19:01, Rich West <Rich.West [at] wesmo> wrote:
....
> If there is more of a "right" way to do this, I'm all ears. :)

I have this vague recollection that Mike (the author of the driver)
said that this was fixed in "recent" versions of the driver. You
might want to send email to the pvrusb2 mail lists, and check.
It may be that your (in kernel) driver is too old.

Gary
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-users

isely at isely

Apr 24, 2012, 7:13 AM

Post #3 of 9 (722 views)
Permalink

Re: wintv-pvr-usb2 audio clipping [solved] [In reply to]

A few bits of added information here -

The control that Rich found to fix the problem is not "private" to the
pvrusb2 driver. Yes the interface through sysfs is rather unique but
the actual underlying control being affected there is just the standard
V4L2 audio volume control. So you *should* be able to fix this problem
within mythtv via some kind of V4L2 UI setting as well though with the
current version of mythtv (it's been a while since I last updated) I'm
not sure how that control is expressed through the mythtv interface.

The reason for the current behavior in the pvrusb2 driver is historic...

Way back, years ago, when I realized this problem, the solution I wanted
to apply was to have the bridge driver (e.g. pvrusb2 itself) scale the
audio level value to be appropriate for the particular hardware in use.
By "scale" what I mean is to transform the incoming range of 0-65535 to
a "real" range that makes more sense for the specific device. This at
the time would have been relatively easy to accomplish in the bridge
driver with a simple, trivial conversion like hardware_volume =
(input_volume * n) / d + offset, where "n", "d" and "offset" would be
attributes coded in the driver appropriate to the actual practical
limits of the device as-a-whole (24xxx vs 29xxx vs HVR-1900/HVR-1950,
etc) rather than just what the audio chip can be told.

That way, regardless of the device, when setting 65535 the actual value
set would be the practical maximum for the hardware, while lower values
would be suitably proportional.

However I was overruled by the V4L2 maintainer. The "policy" in the
V4L2 framework according to the V4L2 maintainer was that the bridge
driver must export the "full range" of all the chips, regardless of what
actually makes sense, and not mess with or translate any of the internal
values. V4L2's "solution" to this problem was that the bridge driver
should instead initialize the default value for the audio level that
represented the practical upper limit. This was supposed to be a hint
to the application and/or user. So that's what the pvrusb2 driver does;
it sets a single solitary "default" that's used for all the devices it
controls.

Thus we have the current situation.

Gary is right however in that I have adjusted that default value
downward a few times. It's probably still not really right. And it
probably won't ever be either, because that one value is currently
applied across all pvrusb2-supported hardware. The current default is
probably correct for one type of model and still distorting for another.

But the best solution for now is to just adjust the V4L2 audio level for
the device (either through sysfs or more likely just through the normal
V4L2 API) downward until there's no more distortion. Any V4L2-using
application should have a "knob" you can manipulate to adjust the audio
gain coming out of the capture hardware, and setting that is what you
really need to do.

Realize this situation only applies for analog capture, where the
hardware has to process (demodulate, digitize, encode, multiplex) the
audio. In the case of digital capture (e.g. HVR-1950/HVR-1900/OnAir)
the device just blindly grabs and hands off the entire MPEG-TS stream
through DVB, in which case the upstream audio packets just pass through
with the rest of the bits.

-Mike Isely

On Mon, 23 Apr 2012, Gary Buhrmaster wrote:

> On Mon, Apr 23, 2012 at 19:01, Rich West <Rich.West [at] wesmo> wrote:
> ....
> > If there is more of a "right" way to do this, I'm all ears. :)
>
> I have this vague recollection that Mike (the author of the driver)
> said that this was fixed in "recent" versions of the driver. You
> might want to send email to the pvrusb2 mail lists, and check.
> It may be that your (in kernel) driver is too old.
>
> Gary
> _______________________________________________
> mythtv-users mailing list
> mythtv-users [at] mythtv
> http://www.mythtv.org/mailman/listinfo/mythtv-users
>

--

Mike Isely
isely @ isely (dot) net
PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-users

Rich.West at wesmo

May 22, 2012, 7:18 AM

Post #4 of 9 (665 views)
Permalink

Re: wintv-pvr-usb2 audio clipping [solved] [In reply to]

Interesting information.. thanks, Mike!

Anyone know if there is a V4L2 UI setting within mythbackend?

The approval factor went down a bit when the recordings from that device
started blasting everyone in the room. I've noticed that I'm seeing a
lot of the following in dmesg, which results in the audio being reset
back to the screemingly loud and very clipped default. So, I put a very
crude hack in to reset the audio back to a more comfortable setting
every 3 minutes and after each channel change. However, I admit it is a
crappy hack, and it still results in the initial 3 minutes of audio
screaming in its clipped way at everyone..

I wasn't able to find any module settings while allowed for passing any
defaults for audio.. :(

I'm tempted to upgrade the machine, effectively undoing my move from one
of my PVR-150's to the USB PVR, to handle all of the hardware (3 PCI
PVR-150's, 5 SATA drives), but finding a motherboard with those specs
while staying on the cheap hasn't been easy. :-(

-Rich

[1427795.965090] pvrusb2: ***WARNING*** device's encoder appears to be
stuck (status=0x00000003)
[1427795.965096] pvrusb2: Encoder command: 0x81
[1427795.965098] pvrusb2: Giving up on command. This is normally
recovered via a firmware reload and re-initialization; concern is only
warranted if this happens repeatedly and rapidly.
[1429596.691258] pvrusb2: ***WARNING*** device's encoder appears to be
stuck (status=0x00000003)
[1429596.691264] pvrusb2: Encoder command: 0x81
[1429596.691266] pvrusb2: Giving up on command. This is normally
recovered via a firmware reload and re-initialization; concern is only
warranted if this happens repeatedly and rapidly.
[1433197.061706] pvrusb2: ***WARNING*** device's encoder appears to be
stuck (status=0x00000003)
[1433197.061712] pvrusb2: Encoder command: 0x81
[1433197.061714] pvrusb2: Giving up on command. This is normally
recovered via a firmware reload and re-initialization; concern is only
warranted if this happens repeatedly and rapidly.
[1451249.643019] ivtv0: Encoder has died : ivtv_serialized_open
[1451249.643026] ivtv0: Detected in ivtv_serialized_open that firmware
had failed - Reloading
[1451250.479691] ivtv0: Loaded v4l-cx2341x-enc.fw firmware (376836 bytes)
[1451250.683223] ivtv0: Firmware restart okay

On 04/24/2012 10:13 AM, Mike Isely wrote:
> A few bits of added information here -
>
> The control that Rich found to fix the problem is not "private" to the
> pvrusb2 driver. Yes the interface through sysfs is rather unique but
> the actual underlying control being affected there is just the standard
> V4L2 audio volume control. So you *should* be able to fix this problem
> within mythtv via some kind of V4L2 UI setting as well though with the
> current version of mythtv (it's been a while since I last updated) I'm
> not sure how that control is expressed through the mythtv interface.
>
> The reason for the current behavior in the pvrusb2 driver is historic...
>
> Way back, years ago, when I realized this problem, the solution I wanted
> to apply was to have the bridge driver (e.g. pvrusb2 itself) scale the
> audio level value to be appropriate for the particular hardware in use.
> By "scale" what I mean is to transform the incoming range of 0-65535 to
> a "real" range that makes more sense for the specific device. This at
> the time would have been relatively easy to accomplish in the bridge
> driver with a simple, trivial conversion like hardware_volume =
> (input_volume * n) / d + offset, where "n", "d" and "offset" would be
> attributes coded in the driver appropriate to the actual practical
> limits of the device as-a-whole (24xxx vs 29xxx vs HVR-1900/HVR-1950,
> etc) rather than just what the audio chip can be told.
>
> That way, regardless of the device, when setting 65535 the actual value
> set would be the practical maximum for the hardware, while lower values
> would be suitably proportional.
>
> However I was overruled by the V4L2 maintainer. The "policy" in the
> V4L2 framework according to the V4L2 maintainer was that the bridge
> driver must export the "full range" of all the chips, regardless of what
> actually makes sense, and not mess with or translate any of the internal
> values. V4L2's "solution" to this problem was that the bridge driver
> should instead initialize the default value for the audio level that
> represented the practical upper limit. This was supposed to be a hint
> to the application and/or user. So that's what the pvrusb2 driver does;
> it sets a single solitary "default" that's used for all the devices it
> controls.
>
> Thus we have the current situation.
>
> Gary is right however in that I have adjusted that default value
> downward a few times. It's probably still not really right. And it
> probably won't ever be either, because that one value is currently
> applied across all pvrusb2-supported hardware. The current default is
> probably correct for one type of model and still distorting for another.
>
> But the best solution for now is to just adjust the V4L2 audio level for
> the device (either through sysfs or more likely just through the normal
> V4L2 API) downward until there's no more distortion. Any V4L2-using
> application should have a "knob" you can manipulate to adjust the audio
> gain coming out of the capture hardware, and setting that is what you
> really need to do.
>
> Realize this situation only applies for analog capture, where the
> hardware has to process (demodulate, digitize, encode, multiplex) the
> audio. In the case of digital capture (e.g. HVR-1950/HVR-1900/OnAir)
> the device just blindly grabs and hands off the entire MPEG-TS stream
> through DVB, in which case the upstream audio packets just pass through
> with the rest of the bits.
>
> -Mike Isely
>
>
> On Mon, 23 Apr 2012, Gary Buhrmaster wrote:
>
>> On Mon, Apr 23, 2012 at 19:01, Rich West <Rich.West [at] wesmo> wrote:
>> ....
>>> If there is more of a "right" way to do this, I'm all ears. :)
>> I have this vague recollection that Mike (the author of the driver)
>> said that this was fixed in "recent" versions of the driver. You
>> might want to send email to the pvrusb2 mail lists, and check.
>> It may be that your (in kernel) driver is too old.

_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-users

mtdean at thirdcontact

May 22, 2012, 12:37 PM

Post #5 of 9 (662 views)
Permalink

Re: wintv-pvr-usb2 audio clipping [solved] [In reply to]

On 05/22/2012 10:18 AM, Rich West wrote:
> Interesting information.. thanks, Mike!
>
> Anyone know if there is a V4L2 UI setting within mythbackend?
>
> The approval factor went down a bit when the recordings from that device
> started blasting everyone in the room. I've noticed that I'm seeing a
> lot of the following in dmesg, which results in the audio being reset
> back to the screemingly loud and very clipped default. So, I put a very
> crude hack in to reset the audio back to a more comfortable setting
> every 3 minutes and after each channel change. However, I admit it is a
> crappy hack, and it still results in the initial 3 minutes of audio
> screaming in its clipped way at everyone..
>
> I wasn't able to find any module settings while allowed for passing any
> defaults for audio.. :(
>
> I'm tempted to upgrade the machine, effectively undoing my move from one
> of my PVR-150's to the USB PVR, to handle all of the hardware (3 PCI
> PVR-150's, 5 SATA drives), but finding a motherboard with those specs
> while staying on the cheap hasn't been easy. :-(

On the capture card configuration in mythtv-setup for V4L (not DVB)
capture devices, there's a setting to tell MythTV not to set the volume
of the capture card.

Do not adjust volume
Enable this option for budget BT878 based DVB-T cards such as the AverTV
DVB-T which require the audio volume to be left alone.

(where I assume it talks about using the analog/V4L side of DVB-T
cards--likely a cheap frame grabber?)

Mike
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-users

Rich.West at wesmo

May 23, 2012, 2:04 PM

Post #6 of 9 (646 views)
Permalink

Re: wintv-pvr-usb2 audio clipping [solved] [In reply to]

On 05/22/2012 03:37 PM, Michael T. Dean wrote:
> On 05/22/2012 10:18 AM, Rich West wrote:
>> Interesting information.. thanks, Mike!
>>
>> Anyone know if there is a V4L2 UI setting within mythbackend?
>>
>> The approval factor went down a bit when the recordings from that device
>> started blasting everyone in the room. I've noticed that I'm seeing a
>> lot of the following in dmesg, which results in the audio being reset
>> back to the screemingly loud and very clipped default. So, I put a very
>> crude hack in to reset the audio back to a more comfortable setting
>> every 3 minutes and after each channel change. However, I admit it is a
>> crappy hack, and it still results in the initial 3 minutes of audio
>> screaming in its clipped way at everyone..
>>
>> I wasn't able to find any module settings while allowed for passing any
>> defaults for audio.. :(
>>
>> I'm tempted to upgrade the machine, effectively undoing my move from one
>> of my PVR-150's to the USB PVR, to handle all of the hardware (3 PCI
>> PVR-150's, 5 SATA drives), but finding a motherboard with those specs
>> while staying on the cheap hasn't been easy. :-(
>
> On the capture card configuration in mythtv-setup for V4L (not DVB)
> capture devices, there's a setting to tell MythTV not to set the
> volume of the capture card.
>
> Do not adjust volume
> Enable this option for budget BT878 based DVB-T cards such as the
> AverTV DVB-T which require the audio volume to be left alone.
>
> (where I assume it talks about using the analog/V4L side of DVB-T
> cards--likely a cheap frame grabber?)
>
> Mike

Thanks again! I'll test that out this evening. I had set the capture
card as an MPEG2 capture device, like the PVR-150's.

-Rich
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-users

mtdean at thirdcontact

May 23, 2012, 5:37 PM

Post #7 of 9 (644 views)
Permalink

Re: wintv-pvr-usb2 audio clipping [solved] [In reply to]

On 05/23/2012 05:04 PM, Rich West wrote:
> On 05/22/2012 03:37 PM, Michael T. Dean wrote:
>> On 05/22/2012 10:18 AM, Rich West wrote:
>>> Interesting information.. thanks, Mike!
>>>
>>> Anyone know if there is a V4L2 UI setting within mythbackend?
>>>
>>> The approval factor went down a bit when the recordings from that device
>>> started blasting everyone in the room. I've noticed that I'm seeing a
>>> lot of the following in dmesg, which results in the audio being reset
>>> back to the screemingly loud and very clipped default. So, I put a very
>>> crude hack in to reset the audio back to a more comfortable setting
>>> every 3 minutes and after each channel change. However, I admit it is a
>>> crappy hack, and it still results in the initial 3 minutes of audio
>>> screaming in its clipped way at everyone..
>>>
>>> I wasn't able to find any module settings while allowed for passing any
>>> defaults for audio.. :(
>>>
>>> I'm tempted to upgrade the machine, effectively undoing my move from one
>>> of my PVR-150's to the USB PVR, to handle all of the hardware (3 PCI
>>> PVR-150's, 5 SATA drives), but finding a motherboard with those specs
>>> while staying on the cheap hasn't been easy. :-(
>> On the capture card configuration in mythtv-setup for V4L (not DVB)
>> capture devices, there's a setting to tell MythTV not to set the
>> volume of the capture card.
>>
>> Do not adjust volume
>> Enable this option for budget BT878 based DVB-T cards such as the
>> AverTV DVB-T which require the audio volume to be left alone.
>>
>> (where I assume it talks about using the analog/V4L side of DVB-T
>> cards--likely a cheap frame grabber?)
> Thanks again! I'll test that out this evening. I had set the capture
> card as an MPEG2 capture device, like the PVR-150's.

Well, if it's an ivtv device, it needs to be set as such (and there's no
option to not set volume for ivtv devices)...

However, there /is/ a volume setting in the recording profiles for ivtv
cards. You likely just need to set that appropriately.

Mike
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-users

Rich.West at wesmo

May 26, 2012, 8:59 PM

Post #8 of 9 (615 views)
Permalink

Re: wintv-pvr-usb2 audio clipping [In reply to]

On 5/23/2012 5:04 PM, Rich West wrote:
> On 05/22/2012 03:37 PM, Michael T. Dean wrote:
>> On 05/22/2012 10:18 AM, Rich West wrote:
>>> Interesting information.. thanks, Mike!
>>>
>>> Anyone know if there is a V4L2 UI setting within mythbackend?
>>>
>>> The approval factor went down a bit when the recordings from that device
>>> started blasting everyone in the room. I've noticed that I'm seeing a
>>> lot of the following in dmesg, which results in the audio being reset
>>> back to the screemingly loud and very clipped default. So, I put a very
>>> crude hack in to reset the audio back to a more comfortable setting
>>> every 3 minutes and after each channel change. However, I admit it is a
>>> crappy hack, and it still results in the initial 3 minutes of audio
>>> screaming in its clipped way at everyone..
>>>
>>> I wasn't able to find any module settings while allowed for passing any
>>> defaults for audio.. :(
>>>
>>> I'm tempted to upgrade the machine, effectively undoing my move from one
>>> of my PVR-150's to the USB PVR, to handle all of the hardware (3 PCI
>>> PVR-150's, 5 SATA drives), but finding a motherboard with those specs
>>> while staying on the cheap hasn't been easy. :-(
>> On the capture card configuration in mythtv-setup for V4L (not DVB)
>> capture devices, there's a setting to tell MythTV not to set the
>> volume of the capture card.
>>
>> Do not adjust volume
>> Enable this option for budget BT878 based DVB-T cards such as the
>> AverTV DVB-T which require the audio volume to be left alone.
>>
>> (where I assume it talks about using the analog/V4L side of DVB-T
>> cards--likely a cheap frame grabber?)
>>
>> Mike
> Thanks again! I'll test that out this evening. I had set the capture
> card as an MPEG2 capture device, like the PVR-150's.

Unfortunately, those options don't exist for the WinTV-pvr-usb2 device. :(
Ah, well, back to the drawing board. Perhaps it is time to upgrade my
motherboard for my backend system after all...

-Rich

_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-users

mtdean at thirdcontact

May 26, 2012, 9:56 PM

Post #9 of 9 (611 views)
Permalink

Re: wintv-pvr-usb2 audio clipping [In reply to]

On 05/26/2012 11:59 PM, Rich West wrote:
> On 5/23/2012 5:04 PM, Rich West wrote:
>> On 05/22/2012 03:37 PM, Michael T. Dean wrote:
>>> On 05/22/2012 10:18 AM, Rich West wrote:
>>>> Interesting information.. thanks, Mike!
>>>>
>>>> Anyone know if there is a V4L2 UI setting within mythbackend?
>>>>
>>>> The approval factor went down a bit when the recordings from that device
>>>> started blasting everyone in the room. I've noticed that I'm seeing a
>>>> lot of the following in dmesg, which results in the audio being reset
>>>> back to the screemingly loud and very clipped default. So, I put a very
>>>> crude hack in to reset the audio back to a more comfortable setting
>>>> every 3 minutes and after each channel change. However, I admit it is a
>>>> crappy hack, and it still results in the initial 3 minutes of audio
>>>> screaming in its clipped way at everyone..
>>>>
>>>> I wasn't able to find any module settings while allowed for passing any
>>>> defaults for audio.. :(
>>>>
>>>> I'm tempted to upgrade the machine, effectively undoing my move from one
>>>> of my PVR-150's to the USB PVR, to handle all of the hardware (3 PCI
>>>> PVR-150's, 5 SATA drives), but finding a motherboard with those specs
>>>> while staying on the cheap hasn't been easy. :-(
>>> On the capture card configuration in mythtv-setup for V4L (not DVB)
>>> capture devices, there's a setting to tell MythTV not to set the
>>> volume of the capture card.
>>>
>>> Do not adjust volume
>>> Enable this option for budget BT878 based DVB-T cards such as the
>>> AverTV DVB-T which require the audio volume to be left alone.
>>>
>>> (where I assume it talks about using the analog/V4L side of DVB-T
>>> cards--likely a cheap frame grabber?)
>> Thanks again! I'll test that out this evening. I had set the capture
>> card as an MPEG2 capture device, like the PVR-150's.
> Unfortunately, those options don't exist for the WinTV-pvr-usb2 device. :(
> Ah, well, back to the drawing board. Perhaps it is time to upgrade my
> motherboard for my backend system after all...

Did you see
http://www.gossamer-threads.com/lists/mythtv/users/518234#518234 ?

Mike
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-users

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads