Re: [PATCH 01/10] alsa_stream: port changes made on xawtv3

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

 



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
--
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