aboutsummaryrefslogtreecommitdiff
path: root/sys/dev/sound
Commit message (Collapse)AuthorAgeFilesLines
* bus_alloc_resource: Pass rid by value to BUS_ALLOC_RESOURCE DEVMETHODJohn Baldwin3 days2-6/+6
| | | | | | | | | The wrapper functions such as bus_alloc_resource_any() still support passing the rid by value or pointer, but the underlying implementation now passes by value. Reviewed by: imp Differential Revision: https://reviews.freebsd.org/D53402
* sound: Retire snd_mixer->busyChristos Margiolis14 days3-35/+1
| | | | | | | | | | | | | | | | | Does not really serve any real purpose. It gets set on mixer_open() and unset on mixer_close(), so it essentially tells us whether the mixer is open or not. mixer_close() uses it to return EBADF in case the mixer is not busied, as in, the mixer has not been open()'d yet. This is redundant. The other place where this is used is to decide whether to serve an ioctl issued by userland, in which case it won't if, again, the mixer has not been busied (i.e., opened). Again, seems redundant. Sponsored by: The FreeBSD Foundation MFC after: 1 week Reviewed by: markj Differential Revision: https://reviews.freebsd.org/D53859
* sound: Fix revents in midi_poll()Nicolas Provost2025-11-241-11/+9
| | | | | | | Sponsored by: The FreeBSD Foundation MFC after: 1 week Reviewed by: christos Pull Request: https://github.com/freebsd/freebsd-src/pull/1887
* Revert "sound: Merge chn_intr() with chn_intr_locked()"Christos Margiolis2025-11-232-2/+19
| | | | | | | | | It turns out that snd_uaudio(4) uses sound(4)'s channel lock for its USB transfer callbacks. I will try to address this at some point, because this is layering violation, but for now we need to revert the commit, as it causes a lock recursion panic with USB audio devices. This reverts commit e254ef87a30bfcaabc6e4d8e0ecf05f6949a4f06.
* sound: Retire snd_mtx* wrappersChristos Margiolis2025-11-2134-556/+512
| | | | | | | | | | | | Do not create mutexes with snd_mtxcreate(). It doesn't provide any value, plus it first allocates the mutex with malloc(9). Allocate mutexes in the stack and use mtx_* functions directly instead of the snd_mtx* wrappers. Sponsored by: The FreeBSD Foundation MFC after: 1 week Reviewed by: kib, markj Differential Revision: https://reviews.freebsd.org/D53855
* sound: Merge chn_intr() with chn_intr_locked()Christos Margiolis2025-11-212-19/+2
| | | | | | | | | | | | There is no scenario where chn_intr() is called with the channel lock already held. No functional change intended. Sponsored by: The FreeBSD Foundation MFC after: 1 week Reviewed by: kib, markj Differential Revision: https://reviews.freebsd.org/D53854
* sound: Merge PCM_ALIVE() with PCM_REGISTERED()Christos Margiolis2025-11-212-3/+3
| | | | | | | | | PCM_ALIVE() is used only in pcm_unregister(), but it does not hurt to use PCM_REGISTERED(), which uses PCM_ALIVE() internally. In fact, it's more robust this way. Sponsored by: The FreeBSD Foundation MFC after: 1 week
* sound: Clean up midi/ includesChristos Margiolis2025-11-212-23/+11
| | | | | | Sponsored by: The FreeBSD Foundation MFC after: 1 week Differential Revision: https://reviews.freebsd.org/D53841
* sound: Simplify logic in dsp_io_ops()Christos Margiolis2025-11-211-22/+10
| | | | | | | | | | | | | | | | | | | | | | Use CHN_LOCK()/CHN_UNLOCK() directly, instead of dsp_lock_chans()/dsp_unlock_chans(). These functions are useful when we want to potentially lock both channels. Here we know which channel we are locking, so we can just lock it directly. This way we get rid of the prio variable as well. Related to runpid again, there is no reason to assign it when CHN_F_RUNNING is not set. channel->pid (as well as channel->comm) is always assigned in dsp_chn_alloc(). Get rid of runpid. I do not see how we can end up with channel->pid (td->td_proc->p_pid) not matching buf->uio_td->td_proc->p_pid. Also improve errno values. Sponsored by: The FreeBSD Foundation MFC after: 1 week Reviewed by: markj Differential Revision: https://reviews.freebsd.org/D53736
* sound: Remove vchan_passthrough() and hw.snd.passthrough_verboseChristos Margiolis2025-11-202-23/+0
| | | | | | | Unused and confusing. Sponsored by: The FreeBSD Foundation MFC after: 1 week
* sound: Fix KASSERT panics in chn_read() and chn_write()Christos Margiolis2025-11-201-48/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | INVARIANTS kernels may trigger a KASSERT panic from sndbuf_acquire(), when fuzzing write(2) using stress2, because of a race in chn_write(). In the case of chn_write(), what sndbuf_acquire() does is extend the ready-to-read area of the buffer by a specified amount of bytes. The KASSERT in question makes sure the number of bytes we want to extend the ready area by, is less than or equal to the number of free bytes in the buffer. This makes sense, because we cannot extend the ready area to something larger than what is available (i.e., free) in the first place. What chn_write() currently does for every write is; calculate the appropriate write size, let's say X, unlock the channel, uiomove() X bytes to the channel's buffer, lock the channel, and call sndbuf_acquire() to extend the ready area by X bytes. The problem with this approach, however, is the following. Suppose an empty channel buffer with a length of 1024 bytes, and 2 threads, (A) and (B), where (B) is a higher-priority one. Suppose thread (A) wants to write 1024 bytes. It unlocks the channel and uiomove()s 1024 bytes to the channel buffer. At the same time, thread (B) picks up the lock, and because it is higher priority, it keeps dominating the lock for a few iterations. By the time thread (A) picks up the lock again, it tries to call sndbuf_acquire() with a size of 1024 bytes, which was calculated before it performed the uiomove(). In this case, there is a very high chance that the buffer will not be empty, that is, have a free area of 1024 bytes, as was the case when thread (A) started executing, and so the KASSERT will trigger a panic because the condition (bytes <= free) is not met. Another scenario that can trigger a panic is the following: suppose a buffer with a size of 4 bytes, and two threads: (A) and (B). In the first iteration, thread (A) wants to write 2 bytes, while the buffer is empty, BUT the pointer (sndbuf_getfreeptr()) is at the end (i.e., buf[3]). In the first iteration of the loop, because of the way we calculate t, we'll end up writing only 1 byte, so after sz -= t, sz will be 1, and so we'll need one more iteration in the inner loop, to write the remaining 1 byte. Now we're at the end of the first loop, thread (A) unlocks the channel, it has written 1 byte, it needs to write 1 more, and the buffer is left with 3 empty slots. Now thread (B) picks up the lock, and it wants to write 3 (or more) bytes. Eventually it writes the 3 bytes, and it leaves the buffer with 0 free slots. By the time thread (A) picks up the lock again, and continues with the second iteration of the inner loop, it will try to write the last byte, but sndbuf_acquire() will panic because there is no free space anymore. To fix this, get rid of the inner loop and calculate the write size on each iteration. Also, call sndbuf_acquire() before unlocking the channel. In the scenarios explained above, we'll end up entering the chn_sleep() case. Modify it as well, so that we do not kill the channel if we need to sleep more. Do the same for chn_read() to avoid possible similar panics from sndbuf_dispose(). Reported by: pho Tested by: christos, pho Sponsored by: The FreeBSD Foundation MFC after: 1 week Reviewed by: pho, kib Differential Revision: https://reviews.freebsd.org/D53666
* snd_hda: Patch Lenovo V15Christos Margiolis2025-11-172-1/+3
| | | | | | | PR: 290496 Tested by: adrian Sponsored by: The FreeBSD Foundation MFC after: 1 week
* sound: Retire SND_DIAGNOSTIC PCM locking macrosChristos Margiolis2025-11-131-103/+0
| | | | | | | | | | Disabled by default, but also redundant, since most of the errors they catch will be caught anyway by WITNESS and the locking subsystem. Sponsored by: The FreeBSD Foundation MFC after: 1 week Reviewed by: kib Differential Revision: https://reviews.freebsd.org/D53735
* sound: Do not use double pointer in dsp_io_ops()Christos Margiolis2025-11-131-13/+13
| | | | | | | | | No reason to do so. Sponsored by: The FreeBSD Foundation MFC after: 1 week Reviewed by: kib Differential Revision: https://reviews.freebsd.org/D53734
* sound: Remove unnecessary uio checks in dsp_io_ops()Christos Margiolis2025-11-131-7/+0
| | | | | | | | | uiomove_faultflag() takes care of that already. Sponsored by: The FreeBSD Foundation MFC after: 1 week Reviewed by: kib Differential Revision: https://reviews.freebsd.org/D53733
* sound: Retire OLDPCM_IOCTLChristos Margiolis2025-11-131-15/+0
| | | | | | | | | | | It is defined by default, and there is no reason to have a switch for it. While here, also get rid of some unnecessary comments and ioctl definitions. No functional change intended. Sponsored by: The FreeBSD Foundation MFC after: 1 week
* sound: Move mixer->modify_counter to more appropriate placeChristos Margiolis2025-11-131-5/+5
| | | | | | | No functional change intended. Sponsored by: The FreeBSD Foundation MFC after: 1 week
* sound: Retire unused mixer functionsChristos Margiolis2025-11-132-47/+0
| | | | | | | No functional change intended. Sponsored by: The FreeBSD Foundation MFC after: 1 week
* sound: Remove dead midi codeChristos Margiolis2025-11-131-123/+14
| | | | | Sponsored by: The FreeBSD Foundation MFC after: 1 week
* sound: Remove KOBJMETHOD_END re-definitionsChristos Margiolis2025-11-123-12/+0
| | | | | | | | | No functional change intended. Sponsored by: The FreeBSD Foundation MFC after: 1 week Reviewed by: markj, emaste Differential Revision: https://reviews.freebsd.org/D53696
* sound: Retire unused SCF_SYNTHChristos Margiolis2025-11-111-1/+0
| | | | | Sponsored by: The FreeBSD Foundation MFC after: 1 week
* sound: Retire DSP_DEFAULT_SPEEDChristos Margiolis2025-11-117-9/+7
| | | | | | | | | | | Only a few drivers use this, but this is not really our "default" speed. And even those drivers most likely override that value at some point once CHANNEL_SETSPEED() has been called. Sponsored by: The FreeBSD Foundation MFC after: 1 week Reviewed by: markj Differential Revision: https://reviews.freebsd.org/D53562
* sound: Retire feeder_register_root()Christos Margiolis2025-11-111-16/+2
| | | | | | | | | We can now use feeder_register(). Sponsored by: The FreeBSD Foundation MFC after: 1 week Reviewed by: markj Differential Revision: https://reviews.freebsd.org/D53560
* sound: Retire unused feeder_printchain()Christos Margiolis2025-11-112-17/+0
| | | | | | | | | We can print it with "sndctl feederchain". Sponsored by: The FreeBSD Foundation MFC after: 1 week Reviewed by: markj Differential Revision: https://reviews.freebsd.org/D53559
* sound: Remove unnecessary initializations in feeder_create()Christos Margiolis2025-11-111-10/+1
| | | | | | | | | | | We do not need to zero out fields since the struct is allocated with M_ZERO. Also we no longer need to have a special case for the root feeder. Sponsored by: The FreeBSD Foundation MFC after: 1 week Reviewed by: markj Differential Revision: https://reviews.freebsd.org/D53558
* sound: Retire pcm_feederdesc->typeChristos Margiolis2025-11-116-17/+10
| | | | | | | | | | | This is always accessed from pcm_feeder->desc->type. Instead of duplicating this field, we can remove it from pcm_feederdesc, and access it through pcm_feeder->class->type. Sponsored by: The FreeBSD Foundation MFC after: 1 week Reviewed by: markj Differential Revision: https://reviews.freebsd.org/D53557
* sound: Retire feeder_class->descChristos Margiolis2025-11-112-18/+18
| | | | | | | | | | | | | The only field we care about is pcm_feederdesc->type, so keep that one only and do not embed the whole pcm_feederdesc. While here, make the feeder type enum into a named one and use it as feeder_class->type's type. Sponsored by: The FreeBSD Foundation MFC after: 1 week Reviewed by: markj Differential Revision: https://reviews.freebsd.org/D53556
* sound: Retire feeder_class->dataChristos Margiolis2025-11-118-11/+8
| | | | | | | | | It's always NULL. No functional change intended. Sponsored by: The FreeBSD Foundation MFC after: 1 week Reviewed by: markj Differential Revision: https://reviews.freebsd.org/D53555
* sound: Retire feedertab_entryChristos Margiolis2025-11-112-28/+10
| | | | | | | | | | Have an SLIST of feeder_class directly. This way we simplify the code, and also avoid the additional malloc()/free() for each entry. Sponsored by: The FreeBSD Foundation MFC after: 1 week Reviewed by: markj Differential Revision: https://reviews.freebsd.org/D53554
* sound: Simplify feeder_getclass()Christos Margiolis2025-11-114-28/+16
| | | | | | | | | | | | | With the parameters we provide feeder_getclass(), the only thing we really care about is the feeder's class type. We can simplify (and make the code more readable) that by simply passing the type to feeder_getclass(). Apart from being simpler, we can now also retire feedertab_entry->desc and cmpdesc(). Sponsored by: The FreeBSD Foundation MFC after: 1 week Reviewed by: markj Differential Revision: https://reviews.freebsd.org/D53553
* sound: Retire unused pcm_feederdesc->flagsChristos Margiolis2025-11-113-11/+2
| | | | | | | Sponsored by: The FreeBSD Foundation MFC after: 1 week Reviewed by: markj Differential Revision: https://reviews.freebsd.org/D53552
* sound: Simplify pcm_feederdesc initializationChristos Margiolis2025-11-118-55/+16
| | | | | | | | | | | | | | | | | Currently we initialize a pcm_feederdesc array for every feeder, which is then used by FEEDER_DECLARE(). However, there is no reason for this to be an array, as each feeder has only one description. Additionally, since the only thing we define in that array is the feeder type, remove the pcm_feederdesc definitions altogether, and instead pass their type to FEEDER_DECLARE() directly, which will then initialize the pcm_feederdesc. This also simplifies feeder_register(). Sponsored by: The FreeBSD Foundation MFC after: 1 week Reviewed by: markj Differential Revision: https://reviews.freebsd.org/D53551
* sound: Remove unnecessary pcm/vchan.h include from pcm/feeder.cChristos Margiolis2025-11-111-1/+0
| | | | | | | Sponsored by: The FreeBSD Foundation MFC after: 1 week Reviewed by: markj Differential Revision: https://reviews.freebsd.org/D53550
* sound: Retire MAXFEEDERS and feedercntChristos Margiolis2025-11-111-11/+1
| | | | | | | | | | | Apart from the fact that it's unrealistic to reach MAXFEEDERS (256), since sound(4) comes with maximum 7 feeders (including feeder_root), there is also no reason to cap it. Sponsored by: The FreeBSD Foundation MFC after: 1 week Reviewed by: markj Differential Revision: https://reviews.freebsd.org/D53549
* sound: Retire unused {pcm_feederdesc,feedertab_entry}->idxChristos Margiolis2025-11-118-20/+13
| | | | | | | Sponsored by: The FreeBSD Foundation MFC after: 1 week Reviewed by: markj Differential Revision: https://reviews.freebsd.org/D53547
* sound: Add to pcm/buffer.* copyrightChristos Margiolis2025-11-112-0/+8
| | | | | Sponsored by: The FreeBSD Foundation MFC after: 1 week
* sound: Get rid of useless sndbuf getters and settersChristos Margiolis2025-11-1133-414/+252
| | | | | | | | No functional change intended. Sponsored by: The FreeBSD Foundation MFC after: 1 week Differential Revision: https://reviews.freebsd.org/D53528
* sound: Remove redundant sndbuf_free() in chn_kill()Christos Margiolis2025-11-111-2/+2
| | | | | | | | | | If b exists, it will get destroyed by sndbuf_destroy() (which calls sndbuf_free()) a few lines below, so the additional sndbuf_free() here is redundant. Sponsored by: The FreeBSD Foundation MFC after: 1 week Differential Revision: https://reviews.freebsd.org/D53527
* sound: Simplify sndbuf_clear() loopChristos Margiolis2025-11-111-8/+2
| | | | | | | Sponsored by: The FreeBSD Foundation MFC after: 1 week Reviewed by: markj Differential Revision: https://reviews.freebsd.org/D53526
* sound: Retire unused sndbuf_getflags() and sndbuf_setflags()Christos Margiolis2025-11-112-17/+0
| | | | | | | Sponsored by: The FreeBSD Foundation MFC after: 1 week Reviewed by: markj Differential Revision: https://reviews.freebsd.org/D53525
* sound: Retire unused sndbuf_dump()Christos Margiolis2025-11-112-22/+0
| | | | | | | | Fixes: e4e61333ffa4e90360de2dd1e4e0146f7cbf0afb Sponsored by: The FreeBSD Foundation MFC after: 1 week Reviewed by: markj, emaste Differential Revision: https://reviews.freebsd.org/D53522
* sound: Define SNDBUF_F_MANAGED as 0x00000001Christos Margiolis2025-11-111-1/+1
| | | | | | | | | | | It's the only flag anyway. No functional change intended. Sponsored by: The FreeBSD Foundation MFC after: 1 week Reviewed by: markj, emaste Differential Revision: https://reviews.freebsd.org/D53521
* sound: Re-arrange sndbuf_create() argumentsChristos Margiolis2025-11-113-5/+5
| | | | | | | | | | | | | Since we always use the channel name as the "drv" argument, we can just get rid of it and fetch it in sndbuf_create(). Also, put the "channel" argument first, as it is more intuitive. No functional change intended. Sponsored by: The FreeBSD Foundation MFC after: 1 week Reviewed by: markj Differential Revision: https://reviews.freebsd.org/D53520
* sound: Retire snd_dbuf->devChristos Margiolis2025-11-113-7/+5
| | | | | | | | | | Redundant, and if we at some point really need this, we can fetch it from snd_dbuf->channel->dev. Sponsored by: The FreeBSD Foundation MFC after: 1 week Reviewed by: markj Differential Revision: https://reviews.freebsd.org/D53519
* sound: Retire unused snd_dbuf->dirChristos Margiolis2025-11-111-1/+1
| | | | | | | Sponsored by: The FreeBSD Foundation MFC after: 1 week Reviewed by: markj Differential Revision: https://reviews.freebsd.org/D53518
* sound: Add kqueue supportChristos Margiolis2025-11-113-2/+90
| | | | | | | | Co-authored by: meka@tilda.center Sponsored by: The FreeBSD Foundation MFC after: 2 weeks Reviewed by: markj Differential Revision: https://reviews.freebsd.org/D53029
* sound: Clarify userland/vchan relationship in sndstat feeder chainChristos Margiolis2025-11-101-4/+8
| | | | | | | | | | | | | | | | | | | | | When vchans are enabled, the primary channels do not interact with userland, but with the vchans. With vchans enabled: $ sndctl feederchain dsp0.play.0.feederchain=[vchans -> [...] -> hardware] dsp0.record.0.feederchain=[hardware -> [...] -> vchans] With vchans disabled: $ sndctl feederchain dsp0.play.0.feederchain=[userland -> [...] -> hardware] dsp0.record.0.feederchain=[hardware -> [...] -> userland] Sponsored by: The FreeBSD Foundation MFC after: 1 week Differential Revision: https://reviews.freebsd.org/D53504
* snd_dummy: Round channel pointer after each writeChristos Margiolis2025-10-271-2/+3
| | | | | | | | Otherwise we go out of bounds and keep incrementing endlessly. Sponsored by: The FreeBSD Foundation MFC after: 4 days Differential Revision: https://reviews.freebsd.org/D53337
* sound: Improve dsp_cdevsw styleChristos Margiolis2025-10-221-9/+9
| | | | | Sponsored by: The FreeBSD Foundation MFC after: 4 days
* snd_dummy: Create device aliasChristos Margiolis2025-10-221-0/+6
| | | | | | | Sponsored by: The FreeBSD Foundation MFC after: 4 days Reviewed by: emaste, ziaee Differential Revision: https://reviews.freebsd.org/D53237
generated by cgit v1.2.3 (git 2.25.1) at 2025-12-12 09:58:58 +0000