On Tue, Sep 6, 2011 at 11:37 PM, Devin Heitmueller <dheitmueller@xxxxxxxxxxxxxx> wrote: > On Tue, Sep 6, 2011 at 11:29 PM, Mauro Carvalho Chehab > <mchehab@xxxxxxxxxx> wrote: >>> Basically the above starts at the *maximum* capture resolution and >>> works its way down. One might argue that this heuristic makes more >>> sense anyway - why *wouldn't* you want the highest quality audio >>> possible by default (rather than the lowest)? >> >> That change makes sense to me. Yet, you should try to disable pulseaudio >> and see what's the _real_ speed that the audio announces. On Fedora, >> just removing pulsaudio-oss-plugin (or something like that) is enough. >> >> It seems doubtful that my em2820 WinTV USB2 is different than yours. >> I suspect that pulseaudio is passing the "extra" range, offering to >> interpolate the data. > > I disabled pulseaudio and the capture device is advertising the exact > same range (8-48 KHz). Seems to be behaving the same way as well. > > So while I'm usually willing to blame things on Pulse, this doesn't > look like the case here. > >>> Even with that patch though, I hit severe underrun/overrun conditions >>> at 30ms of latency (to the point where the audio is interrupted dozens >>> of times per second). >> >> Yes, it is the same here: 30ms on my notebook is not enough for WinTV >> USB2 (it is OK with HVR-950). >> >>> Turned it up to 50ms and it's much better. >>> That said, of course such a change would impact lipsync, so perhaps we >>> need to be adjusting the periods instead. >> >> We've added a parameter for that on xawtv3 (--alsa-latency). We've parametrized >> it at the alsa stream function call. So, all it needs is to add a new parameter >> at tvtime config file. > > Ugh. We really need some sort of heuristic to do this. It's > unreasonable to expect users to know about some magic parameter buried > in a config file which causes it to start working. Perhaps a counter > that increments whenever an underrun is hit, and after a certain > number it automatically restarts the stream with a higher latency. Or > perhaps we're just making some poor choice in terms of the > buffers/periods for a given rate. > > Devin > > -- > Devin J. Heitmueller - Kernel Labs > http://www.kernellabs.com > One more thing worth noting before I quit for the night: What audio processor is on your WinTV USB 2 device? The DVC-90 has an emp202. Perhaps the WInTV uses a different audio processor (while still using an em2820 as the bridge)? That might explain why your device advertises effectively only one capture rate (32), while mine advertises a whole range (8-48). 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
