No longer used.
Sponsored by: The FreeBSD Foundation
MFC after: 2 days
Reviewed by: dev_submerge.ch
Differential Revision: https://reviews.freebsd.org/D47269
(cherry picked from commit 9a6cf27583ffc13bb0a7c5be0704ba0d2f3b834d)
When adding a new vchan, we are looking for a parent channel which
either already has vchans (i.e CHN_F_HAS_VCHAN), or does not, but is
also not being used (i.e !CHN_F_BUSY). Since CHN_F_BUSY essentially
tells us if the channel is currently being used or not, there is no need
to check if the channel's refcount is 0 as well.
When removing a vchan, we first check if we have only 1 vchan allocated
that is also being used (so we cannot remove it at the moment), and then
we check if the vchan is not busy and remove it. Again, checking
CHN_F_BUSY is enough.
Sponsored by: The FreeBSD Foundation
MFC after: 2 days
Reviewed by: dev_submerge.ch
Differential Revision: https://reviews.freebsd.org/D47268
(cherry picked from commit 43c0b593c2c3b2c07009c031a0e7e8190a45b31a)
Before de8c0d15a64fa ("sound: Get rid of snd_clone and use
DEVFS_CDEVPRIV(9)"), sound(4) would create one device for each allocated
channel. The device names would be chosen from dsp_cdevs[], and created
with dsp_unit2name(). Additionally, dsp_cdevs[] was also used to match
these devices names, as well as OSSv4 aliases in dsp_clone().
Since sound(4) does not create separate devices for each channel
anymore, the meaning and use dsp_cdevs[] has changed. Part of it no
longer corresponds to devices at all, but instead is used to create
channel names, and another part is used to match only OSSv4 aliases in
dsp_clone().
To address this confusion, separate dsp_cdevs[] into a dsp_aliases[]
array, and move dsp_unit2name() to pcm/channel.c and rename it to
chn_mkname().
While here, get rid of the SND_DEV_DSPHW_* channel types, and simply use
the existing PCMDIR_* constants as the channel types. There is no need
to duplicate the same meaning twice.
Sponsored by: The FreeBSD Foundation
MFC after: 2 days
Reviewed by: dev_submerge.ch
Differential Revision: https://reviews.freebsd.org/D47199
(cherry picked from commit 802c78f5194e4524faa30ea57adbf00f28fc72c6)
(cherry picked from commit b1bb6934bb8774dd96be76d88e6824e49b613549)
Needed by a follow-up patch, so that channels can be sorted properly.
This change does not affect the behavior of any subsystem.
While here, change to an enum.
Sponsored by: The FreeBSD Foundation
MFC after: 2 days
Reviewed by: dev_submerge.ch, markj
Differential Revision: https://reviews.freebsd.org/D47198
(cherry picked from commit a4111e9dc7225618fa8d2af64d866cf0b0aebd56)
DSP_REGISTERED calls PCM_REGISTERED, and already contains all the checks
we are doing.
No functional change intended.
Sponsored by: The FreeBSD Foundation
MFC after: 2 days
Reviewed by: dev_submerge.ch, markj
Differential Revision: https://reviews.freebsd.org/D47196
(cherry picked from commit bb5e3ac1a7b71480a50fc0c813c916a3d058336c)
DSP_REGISTERED first checks if the softc is not null, through
PCM_REGISTERED, which in turn calls PCM_ALIVE, whereas PCM_DETACHING
accesses the softc flags directly.
Sponsored by: The FreeBSD Foundation
MFC after: 2 days
Reviewed by: dev_submerge.ch, markj, emaste
Differential Revision: https://reviews.freebsd.org/D47195
(cherry picked from commit 9693241188aa6882166b091d9006f9d0affeda7e)
Both conditions are the same, so the second one is unreachable.
PR: 229550
Sponsored by: The FreeBSD Foundation
MFC after: 2 days
Reviewed by: andreast, markj
Differential Revision: https://reviews.freebsd.org/D47167
(cherry picked from commit 6f96ef84b359137a51dc1e717887ca7d31ba7bad)
No functional change intended.
Sponsored by: The FreeBSD Foundation
MFC after: 2 days
Reviewed by: markj, emaste
Differential Revision: https://reviews.freebsd.org/D47152
(cherry picked from commit de009cf68ba68aa5823be3d6afeebb49a15b1251)
These malloc(9) calls are in contexts where sleeping is permitted.
Sponsored by: The FreeBSD Foundation
MFC after: 2 days
Reviewed by: dev_submerge.ch, zlei, markj, emaste
Differential Revision: https://reviews.freebsd.org/D46845
(cherry picked from commit 5e33eca8e8f359d4d48f4c50334a03748420a7da)
The current channel naming convention is:
pcmX:[virtual_]play|record:dspX.[v]p|rY
- pcmX and dspX share the same unit numbers
- "[v]p|r" gives us the same information as "[virtual_]play|record"
Remove the redundant information, so that the channel names become more
readable: dspX.[virtual_]play|record.Y
Sponsored by: The FreeBSD Foundation
MFC after: 2 days
Reviewed by: dev_submerge.ch
Differential Revision: https://reviews.freebsd.org/D46836
(cherry picked from commit c30f531ddb629ab51359fb540c8ef6068bab288b)
Currently we create and destroy channels with the following consistent
pattern:
- chn_init() -> pcm_chn_add()
- pcm_chn_remove() -> chn_kill()
Instead of calling two separate functions, merge pcm_chn_add() with
chn_init(), and pcm_chn_remove() with chn_kill().
Another benefit of this change is that we avoid the confusion caused by
having pcm_chn_add(), as well as pcm_addchan().
Sponsored by: The FreeBSD Foundation
MFC after: 2 days
Reviewed by: dev_submerge.ch, markj
Differential Revision: https://reviews.freebsd.org/D46835
(cherry picked from commit 9263f854e9a63cc326a3d5f6331b933c4a010abf)
feeder_rate_min functions as the lower boundary.
Sponsored by: The FreeBSD Foundation
MFC after: 2 days
Reviewed by: dev_submerge.ch, markj, emaste
Differential Revision: https://reviews.freebsd.org/D46834
(cherry picked from commit f3092614bcae949332a8f21f7b78ba68b3ee5899)
Instead of checking the value of "ret" multiple times, just set a goto
label and jump there immediately in case of an error.
While here, remove a redundant assignment to "d".
Sponsored by: The FreeBSD Foundation
MFC after: 2 days
Reviewed by: dev_submerge.ch, markj, emaste
Differential Revision: https://reviews.freebsd.org/D46833
(cherry picked from commit 3cab66d12d439357b948093756ca1af87967c8cc)
No longer used.
Sponsored by: The FreeBSD Foundation
MFC after: 2 days
Reviewed by: dev_submerge.ch
Differential Revision: https://reviews.freebsd.org/D46522
(cherry picked from commit 248aced26eee6f569717618d097bc2205a93c800)
If we do not enter dummy_chan_trigger() before detaching, we'll get a
use-after-free since the callout(9) callback might be called after
having been detached.
Sponsored by: The FreeBSD Foundation
MFC after: 2 days
Reviewed by: dev_submerge.ch, markj, emaste
Differential Revision: https://reviews.freebsd.org/D46715
(cherry picked from commit e42c8267821952407d4f4064026058aeaaa741ac)
feeder_register() is currently a SYSINIT in order to create the root
feeder, which happens only when feedercnt is 0. Separating the root
feeder registration makes the code more readable.
No functional change intended.
While here, fix some style errors.
Sponsored by: The FreeBSD Foundation
MFC after: 2 days
Reviewed by: dev_submerge.ch, zlei, markj
Differential Revision: https://reviews.freebsd.org/D46821
(cherry picked from commit 97570db05ced435f4fb1c6a67bdb16966ce5e4d9)
There is no reason to initialize global variables in feeder_register(),
as these variables are unrelated to what the function does. Instead,
initialize them during sound(4) load.
Sponsored by: The FreeBSD Foundation
MFC after: 2 days
Reviewed by: zlei
Differential Revision: https://reviews.freebsd.org/D46749
(cherry picked from commit 0a0301deb5b6a9c66829dd20cff9d40c5ba9ad92)
Sponsored by: The FreeBSD Foundation
MFC after: 2 days
Reviewed by: emaste
Differential Revision: https://reviews.freebsd.org/D46856
(cherry picked from commit 41ff4177614562923a30e2541e2a15883a4ce32c)
Currently it is possible to assign a unit number that already exists.
Suppose the following channel list:
[vp2]
If we create 3 channels, we'll end up with the following list:
[vp0, vp1, vp2, vp2]
This happens because chn_init() does not check if the unit number we are
assigning already exists. While fixing this is trivial when the channel
list is sorted in ascending order, it is way more involved when sorted
in descending order. Even though sorting the list in descending order
would require deliberately modifying pcm_chn_add(), and is most likely
not going to happen, make the mechanism more robust by using a unr(9)
allocator for each channel type.
Sponsored by: The FreeBSD Foundation
MFC after: 2 days
Reviewed by: dev_submerge.ch
Differential Revision: https://reviews.freebsd.org/D46680
(cherry picked from commit ad4c8671bddaa30bf0413089c74dde6a618d9021)
Refactor CHN_INSERT_SORT() to also take into account the unit number of
each channel, while still prioritizing the type, to make the channel
list easier to work with.
Sponsored by: The FreeBSD Foundation
MFC after: 2 days
Reviewed by: dev_submerge.ch
Differential Revision: https://reviews.freebsd.org/D46549
(cherry picked from commit 142aca25b07c9a7067d8040ea98812c54b253bbf)
Simplify logic to execute the following algorithm:
1. Search for a free (i.e not busy) channel and return successfully.
2. If no channel was found, either return an ENOTSUP if no VCHAN can be
created (disabled or we reached the limit), or create one more VCHAN
and scan for it again.
3. If the second scan failed again, return EBUSY.
This patch also solves a bug where we'd end up in an infinite loop,
calling vchan_setnew() with the same `newcnt` value indefinitely, after
the following scenario:
1. Plug device.
2. Spawn X channels.
3. Kill all channels except _last_ opened.
4. Clean up all unused VCHANs.
5. Spawn X+1 channels.
6. Infinite loop in pcm_chnalloc().
I am not exactly sure which part of pcm_chnalloc() caused this bug, but
the patch fixes it at least...
Sponsored by: The FreeBSD Foundation
MFC after: 2 days
Reviewed by: dev_submerge.ch
Differential Revision: https://reviews.freebsd.org/D46548
(cherry picked from commit b973a14d354f332a3428cbab8e9d4b72cb3e2d6e)
The VCHAN count is checked in vchan_setnew(), and there is no reason to
cap the hardware channels in the first place.
This is part of a series of follow-up patches.
Sponsored by: The FreeBSD Foundation
MFC after: 2 days
Reviewed by: dev_submerge.ch
Differential Revision: https://reviews.freebsd.org/D46521
(cherry picked from commit de8ee333388bf5e551e697b08823b3a6c262f609)
This check is not really useful, and can in fact break things, if
sysctl_dev_pcm_vchans() calls vchan_setnew() with a value that will not
satisfy the KASSERT condition.
Sponsored by: The FreeBSD Foundation
MFC after: 2 days
Reviewed by: dev_submerge.ch, emaste
Differential Revision: https://reviews.freebsd.org/D46545
(cherry picked from commit 998de46c51452b046ecd9ba8ed592dd7c4f79f51)
Reviewed by: emaste
Fixes: 35e492f3bd ("Update list of Conexant and Realtek codecs.")
Differential Revision: https://reviews.freebsd.org/D45965
(cherry picked from commit 4004e1752ec7992eeace7f0318d2ca3fc7ba9e03)
- Use snd_afmt2str() to display format conversions in feeder_format,
instead of the plain hex value.
- Simplify feeder_rate contents.
- Print "ch" (e.g 2.1ch) after matrix values in feeder_matrix.
- Use snd_afmt2str() instead of a plain hex for the the rest of the
feeder classes.
Sponsored by: The FreeBSD Foundation
MFC after: 2 days
Reviewed by: dev_submerge.ch
Differential Revision: https://reviews.freebsd.org/D46309
(cherry picked from commit 0864dfe6299b75e424b845c0d0e1a593da905ae3)
sndstat(4) falsely reports "hardware" as the starting point of
recording, and ending point of playback VCHANs. Recording VCHANs get
their input from the primary recording channel, and playback VCHANs send
their input to the primary playback channel.
Sponsored by: The FreeBSD Foundation
MFC after: 2 days
Reviewed by: dev_submerge.ch, markj
Differential Revision: https://reviews.freebsd.org/D46177
(cherry picked from commit b58d9db4d77a6f42ac7cf3cdb2af2443666033e2)
- Remove unnecessary CHN_[UN]LOCKs.
- Improve device_printf() messages.
- Remove redundant checks.
- Remove 0 assignments, since the channel is allocated with M_ZERO.
- Re-organize sections in a more coherent way.
- Remove "out1" label, just return NULL directly.
- Rename "out2" to "fail" and simplify logic.
- Do not check the return value of dsp_unit2name(), as it is guaranteed
not to fail (we pass a valid channel type).
Sponsored by: The FreeBSD Foundation
MFC after: 2 days
Reviewed by: dev_submerge.ch
Differential Revision: https://reviews.freebsd.org/D45985
(cherry picked from commit 5b209e153b58515c0315f5902e18ecd7d75ecd2a)
No functional change intended.
Sponsored by: The FreeBSD Foundation
MFC after: 2 days
Reviewed by: dev_submerge.ch, markj
Differential Revision: https://reviews.freebsd.org/D45984
(cherry picked from commit c55f995502cbaa2d38b7a7003bc27805b28a6a29)
In case chn_init() fails, we are leaking memory by not freeing the
feeder.
Sponsored by: The FreeBSD Foundation
MFC after: 2 days
Reviewed by: dev_submerge.ch, markj
Differential Revision: https://reviews.freebsd.org/D45979
(cherry picked from commit 16329b7b3276f09dc70bdd1ca8bc605546fe71e0)
Sponsored by: The FreeBSD Foundation
MFC after: 2 days
Reviewed by: dev_submerge.ch
Differential Revision: https://reviews.freebsd.org/D45967
(cherry picked from commit c15c9315b2cb7601cc337f7d5a8e124f4b2d5861)
Assignment taken from dsp_oss_engineinfo().
Sponsored by: The FreeBSD Foundation
MFC after: 2 days
Reviewed by: dev_submerge.ch
Differential Revision: https://reviews.freebsd.org/D46166
(cherry picked from commit bd5bcc848c5764229926ad27a4bd77af4f87d189)
Sponsored by: The FreeBSD Foundation
MFC after: 2 days
Reviewed by: dev_submerge.ch
Differential Revision: https://reviews.freebsd.org/D46164
(cherry picked from commit a6283717577066b0ff6c62053145470ff4134051)
Sponsored by: The FreeBSD Foundation
MFC after: 2 days
Reviewed by: dev_submerge.ch
Differential Revision: https://reviews.freebsd.org/D46163
(cherry picked from commit 810530aa2648812860e84d951d9cf96dfd24e595)
At least for HDSPe RayDAT cards, newer firmware comes with RME's own PCI
vendor id instead of the Xilinx one. Other HDSPe cards are probably also
affected. Update snd_hdspe(4) to recognize both the old Xilinx and the
new RME vendor ids.
Differential Revision: https://reviews.freebsd.org/D44978
MFC after: 1 day
(cherry picked from commit 9718d4ab99386918f5b5c207c58289eaade20623)
In sndstat_build_sound4_nvlist(), if we have INVARIANTS or
SND_DIAGNOSTIC enabled, we will hit a lock assertion panic when we call
CHN_GETVOLUME(). Also lock the channel in the sndstat_prepare_pcm() loop
for good measure.
Fixes: bbca3a75bb41 ("sound: Include sound(4) channel information in sndstat nvlist")
Sponsored by: The FreeBSD Foundation
MFC after: 2 days
Reviewed by: dev_submerge.ch
Differential Revision: https://reviews.freebsd.org/D45898
(cherry picked from commit e850bd36dfda98608432d2459800627d16119fec)
If the channel list is empty, min_rate and min_channels will be INT_MAX.
Instead, assign them to 0, like we do in sndstat_get_caps().
Sponsored by: The FreeBSD Foundation
MFC after: 2 days
Reviewed by: dev_submerge.ch
Differential Revision: https://reviews.freebsd.org/D45876
(cherry picked from commit 1a768ea9db3d66941b0dc5340ac028ef548808b8)
The current implementation of sndstat_get_caps() does not work properly
when VCHANs are enabled, as it skips all information about physical
channels, and also assigns the min/max rates and channels to same
values, which is usually not the case. A device either supports any
sample rate within the [feeder_rate_min, feeder_rate_max] range, or
[hw_rate_min, hw_rate_max] range when the device is opened in exclusive
or bitperfect mode. The number of channels can also vary and is not
always the same for both min and max.
Refactor the whole function to resemble the way we handle fetching of
these values in dsp_oss_audioinfo() and dsp_oss_engineinfo().
Sponsored by: The FreeBSD Foundation
MFC after: 2 days
Reviewed by: dev_submerge.ch
Differential Revision: https://reviews.freebsd.org/D45872
(cherry picked from commit 9d8b93bc9ccea82b648ffa9354200c9e4d3f211b)
Since we allow feeding of any rate within the [feeder_rate_min,
feeder_rate_max] range, report this as the min/max rate as well. Only
exceptions are when we the device is opened in exclusive or bitperfect
mode.
Sponsored by: The FreeBSD Foundation
MFC after: 2 days
Reviewed by: dev_submerge.ch
Differential Revision: https://reviews.freebsd.org/D45862
(cherry picked from commit 86585210fd5657542884b22eb52b21e960b7be6c)
midistat_lock is used outside midi/midi.c as well, so implement lock,
unlock and lockassert functions in order not to expose the lock in the
header file.
Sponsored by: The FreeBSD Foundation
MFC after: 2 days
Reviewed by: emaste
Differential Revision: https://reviews.freebsd.org/D45857
(cherry picked from commit 2d6fc24673ccc97020c94094f97ee015f1db9702)
