execution should help us avoiding potential deadlock and illegal locking
while sleeping in various mixer -> usb calls. To enable it, use
hint.uaudio.%d.async="1" or sysctl dev.uaudio.%d.async=1. Default is
disable, to remain compatible with old behaviour (with slight risk of
potential deadlock).
on amd64 and i386) until we gain proper BUS_DMA_NOCACHE support.
(in progress).
Tested by: rafan, infofarmer, Nguyen Tam Chinh <unixvn@gmail.com>
Tested on: amd64, i386
- SWAPLR quirk for (unknown, luckily it is mine) broken uaudio stick.
Fixing by rewiring is impossible without damaging it. Luckily,
we can fix it using "other" methods :) .
- Add uaudio_get_vendor(), _product() and _release() in uaudio.c
(currently used by uaudio_pcm quirk).
- Implement CHANNEL_SETFRAGMENTS().
- Drop channel locking in few places where it is about to sleep
somewhere. This should help eliminating illegal locking acquisition
where the current thread is about to sleep, and also few deadlock
cases. Dropping it right here is quite safe since it is already
protected by CHN_F_BUSY flag and other threads won't bother to touch it.
Solving other illegal locking issues are quite tricky without converting
most usbd_do_request() calls to its equivalent _async() calls,
which I intend to do it later after getting full test report from
other people with different uaudio hardwares.
- Fix memory leak issues during detach. This seems common to any drivers
(notably emu10kx, csapcm?) with bridge functions.
Implement CHANNEL_SETFRAGMENTS() for snd_atiixp, snd_es137x, snd_hda
and snd_via8233. CHANNEL_SETBLOCKSIZE() will basically call
CHANNEL_SETFRAGMENTS() internally using conservative blocksize /
blockcount hints. Other drivers will be converted later.
- Disable stray buffer management, since sample size aligned buffering
are pretty much guaranteed through out the entire feeder_* chain
processes.
- Few style(9) cleanups.
channel.c/channel_if.m:
- Macros cleanups, prefer inlined min() over MIN().
- Rework chn_read()/chn_write() for better dead interrupt detection
policy. Reduce scheduling overhead by doing pure 5 seconds sleep
before giving up, instead of several cycle of brute micro sleeping.
- Avoid calling wakeup_one() for non-sleeping channel (for example,
vchan parent channel).
- EWOULDBLOCK -> EAGAIN.
- Fix possible divide-by-zero panic on chn_sync().
- Re-enforce ^2 blocksize policy, since there are too many broken
userland apps that blindly assume it without even trying to do
serious calculations.
- New channel method - CHANNEL_SETFRAGMENTS(), a refined version of
CHANNEL_SETBLOCKSIZE(). It accept _both_ blocksize and blockcount
arguments, so the driver internals will have better hints for
buffering and timing calculations.
- Hook FEEDER_SWAPLR into feederchain building process.
feeder_fmt.c:
- Unified version of various filters, avoiding duplications.
- malloc()less feeder_fmt. Informations can be retrieved dynamically
by doing table lookup on static data. For cases such as converting
from stereo to mono or reducing bit depth where input data is larger
than output, cycle remaining available free space until it has been
exhausted and start kicking 8 bytes reservoir space from there to
complete the remaining requested count.
- Introduce FEEDER_SWAPLR. Few super broken hardwares (found on several
extremely cheap uaudio stick, possibly others) mistakenly wired left
and right channels wrongly, screwing output or input.
- Rearrange FEEDER_* constants starting from 0 to 31, so the future
additions will be much easier and consistent.
- Introduce FEEDER_SWAPLR. Few super broken hardwares (found on several
extremely cheap uaudio stick, possibly others) mistakenly wired left
and right channels wrongly, screwing output or input.
malloc()less feeder_vchan. Informations can be retrieved dynamically
by doing table lookup on static data. Reduce mixing overhead by
doing direct copy on first channel. Mixing process will begin starting
from second channel onwards.
malloc()less feeder_volume. Informations can be retrieved dynamically
by doing table lookup on static data. Increase resolution from 6bit
to PCM_FXSHIFT (8bit) for better resolution and finer volume changes.
- Convert sx lock to plain mutex. Since the access of /dev/sndstat
is pretty much exclusive and protected by toggling sndstat_isopen,
plain mutex is more than enough.
- Enable SBUF_AUTOEXTEND to avoid buffer truncation.
cache coherency, besides of causing train wreck in other places
(especially on amd64, possibly on i386).
Discussed with: kib@, rafan@
Tested by: rafan@
confusions and panic provided that the following conditions are met:
1) WITNESS is enabled (watch/trace).
2) Using modules, instead of statically linked (Not a strict
requirement, but easier to reproduce this way).
3) 2 or more modules share the same mtx type ("sound softc").
- They might share the same name (strcmp() == 0), but it always
point to different address.
4) Repetitive kldunload/load on any module that shares the same mtx
type (Not a strict requirement, but easier to reproduce this way).
Consider module A and module B:
- From enroll() - subr_witness.c:
* Load module A. Everything seems fine right now.
wA-w_refcount == 1 ; wA-w_name = "sound softc"
* Load module B.
* w->w_name == description will always fail.
("sound softc" from A and B point to different address).
* wA->w_refcount > 0 && strcmp(description, wA->w_name) == 0
* enroll() will return wA instead of returning (possibly unique)
wB.
wA->w_refcount++ , == 2.
* Unload module A, mtx_destroy(), wA->w_name become invalid,
but wA->w_refcount-- become 1 instead of 0. wA will not be
removed from witness list.
* Some other places call mtx_init(), iterating witness list,
found wA, failed on wA->w_name == description
* wA->w_refcount > 0 && strcmp(description, wA->w_name)
* Panic on strcmp() since wA->w_name no longer point to valid
address.
Note that this could happened in other places as well, not just sound
(eg. consider lots of drivers that share simmilar MTX_NETWORK_LOCK).
Solutions (for sound case):
1) Provide unique mtx type string for each mutex creation (chosen)
or
2) Put "sound softc" global variable somewhere and use it.
their latest Compaq V3000 BIOS (revision F.22). As a result, analog CD
connectivity is gone to the oblivion. Even if they decide to fix it in
future revisions, the damage has been done.
excessive interrupt clock timer reset, screwing interrupt generation
for already active channels. Track moving DMA pointer and call buffer
interrupt on each blocksize boundary.
PR: kern/109791
MFC after: 3 days
(external) microphone pin tend to screw it. Internal microphone (found
on several laptops) still need high VRef.
Tested by: Pietro Cerutti <pietro.cerutti@gmail.com>
lenix <irc.freenode.net>
changes. This should ease the job of maintaining codebase since much
of the regression tests are done across os versions.
- bus_setup_intr() -> snd_setup_intr().
Use bus_get_dma_tag() to obtain the parent DMA tag to make the drivers
a little bit more non-ia32/amd64 friendly.
There is no man page for bus_get_dma_tag, so this is modelled after
rev. 1.62 of src/sys/dev/sound/pci/es137x.c by marius.
Inspired by: commit by marius
approval, change the copyright statement to point at him instead of
"FreeBSD, Inc".
Encouraged by: rwatson
Reviewed by: imp
Discussed with and approved by: orion
/usr/share/examples/etc/bsd-style-copyright. I've fixed a
few minor wording and formatting differences.
Approved by: luigi, Hannu Savolainen <hannu@opensound.com>
buffer resizing, etc.) that was here since eon. Free all (unmanaged)
allocated buffer through sndbuf_destroy() in case we forgot to call
sndbuf_free(). For a managed buffer (mostly hw specific managed buffer),
either provide CHANNEL_FREE() method with appropriate return value to
invoke semi-automatic sndbuf_free() or simply do it on their own. If
everything is failed, sndbuf_destroy() will come to the rescue as a
final measure.
MFC after: 3 days
/usr/share/examples/etc/bsd-style-copyright. I've fixed a
few minor wording and formatting differences.
Approved by: matk, Hannu Savolainen <hannu@opensound.com>
Reviewed by: imp
unsolicited pin sense event and need manual control to turn off speaker
volume while attaching headphone.
Tested by: Ingeborg Hellemo <Ingeborg.Hellemo@cc.uit.no>
Disable global Acer + ALC883 headphone automute settings since there are
few models that does not respect this and causing broken behaviour.
Reported/Tested by: Pavel Argentov <argentoff@rtelekom.ru>
sparc64 GENERIC and the sound device drivers known working on sparc64
to use bus_get_dma_tag() to obtain the parent DMA tag so we can get rid
of the sparc64_root_dma_tag kludge eventually. Except for ath(4), sk(4),
stge(4) and ti(4) these changes are runtime tested (unless I booted up
the wrong kernels again...).
laptops.
Tested by: [1] Lion G. <liontanker@hotmail.com>
[2] Pietro Cerutti <pietro.cerutti@gmail.com>
Specialized mixer initialization for STAC9221, much like STAC9220.
Tested by: Devon H. O'Dell
revision 1.98 is NOT merged, because FreeBSD does not support this
syntax.
revision 1.99 is NOT merged, "const poisoning" part is not applicable
to FreeBSD. There is no variable shadowing, GCC can't find
this one (but there are others)
revision 1.100 is NOT merged, because it was null patch (no changes)
revision 1.101 is NOT merged, there is no BIT() macro in FreeBSD
revision 1.102 is merged
revision 1.103 is partially merged. There is no ai.ifaceh in FreeBSD
revision 1.104 is NOT merged
revision 1.105 is merged
revision 1.106 is not merged, because of rev. 1.107
revision 1.107 is a backuout of 1.106
Submitted by: Yuriy Tsibizov <Yuriy.Tsibizov@gfk.ru>
---snip---
New features:
1. Optional multichannel recording (32 channels on Live!, 64 channels
on Audigy).
All channels are 16bit/48000Hz/mono, format is fixed.
Half of them are copied from sound output, another half can be
used to record any data from DSP. What should be recorded is
hardcoded in DSP code. In this version it records dummy data, but
can be used to record all DSP inputs, for example..
Because there are no support of more-than-stereo sound streams
multichannell stream is presented as one 32(64)*48000 Hz 16bit mono
stream.
Channel map:
SB Live! (4.0/5.1)
offset (words) substream
0x00 Front L
0x01 Front R
0x02 Digital Front L
0x03 Digital Front R
0x04 Digital Center
0x05 Digital Sub
0x06 Headphones L
0x07 Headphones R
0x08 Rear L
0x09 Rear R
0x0A ADC (multi-rate recording) L
0x0B ADC (multi-rate recording) R
0x0C unused
0x0D unused
0x0E unused
0x0F unused
0x10 Analog Center (Live! 5.1) / dummy (Live! 4.0)
0x11 Analog Sub (Live! 5.1) / dummy (Live! 4.0)
0x12..-0x1F dummy
Audigy / Audigy 2 / Audigy 2 Value / Audigy 4
offset (words) substream
0x00 Digital Front L
0x01 Digital Front R
0x02 Digital Center
0x03 Digital Sub
0x04 Digital Side L (7.1 cards) / Headphones L (5.1 cards)
0x05 Digital Side R (7.1 cards) / Headphones R (5.1 cards)
0x06 Digital Rear L
0x07 Digital Rear R
0x08 Front L
0x09 Front R
0x0A Center
0x0B Sub
0x0C Side L
0x0D Side R
0x0E Rear L
0x0F Rear R
0x10 output to AC97 input L (muted)
0x11 output to AC97 input R (muted)
0x12 unused
0x13 unused
0x14 unused
0x15 unused
0x16 ADC (multi-rate recording) L
0x17 ADC (multi-rate recording) R
0x18 unused
0x19 unused
0x1A unused
0x1B unused
0x1C unused
0x1D unused
0x1E unused
0x1F unused
0x20..0x3F dummy
Fixes:
1. Do not assign negative values to variables used to index emu_cards
array. This array was never accessed when index is negative, but
Alexander (netchild@) told me that Coverity does not like it.
After this change emu_cards[0] should never be used to identify
valid sound card.
2. Fix off-by-one errors in interrupt manager. Add more checks there.
3. Fixes to sound buffering code now allows driver to use large playback
buffers.
4. Fix memory allocation bug when multichannel recording is not
enabled.
5. Fix interrupt timeout when recording with low bitrate (8kHz).
Hardware:
1. Add one more known Audigy ZS card to list. Add two cards with
PCI IDs betwen old known cards and new one.
Other changes:
1. Do not use ALL CAPS in messages.
Incomplete code:
1. Automute S/PDIF when S/PDIF signal is lost.
Tested on i386 only, gcc 3.4.6 & gcc41/gcc42 (syntax only).
---snip---
This commits enables a little bit of debugging output when the driver is
loaded as a module. I did a cross-build test for amd64.
The code has some style issues, this will be addressed later.
The multichannel recording part is some work in progress to allow playing
around with it until the generic sound code is better able to handle
multichannel streams.
This is supposed to fix
CID: 171187
Found by: Coverity Prevent
Submitted by: Yuriy Tsibizov <Yuriy.Tsibizov@gfk.ru>
- Playback and headphone/speaker automute works.
- Recording untested due to me being deaf doing back-and-forth
remote debugging.
Free Macbook donation is highly appreciated :)
Tested by: Dennis Pielken <mips128@gmx.net>
in every sense.
General
-------
- Multichannel safe, endian safe, format safe
* Large part of critical pcm filters such as vchan.c, feeder_rate.c,
feeder_volume.c, feeder_fmt.c and feeder.c has been rewritten so that
using them does not cause the pcm data to be converted to 16bit little
endian.
* Macrosses for accessing pcm data safely are defined within sound.h in
the form of PCM_READ_* / PCM_WRITE_*
* Currently, most of them are probably limited for mono/stereo handling,
but the future addition of true multichannel will be much easier.
- Low latency operation
* Well, this require lot more works to do not just within sound driver,
but we're heading towards right direction. Buffer/block sizing within
channel.c is rewritten to calculate precise allocation for various
combination of sample/data/rate size. As a result, applying correct
SNDCTL_DSP_POLICY value will achive expected latency behaviour simmilar
to what commercial 4front driver do.
* Signal handling fix. ctrl+c of "cat /dev/zero > /dev/dsp" does not
result long delay.
* Eliminate sound truncation if the sound data is too small.
DIY:
1) Download / extract
http://people.freebsd.org/~ariff/lowlatency/shortfiles.tar.gz
2) Do a comparison between "cat state*.au > /dev/dsp" and
"for x in state*.au ; do cat $x > /dev/dsp ; done"
- there should be no "perceivable" differences.
Double close for PR kern/31445.
CAVEAT: Low latency come with (unbearable) price especially for poorly
written applications. Applications that trying to act smarter
by requesting (wrong) blocksize/blockcount will suffer the most.
Fixup samples/patches can be found at:
http://people.freebsd.org/~ariff/ports/
- Switch minimum/maximum sampling rate limit to "1" and "2016000" (48k * 42)
due to closer compatibility with 4front driver.
Discussed with: marcus@ (long time ago?)
- All driver specific sysctls in the form of "hw.snd.pcm%d.*" have been
moved to their own dev sysctl nodes, notably:
hw.snd.pcm%d.vchans -> dev.pcm.%d.vchans
Bump __FreeBSD_version.
Driver specific
---------------
- Ditto for sysctls.
- snd_atiixp, snd_es137x, snd_via8233, snd_hda
* Numerous cleanups and fixes.
* _EXPERIMENTAL_ polling mode support using simple callout_* mechanisme.
This was intended for pure debugging and latency measurement, but proven
good enough in few unexpected and rare cases (such as problematic shared
IRQ with GIANT devices - USB). Polling can be enabled/disabled through
dev.pcm.0.polling. Disabled by default.
- snd_ich
* Fix possible overflow during speed calibration. Delay final
initialization (pcm_setstatus) after calibration finished.
PR: kern/100169
Tested by: Kevin Overman <oberman@es.net>
* Inverted EAPD for few Nec VersaPro.
PR: kern/104715
Submitted by: KAWATA Masahiko <kawata@mta.biglobe.ne.jp>
Thanks to various people, notably Joel Dahl, Yuriy Tsibizov, Kevin Oberman,
those at #freebsd-azalia @ freenode and others for testing.
Joel Dahl will do the manpage update.
Rename MAX_SAMPLE_RATES macro to OSS_MAX_SAMPLE_RATES. The old
macro clashed with those used in other applications and libaries
(ex: RtAudio). 4Front responded by updating their spec, so we
will follow suit.
Submitted by: ryanb
Noticed by: pointyhat/kris
- Add support for the Conexant Waikiki/CX20551-22, found
in most Toshiba P100 series laptops. Despite of growing
urban legend of "unsupported Conexant", this codec is fully
supported in this driver.
Note: Toshiba P100 has broken (acpi) BIOS, thus rendering
its soundchip useless. Please disable ACPI, or get
BIOS updates (if any).
Found/tested by: Vulpes Velox <v.velox@vvelox.net>
URL: http://lists.freebsd.org/pipermail/freebsd-multimedia/2006-September/004896.html
- Parser cleanups to handle possible oss/mixer collision. Found
after parsing Conexant Waikiki nodes.
- Increase resilient against resource failure during attach/detach.
- Implement simple config through hint.pcm.<unit>.config. Supported
options:
gpio0 (default on Acer), gpio1, gpio2, softpcmvol,
fixedrate (default), forcestereo (default)
* Option prefixed with "no" (such as "nofixedrate") will do
the opposite.
* Options can be separated using space " " or comma ",".
* The "no" option will take precedence over anything else.
Example:
hint.pcm.0.config="gpio2,nofixedrate,noforcestereo,nogpio0,softpcmvol"
hint.pcm.0.config="softpcmvol noforcestereo"
- Fix support for ASUS M5200ae (buggy BIOS)
- Fix few problems, reported by Coverity Prevent (TM).
CID: 246991, 246676, 246675, 246674, 246477
Found by: Coverity Prevent (TM)
Add support for Intel High Definition Audio Controller.
This driver make a special guarantee that "playback" works
on majority hardwares with minimal or without specific vendor
quirk.
This driver is a product of collaborative effort made by:
Stephane E. Potvin <sepotvin@videotron.ca>
Andrea Bittau <a.bittau@cs.ucl.ac.uk>
Wesley Morgan <morganw@chemikals.org>
Daniel Eischen <deischen@FreeBSD.org>
Maxime Guillaud <bsd-ports@mguillaud.net>
Ariff Abdullah <ariff@FreeBSD.org>
....and various people from freebsd-multimedia@FreeBSD.org
Refer to snd_hda(4) for features and issues.
Welcome To HDA.
Sponsored by: Defenxis Sdn. Bhd.
This driver make a special guarantee that "playback" works
on majority hardwares with minimal or without specific vendor
quirk.
This driver is a product of collaborative effort made by:
Stephane E. Potvin <sepotvin@videotron.ca>
Andrea Bittau <a.bittau@cs.ucl.ac.uk>
Wesley Morgan <morganw@chemikals.org>
Daniel Eischen <deischen@FreeBSD.org>
Maxime Guillaud <bsd-ports@mguillaud.net>
Ariff Abdullah <ariff@FreeBSD.org>
....and various people from freebsd-multimedia@FreeBSD.org
Refer to snd_hda(4) for features and issues.
Welcome To HDA.
Sponsored by: Defenxis Sdn. Bhd.
- fix multiple initialization of the first codec (support for more than
one codec should be added in the future)
- use spicds instead of ak452x module
Submitted by: "Konstantin Dimitrov" <kosio.dimitrov@gmail.com>
commit.
1) sys/dev/sound/pcm/sound.h
sys/dev/sound/pcm/channel.c
* Be more specific: SD_F_SOFTVOL -> SD_F_SOFTPCMVOL
2) sys/dev/sound/pcm/mixer.[ch]
* Implement
mix_setparentchild()
mix_setrealdev()
mix_getparent()
mix_getchild()
The purpose of these functions is implement relative volume
adjustment, such as to tie two or more mixer device into a
single logical device. Usefull for the upcoming HDA driver
and few AC97 codec (such as AD1981B) where the master volume
"vol" need to be implemented using this logical manner.
3) sys/dev/sound/pcm/ac97_patch.[ch]
* Patch for AD1981B codec to enable (automuting) headphone jack sense.
4) sys/dev/sound/pcm/ac97.c
* Implement proper logical master volume for AD9181B codec
through various mix_set{parentchild,realdev}(). Tie both
"ogain" (headphone volume) and "phone" (speaker/lineout) to
a logical "vol".
5) sys/dev/sound/pcm/usb/uaudio_pcm.c
* ditto, for "vol" -> { "pcm" }.
MFC after: 1 month
The goal was to sync with the OSSv4 API 4Front Technologies uses in their
proprietary OSS driver. This was successful as far as possible. The part
of the API which is stable is implemented, for the rest there are some
stubs already.
New system ioctls:
- SNDCTL_SYSINFO - obtain audio system info (version, # of audio/midi/
mixer devices, etc.)
- SNDCTL_AUDIOINFO - fetch details about a specific audio device
- SNDCTL_MIXERINFO - fetch details about a specific mixer device
New audio ioctls:
- Sync groups (SNDCTL_DSP_SYNCGROUP/SNDCTL_DSP_SYNCSTART) which allow
triggered playback/recording on multiple devices (even across processes
simultaneously).
- Peak meters (SNDCTL_DSP_GETIPEAKS/SNDCTL_DSP_GETOPEAKS) - can query
audio drivers for peak levels (needs driver support, disabled for now).
- Per channel playback/recording levels -
SNDCTL_DSP_{GET,SET}{PLAY,REC}VOL. Note that these are still in name
only, just wrapping around the AC97-style mixer at the moment. The next
step is to push them down to the drivers.
Audio ioctls still under development by 4Front (for which stubs may exist
in this commit):
- SNDCTL_GETNAME, SNDCTL_{GET,SET}{SONG,LABEL}
- SNDCTL_DSP_{GET,SET}_CHNORDER
- SNDCTL_MIX_ENUMINFO, SNDCTL_MIX_EXTINFO - (might be documented enough in
the OSS releases to work on this. These ioctls cover the cool "twiddle
any knob on your card" features.)
Missing:
- SNDCTL_DSP_COOKEDMODE -- this ioctl is used to give applications direct
access to a card's buffers, bypassing the feeder architecture. It's
a toughy -- "someone" needs to decide :
(a) if this is desireable, and (b) if it's reasonably feasible.
Updates for driver writers:
So far, only two routines to the channel class (in channel_if.m) are added.
One is for fetching a list of discrete supported playback/recording rates
of a channel, and the other is for fetching peak level info (useful for
drawing peak meters). Interested parties may want to help pushing down
SNDCTL_DSP_{GET,SET}{PLAY,REC}VOL into the drivers.
To use the new stuff you need to rebuild the sound drivers or your kernel
(depending on if you use modules or not) and to install soundcard.h (a
buildworld/installworld handles this).
Sponsored by: Google SoC 2006
Submitted by: ryanb
Many thanks to: 4Front Technologies for their cooperation, explanations
and the nice license of their soundcard.h.
Reported by: Nick Withers < nick AT nickwithers DOT com >
Tested by: Nick Withers < nick AT nickwithers DOT com >
No objection from: ariff
MFC after: 1 week
is interaction between in-kernel sound buffer handling and hardware.
With small buffer, there are times when both harwdare reads and
kernel writes to the same buffer (it is only visible on slow machines, i
think). I'm digging in channel.c and buffer.c to find a solution that
allow use of large hardware buffers without sound lags - hardware can
handle buffers up to 32Mb."
Submitted by: Yuriy Tsibizov <Yuriy.Tsibizov@gfk.ru>
- fix "No sound in KDE":
The problem is related to the implementation of Envy24(1712) hardware
mixer support in the driver. Envy24(1712) has very precise 36bit wide
hardware mixer, which is superior that vchans (software sound mixer in
the kernel). The driver supports Envy24(1712) hardware mixer, so up to
10 channels (5 stereo pairs) can be playback simultaneously.
However, there are problems with the implementation of Envy24(1712)
hardware mixer support in the driver, one of them is the problem with
"no sound in KDE":
When playing back several channels simultaneously and
stoping one of the channels, sound starts to stutter and
plays at very low speed.
Another problem is:
Playing back simultaneously more than one 24bit/32bit
sound file or 16bit sound file and 24bit/32bit sound
file doesn't work as expected.
Submitted by: "Konstantin Dimitrov" <kosio.dimitrov@gmail.com>
from a semantic point of view, but I notified the author of the driver
for confirmation. So far it at least fixes the build and should only
lead to not identifying or wrongly identifying a soundcard in the worst
case.
sound cards with optional pseudo-multichannel playback.
It's based on snd_emu10k1 sound driver. Single channel version is available
from audio/emu10kx port since some time.
The two new ALSA header files (GPLed), which contain Audigy 2 ("p16v") and
Audigy 2 Value ("p17v") specific interfaces, are latest versions from ALSA
Mercurial repository.
This is not connected to the build yet.
Submitted by: Yuriy Tsibizov <Yuriy.Tsibizov@gfk.ru>
latest version from Mercurial repository. It brings definition of some
additional Audigy 2 / Audigy 2 Value registers.
- Use new #defines from ALSA emu10k1.h
- Remove unused include files:
+ emu10k1-ac97.h was imported from ALSA and never used,
+ emu10k1.h was imported from Creative Linux emu10k1 driver, but only
AUDIGY_CODEBASE was used from it.
Submitted by: Yuriy Tsibizov <Yuriy.Tsibizov@gfk.ru>
- Enable 4 automatic vchan's by default.
- Add some comments which provide ides/questions for improvement.
- Prefix some temporary sysctl's with an underscore to denote that it is not
an official API but a workaround until the real solution is implemented.
yet. More commits to follow.
I got no response from the author, but since the driver is BSD licensed
I don't think he will complain. :-)
I got it from http://people.freebsd.org/~lofi/envy24.tar.gz
Written by: Katsurajima Naoto <raven@katsurajima.seya.yokohama.jp>
but large parts are rewritten by matk and tanimura.
This is old code, it's not maintained since 2003. We also don't have a
maintainer for this! Yuriy Tsibizov took it and uses it in his emu10kx
driver. Since the emu10kx driver will enter the tree "soon" (some bugs
have to be fixed after Yuriy return from his holidays), I add it here
already.
This also contains some changes to emu10k1 and cmi, so if you're lucky,
you can now make some kind of use of midi with those soundcards.
To all those poor souls which don't have such a card: feel free to send
patches, we don't have a maintainer for this.
To those which miss a specific feature in the midi code: feel free to
submit patches, we don't have a maintainer for this.
Oh, did I already told that it would be nice if someone would take care
of it? Maintainer with midi equipment wanted! :-)
If you get LOR's, submit a PR and notify multimedia@ please. If you get
panics, submit a PR with a backtrace (compile the sound system into your
kernel instead of using modules in this case) and notify multimedia@
please.
Written by: matk, tanimura
Submitted by: "Yuriy Tsibizov" <Yuriy.Tsibizov@gfk.ru>
Based upon: code from NetBSD
but large parts are rewritten by matk and tanimura.
This is old code, it's not maintained since 2003. We also don't have a
maintainer for this! Yuriy Tsibizov took it and uses it in his emu10kx
driver. Since the emu10kx driver will enter the tree "soon" (some bugs
have to be fixed after Yuriy return from his holidays), I add it here
already.
This also contains some changes to emu10k1 and cmi, so if you're lucky,
you can now make some kind of use of midi with those soundcards.
To all those poor souls which don't have such a card: feel free to send
patches, we don't have a maintainer for this.
To those which miss a specific feature in the midi code: feel free to
submit patches, we don't have a maintainer for this.
Oh, did I already told that it would be nice if someone would take care
of it? Maintainer with midi equipment wanted! :-)
If you get LOR's, submit a PR and notify multimedia@ please. If you get
panics, submit a PR with a backtrace (compile the sound system into your
kernel instead of using modules in this case) and notify multimedia@
please.
Written by: matk, tanimura
Submitted by: "Yuriy Tsibizov" <Yuriy.Tsibizov@gfk.ru>
Based upon: code from NetBSD
A slight difference of this chip from its previous siblings is that
it need a gentle "wake up" on every (full) DMA buffer completion to
avoid stalled interrupt handler.
Thanks to George Hartzell for permission on doing remote debugging.
Prime MFC candidate for 6.1-RELEASE. Please reply to this commit if
there are any objections (so I won't bug re@), since the changes
are too small and only specific to VT8251.
PR: i386/95949
Tested by: [1] George Hartzel
myself (remotely)
MFC after: 3 days
[1] http://lists.freebsd.org/pipermail/freebsd-multimedia/2006-April/004003.html
--------------------
- Seal the fate of long standing memory leak (4 years, 7 months) during
pcm_unregister(). While destroying cdevs, scan / detect possible
children and free its SLIST placeholder properly.
- Optimize channel allocation / numbering even further. Do brute cyclic
checking only if the channel numbering screwed.
- Mega vchan create/destroy cleanup:
o Implement pcm_setvchans() so everybody can use it freely instead
of implementing their own, be it through sysctl or channel auto
allocation.
o Increase vchan creation/destruction resiliency:
+ it's possible to increase/decrease total vchans even during
busy playback/recording. Busy channel will be left alone, untouched.
Abusive test sample:
# play whatever...
#
while : ; do
sysctl hw.snd.pcm0.vchans=1
sysctl hw.snd.pcm0.vchans=10
sysctl hw.snd.pcm0.vchans=100
sysctl hw.snd.pcm0.vchans=200
done
# Play something else, leave above loop running frantically.
+ Seal another 4 years old bug where it is possible to destroy (virtual)
channel even when its cdevs being referenced by other process.
The "First Come First Served" nature of dsp_clone() is the main
culprit of this issue, and usually manifest itself as dangling
channel <-> process association. Ensure that all of its cdevs
are free from being referenced before destroying it (through
ORPHAN_CDEVT() macross).
All these fixes (including previous fixes) will be MFCed, later.
to avoid possible device unregister race (impossible to reproduce, yet
possible).
- Extra sanity check to ensure proper parent channel is being selected.
- Reset parent channel once all of its children gone.
- [1] Make the driver friendly towards kernel without PREEMPTION.
Use msleep(9) instead of simple unlock-check_variable-lock mechanisme
since the later not really effective in non-preemptible kernel
(especially during codec detection routine).
- Free most driver resources in a sane manner to avoid possible
double free and panics especially during device detach and codec
detection failure.
MFC after: 3 days
[1] http://lists.freebsd.org/pipermail/freebsd-questions/2006-March/116515.html
- Determine open direction using 'flags', not 'mode'. This bug exist since
past 4 years.
- Don't allow opening the same device twice, be it in a same or different
direction.
- O_RDWR is allowed, provided that it is done by a single open (for example
by mixer(8)) and the underlying hardware support true full-duplex operation.
- Do various paranoid checking in case other process/thread trying to hijack
the same device twice (or more).
MFC after: 5 days
especially for vchans. It turns out that channel numbering always depend
on d->devcount counter (which keep increasing), while PCMMKMINOR() truncate
everything to 8bit length. At some point the truncation cause the newly
created character device overlapped with the existence one, causing erratic
overall system behaviour and panic. Easily reproduce with something like:
(Luckily, only root can reproduce this)
while : ; do
sysctl hw.snd.pcm0.vchans=200
sysctl hw.snd.pcm0.vchans=100
done
- Enforce channel/chardev numbering within 8bit boundary. Return E2BIG
if necessary.
- Traverse d->channels SLIST and try to reclaim "free" counter during channel
creation. Don't rely on d->devcount at all.
- Destroy vchans in reverse order.
Anyway, this is not the fault of vchans. It is just that vchans are so cute
and begging to be abused ;) . Don't blame her.
Old, hidden bugs.. sigh..
MFC after: 3 days
forcing DMA alignment to default buffer size.
- Make sure DMA pointer properly aligned to avoid being truncated by caller
which causing severe underruns and random popping (especially in 32bit
playback / recording).
- Add AC97 inverted external amplifier quirk for Maxselect x710s
- http://maxselect.ru/
MFC after: 1 week
dereferencing) since a NULL value would be a bug here.
Note: Both affected functions look very similar. A refactoring may
be beneficial.
CID: 483, 485
Found with: Coverity Prevent(tm)
Discussed with: ariff
MFC after: 5 days
needed here, except there's a bug which results in detaching the device
twice.
Move the NULL pointer check to the beginning of the function and convert
it into a KASSERT.
CID: 420
Found with: Coverity Prevent(tm)
Discussed with: ariff
MFC after: 5 days
This is supposed to fix some Coverity Prevent errors (Ariff didn't
looked at the CID's (ENOTIME), I just told him that there are some problems
in function dsp_ioctl()).
CID: 215-218
Found with: Coverity Prevent(tm)
Submitted by: ariff
MFC after: 5 days
(1) Fix DMA alignment, based on bytes per sample.
feeder_rate.c:
Handle strayed bytes (mostly caused by #1) better.
This DMA alignment issues are extremely hard to reproduce unless
the user happen to have a 32bit capable soundcards (ATI IXP) and
knowledgeable enough to force it to operate under pure 32bit
operations on both record and play directions.
feeder.h:
feeder.c:
- Implement scoring mechanisme to select best format for conversion.
This is actually part of newer format chaining procedures which
will be commited someday. Confusion during chaining process solved
by this scoring since it will try to reduce list of from/to formats
to a single, best format.
Related PR: kern/91683
channel.c:
- Simplify feeder building process since we have smarter format
chaining.
feeder_fmt.c:
- Add few more sign conversion feeders for 24 and 32 bit format.
feeder_rate.c:
- Force buffer / bytes allignment. Unaligned buffer may cause
panics during recording on pure 32bit sample format if it
involves feeder_rate as part of feeders chain.
Tested on: ATI IXP, force 32bit recording.
MFC after: 5 days
The minimum / maximum speed was way too low / high!
minspeed = 2000 - is this for real ?
maxspeed = 767999 - is this for real ?????
Wrap everything into 8000 - 48000 boundary, just to be safe.
MFC after: 3 days
- Mark MPSAFE since most of the locking procedures already implemented.
- Turn on inverted external amplifier sense flag for selected boards.
Tested by: bland
MFC after: 1 week
Instead of dragging the entire ICH4/82801DB into this mess, select
only few boards based on pci subdevice / subvendor.
Tested by: Daisuke Orikasa <luxury-acura-3.5rl at nifty.com>
MFC after: 3 days
- MPSAFE
- Fix / reorganize attach routine. Device specific initialization must
be done after generic bus / DMA setup. At last, Virtual Channels
(vchan) works as expected.
Note: Recent commit / fix against this driver proves that major enhancements
on the generic sound layer does indeed help to expose flaw within
device specific code. There are probably other drivers that need to
be addressed as well.
Tested by: barner
MFC after: 1 week
