[mythtv-users] wintv-pvr-usb2 audio clipping [solved]

[Mike Isely]

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.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.
> 
> Gary
> _______________________________________________
> mythtv-users mailing list
> mythtv-users at mythtv.org
> 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