Date: Thu, 31 May 2007 18:43:33 +0000 (UTC) From: Ariff Abdullah <ariff@FreeBSD.org> To: src-committers@FreeBSD.org, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org Subject: cvs commit: src/sys/conf files src/sys/dev/sound/pcm buffer.c channel.c channel.h dsp.c dsp.h feeder.c mixer.c sndstat.c sound.c sound.h vchan.c vchan.h src/sys/dev/sound/usb uaudio.c src/sys/modules/sound/sound Makefile Message-ID: <200705311843.l4VIhXUO065757@repoman.freebsd.org>
next in thread | raw e-mail | index | archive | help
ariff 2007-05-31 18:43:33 UTC
FreeBSD src repository
Modified files:
sys/conf files
sys/dev/sound/pcm buffer.c channel.c channel.h dsp.c dsp.h
feeder.c mixer.c sndstat.c sound.c
sound.h vchan.c vchan.h
sys/dev/sound/usb uaudio.c
sys/modules/sound/sound Makefile
Log:
Last major commit and updates for RELENG_7:
- Rework the entire pcm_channel structure:
* Remove rarely used link placeholder, instead, make each pcm_channel
as head/link of each own/each other. Unlock - Lock sequence due to
sleep malloc has been reduced.
* Implement "busy" queue which will contain list of busy/active
channels. This greatly reduce locking contention for example while
servicing interrupt for hardware with many channels or when virtual
channels reach its 256 peak channels.
- So I heard you like v chan ... O RLY?
Welcome to Virtual **Record** Channels (vrec, rec vchans, vchans for
recording, Rec-Chan, you decide), the ultimate solutions for your
nagging O_RDWR full-duplex wannabe (note: flash plugins) monopolizing
single record channel causing EBUSY. Vrec works exactly like Vchans
(or, should I rename it to "Vplay" :) , except that it operates on the
opposite direction (recording). Up to 256 vrecs (like vchans) are
possible.
Notes:
* Relocate dev.pcm.%d.{vchans,vchanformat,vchanrate} to each of its
respective node/direction:
dev.pcm.%d.play.* for "play" (cdev = dsp%d.vp%d)
dev.pcm.%d.rec.* for "record" (cdev = dsp%d.vr%d)
* Don't expect that it will magically give you ability to split
"recording source" (eg: 1 channel for cdrom, 1 channel for mic,
etc). Just admit that you only have a *single* recording source /
channel. Please bug your hardware vendor instead :)
- Bump maxautovchans from 4 to 16. For a full-fledged multimedia
desktop/workstation with too many soundservers installed (esound,
artsd, jackd, pulse/polypaudio, ding-dong pling plong mudkip fuh fuh,
etc), 4 seems inadequate. There will be no memory penalty here, since
virtual channels are allocate only by demand.
- Nuke/Rework the entire statically created cdev entries. Everything is
clonable through snd own clone manager which designed to withstand many
kind of abusive devfs droids such as:
* while : ; do /bin/test -e /dev/dsp ; done
* jot 16777216 0 | while read x ; do ls /dev/dsp0.$x ; done
* hundreds (could be thousands) concurrent threads/process opening
"/dev/dsp" (previously, this might result EBUSY even with just
3 contesting threads/procs).
o Reusable clone objects (instead of creating new one like there's no
tomorrow) after certain expiration deadline. The clone allocator will
decide whether to reuse, share, or creating new clone.
o Automatic garbage collector.
- Dynamic unit magic allocator. Maximum attached soundcards can be tuned
using tunable "hw.snd.maxunit" (Default to 512). Minimum is 16, and
maximum is 2048.
- ..other fixes, mostly related to concurrency issues.
joel@ will do the manpage updates on sound(4).
Have fun.
Revision Changes Path
1.1212 +2 -0 src/sys/conf/files
1.35 +3 -3 src/sys/dev/sound/pcm/buffer.c
1.118 +108 -35 src/sys/dev/sound/pcm/channel.c
1.35 +85 -10 src/sys/dev/sound/pcm/channel.h
1.103 +459 -187 src/sys/dev/sound/pcm/dsp.c
1.12 +1 -0 src/sys/dev/sound/pcm/dsp.h
1.41 +5 -3 src/sys/dev/sound/pcm/feeder.c
1.59 +42 -25 src/sys/dev/sound/pcm/mixer.c
1.26 +79 -33 src/sys/dev/sound/pcm/sndstat.c
1.113 +596 -422 src/sys/dev/sound/pcm/sound.c
1.77 +45 -39 src/sys/dev/sound/pcm/sound.h
1.32 +362 -268 src/sys/dev/sound/pcm/vchan.c
1.5 +20 -1 src/sys/dev/sound/pcm/vchan.h
1.29 +5 -18 src/sys/dev/sound/usb/uaudio.c
1.21 +3 -2 src/sys/modules/sound/sound/Makefile
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200705311843.l4VIhXUO065757>