The old way fails, if a distro has the header but not the library,
which can happen on at least Gentoo with multilib deployments,
where the shared header is present but non-native libraries might not.
This could still fail, if a distro had some but not all libraries for
some architectures but hopefully no one did that. In that case, a compile
test would likely be required via cc.check_header() instead but let's try
the faster fix first.
Reported-by: Sam James <sam@gentoo.org>
Thanks-to: Barnabás Pőcze <pobrn@protonmail.com>
Thanks-to: Xavier Claessens <xavier.claessens@collabora.com>
Signed-off-by: Niklāvs Koļesņikovs <89q1r14hd@relay.firefox.com>
Bring the state to CONFIGURE by actually setting the FORMAT to NULL when
we remove the last mixer. Otherwise the buffers and formats are still on
the port and we might try to use them while negotiating a new format
later.
Avoids some crashes.
Use the port_set_mix_info to add and remove mix info information to the
client.
Previously it was impossible to clean up mix_info.
With this change we can also simplify the jack peer port detection.
Because the mix info is always sent before the link appears we can
simply look up the info when the link appears.
When we don't set a rate, assume both input and output streams are
following the graph rate and so disable the resampler.
This mostly works around an issue where the input and output could
negotiate to different rates in some cases. With the resampler disabled
this would still result in the same amount of samples going in as
comming out instead of a stuttering mismatch.
See #2969
When one side of the loopback suspends, do a EnumFormat params to force
renegotiation on the other side as well.
Suppose this:
1. sink/filter/pw-play plays at 48000Hz
2. pw-play goes away, sink and filter-sink suspend, filter-playback
idles
3. pw-play starts with 44100Hz
4. sink/filter-sink renegotiate to 44100Hz, filter-playback is still
at 48000Hz and pitch shifted.
We might want to manually suspend the IDLE nodes instead but for now
this is a good workaround.
Fixes#2969
There is already an id in the port_mix structure that can be used to
index the mix structures in map if needed, the mix_id is the port_id of
the mixer and should not be confused.
Our sink and source callbacks are called twice, once when the graph
starts and once when it completes, make sure we don't signal the jack
graph twice or we get corrupted output.
Fixes#3255
Add an option to export the node from the factory.
That way you can locally create a node from a factory and then export it
to the server. This is handy to make object in the server from a config
file using the node-factory.
See !1643
Check for multiple recursive disconnect calls by checking the flags
before calling the pw_proxy methods. This ensure that calling disconnect
from one of the proxy removed callbacks does not trigger another
disconnect later on.
Let the implementation handle this when needed. The main problem is that
we can set this to NULL before calling the port function and that might
crash things.
If we are not recursing, take the complete property value without
attempting to parse it as json, only do this when recursing.
If the property value looks like a container is is exactly of the right
length, print is as a container, otherwise print is as string.
This makes properties like "[192.0.0.1]:45000" be printed as a string
instead of the array [192.0.0.1]. but still makes "[FL FR]" be an
array.
Fixes#3290
Because the capture triggers the playback stream, the playback stream
might not be actually triggered when the stream is not running.
This can cause a buffer to be queued in the capture side that is never
dequeued from the playback side. If 2 buffers are queued (and 2 buffers
are available on the stream), the capture source has no more buffers and
starts to drop/stutter.
Fix this problem by always dequeueing/queuing all the queued buffers so
that we always use the last one.
See #3276
When one side of the loopback suspends, do a EnumFormat params to force
renegotiation on the other side as well.
Suppose this:
1. sink/filter/pw-play plays at 48000Hz
2. pw-play goes away, sink and filter-sink suspend, filter-playback
idles
3. pw-play starts with 44100Hz
4. sink/filter-sink renegotiate to 44100Hz, filter-playback is still
at 48000Hz and pitch shifted.
We might want to manually suspend the IDLE nodes instead but for now
this is a good workaround.
Fixes#2969
Clear the READ flag when the param is removed.
Don't recursively emit param_changed events or we could end up in an
infite loop when we update params from param_changed.
