Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 9 Jul 2005 10:24:57 +0200
From:      sebastian ssmoller <sebastian.ssmoller@gmx.net>
To:        freebsd-multimedia@freebsd.org
Subject:   Re: Massive sound changes / fix (24/32bit pcm support, new sampling rate converter, various fixes)
Message-ID:  <20050709102457.49fe7443.sebastian.ssmoller@gmx.net>

next in thread | raw e-mail | index | archive | help
hi,
i just wonna say: THX! really GREAT work! ... this improves sound
quality on my boxes much !!   ;-)

THX,
regards,
seb

> 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?20050709102457.49fe7443.sebastian.ssmoller>