Hauppage hvr-950q au0828 transfer problem affecting audio and perhaps video

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



I have problems with my audio that I've tracked down to the transfer
of audio from the au0828
in my hvr-950Q. I spotted the following comment about green screen
detection and I wonder
if it might be related.

drivers/media/video/au0828/au0828-video.c:

        /* Workaround for a bug in the au0828 hardware design that sometimes
           results in the colorspace being inverted */

The problem is that sound/usb/usbaudio.c assumes that each urb data
field contains an integer
number of audio frames (aka audio slots), in this case a integer
number of left channel-right
channel pairs. About 12 times a second for my device a urb doesn't.
This causes a flutter noise
with non-quiet audio that contains a difference between the channels.

I found this by using audacity to look at wave forms and a usb trace
to see the problematic urb's.
I've confirmed by relaxing the constraint in sound/usb/usbaudio.c with
a patch and can confirm that
it clears up the audio.


Is the code comment at the top related to my problem?

More importantly, is there the possibility of setting up the transfer
differently so that
audio slots aren't split between urbs?


>From what I have read in the spec I believe the split of the audio
slots between urb's is non-
conformant. Therefore I think it would be a mistake to change the
default behaviour of
usbaudio.c since, as it is now,usbaudio.c won't swap channels in the
case of dropped urbs.
It would be optimal if the hvr-950q could be set up to conform by not
splitting audio slots.

I think the problem also occurs for video when blue will turn to pink
for a flash until the top
of frame resyncs things up--because of the corresponding swap of UY
with VY. This seems
to be related to how busy my system is and what usb slot I'm using on
my laptop. Again
I could see in a usb trace the urb's with data_lengths such that UY
would be split from the
corresponding VY. The video transfer is a straight byte copy so
ordinarily this isn't a
problem but would be if an abnormally sized urb were dropped and the
device and host
were to get out of sync regarding V and U.

I also have caught an occasional odd number of bytes transferred in
traces, which requires
the drop of incomplete samples in usbaudio.c. I wonder if this is
related to the green screen
problem on video from the top comment.

The easiest way to reproduce the audio problem is to use the composite
video input but only
hook up either the left or the right audio. With earphonesyou can hear
the audio rapidly
go from ear to ear.

Thanks for those on the list for their hard work on getting devices
such as this to work. I'd
appreciate any answers, comments, corrections, or information.
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux