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


[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