[mythtv-users] wintv-pvr-usb2 audio clipping [solved]
isely at isely.net
Tue Apr 24 14:13:32 UTC 2012
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
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.
On Mon, 23 Apr 2012, Gary Buhrmaster wrote:
> On Mon, Apr 23, 2012 at 19:01, Rich West <Rich.West at wesmo.com> 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.org
isely @ isely (dot) net
PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8
More information about the mythtv-users