gst: Implement new pwaudio{src,sink} elements, based on GstAudioBase{Src,Sink} #140
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
gkiagia
added a commit
to gkiagia/pipewire
that referenced
this pull request
Jul 29, 2019
…Src,Sink} These are much more reliable elements to use for audio data. * GstAudioBaseSink provides a reliable clock implementation based on the number of samples read/written * on the pipewire side we make sure to dequeue, fill and enqueue a single buffer inside the process() function, which avoids underruns Both elements share a common ringbuffer that actually implements the pipewire integration. Upstream-Status: Submitted [PipeWire#140]
gkiagia
pushed a commit
to gkiagia/pipewire
that referenced
this pull request
Jul 29, 2019
…f channels Upstream-Status: Submitted [PipeWire#140]
gkiagia
added a commit
to gkiagia/pipewire
that referenced
this pull request
Jul 29, 2019
…tate changes This allows the client to properly go to PAUSED when the session manager unlinks the stream and go again to PLAYING when the sm re-links it. This allows the session manager to implement policies without letting the client pipeline freeze (in the absence of a running audio clock) when it is unlinked. Note that in case the client doesn't handle the request, there is still no issue. Like in pulseaudio, the clock just freezes, so the pipeline stops progressing. This is similar to the pulseaudio cork/uncork mechanism. Upstream-Status: Submitted [PipeWire#140]
gkiagia
added a commit
to gkiagia/pipewire
that referenced
this pull request
Jul 29, 2019
…ting The CONFIGURE state is reached when the pw_client_node is exported, while the READY state requires the session manager to try and link the stream. If the SM does not want to link the stream due to policy, the client should not hang there forever. Upstream-Status: Submitted [PipeWire#140]
gkiagia
added a commit
to gkiagia/pipewire
that referenced
this pull request
Jul 29, 2019
This is to solve underrun issues that seem to appear with the default 10ms latency that GstBaseAudioSink has. Hopefully in the future we will have a better mechanism to pick the appropriate latency instead of hardcoding it here. Upstream-Status: Submitted [PipeWire#140]
gkiagia
added a commit
to gkiagia/pipewire
that referenced
this pull request
Aug 1, 2019
…Src,Sink} These are much more reliable elements to use for audio data. * GstAudioBaseSink provides a reliable clock implementation based on the number of samples read/written * on the pipewire side we make sure to dequeue, fill and enqueue a single buffer inside the process() function, which avoids underruns Both elements share a common ringbuffer that actually implements the pipewire integration. Upstream-Status: Submitted [PipeWire#140]
gkiagia
pushed a commit
to gkiagia/pipewire
that referenced
this pull request
Aug 1, 2019
…f channels Upstream-Status: Submitted [PipeWire#140]
gkiagia
added a commit
to gkiagia/pipewire
that referenced
this pull request
Aug 1, 2019
…tate changes This allows the client to properly go to PAUSED when the session manager unlinks the stream and go again to PLAYING when the sm re-links it. This allows the session manager to implement policies without letting the client pipeline freeze (in the absence of a running audio clock) when it is unlinked. Note that in case the client doesn't handle the request, there is still no issue. Like in pulseaudio, the clock just freezes, so the pipeline stops progressing. This is similar to the pulseaudio cork/uncork mechanism. Upstream-Status: Submitted [PipeWire#140]
gkiagia
added a commit
to gkiagia/pipewire
that referenced
this pull request
Aug 1, 2019
…ting The CONFIGURE state is reached when the pw_client_node is exported, while the READY state requires the session manager to try and link the stream. If the SM does not want to link the stream due to policy, the client should not hang there forever. Upstream-Status: Submitted [PipeWire#140]
gkiagia
added a commit
to gkiagia/pipewire
that referenced
this pull request
Aug 1, 2019
This is to solve underrun issues that seem to appear with the default 10ms latency that GstBaseAudioSink has. Hopefully in the future we will have a better mechanism to pick the appropriate latency instead of hardcoding it here. Upstream-Status: Submitted [PipeWire#140]
julianbouzas
pushed a commit
to julianbouzas/pipewire
that referenced
this pull request
Aug 7, 2019
…Src,Sink} These are much more reliable elements to use for audio data. * GstAudioBaseSink provides a reliable clock implementation based on the number of samples read/written * on the pipewire side we make sure to dequeue, fill and enqueue a single buffer inside the process() function, which avoids underruns Both elements share a common ringbuffer that actually implements the pipewire integration. Upstream-Status: Submitted [PipeWire#140]
julianbouzas
added a commit
to julianbouzas/pipewire
that referenced
this pull request
Aug 7, 2019
…f channels Upstream-Status: Submitted [PipeWire#140]
julianbouzas
pushed a commit
to julianbouzas/pipewire
that referenced
this pull request
Aug 7, 2019
…tate changes This allows the client to properly go to PAUSED when the session manager unlinks the stream and go again to PLAYING when the sm re-links it. This allows the session manager to implement policies without letting the client pipeline freeze (in the absence of a running audio clock) when it is unlinked. Note that in case the client doesn't handle the request, there is still no issue. Like in pulseaudio, the clock just freezes, so the pipeline stops progressing. This is similar to the pulseaudio cork/uncork mechanism. Upstream-Status: Submitted [PipeWire#140]
julianbouzas
pushed a commit
to julianbouzas/pipewire
that referenced
this pull request
Aug 7, 2019
…ting The CONFIGURE state is reached when the pw_client_node is exported, while the READY state requires the session manager to try and link the stream. If the SM does not want to link the stream due to policy, the client should not hang there forever. Upstream-Status: Submitted [PipeWire#140]
julianbouzas
pushed a commit
to julianbouzas/pipewire
that referenced
this pull request
Aug 7, 2019
This is to solve underrun issues that seem to appear with the default 10ms latency that GstBaseAudioSink has. Hopefully in the future we will have a better mechanism to pick the appropriate latency instead of hardcoding it here. Upstream-Status: Submitted [PipeWire#140]
julianbouzas
pushed a commit
to julianbouzas/pipewire
that referenced
this pull request
Aug 7, 2019
…Src,Sink} These are much more reliable elements to use for audio data. * GstAudioBaseSink provides a reliable clock implementation based on the number of samples read/written * on the pipewire side we make sure to dequeue, fill and enqueue a single buffer inside the process() function, which avoids underruns Both elements share a common ringbuffer that actually implements the pipewire integration. Upstream-Status: Submitted [PipeWire#140]
julianbouzas
added a commit
to julianbouzas/pipewire
that referenced
this pull request
Aug 7, 2019
…f channels Upstream-Status: Submitted [PipeWire#140]
julianbouzas
pushed a commit
to julianbouzas/pipewire
that referenced
this pull request
Aug 7, 2019
…tate changes This allows the client to properly go to PAUSED when the session manager unlinks the stream and go again to PLAYING when the sm re-links it. This allows the session manager to implement policies without letting the client pipeline freeze (in the absence of a running audio clock) when it is unlinked. Note that in case the client doesn't handle the request, there is still no issue. Like in pulseaudio, the clock just freezes, so the pipeline stops progressing. This is similar to the pulseaudio cork/uncork mechanism. Upstream-Status: Submitted [PipeWire#140]
julianbouzas
pushed a commit
to julianbouzas/pipewire
that referenced
this pull request
Aug 7, 2019
…ting The CONFIGURE state is reached when the pw_client_node is exported, while the READY state requires the session manager to try and link the stream. If the SM does not want to link the stream due to policy, the client should not hang there forever. Upstream-Status: Submitted [PipeWire#140]
julianbouzas
pushed a commit
to julianbouzas/pipewire
that referenced
this pull request
Aug 7, 2019
This is to solve underrun issues that seem to appear with the default 10ms latency that GstBaseAudioSink has. Hopefully in the future we will have a better mechanism to pick the appropriate latency instead of hardcoding it here. Upstream-Status: Submitted [PipeWire#140]
julianbouzas
pushed a commit
to julianbouzas/pipewire
that referenced
this pull request
Aug 9, 2019
…Src,Sink} These are much more reliable elements to use for audio data. * GstAudioBaseSink provides a reliable clock implementation based on the number of samples read/written * on the pipewire side we make sure to dequeue, fill and enqueue a single buffer inside the process() function, which avoids underruns Both elements share a common ringbuffer that actually implements the pipewire integration. Upstream-Status: Submitted [PipeWire#140]
julianbouzas
added a commit
to julianbouzas/pipewire
that referenced
this pull request
Aug 9, 2019
…f channels Upstream-Status: Submitted [PipeWire#140]
julianbouzas
pushed a commit
to julianbouzas/pipewire
that referenced
this pull request
Aug 9, 2019
…tate changes This allows the client to properly go to PAUSED when the session manager unlinks the stream and go again to PLAYING when the sm re-links it. This allows the session manager to implement policies without letting the client pipeline freeze (in the absence of a running audio clock) when it is unlinked. Note that in case the client doesn't handle the request, there is still no issue. Like in pulseaudio, the clock just freezes, so the pipeline stops progressing. This is similar to the pulseaudio cork/uncork mechanism. Upstream-Status: Submitted [PipeWire#140]
julianbouzas
pushed a commit
to julianbouzas/pipewire
that referenced
this pull request
Aug 9, 2019
…ting The CONFIGURE state is reached when the pw_client_node is exported, while the READY state requires the session manager to try and link the stream. If the SM does not want to link the stream due to policy, the client should not hang there forever. Upstream-Status: Submitted [PipeWire#140]
julianbouzas
pushed a commit
to julianbouzas/pipewire
that referenced
this pull request
Aug 9, 2019
This is to solve underrun issues that seem to appear with the default 10ms latency that GstBaseAudioSink has. Hopefully in the future we will have a better mechanism to pick the appropriate latency instead of hardcoding it here. Upstream-Status: Submitted [PipeWire#140]
julianbouzas
pushed a commit
to julianbouzas/pipewire
that referenced
this pull request
Aug 13, 2019
…Src,Sink} These are much more reliable elements to use for audio data. * GstAudioBaseSink provides a reliable clock implementation based on the number of samples read/written * on the pipewire side we make sure to dequeue, fill and enqueue a single buffer inside the process() function, which avoids underruns Both elements share a common ringbuffer that actually implements the pipewire integration. Upstream-Status: Submitted [PipeWire#140]
julianbouzas
added a commit
to julianbouzas/pipewire
that referenced
this pull request
Aug 13, 2019
…f channels Upstream-Status: Submitted [PipeWire#140]
julianbouzas
pushed a commit
to julianbouzas/pipewire
that referenced
this pull request
Aug 13, 2019
…tate changes This allows the client to properly go to PAUSED when the session manager unlinks the stream and go again to PLAYING when the sm re-links it. This allows the session manager to implement policies without letting the client pipeline freeze (in the absence of a running audio clock) when it is unlinked. Note that in case the client doesn't handle the request, there is still no issue. Like in pulseaudio, the clock just freezes, so the pipeline stops progressing. This is similar to the pulseaudio cork/uncork mechanism. Upstream-Status: Submitted [PipeWire#140]
julianbouzas
pushed a commit
to julianbouzas/pipewire
that referenced
this pull request
Aug 13, 2019
…ting The CONFIGURE state is reached when the pw_client_node is exported, while the READY state requires the session manager to try and link the stream. If the SM does not want to link the stream due to policy, the client should not hang there forever. Upstream-Status: Submitted [PipeWire#140]
julianbouzas
added a commit
to julianbouzas/pipewire
that referenced
this pull request
Aug 29, 2019
…f channels Upstream-Status: Submitted [PipeWire#140]
julianbouzas
pushed a commit
to julianbouzas/pipewire
that referenced
this pull request
Aug 29, 2019
…tate changes This allows the client to properly go to PAUSED when the session manager unlinks the stream and go again to PLAYING when the sm re-links it. This allows the session manager to implement policies without letting the client pipeline freeze (in the absence of a running audio clock) when it is unlinked. Note that in case the client doesn't handle the request, there is still no issue. Like in pulseaudio, the clock just freezes, so the pipeline stops progressing. This is similar to the pulseaudio cork/uncork mechanism. Upstream-Status: Submitted [PipeWire#140]
julianbouzas
pushed a commit
to julianbouzas/pipewire
that referenced
this pull request
Aug 29, 2019
…ting The CONFIGURE state is reached when the pw_client_node is exported, while the READY state requires the session manager to try and link the stream. If the SM does not want to link the stream due to policy, the client should not hang there forever. Upstream-Status: Submitted [PipeWire#140]
julianbouzas
pushed a commit
to julianbouzas/pipewire
that referenced
this pull request
Aug 29, 2019
This is to solve underrun issues that seem to appear with the default 10ms latency that GstBaseAudioSink has. Hopefully in the future we will have a better mechanism to pick the appropriate latency instead of hardcoding it here. Upstream-Status: Submitted [PipeWire#140]
gkiagia
added a commit
to gkiagia/pipewire
that referenced
this pull request
Sep 1, 2019
…Src,Sink} These are much more reliable elements to use for audio data. * GstAudioBaseSink provides a reliable clock implementation based on the number of samples read/written * on the pipewire side we make sure to dequeue, fill and enqueue a single buffer inside the process() function, which avoids underruns Both elements share a common ringbuffer that actually implements the pipewire integration. Upstream-Status: Submitted [PipeWire#140]
gkiagia
added a commit
to gkiagia/pipewire
that referenced
this pull request
Sep 1, 2019
…tate changes This allows the client to properly go to PAUSED when the session manager unlinks the stream and go again to PLAYING when the sm re-links it. This allows the session manager to implement policies without letting the client pipeline freeze (in the absence of a running audio clock) when it is unlinked. Note that in case the client doesn't handle the request, there is still no issue. Like in pulseaudio, the clock just freezes, so the pipeline stops progressing. This is similar to the pulseaudio cork/uncork mechanism. Upstream-Status: Submitted [PipeWire#140]
gkiagia
added a commit
to gkiagia/pipewire
that referenced
this pull request
Sep 1, 2019
…ting The CONFIGURE state is reached when the pw_client_node is exported, while the READY state requires the session manager to try and link the stream. If the SM does not want to link the stream due to policy, the client should not hang there forever. Upstream-Status: Submitted [PipeWire#140]
gkiagia
added a commit
to gkiagia/pipewire
that referenced
this pull request
Sep 1, 2019
This is to solve underrun issues that seem to appear with the default 10ms latency that GstBaseAudioSink has. Hopefully in the future we will have a better mechanism to pick the appropriate latency instead of hardcoding it here. Upstream-Status: Submitted [PipeWire#140]
gkiagia
added a commit
to gkiagia/pipewire
that referenced
this pull request
Sep 10, 2019
…Src,Sink} These are much more reliable elements to use for audio data. * GstAudioBaseSink provides a reliable clock implementation based on the number of samples read/written * on the pipewire side we make sure to dequeue, fill and enqueue a single buffer inside the process() function, which avoids underruns Both elements share a common ringbuffer that actually implements the pipewire integration. Upstream-Status: Submitted [PipeWire#140]
gkiagia
added a commit
to gkiagia/pipewire
that referenced
this pull request
Sep 10, 2019
…tate changes This allows the client to properly go to PAUSED when the session manager unlinks the stream and go again to PLAYING when the sm re-links it. This allows the session manager to implement policies without letting the client pipeline freeze (in the absence of a running audio clock) when it is unlinked. Note that in case the client doesn't handle the request, there is still no issue. Like in pulseaudio, the clock just freezes, so the pipeline stops progressing. This is similar to the pulseaudio cork/uncork mechanism. Upstream-Status: Submitted [PipeWire#140]
gkiagia
added a commit
to gkiagia/pipewire
that referenced
this pull request
Sep 10, 2019
…ting The CONFIGURE state is reached when the pw_client_node is exported, while the READY state requires the session manager to try and link the stream. If the SM does not want to link the stream due to policy, the client should not hang there forever. Upstream-Status: Submitted [PipeWire#140]
gkiagia
added a commit
to gkiagia/pipewire
that referenced
this pull request
Sep 10, 2019
This is to solve underrun issues that seem to appear with the default 10ms latency that GstBaseAudioSink has. Hopefully in the future we will have a better mechanism to pick the appropriate latency instead of hardcoding it here. Upstream-Status: Submitted [PipeWire#140]
gkiagia
added a commit
to gkiagia/pipewire
that referenced
this pull request
Sep 18, 2019
…Src,Sink} These are much more reliable elements to use for audio data. * GstAudioBaseSink provides a reliable clock implementation based on the number of samples read/written * on the pipewire side we make sure to dequeue, fill and enqueue a single buffer inside the process() function, which avoids underruns Both elements share a common ringbuffer that actually implements the pipewire integration. Upstream-Status: Submitted [PipeWire#140]
gkiagia
added a commit
to gkiagia/pipewire
that referenced
this pull request
Sep 18, 2019
…tate changes This allows the client to properly go to PAUSED when the session manager unlinks the stream and go again to PLAYING when the sm re-links it. This allows the session manager to implement policies without letting the client pipeline freeze (in the absence of a running audio clock) when it is unlinked. Note that in case the client doesn't handle the request, there is still no issue. Like in pulseaudio, the clock just freezes, so the pipeline stops progressing. This is similar to the pulseaudio cork/uncork mechanism. Upstream-Status: Submitted [PipeWire#140]
gkiagia
added a commit
to gkiagia/pipewire
that referenced
this pull request
Sep 18, 2019
…ting The CONFIGURE state is reached when the pw_client_node is exported, while the READY state requires the session manager to try and link the stream. If the SM does not want to link the stream due to policy, the client should not hang there forever. Upstream-Status: Submitted [PipeWire#140]
gkiagia
added a commit
to gkiagia/pipewire
that referenced
this pull request
Sep 18, 2019
This is to solve underrun issues that seem to appear with the default 10ms latency that GstBaseAudioSink has. Hopefully in the future we will have a better mechanism to pick the appropriate latency instead of hardcoding it here. Upstream-Status: Submitted [PipeWire#140]
gkiagia
added a commit
to gkiagia/pipewire
that referenced
this pull request
Sep 26, 2019
…Src,Sink} These are much more reliable elements to use for audio data. * GstAudioBaseSink provides a reliable clock implementation based on the number of samples read/written * on the pipewire side we make sure to dequeue, fill and enqueue a single buffer inside the process() function, which avoids underruns Both elements share a common ringbuffer that actually implements the pipewire integration. Upstream-Status: Submitted [PipeWire#140]
gkiagia
added a commit
to gkiagia/pipewire
that referenced
this pull request
Sep 26, 2019
…tate changes This allows the client to properly go to PAUSED when the session manager unlinks the stream and go again to PLAYING when the sm re-links it. This allows the session manager to implement policies without letting the client pipeline freeze (in the absence of a running audio clock) when it is unlinked. Note that in case the client doesn't handle the request, there is still no issue. Like in pulseaudio, the clock just freezes, so the pipeline stops progressing. This is similar to the pulseaudio cork/uncork mechanism. Upstream-Status: Submitted [PipeWire#140]
gkiagia
added a commit
to gkiagia/pipewire
that referenced
this pull request
Sep 26, 2019
…ting The CONFIGURE state is reached when the pw_client_node is exported, while the READY state requires the session manager to try and link the stream. If the SM does not want to link the stream due to policy, the client should not hang there forever. Upstream-Status: Submitted [PipeWire#140]
gkiagia
added a commit
to gkiagia/pipewire
that referenced
this pull request
Sep 26, 2019
This is to solve underrun issues that seem to appear with the default 10ms latency that GstBaseAudioSink has. Hopefully in the future we will have a better mechanism to pick the appropriate latency instead of hardcoding it here. Upstream-Status: Submitted [PipeWire#140]
gkiagia
added a commit
to gkiagia/pipewire
that referenced
this pull request
Sep 26, 2019
…Src,Sink} These are much more reliable elements to use for audio data. * GstAudioBaseSink provides a reliable clock implementation based on the number of samples read/written * on the pipewire side we make sure to dequeue, fill and enqueue a single buffer inside the process() function, which avoids underruns Both elements share a common ringbuffer that actually implements the pipewire integration. Upstream-Status: Submitted [PipeWire#140]
gkiagia
added a commit
to gkiagia/pipewire
that referenced
this pull request
Sep 26, 2019
…tate changes This allows the client to properly go to PAUSED when the session manager unlinks the stream and go again to PLAYING when the sm re-links it. This allows the session manager to implement policies without letting the client pipeline freeze (in the absence of a running audio clock) when it is unlinked. Note that in case the client doesn't handle the request, there is still no issue. Like in pulseaudio, the clock just freezes, so the pipeline stops progressing. This is similar to the pulseaudio cork/uncork mechanism. Upstream-Status: Submitted [PipeWire#140]
gkiagia
added a commit
to gkiagia/pipewire
that referenced
this pull request
Sep 26, 2019
…ting The CONFIGURE state is reached when the pw_client_node is exported, while the READY state requires the session manager to try and link the stream. If the SM does not want to link the stream due to policy, the client should not hang there forever. Upstream-Status: Submitted [PipeWire#140]
gkiagia
added a commit
to gkiagia/pipewire
that referenced
this pull request
Sep 26, 2019
This is to solve underrun issues that seem to appear with the default 10ms latency that GstBaseAudioSink has. Hopefully in the future we will have a better mechanism to pick the appropriate latency instead of hardcoding it here. Upstream-Status: Submitted [PipeWire#140]
gkiagia
added a commit
to gkiagia/pipewire
that referenced
this pull request
Oct 7, 2019
…Src,Sink} These are much more reliable elements to use for audio data. * GstAudioBaseSink provides a reliable clock implementation based on the number of samples read/written * on the pipewire side we make sure to dequeue, fill and enqueue a single buffer inside the process() function, which avoids underruns Both elements share a common ringbuffer that actually implements the pipewire integration. Upstream-Status: Submitted [PipeWire#140]
gkiagia
added a commit
to gkiagia/pipewire
that referenced
this pull request
Oct 7, 2019
…tate changes This allows the client to properly go to PAUSED when the session manager unlinks the stream and go again to PLAYING when the sm re-links it. This allows the session manager to implement policies without letting the client pipeline freeze (in the absence of a running audio clock) when it is unlinked. Note that in case the client doesn't handle the request, there is still no issue. Like in pulseaudio, the clock just freezes, so the pipeline stops progressing. This is similar to the pulseaudio cork/uncork mechanism. Upstream-Status: Submitted [PipeWire#140]
gkiagia
added a commit
to gkiagia/pipewire
that referenced
this pull request
Oct 7, 2019
…ting The CONFIGURE state is reached when the pw_client_node is exported, while the READY state requires the session manager to try and link the stream. If the SM does not want to link the stream due to policy, the client should not hang there forever. Upstream-Status: Submitted [PipeWire#140]
gkiagia
added a commit
to gkiagia/pipewire
that referenced
this pull request
Oct 7, 2019
This is to solve underrun issues that seem to appear with the default 10ms latency that GstBaseAudioSink has. Hopefully in the future we will have a better mechanism to pick the appropriate latency instead of hardcoding it here. Upstream-Status: Submitted [PipeWire#140]
|
I would prefer to figure out why the current code doesn't work. It has support for encoded formats and has an internal ringbuffer as well. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
These are much more reliable elements to use for audio data.
on the number of samples read/written
a single buffer inside the process() function, which avoids
underruns
Both elements share a common ringbuffer that actually implements
the pipewire integration.
NOTE: pwaudiosrc did not work properly last time I checked. I am not sure where the problem is, if it originates in the gstreamer code or actually somewhere inside pipewire's ALSA capture path.
@wtay , I am not sure if you think this is a good idea or if you had something else in mind for fixing this. The problem was, at the time I created this (~2 months ago), that I couldn't get audio reliably to the sound card through pipewiresink and after playing with the pipewiresink code a bit, I realized I needed a ringbuffer that could be read in a thread that is driven by pipewire's ALSA sink instead of driven by gstreamer.