snd_midi_event_encode() will reset the encoder when it returns an
encoded event. It is possible that the function returns with an encoded
event when the internal buffer is full, in that case we need to push the
event and continue encoding without reseting the encoder.
0 is not a snd_midi_event_encode() error, so don't handle it like
one.
The messages, mostly sysex, can be split over multiple control message.
This happens when we read large messages from the sequencer, the
snd_seq_event_input function returns split messages that we transfer to
control messages directly.
When we send those messages out, however, the encoder wants the complete
message before it will return a valid event that we can send out. Keep
on calling the encoder with the control events until we get a complete
message that we can send out.
Fixes#4005
This fixes an issue introduced in 771f71f622
where the quantum is forced and may break applications the specify their
own quantum.
Signed-off-by: Lukas Rusak <lorusak@gmail.com>
This patch fixes use case, when disable_tsched is set and
api.alsa.period-size is set to value different from default quantum size.
In a such configuration, threshold needs to be set to a final value
before snd_pcm_sw_params_set_avail_min is called to get IRQs with
right timing.
Avail minimum is calculated from a threshold set in the check_position_config.
The method returned different value for threshold right before playback
started and after the playback started. Therefore threshold used in
the snd_pcm_sw_params_set_avail_min was incorrect.
Force the check_position_config to use configured values when called
from spa_alsa_prepare as this method is called when starting new playback
and the state->period_frames and the state->rate are already known.
Signed-off-by: Martin Geier <martin.geier@streamunlimited.com>
Without this change, playback_ready or capture_ready was called
immediately after spa_alsa_start even tho start-delay was set.
Ready function was called with not precise "nsec" value, as "nsec"
plus latency should return time when the next buffer should be played
which wasn't true as start-delay was not included.
Now the playback is started immediately when the start_delay is set.
The alsa_do_wakeup_work is still called immediately but two things can
happened. Either start-delay is smaller then max_error and *_ready
function is called immediately, or start-delay is bigger then max_error
and state->next_time will be updated to correct value.
Signed-off-by: Martin Geier <martin.geier@streamunlimited.com>
Alsa needs to call handler soon enough to have headroom plus threshold
frames in the buffer and not only threshold left.
Signed-off-by: Martin Geier <martin.geier@streamunlimited.com>
Headroom are extra samples available in alsa buffer on top of a threshold.
Its use to prefill alsa buffer with silence before the playback starts
and later its use to calculate target number of a frames in the alsa buffer
when get_status is called. Target is calculated as headroom plus
threshold, which should be smaller then buffer size to make sense.
Signed-off-by: Martin Geier <martin.geier@streamunlimited.com>
Signed-off-by: Carlos Rafael Giani <crg7475@mailbox.org>
Use alsa:acp: as the object prefix to make it different from the
alsa:pcm prefix when we are not using ACP.
Replace the card index in the object.path with the card_name, which
we try to construct from the alsa.id when it is available. This brings
the object.path in line with the alsa-pcm-device naming and adds the
user configurable id in the object.path to make it possible to
differentiate between identical devices.
Place the acp device index after the card_name instead of the unstable
device name (which depends on the alsa card number, which depends on the
kernel probing order).
This should make the object.path stable accross reboots for ACP and user
configurable with udev. With such a stable id, the other fields can be
made stable as well with custom rules.
See #3912
Use snd_ctl_card_info to set some more card properties such as the
alsa.id, alsa.mixer_name and alsa.components.
alsa.id is interesting because it is possible to use udev rules to set a
custom id, which is handy when you have two identical cards in the
system and want to assign unique ids to them.
See #3912
This does a couple of things: first, we implement revents demangling,
which seems to be required (although hw: devices work fine without it).
The second is to actually read the ctl events so we can tell when
elements we care about have changed, instead of reading everything and
trying to do a diff.
The latter is also required from a correctness perspective, as otherwise
the ctl might keep triggering wakeups while the fd is ready to be read.
Variable declarations after a label are not allowed,
and clang does not accept them. Fix the build failure
by removing the variable.
Fixes b3fbd0e607 ("alsa-pcm: add_bind_ctl_param: add support for array")
For matching kctl without the numid you need to specify interface,
device, subdevice, name and index. So the current implementation can
only match kctls on IFACE_PCM, device 0, subdevice 0 and index 0.
Instead of adding all these matching parameters this commit fetches all
kctls attached to the audio card and match on the first occurred kctl
with matching name.
This should be sufficient for audio cards with unique kctl names. When
non unique names are needed, more kctl matching parameters needs to be
added.
ALSA controls can only be opened on the card itself and will fail when
trying to open controls on the ALSA device. The device name we get may
or may not include the device suffix. If no suffix is present the
default device is 0 that's why currently it works on most audio cards.
But all other devices above 0 needs the suffix [1].
[1]
Device 0: hw:cardname
Device 0: hw:cardname,0
Device 1: hw:cardname,1
Device 2: hw:cardname,2
Device X: hw:cardname,X
We know in IRQ mode that any valid hi-res timestamp that the
driver privides will be before the wakeup event in pipewire.
This makes it so in IRQ mode we use better timestamping when possible,
which decreases jitter injected into the DLL, which in turn reduces
the amount of oscillations the resampler is exposed to.
Currently the HDMI output paths have jack mixers named "HDMI/DP" and
with append-pcm-to-name=true. However, most of the SOC audio drivers
are just named "HDMI" and don't add the ",pcm=N". Add these alternate
jack names to the HDMI audio path files so that jack detection will work
on these SOCs.
We would timestamp within an unlikely block, which would introduce
additional jitter to current_time, which would have an impact on
the performance of the timer sensitive code.
Previously both `impl_on_notify_events()` and `process_{device,card}()`
called `check_access()`. Avoid that by merging `ACTION_ADD` and
`ACTION_DISABLE` into a single `ACTION_CHANGE` and let `process_{device,card}()`
call `check_access()` and decide what to do.
Split up `process_{device,card}()` to have a separate function that does
the lookup based on the udev device, and only use that when there is
no available reference to the actual device/card object.
`IN_IGNORED` event is sent whenever the watch is removed,
which includes when the entity is deleted among other things,
so watch that instead of the more specific `IN_DELETE_SELF`.
Always reevaluate the rate matching even when we did not change the
follower state.
It is possible that we were a follower from some node with the same
clock and now become a follower of a node with a different clock. The
follower state doesn't change but we need to activate the rate matching
logic in that case.
Fixes rate matching in pro audio (playback) when capture and playback
are moved to another driver.
We can increase the MAX_LATENCY again if we increase the amount of
buffers when we are using a small buffer.
Normally we ask for 4 * quantum-limit as the buffer. This should be good
to use 1 buffer and quantum-limit as the quantum with enough headroom
to not run out of buffers.
If we are however using less buffer-frames we need to be careful and
allocate an extra buffer. Imagine using a buffer of 4096 frames, we can
support a quantum of up to 2048 frames if we use 2 buffers.
See #3744
Half of the buffersize is not enough to support as a max-quantum, we
need to divide by (4 * frame_scale) to allow some headroom and account
for the DSD scaling. We do the same calculation to suggest a buffer size
using the quantum-limit.
See #3744
As part of the setup for IRQ based scheduling, a period event
was installed. Not only is a timer based polling unecessary for
IRQ scheduling, depending on the state of the system, the timer
could fire far enough from the IRQ, causing alsa wakeup events
with no data in the ring buffer. Pipewire would identify these
events as an "early wakeup", adding an extra quantum of time
to the next_time estimate, skewing the clock and causing issues
with apps that depend on precise timing.
This reverts commit 49cdb468c2.
We should not do this, the nsec field should be relatable to the clock
monotonic time. If we use the estimated time, without actually using it
as a timer, we might end up with a wakeup time in the future compared to
the MONOTONIC clock time.
Instead, you can use the estimated current time simply by subtracting
the rate corrected duration from the next_nsec. This is really only
useful for some selected use cases (like in the JACK library).
This fixes some issues where in pro-audio mode, a client would try to
compare the current MONOTONIC time to nsec and find that it is in the
past.
This commit was done in an attempt to fix#3657 but it turned out the
real problem was something else.
The alsa sequencer rate matching was not actually working correctly.
It would compare the previous queue time with the current time and
compare that to the quantum. This would include uncorrected errors from
jitter and would result in the timeouts being scaled in the wrong
direction forever.
Instead, calculate an ideal queue time and compare our current queue
time against that. We then use the correction to scale the timeout or
the next queue time prediction.
Also use the predicted time as the base time for the event timestamps.
this results in less jitter.
Fixes#3657
While switching to the Pro Audio profile from a UCM profile, the active
UCM profile is not disabled because the devices may need a UCM verb to
be set before being used. Then, switching away from the Pro profile to a
UCM profile is done by passing the Off profile as the old profile,
instead of the actually-still-enabled UCM profile.
This means the devices from the old UCM profile are kept enabled when we
try to switch to another UCM profile. And the devices to enable may be
conflicting with the still-enabled devices, which will cause failures.
To avoid this, we need to tell the UCM code to disable the profile when
switching away from it. Doing so disables UCM devices and the UCM verb.
Existing code sets the highest priority UCM verb before probing the Pro
profile, so manually enable the same one here as well, instead of
relying on unclean state from whatever profile that was last active.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
The hardware controls we track for volume and mute state can change as
part of enabling or disabling the UCM device. This then triggers a
re-sync of our state with the hardware controls, which can e.g. set our
volume to an unwanted value as the result of enabling the device, or set
a hardware control to a wrong value based on our volume while disabling
the device. So these UCM-triggered changes to enable/disable the device
will at best show up on user interfaces and cause confusion, but maybe
even will push the hardware into an unexpected state.
The volume and mute state we set from user interfaces only make sense
when the devices are enabled. They should not be kept in sync with
hardware for inactive UCM devices [1]. Skip the callbacks for reading
and changing volume and mute state if the UCM device is disabled. This
way, the volume/mute controls for sinks/sources are essentially detached
from the hardware controls until the UCM device is re-enabled.
[1] https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/772#note_1872757
Link: https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/772
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
