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.
There are currently several issues when multiple alsa devices are
involved.
For alsa devices that are followers, all data is written via
impl_node_process(). Currently spa_alsa_write() is only called if a new
buffer was queued.
It can happen that all buffers are in the ready list (queued by previous
calls but not yet written because there was no free space in the kernel
ring buffer). In this case writing stalls indefinitely.
To fix this, also call spa_alsa_write() if no new buffer is queued but
there are still buffers in the ready list.
If the ready list of the primary device is not empty then only this
device is handled because spa_alsa_write() is called directly. The other
devices make no progress during this interval.
The clock drift calculation works by comparing the alsa delay with the
expected delay since the last wakeup. This only work if the alsa
ringbuffer was filled completly. If the ready list contains a partial
buffer then the ringbuffer is not filled and the timing calculation
during the next wakeup is incorrect.
To fix all this, remove the special case for the non-empty ready list
and just call spa_node_call_ready() every time.
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.
When we have a callback installed but the bufsize/srate can not be
notified yet because the client is inactive, try again in the next
cycle.
Fixes#3297
If we detect Playback/Capture Pitch 1000000, we can adjust those values
to update the feedback endpoint for the host. On the capture side, this
will instruct the host to adjust the rate at which data is being sent.
On the playback side, this will adjust the amount of data the USB gadget
driver sends out in each USB tick.
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.
