On Thu, Dec 3, 2009 at 11:00 PM, John S Gruber <johnsgruber@xxxxxxxxx> wrote: > 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. Hi John, I have actually actively debugging the au0828 audio this evening. The comment you referred to (which I wrote) has to do with the delivery of the UYVY data from the demodulator to the au0828 bridge, which can cause the start of the stream to be off-by-one (the pink/green you see is the colorspace inverted when the decoder loses sync). It is unrelated to audio. I'm working an issue now where the audio keeps dropping out. If you want to show me the code change you did to usbaudio.c, it might give me a better understand the issue. Cheers, Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- 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
