Bug #2098
First soundchunk determines pipeline delay
| Status: | Closed | Start date: | 11/20/2014 | |
|---|---|---|---|---|
| Priority: | Normal | Due date: | ||
| Assignee: | - | % Done: | 0% | |
| Category: | - | |||
| Target version: | - |
Description
The first soundchunk received introduces a delay to the whole pipeline equal to its own length. This does not go away, even after a timestamp reset through a pause in sending data to the pipeline.
I initially thought this phenomenon might be the root of the problem but it is not:
gst_rsb_src_base->buffer_number is initialized to 0 but then subsequently starts at 1 because it is incremented at buffer creation time:
GST_BUFFER_OFFSET (temp) = gst_rsb_src_base->buffer_number;
GST_BUFFER_OFFSET_END(temp) = ++gst_rsb_src_base->buffer_number;
This leads to problems when the buffer number is used to assess the timestamps for the extrapolate scheduler:
*timestamp = (gst_rsb_src_base->first_event_element_time
+ (static_cast<guint64>(gst_rsb_src_base->buffer_number)
* *duration));
History
#1 Updated by C. Leichsenring over 9 years ago
- Subject changed from Buffer number is incongruent to First soundchunk determines pipeline delay
- Description updated (diff)
Testing revealed that the error is actually different than I initially thought.
#2 Updated by C. Leichsenring over 9 years ago
- Status changed from New to Rejected
Well, the buffer numbering is still odd but since this doesn't have a functional aspect, I'm closing this because "don't care".
#3 Updated by C. Leichsenring over 9 years ago
- Status changed from Rejected to Closed
Oh, well, too many tabs and I changed the subject ... since this bug is no longer about the buffer numbering, closing it isn't as straightforward. A fix is in the resume-stream-fix branch. Let's gain some more experience with how this behavior goes and then we can see if and how to change the master behavior.