For now, put a limit on the amount of items we can send and receive
over the native protocol. A more complex way of allocating and freeing
can be implemented later when we really need to raise the limits.
Fixes#2070
Do pattern matching on object properties to also allow lookups on
type, object.path, object.serial and <type>.name.
ex:
pw-dump alsa_card.usb-BEHRINGER_UMC404HD_192k-00
pw-dump alsa_input*
pw-dump Node
When a node that requires a driver is moved to a driver, collect all
linked nodes and move them to the driver as well.
This fixes the case where a single jack node (zita-n2j) is linked to
paplay. The zita-n2j node is moved to the dummy driver but paplay is not
and so nothing happens before this patch.
We should always advance the read pointer when we are underrun and
not corked. This will request more bytes from the client to make
things advance.
Fixes#2041
Make sure we mark the port invalid when we can't allocate an id
for it. Also check that the id does not exceed the max amount of
areas we have allocated and release resources correctly.
It is possible that the mixer input can't be created because of hitting
the max limits of dsp mixer or client-node. Make sure we handle those
errors, destroy the link and clean up properly.
That tries to both set the buffersize and the samplerate of the graph.
Document them in README.md
Also add the same env variables to pw-stream and pw-filter.
* Possible to set max buffer size from config
* New play buffer with possibility to set a delay sent to backend,
orignal play buffer is still sent without delay to output
Change-Id: If787977305586a40cba4585ab6dad4b7163bee5a
Make sure the node name is something unique for the capture and playback
part of filter-chain and loopback so that volumes can be remembered
separately.
Fixes#1983
The policy can of course be higher than zero if the current thread uses
anything other than `SCHED_OTHER`, and `SCHED_RESET_ON_FORK` needs to be
set according to the old policy or we'll either run into errors or cause
unwanted side effects.
There are a couple other ways to allow a user/process to use realtime
priviliges like `CAP_SYS_NICE`. Instead of trying to check every
possible factor, just trying if setting realtime priviliges works is
going to be a much cleaner solution.
This automatically configures the node in a supported format with the
highest amount of channels. Options are available to enable monitor
and to override the port channels as AUX or UNKNOWN.
Add an option to check if the rate and quantum configured with the
settings metadata is in the allowed range.
This is false by default, you can use metadata to set any rate/quantum
but in a minimal controlled setup you might want to restrict this.
