Re: [PATCH] sound/usb: Relax urb data alignment restriciton for HVR-950Q only
On Thu, Dec 10, 2009 at 8:49 PM, Devin Heitmueller wrote: > Hello John, > > On Thu, Dec 10, 2009 at 8:38 PM, John S Gruber wrote: >> I think you found something in the specification I haven't found. What did >> you >> see that indicated how to deal with equipment misbehaving in this way? > > I'm referring to section 2.3.2.3 of "Universal Serial Bus Device Class > Definition for Audio Data Formats" > >> I found the following list of USB ID's. Just double checking, but is >> the 850 enough like the >> 950 line for me to include it? >> >> case 72000: /* WinTV-HVR950q (Retail, IR, ATSC/QAM */ >> case 72001: /* WinTV-HVR950q (Retail, IR, ATSC/QAM and analog video */ >> case 72211: /* WinTV-HVR950q (OEM, IR, ATSC/QAM and analog video */ >> case 72221: /* WinTV-HVR950q (OEM, IR, ATSC/QAM and analog video */ >> case 72231: /* WinTV-HVR950q (OEM, IR, ATSC/QAM and analog video */ >> case 72241: /* WinTV-HVR950q (OEM, No IR, ATSC/QAM and analog video */ >> case 72251: /* WinTV-HVR950q (Retail, IR, ATSC/QAM and analog video */ >> --> case 72301: /* WinTV-HVR850 (Retail, IR, ATSC and analog video */ >> case 72500: /* WinTV-HVR950q (OEM, No IR, ATSC/QAM */ > > Yes, the HVR-850 should be included in the list. > >> I'd add that being the beginner at making kernel changes your review >> is particularly >> helpful to me (and to my confidence). > > You are likely to receive a more thorough/critical review when you > send to the alsa-devel mailing list, as they have considerably more > expertise in this area than I do. > > Devin > > -- > Devin J. Heitmueller - Kernel Labs > http://www.kernellabs.com > I'll do that. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] sound/usb: Relax urb data alignment restriciton for HVR-950Q only
> After reviewing the patch as well as the spec, your change looks > pretty reasonable (aside from the fact that you need the other USB > IDs). It seems pretty clear that the au0828 violates the spec, but > the spec does indicate how to handle that case, which is what your > code addresses. > I think you found something in the specification I haven't found. What did you see that indicated how to deal with equipment misbehaving in this way? I found the following list of USB ID's. Just double checking, but is the 850 enough like the 950 line for me to include it? case 72000: /* WinTV-HVR950q (Retail, IR, ATSC/QAM */ case 72001: /* WinTV-HVR950q (Retail, IR, ATSC/QAM and analog video */ case 72211: /* WinTV-HVR950q (OEM, IR, ATSC/QAM and analog video */ case 72221: /* WinTV-HVR950q (OEM, IR, ATSC/QAM and analog video */ case 72231: /* WinTV-HVR950q (OEM, IR, ATSC/QAM and analog video */ case 72241: /* WinTV-HVR950q (OEM, No IR, ATSC/QAM and analog video */ case 72251: /* WinTV-HVR950q (Retail, IR, ATSC/QAM and analog video */ --> case 72301: /* WinTV-HVR850 (Retail, IR, ATSC and analog video */ case 72500: /* WinTV-HVR950q (OEM, No IR, ATSC/QAM */ Thanks again, not only for your help with my change, but with all you did to provide support for the Hauppage equipment. I'd add that being the beginner at making kernel changes your review is particularly helpful to me (and to my confidence). John -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] sound/usb: Relax urb data alignment restriciton for HVR-950Q only
Addressing audio quality problem.
In sound/usb/usbaudio.c, for the Hauppage HVR-950Q only, change
retire_capture_urb to copy the entire byte stream while still counting
entire audio frames. urbs unaligned on channel sample boundaries are
still truncated to the next lowest stride (audio slot) size to try to
retain channel alignment in cases of data loss over usb.
With the HVR950Q the left and right channel samples can be split between
two different urbs. Throwing away extra channel samples causes a sound
quality problem for stereo streams as the left and right channels are
swapped repeatedly.
modified: sound/usb/usbaudio.c
Signed-off-by: John S. Gruber
---
sound/usb/usbaudio.c | 45 +++--
1 files changed, 35 insertions(+), 10 deletions(-)
diff --git a/sound/usb/usbaudio.c b/sound/usb/usbaudio.c
index 44b9cdc..64d9d3a 100644
--- a/sound/usb/usbaudio.c
+++ b/sound/usb/usbaudio.c
@@ -107,8 +107,9 @@ MODULE_PARM_DESC(ignore_ctl_error,
#define MAX_PACKS_HS (MAX_PACKS * 8) /* in high speed mode */
#define MAX_URBS 8
#define SYNC_URBS 4 /* always four urbs for sync */
#define MAX_QUEUE 24 /* try not to exceed this queue length, in ms */
+#define ALLOW_SUBSLOT_BOUNDARIES 0x01 /* quirk */
struct audioformat {
struct list_head list;
snd_pcm_format_t format;/* format type */
@@ -126,8 +127,9 @@ struct audioformat {
unsigned int rates; /* rate bitmasks */
unsigned int rate_min, rate_max;/* min/max rates */
unsigned int nr_rates; /* number of rate table entries */
unsigned int *rate_table; /* rate table */
+ unsigned int txfr_quirks; /* transfer quirks */
};
struct snd_usb_substream;
@@ -174,8 +176,11 @@ struct snd_usb_substream {
unsigned int running: 1;/* running status */
unsigned int hwptr_done;/* processed frame
position in the buffer */
+ unsigned int byteptr; /* position, in bytes, of next move */
+ unsigned int remainder; /* extra bytes moved to buffer */
+ unsigned int txfr_quirks; /* substream transfer quirks */
unsigned int transfer_done; /* processed frames since last
period update */
unsigned long active_mask; /* bitmask of active urbs */
unsigned long unlink_mask; /* bitmask of unlinked urbs */
@@ -342,9 +347,9 @@ static int retire_capture_urb(struct
snd_usb_substream *subs,
{
unsigned long flags;
unsigned char *cp;
int i;
- unsigned int stride, len, oldptr;
+ unsigned int stride, len, bytelen, oldbyteptr;
int period_elapsed = 0;
stride = runtime->frame_bits >> 3;
@@ -353,31 +358,44 @@ static int retire_capture_urb(struct
snd_usb_substream *subs,
if (urb->iso_frame_desc[i].status) {
snd_printd(KERN_ERR "frame %d active: %d\n", i,
urb->iso_frame_desc[i].status);
// continue;
}
- len = urb->iso_frame_desc[i].actual_length / stride;
- if (! len)
+ bytelen = (urb->iso_frame_desc[i].actual_length);
+ if (!bytelen)
continue;
+ if (!(subs->txfr_quirks & ALLOW_SUBSLOT_BOUNDARIES))
+ bytelen = (bytelen/stride)*stride;
+ if (bytelen%(runtime->sample_bits>>3) != 0) {
+ int oldbytelen = bytelen;
+ bytelen = ((bytelen/stride)*stride);
+ printk(KERN_DEBUG "Corrected urb data len. %d -> %d\n",
+ oldbytelen, bytelen);
+ }
/* update the current pointer */
spin_lock_irqsave(&subs->lock, flags);
- oldptr = subs->hwptr_done;
+ len = (bytelen + subs->remainder) / stride;
+ subs->remainder = (bytelen + subs->remainder) % stride;
+ oldbyteptr = subs->byteptr;
subs->hwptr_done += len;
if (subs->hwptr_done >= runtime->buffer_size)
subs->hwptr_done -= runtime->buffer_size;
subs->transfer_done += len;
if (subs->transfer_done >= runtime->period_size) {
subs->transfer_done -= runtime->period_size;
period_elapsed = 1;
}
+ subs->byteptr += bytelen;
+ if (subs->byteptr >= runtime->buffer_size*stride)
+ subs->byteptr -= runtime->buffer_size*stride;
spin_unlock_irqrestore(&subs->lock, flags);
/* copy a data chunk */
- if (oldptr + len > runtime-
Re: Hauppage hvr-950q au0828 transfer problem affecting audio and perhaps video
On Fri, Dec 4, 2009 at 10:43 AM, Devin Heitmueller wrote: > On Fri, Dec 4, 2009 at 9:31 AM, John S Gruber wrote: >> I produced the dump of URB sizes you requested by adding that printk() line. >> The >> results are at http://pastebin.com/f26f29133 > > Hi John, > > This is good info (especially since you have kernel timestamps enabled). > > Did you have a specific reference to the USB audio spec which said the > packet size has to be on an integer boundary? I took a look at the > spec last night and didn't see anything to that end. > > Do you have a proposed patch to usbaudio.c which "works for you"? If > so, feel free to send it along and I will review and provide comments. > If the spec does not require the packets to be on an integer > boundary, perhaps the driver just improperly assumes they will be (and > they were for whatever developer wrote the original code). > > Devin > > -- > Devin J. Heitmueller - Kernel Labs > http://www.kernellabs.com > Hi Devin, You might look at this: http://www.usb.org/developers/devclass_docs/Audio2.0_final.zip File: Frmts20 final.pdf Sections 2.3.1.3, 2.3.1.4 and 2.3.1.5 on page 15 This is from release 2.0 from 5/31/2006 Also http://www.usb.org/developers/devclass_docs/frmts10.pdf Sections 2.2.2, 2.2.3 and 2.2.4 on page 9. This is the 1998 1.0 release. Thanks for your offer to review my patch. I'll try to post it yet today. I'm still messing around with it. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Hauppage hvr-950q au0828 transfer problem affecting audio and perhaps video
> 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 > I produced the dump of URB sizes you requested by adding that printk() line. The results are at http://pastebin.com/f26f29133 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hauppage hvr-950q au0828 transfer problem affecting audio and perhaps video
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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
