[WIP] Output audio queue #1253
[WIP] Output audio queue #1253
Conversation
It is placed in the very beginning, not elsewhere.
We want to get the segments in sync with when they are passed onto the sound card, and now that is after the output queue.
Now that we have an output audio queue, which is fully processed, if we change some parameters of the elements (that are placed before said queue), the changes will not propagate to the output immediately, as expected. But that is not what one wants. So when changing parameters of such elements, we must ensure to flush the now-stale caches, thus forcing re-processing of the audio. Now, this works, but i really don't understand how flushing is supposed to work in gstreamer, it just doesn't seem to work if there is no seeking, so there is some jumps when changing parameters now. Maybe this can be avoided? Also, fader needs to be reimplemented. It fundamentally does not fit into this structure.
|
Since "use-buffering" is set to false for the input queue, low/high watermark settings are ignored, I'm not sure about "max-size-time", but not much need for the loop just for one extra line. |
Ah. That's because i thought that it would only disable messages, but not buffering altogether, I'm mainly just not sure where to start untangling all this (+gapless playback, +proper faders), |
After looking through gstqueue2.c it is not obvious to me why
|
|
I think you are right about this, Strawberry is a bit too sensitive to CPU high load, more so than compared to for example VLC. I've experienced this a few times when I've been compiling Qt at the same time as playing music, I think it is also worse on Windows than on Linux. |
|
Sorry that I've created conflicts for you now. |
What kind of issues, specifically? That being said, please maybe don't merge this/that, i believe i want to first deal with
No. |
This is incomplete.
Currently, the queue is placed before all of our elements,
which is great to precache input and not stutter through
the times where there's IO latency spikes,
but if there's a CPU latency spike, we may still stutter
because we still need to process the input.
By also caching the final output, we should be safe from that.
This introduces subtleties: when changing parameters
of said modules, the changes will no longer be immediate,
but delayed by the cache length. So we must flush the pipeline's caches.
This sounds simple, but the obvious approach does not work,
and the one that works (seek to the current position)
causes temporary stutters. This isn't nice.
Also, probes need to be taken after the output queue.
Also, the way the fader is implemented just doesn't work with this approach.
But overall, this works better than i expected.