On Thu, Dec 3, 2009 at 11:21 PM, Devin Heitmueller <dheitmueller@xxxxxxxxxxxxxx> wrote: > 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. I am definitely seeing what you are saying with regards to the channel flipping back and forth. Do you know what size URBs are being delivered? If you've got a hacked up version of usbaudio.c, how about adding a printk() line which dumps out the URB size and send me a dump? 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
