| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
a videosrc at this point
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The driver has an internal buffer of unspecified and unconfigurable size, and
it will pull data from our ring buffer as fast as it can until that is full.
Unfortunately that means that we pull silence from the ringbuffer unless its
size is by conincidence larger than the driver's internal ringbuffer.
The good news is that it's not required to completely fill the buffer for
proper playback. So we now throttle reading from the ringbuffer whenever
the driver has buffered more than half of our ringbuffer size by waiting
on the clock for the amount of time until it has buffered less than that
again.
|
|
|
|
|
|
| |
The ringbuffer's acquire() is too early, and ringbuffer's start() will only be
called after the clock has advanced a bit... which it won't unless we start
scheduled playback.
|
|
|
|
|
|
|
|
|
|
| |
are ready and we are in PLAYING
Otherwise we might start the scheduled playback before the audio or video streams are
actually enabled, and then error out later because they are enabled to late.
We enable the streams when getting the caps, which might be *after* we were
set to PLAYING state.
|
|
|
|
|
|
| |
not jump when going from PAUSED to PLAYING
It basically behaves the same as the audio clocks.
|
| |
|
|
|
|
|
|
| |
CID 1262288
CID 1262287
CID 1262289
|
|
|
|
|
|
| |
the same device
This causes deadlocks sometimes for some reason.
|
| |
|
| |
|
|
|