Date: Thu, 7 Jul 2005 06:46:03 +0800 From: Ariff Abdullah <skywizard@MyBSD.org.my> To: freebsd-multimedia@freebsd.org Cc: mat@cnd.mcgill.ca Subject: Massive sound changes / fix (24/32bit pcm support, new sampling rate converter, various fixes) Message-ID: <20050707064603.6c295451.skywizard@MyBSD.org.my>
next in thread | raw e-mail | index | archive | help
After sometimes, I've decided to release this (massive 4k lines) diff to our sound driver. This need proper review and confirmation, before it can be committed. Patches for both HEAD / RELENG_5 available at: http://staff.mybsd.org.my/skywizard/FreeBSD/sound/ (Note the snd_RELTAG*.diff) Whats New ========= 1. Support wide range sampling rate as low as 1hz up to int32 max (which is, insane) through new feeder_rate, multiple precisions choice (32/64 bit converter). This is indeed, quite insane, but it does give us more room and flexibility. 2. Support 24/32 bit pcm format conversion through new, much improved feeder_fmt. System wide changes =================== 1. sys/soundcard.h * Add definition for AFMT_(U|S)24_(B|L)E. This is somehow contradict with OSS/Voxware definition of 24bit, but anyway... General sound infrastructure changes ==================================== 1. ac97.c * Slightly new method to detect mixer capabilities and resolution. This mostly to help CT4730, but apparently it does help other cards too (especially via8233x). This probably need futher test and confirmation from other people with ac97 cards other than via / es137x. * Aggresive dac power wake up call, again, to help CT4730 (and probably others). 2. mixer.c / sound.c (high priority / grave severity) * Fix super grave serious (call it whatever) panic/death during driver unload on second attempt after failure on first (device busy). 3. buffer.c / dsp.c / sound.h * Support for 24/32 AFMT 4. feeder_rate.c * New implementation of sampling rate conversion with 32/64 bit precision, 1 - int32max hz (which is, ridiculous, yet very addictive). Much improved / smarter buffer management to not cause any missing samples at the end of conversion process * Tunable sysctls for various aspect: hw.snd.feeder_rate_ratemin - minimum allowable sampling rate (default to 4000) hw.snd.feeder_rate_ratemax - maximum allowable sampling rate (default to 1102500) hw.snd.feeder_rate_buffersize - conversion buffer size (default to 8192) hw.snd.feeder_rate_scaling - scaling / conversion method (please refer to the source for explaination). Default to previous implementation type. 5. feeder_fmt.c / sound.h * New implementation, support for 24/32bit conversion, optimized, and simplified. Few routines has been removed (8 to xlaw, 16 to 8). It just doesn't make sense. 6. channel.c * Support for 24/32 AFMT * Fix wrong xruns increment, causing incorrect underruns statistic while using vchans. 7. vchan.c (high priority) * Support for 24/32 AFMT * Proper speed / rate detection especially for fixed rate ac97. User can override it using kernel hint: hint.pcm.<unit>.vchanrate="xxxx". Hardware spessific changes ========================== 1. als4000.c * als4000 can't do 48k properly (perhaps it really can't at all!). Set maxspeed to 44.1k instead. * Add locking / MPSAFE * Fix recording 2. cmi.c * remove busdma_lock_mutex and Giant from bus_dma_tag_create. Nothing changes. 3. es137x.c / es137x.h * Register programming error during device initialization especially for CT4730 / EV1938 chip, causing misconfigured mixer (David Xu), crippled after power cycle (Kevin Oberman). Fixed. * Incorporate locking/spdif patches from Jon Noack. Not all es137x can really do spdif, clean it up a bit to only let few capable chip. * Convert all bus_space_(read|write) to use es_rd/es_wr, simmilar with other drivers. * Add tunable hw.snd.pcm<unit>.latency_timer sysctl to toggle pci latency timer value on the fly. Much noise / pop / crackling issues can be solved by increasing its value. Other people can point out to use pciconf instead, but this is just and added value specifically for braindead CT4730/EV1938. 4. via8233.c * Add locking / MPSAFE * Add kernel hint option to disable DXS channels entirely. Report from several skype users / Pav Lucistnik indicate that disabling DXS fix lots of pop / crackling noise. To disable DXS, add hint.pcm.<unit>.via_dxs_disabled="1" into /boot/device.hints. NOTE: It is advisable to disable DXS entirely. Although DXS can provide multiple concurrent access, doing so will cause more harm than good (pop / crackling noise, sudden slowness, overruns). There are few cases where this is considered invalid, but I had to investigate more as this is not a global issue. Use / enable vchans for multiple sound sources (Please refer to vchans notes below). 5. via82c686.c * Add locking / MPSAFE. I don't have this card, so other people had to confirm it. Anyway, the logic is correct. Notes / Issues ============== * Virtual Channels (vchans) Enabling vchans can really, really help to solve overruns issue. This is quite understandable, because it operate entirely within its own buffering system without relying on hardware interrupt / state. Even if you don't need vchan, just enable single channel can help much. * Feeder alignment is really a monster on its own, this should be fixed or revamp in near future. * Mixer infrastructure is really outdated, without support for proper multichannel. Best candidate for hacking fest. * The arrival of 24/32 also come with a price. Applications that can do 24/32bit playback need to be recompiled (notably mplayer). Use (recompiled) mplayer to experiment / test / debug this various format using -af format=fmt. Note that 24bit seeking in mplayer is a little bit broken, sometimes can cause silence or loud static noise. Pausing / seeking few times can solve this problem. You don't have to rebuild world entirely for this. Simply copy /usr/src/sys/sys/soundcard.h to /usr/include/sys/soundcard.h would suffice. Few drivers also need recompilation, and this can be done via /usr/src/sys/modules/sound/. Support for 24bit hardware playback is beyond the scope of this changes. That would require spessific hardware driver changes and currently I don't have any of it. * Don't expect playing 9999999999hz is a wise decision. Be reasonable. The new feeder_rate implemention provide flexibility, not insanity. You can easily chewed up your CPU with this kind of mind instability. Please use proper mosquite repellent device for this obvious cracked brain attempt. As for testing purposes, you can use (again) mplayer to generate / play with different sampling rate. Use something like mplayer -af resample=192000:0:0 files.. -- Ariff Abdullah MyBSD http://www.MyBSD.org.my (IPv6/IPv4) http://staff.MyBSD.org.my (IPv6/IPv4) http://tomoyo.MyBSD.org.my (IPv6/IPv4)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050707064603.6c295451.skywizard>