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
This should reduce huge playback / recording latency for
applications that try to act smarter and manage their own
buffering (XMMS, Skype, etc.).
Note to Skype + via8xxx users: Remove previous hackish
"hint.pcm.<unit>.via_dxs_disabled" from kernel hint and see
whether this changes cure all those annoying sound issues.
that enabling busmastering would result in PCR bit ON after codec
reset.
While I'm here add DELAY(1) to codec access routine to give reasonable
time to codec operation. Without the delay, it would cause problems on
super-fast machines(> 2GHz). Also enable legacy audio for all 6300ESB,
82801[D-G]B chips. Previously, it enabled legacy audio for 82801DB(ICH4)
chip only.
Reported by: Maxim Maximov mcsi AT mcsi DOT pp DOT ru
Andrew Bliznak andriko.b AT gmail DOT com
Tested by: brueffer, Maxim Maximov, Andrew Bliznak
This one simply tries to simplify the logic to select the
buffer sizes. I am not sure it is necessary but the code
seems a bit more readable to me. And at least i have tried
to document how the buffer sizes are computed.
Thanks to luigi for deciphering one of the most cryptic part of
sound driver.
Submitted by: luigi
Approved by: netchild (mentor)
In SNDCTL_DSP_SETFRAGMENT, if you specify both read and
write channels, the existing code first acts on the
read channel, but as a side effect it updates the
arguments (maxfrags, fragsz) passed by the caller according
to acceptable values for the read channel, and then uses the
modified values to act on the write channel.
The problem with this approach is that, given a
(maxfrags, fragsz) user-specified value, the actual
values computed by the read and write channels may differ:
e.g. the read channel might want to allocate more fragments
than what the user specified because it has no side-effects
on the delay and it helps in case of slow readers,
whereas the write channel needs to use as few fragments
as possible to keep the audio latency low (very important
with telephony apps).
This patch stores the values computed by the read channel
into temproary variables so the write channel will use
the actual arguments of the ioctl.
This patch is very helpful with telephony apps such as asterisk.
Submitted by: luigi
Approved by: netchild (mentor)
- Added new codec id for CX20468-21 and VIA1617A.
Submitted by: Chen Lihong <lihong.chen@gmail.com>
- Re-enable SOUND_MIXER_IGAIN, but set the default level as 0 (mute)
Suggested by: luigi
mixer.c:
- Set default value for SOUND_MIXER_IGAIN as 0 (mute) to avoid
feedback problems on some laptops (was disabled by jhb during
ac97.c revision 1.42).
Approved by: netchild (mentor)
erratic system slowdown (beaten to a pulp) and possible panic. This
issue has bugged me for as long as I could remember, until I
realized that it is possible for register base offset to hold zero
value which is definitely a "FALSE".
Approved by: netchild (mentor)
compatible AC97 codec.
- As the driver supports so many variants, create a table ids for
ease of probing and maintenance.
Submitted by: yongari
Reviewed/Tested by: multimedia@
- From luigi:
The code to compute fragment sizes in the ich driver almost
invariably ends up using the full buffer available, no matter
how the user specifies fragment size and number.
With audio telephony (8khz, 16bit-stereo) and the 16k buffer
size this results in an unbearable 500ms delay.
This patch makes sure that we never use more than 4 fragments,
(i don't think we need more unless there are huge interrupt
servicing latencies), and obey to the requested fragment size,
so that latency is acceptable.
Based on this (and after much regression tests), I can conclude
that this driver works best with 2 fragments, thus solving various
long standing issues of ICH driver not capable to flush or play
short files perfectly.
Suggested by: luigi (the idea of smaller fragments)
- MPSAFE conversion.
Approved by: netchild (mentor)
distinct hardware playback channels. DAC configuration can be
accessed through kernel hint - hint.pcm.<unit>.dac="val" with
following possible values:
0 = Enable both DACs (default)
1 = Enable single DAC (DAC1)
2 = Enable single DAC (DAC2)
3 = Enable both DACs, swap position (DAC2 comes first instead
of DAC1)
Special case for ES1370:
Unlike ES1371,2,3/CT5880, volume for each DAC 1 and 2 can be
controlled indepedently (synth for DAC1, pcm for DAC2). It is
possible that user will confuse by this behaviour, since both
DACs are enabled by default. Thus, provide a knob through sysctl
hw.snd.pcm<unit>.single_pcm_mixer:
0 = each DACs will be controlled separately (synth/pcm).
1 = combine both DACs volume mixer controller into a single
"pcm" (default)
As a side note, fixed rate operation (provided by previous
commit) is not a mandatory if the configuration space does not
involve DAC2 (perhaps disabled by user through the above kernel
hint). Unlike DAC2, DAC1 has its own register / control space,
not affected by the speed settings of ADC.
Tested by: multimedia@
Approved by: netchild (mentor)
mask to recdev_l and recdev_r, since each have its own unique mask.
Submitted by: Watanabe Kazuhiro <CQG00620@nifty.ne.jp>
Approved by: netchild (mentor)
It may be the case that you may hear some unwanted noise while
playing back with 24/32 bit. This is a problem in the USB system.
Explanation from Hans Petter Selasky:
---snip---
The current USB sound driver only uses one isochronous
buffer, that is restarted when it is completed. This will lead to a short
period of time, +1ms, where no sound data is sent to the external USB device.
Depending on the load of your computer, this can be as much as 50ms. So the
USB sound driver must use 2 isochronous transfers. At the beginning one will
queue both. Then these are restarted on completion. This will result in a
constant-rate data stream to the external sound device, a minimum sound
buffer equal to the size of the isochronous buffer, and possibly the sound
will reach your ears with less delay. Little delay is a result of constant
data rate. Currently only my USB driver will support that. If one tries that
with the USB driver in *BSD, then it will crash at the first moment one gets
a buffer underrun.
---snip---
Submitted by: Kazuhito HONDA <kazuhito@ph.noda.tus.ac.jp>
Mono-recording still not tested by: julian
- Return EINVAL if play_format or rec_format is set but the corresponding
sample rate is 0.
- Don't try to set the playback or recording format to 0. Previously,
issuing an AIOSFMT ioctl with an all-zeroes snd_chan_param would
trigger a KASSERT in chn_fmtchain(); I'm unsure about the effects on
a kernel without INVARIANTS. After this commit, issuing AIOSFMT with
an all-zeroes snd_chan_param is equivalent to issuing AIOGFMT.
MFC after: 2 weeks
sampling rate:
- Improve vchan chn_setspeed() strategy. Try to avoid FEEDER_RATE
on parent channel if the requested value is not supported
by the hardware.
- Fix vchan default speed calculation. In any case, vchan should
rely on parent bufsoft speed instead of bufhard since it is
possible that the entire feeder chain might involve FEEDER_RATE.
This is possible under extreme, rare condition if the above
chn_setspeed() strategy failed.
Approved by: netchild (mentor)
- Don't keep the SPDIF state in the driver private struct since it
can be overriden by hand with pciconf(8), query it when needed instead.
Regarding the locking I let Ariff explain it himself:
---snip---
About the locking, that is what I'm intended to do since the beginning.
The reason I'm not putting that along since my first patchset was
because several people especially from amd46 camp reported that it cause
lots of LORs, which is weird considering that I've never encounter such
in a pretty much strict locking environment (i386). However, since our
previous discussion with Pyun YongHyeon about strict locking, I've
decided to bring it back for all the affected drivers, not just for
es137x. It turns out that the root of the problem was within dsp.c
during device open, which has been fixed since dsp.c revision 1.84.
---snip---
Submitted by: Ariff Abdullah <skywizard@MyBSD.org.my>
code which may help.
People with a ich compatible soundcard which want to help out should
change the "#if 1" to a "#if 0" and try if the soundcard still works.
Reports about working or not-working soundcards with this change to
multimedia@ please.
PR: 73987
sampling rate between playback and recording. This can be
disabled / enabled via kernel hints
(hint.pcm.<unit>.fixed_rate=0/4000-48000) or sysctl
hw.snd.pcm<unit>.fixed_rate=0/4000-48000). Default to 48khz
fixed rate. [1]
* Basic cleanup. *_es1371x_* -> *_es137x_*.
* Some locking fixes. [2]
Submitted by: Ariff Abdullah <skywizard@MyBSD.org.my>
Discussed with: yongari [2]
See also: http://lists.freebsd.org/pipermail/freebsd-multimedia/2005-September/002758.html [1]
Reported by: Jos Backus <jos at catnook.com> [1]
* General spl* cleanup. It doesn't serve any purpose anymore.
* Nuke sndstat_busy(). Addition of sndstat_acquire() /
sndstat_release() for sndstat exclusive access. [1]
sys/dev/sound/pcm/sound.c:
* Remove duplicate SLIST_INIT()
* Use sndstat_acquire() / release() to lock / release the entire
sndstat during pcm_unregister(). This should fix LOR #159 [1]
sys/dev/sound/pcm/sound.h:
* Definition of SD_F_SOFTVOL (part of feeder volume)
* Nuke sndstat_busy(). Addition of sndstat_acquire() /
sndstat_release() for exclusive sndstat access. [1]
Submitted by: Ariff Abdullah <skywizard@MyBSD.org.my>
LOR: 159 [1]
Discussed with: yongari [1]
* Added codec id for CMI9761.
* feeder_volume *whitelist* through ac97_fix_volume()
sys/dev/sound/pcm/ac97.h:
* Added AC97_F_SOFTVOL definition.
sys/dev/sound/pcm/channel.c:
* Slight changes for chn_setvolume() to conform with OSS.
* FEEDER_VOLUME is now part of feeder building process.
sys/dev/sound/pcm/mixer.c:
* General spl* cleanup. It doesn't serve any purpose anymore.
* Main hook for feeder_volume.
Submitted by: Ariff Abdullah <skywizard@MyBSD.org.my>
Tested by: multimedia@
While I'm here add KASSERT(9) to notify failure of SYSUNINIT handler.
Reported by: Ben Kaduk < minimarmot AT gmail DOT com >
Tested by: Ben Kaduk < minimarmot AT gmail DOT com >
- Remove an assertion in sound.c, it's not needed (and causes a panic now).
From the conversation via mail between glebius and Ariff:
---snip---
> Well, but which mutex protects now? Do we own anything else
> in pcm_chnalloc()? I see some queue(4) macros in pcm_chnalloc(),
> they should be protected, shouldn't they?
Queue insertion/removal occur during
1) driver loading (which is pretty much single thread /
sequential) or unloading (mutex protected, bail out if there is
any channel with refcount > 0 or busy).
2) vchan_create()/destroy(), (which is *sigh* quite complicated), but
somehow protected by 'master'/parent channel mutex. Other
thread cannot add/remove vchan (or even continue traversing
that queue) unless it can acquire parent channel mutex.
---snip---
Fix the locking in dsp.c to prevent a LOR (AFAIK not on the LOR page).
Submitted by: Ariff Abdullah <skywizard@MyBSD.org.my>
Tested with: INVARIANTS[1] and DIAGNOSTICS[2]
Tested by: netchild [1,2], David Reid <david@jetnet.co.uk> [1]
In case this causes trouble for some other chipsets add a comment how to
proceed. If we don't get bugreports, this should be removed after a while
(some releases?).
PR: 56617 [1], 29465, 39260, 40574, 68225
Submitted by: Matthew E. Gove <mgove@comcast.net> [1]
believe that there are PC98 systems with an OPTi chip.
I don't know enough about this special PC architecture to be sure about
this, so let's find out by letting people with such a system complain in
case this commit breaks the sound system for them. It's easy to revert
then.
PR: 45673
Submitted by: Watanabe Kazuhiro <CQG00620@nifty.ne.jp>
* New definition CHN_F_HAS_VCHAN.
- channel.c
* Use CHN_F_HAS_VCHAN to mark channel with vchan capability instead
of relying on SLIST_EMPTY(&channel->children) == true for better
clarification and future possible usages of children (like
'slave' channel).
* Various fixes, including blocksize / format bps allignment,
better 24bit seeking (mplayer, others).
* Improve format chain building, it's now possible to record something
to a format non-native to the soundcard through various feeder format
converters or to higher sampling rate. This also gains another feature,
like doing vchan mixing on non s16le soundcard such as sb8.
- sound.c
* Increase robustness within various function that handle vchan
creation / termination (these function need a total rewrite, but
that would cause other major rewrite within various places too!).
As far as its robustness can be guaranteed, leave it as is.
* Optimize channel ordering, prefer *real* hardware playback
channels over virtual channels. cat /dev/sndstat should look
better.
* Increase sndstat verbosity to include bufsoft/bufhard allocation.
- vchan.c
* Fix LOR 119.
- http://sources.zabbadoz.net/freebsd/lor.html#119
* Reorder / increase robustness of vchan_create() / destroy().
Enforce destroy_dev() during destroy operation, fix possible
panic / dangling character device.
- http://lists.freebsd.org/pipermail/freebsd-current/2005-May/050308.html
* Tolerate a little bit more during mixing process, this should help
non s16le soundcards.
Note: Recoring in a non-native rate/format may result in overruns. A friendly
application is wavrec from audio/wavplay. The problem is under
investigation.
Submitted by: Ariff Abdullah <skywizard@MyBSD.org.my>
From the PR:
---snip---
The vibra16X supports full duplex. I traced the Windows driver, and what is
does is that it programs one DMA channel 8-bit, and the other 16-bit. There
might be some kind of auto detection logic here, because it always uses 8-bit
for playback, even if I play 16-bit sound ...
---snip---
PR: 80977
Submitted by: Hans Petter Selasky <hselasky@c2i.net>
event handler, dev_clone, which accepts a credential argument.
Implementors of the event can ignore it if they're not interested,
and most do. This avoids having multiple event handler types and
fall-back/precedence logic in devfs.
This changes the kernel API for /dev cloning, and may affect third
party packages containg cloning kernel modules.
Requested by: phk
MFC after: 3 days
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. Plenty sysctl options to
adjust resampling characteristics.
2. Support 24/32 bit pcm format conversion through new, much improved,
simplified and optimized feeder_fmt.
Changes:
1. buffer.c / dsp.c / sound.h
* Support for 24/32 AFMT.
2. 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.
3. 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.
4. channel.c
* Support for 24/32 AFMT
* Fix wrong xruns increment, causing incorrect underruns statistic
while using vchans.
5. vchan.c
* 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".
Notes / Issues:
* Virtual Channels (vchans)
Enabling vchans can really, really help to solve overrun
issues. This is quite understandable, because it operates
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. Few soundcards
(notably via8233x, sblive, possibly others) have their own
hardware multi channel, and this is unfortunately beyond
vchan reachability.
* 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.
* Don't expect playing 9999999999hz is a wise decision. Be
reasonable. The new feeder_rate implemention provide
flexibility, not insanity. You can easily chew up your CPU
with this kind of mind instability. Please use proper
mosquito 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>".
Submitted by: Ariff Abdullah <skywizard@MyBSD.org.my>
Tested by: multimedia@
This mostly to help CT4730, but apparently it does help other
cards too (especially via8233x). This probably need further 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).
Submitted by: Ariff Abdullah <skywizard@MyBSD.org.my>
Tested by: multimedia@
- Don't mark MPSAFE (yet).
- DSP_CMD_DMAEXIT_8 doesn't work on old cards, use sb_reset_dsp() instead.
Submitted by: Ariff Abdullah <skywizard@MyBSD.org.my>
* Add kernel hint option to disable DXS channels entirely. Report
from several skype users / Pav Lucistnik indicate that disabling
DXS may fix lots of pop / crackling noise. To disable DXS add
hint.pcm.<unit>.via_dxs_disabled="1" to /boot/device.hints.
Further investigation of the issues regarding DXS showed, that
the problem is in another (more generic) place, but until the
right fix is tested/reviewed this may help a little bit.
Added sysctl's to aid testing/debugging:
hint.pcm.<unit>.via_dxs_disabled=X - Disable / Enable DXS channels entirely
hint.pcm.<unit>.via_dxs_channels=X - Limit DXS channels up to X
hint.pcm.<unit>.via_sgd_channels=X - Limit SGD channels up to X
hint.pcm.<unit>.via_dxs_src=X - Enable / Disable DXS sample rate
converter.
Submitted by: Ariff Abdullah <skywizard@MyBSD.org.my>
Tested by: multimedia@
especially for CT4730 / EV1938 chip, causing misconfigured mixer
(David Xu), crippled after power cycle (Kevin Oberman). Fixed.
* Incorporate locking/spdif patches from Jon Noack / matk. Not all
es137x can really do spdif, clean it up a bit to only let few capable
chip. This adds a "hw.snd.pcm<unit>.spdif_enabled" sysctl until
a more generic way of handling this from userland (by an ordinary
user) is designed/implemented.
* 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 have
pointed out to use pciconf instead, but this is just an added
value specific for CT4730/EV1938.
* Remove es137x specific debug sysctl/code.
Several PRs can now be closed.
Submitted by: Ariff Abdullah <skywizard@MyBSD.org.my>
Submitted by: Jon Noack <noackjr@alumni.rice.edu> (implicit)
Submitted by: matk (implicit)
PR: 59349, 68594, 73498
Tested by: multimedia@
this buffer anyway so the constraint that it had to be DMA capable only
caused pain when devices failed to aquire the memory. Use a regular
malloc instead with sndbuf_setup.
Approved by: tanimura (mentor)
Affects to people WITH an AD1888 codec, the system will output to the port
labeled "speaker" instead of microphone. System will work the same in
multiple operating systems.
If people are currently using their systems with this codec they will need
to swap their output ports.
I have _not_ checked audio input or line input (basically, I have checked
nothing other than line-out).
I believe this is an appropriate change, it makes us consistent with
documentation, and other operating systems. Furthermore, this feature
(playing) is the vast majority of sound activities, so if this makes is
right for playback and wrong for recording... playback is more important,
and we can fix recoding in the future without worries of screwing people
again in the future (since we'll be "right" on the playback).
Submitted by: David Cross
One of a set of patches submitted by Kazuhito HONDA
to make the usb audio driver a lot more capable.
PR: 75274
Submitted by: Kazuhito HONDA (kazuhito at ph dot noda dot tus dot ac dot jp)
Obtained from: NetBSD (indirectly)
MFC after: 2 weeks
These devices should be probed first because they are at fixed
locations and cannot be turned off. ISA PNP devices, on the other
hand, can be turned off and often can be flexible in the resources
they use. Probe them last, as always.
on UltraSPARC workstations. The driver is based on OpenBSD's SBus
cs4231 driver and heavily modified to incorporate into sound(4)
infrastructure. Due to the lack of APCDMA documentation, the DMA
code of SBus cs4231 came from OpenBSD's driver.
The driver runs without Giant lock and supports both SBus and EBus
based CS4231 audio controller. Special thanks to marius for providing
feedbacks during the driver writing. His feedback made it possible
to write hiccup free playback code under high system loads.
Approved by: jake (mentor)
Reviewed by: marius (initial version)
Tested by: marius, kwm, Julian C. Dunn(jdunn AT opentrend DOT net)
handle DMA addresses located above 1GB. The LBA(loop begin address)
register which holds DMA base address is 32bits register. But the
MSB 2bits are used for other purposes. This effectivly limits the
DMA address space up to 1GB.
Approved by: jake (mentor)
Reviewed by: truckman, matk
assign DMA address to the wrong address. It can cause system lockup
or other mysterious errors. Since most sound cards requires low DMA
address(BUS_SPACE_MAXADDR_24BIT) sndbuf_alloc() would fail when the
audio driver is loaded after long running of operations.
Approved by: jake (mentor)
Reviewed by: truckman, matk
that conjures up the device node so it isn't true PNP. Noticed by jhb@.
* Add an attachment for esscontrol since it too uses ISA_PNP_PROBE.
* Move an attachment from snd_mss to snd_pnpmss. The latter is the real
PNP user.
calls in sb_cmd2() and sb_getmixer(). The lock has already be grabbed
before these functions are called.
This is a RELENG_5 candidate.
PR: 71189
Submitted by: stephane
MFC after: 3 days
holds sndstat_lock across a call to uiomove(), which is not legal
to do with a mutex because of the possibility that the data transfer
could sleep because of a page fault. It is not possible to just
unlock the mutex for the uiomove() call without introducing another
locking mechanism to prevent the body of sndstat_read() from being
re-entered. Converting sndstat_lock to an sx lock is the least
complicated change.
This is a candidate for RELENG_5.
LOR: 030
MFC after: 4 days
allocation. Notably, in this case, the driver tries to allocate several
pieces of memory and then fails if the pieces allocated after the first
do not come after it physically, and within a specific range (8MB I
believe). Of course, this could just as easily fail for any number of
reasons, but it almost always fails now that contiguous allocations start
at the end of possible specified memory locations rather than the beginning.
Allocate all the possibly-needed memory up front, even though it's a waste,
to get around this. The least bogus solution would be to take the physical
address from the first allocation and create a new tag that specified that
further allocations must follow it within that 8MB window, then use that
when allocating new channels, but that's left for anyone else that really
feels like doing it.
Tested by: Erwin Lansing <erwin@lansing.dk>
- `sound'
The generic sound driver, always required.
- `snd_*'
Device-dependent drivers, named after the sound module names.
Configure accordingly to your hardware.
In addition, rename the `snd_pcm' module to `sound' in order to sync
with the driver names.
Suggested by: cg
for unknown events.
A number of modules return EINVAL in this instance, and I have left
those alone for now and instead taught MOD_QUIESCE to accept this
as "didn't do anything".
The big lines are:
NODEV -> NULL
NOUDEV -> NODEV
udev_t -> dev_t
udev2dev() -> findcdev()
Various minor adjustments including handling of userland access to kernel
space struct cdev etc.
I added bounds checking to the patch and cg improved
the formular.
Submitted by: Andriy Gapon <avg@icyb.net.ua>
PR: kern/65485
Approved by: cg
Reviewed by: imp, rwatson, le
exactly as done in the cmi driver. I am quite confident this is
safe since I'm runing this for more than two weeks now, on an SMP
box. A few people tested this patch for me successfully as well.
proper locking to be checked at runtime.
Remove sb_lock() and sb_unlock() calls from sb_reset_dsp() because the
latter is called from sb_setup() with the lock already held. Add a
call to sb_lockassert().
Surround the call to sb_reset_dsp() in sb16_attach() with sb_lock()
and sb_unlock() calls.
Tested by: Bartek Marcinkiewicz <junior AT p233.if.pwr.wroc.pl>
of you with other cards, please do review and test the drivers for
MP-safety and disable Giant in the interrupt routines when you are
sure of proper functionality.
because they bogusly check for defined(INTR_MPSAFE) -- something which
never was a #define. Correct the definitions.
This make INTR_TYPE_AV finally get used instead of the lower-priority
INTR_TYPE_TTY, so it's quite possible some improvement will be had
on sound driver performance. It would also make all the drivers
marked INTR_MPSAFE actually run without Giant (which does seem to
work for me), but:
INTR_MPSAFE HAS BEEN REMOVED FROM EVERY SOUND DRIVER!
It needs to be re-added on a case-by-case basis since there is no one
who will vouch for which sound drivers, if any, willy actually operate
correctly without Giant, since there hasn't been testing because of
this bug disabling INTR_MPSAFE.
Found by: "Yuriy Tsibizov" <Yuriy.Tsibizov@gfk.ru>
read-only. Need to enable "legacy support", by poking
into pci config space. (comment from the patch)
Submited by: Autrijus Tang <autrijus@autrijus.org>
Approved by: tanimura (mentor)
This change has not been tested.
This change was triggered by a gcc(1) warning on ia64 at -O2. The
variable v was not used after being computed, which resulted in enough
dead code elimination (DCE) to confuse the compiler and emit a bogus
warning about the use of the variable i without prior definition. The
variable i is the loop variable.
Submitted by: des
Responsibility: marcel
rid of the MTX_DUPOK flag on channel mutexes, which allows witness to
do a better job of lock order checking. Nuke snd_chnmtxcreate() since
it is no longer needed.
Tested by: matk
channel at a time unless it is actually necessary to lock both.
This avoids problems with lock order reversal and malloc() calls
with a mutex held when lower level code unlocks a channel, calls malloc(),
and relocks the channel. This also avoids the cost of some unnecessary
locking and unlocking.
Tested by: matk
Remove the unused second argument from udev2dev().
Convert all remaining users of makedev() to use udev2dev(). The
semantic difference is that udev2dev() will only locate a pre-existing
dev_t, it will not line makedev() create a new one.
Apart from the tiny well controlled windown in D_PSEUDO drivers,
there should no longer be any "anonymous" dev_t's in the system
now, only dev_t's created with make_dev() and make_dev_alias()
Introduce d_version field in struct cdevsw, this must always be
initialized to D_VERSION.
Flip sense of D_NOGIANT flag to D_NEEDGIANT, this involves removing
four D_NOGIANT flags and adding 145 D_NEEDGIANT flags.
panic() so that the buffer overflow just beyond this point is always
caught, even when the code is not compiled with INVARIANTS.
Change chn_setblocksize() buffer reallocation code to attempt to avoid
the feed_vchan16() buffer overflow by attempting to always keep the
bufsoft buffer at least as large as the bufhard buffer.
Print a diagnositic message
Danger! %s bufsoft size increasing from %d to %d after CHANNEL_SETBLOCKSIZE()
if our best attempts fail. If feed_vchan16() were to be called by
the interrupt handler while locks are dropped in chn_setblocksize()
to increase the size bufsoft to match the size of bufhard, the panic()
code in feed_vchan16() will be triggered. If the diagnostic message
is printed, it is a warning that a panic is possible if the system
were to see events in an "unlucky" order.
Change the locking code to avoid the need for MTX_RECURSIVE mutexes.
Add the MTX_DUPOK option to the channel mutexes and change the locking
sequence to always lock the parent channel before its children to avoid
the possibility of deadlock.
Actually implement locking assertions for the channel mutexes and fix
the problems found by the resulting assertion violations.
Clean up the locking code in dsp_ioctl().
Allocate the channel buffers using the malloc() M_WAITOK option instead
of M_NOWAIT so that buffer allocation won't fail. Drop locks across
the malloc() calls.
Add/modify KASSERTS() in attempt to detect problems early.
Abuse layering by adding a pointer to the snd_dbuf structure that points
back to the pcm_channel that owns it. This allows sndbuf_resize() to do
proper locking without having to change the its API, which is used by
the hardware drivers.
Don't dereference a NULL pointer when setting hw.snd.maxautovchans
if a hardware driver is not loaded. Noticed by Ryan Sommers
<ryans at gamersimpact.com>.
Tested by: Stefan Ehmann <shoesoft AT gmx.net>
Tested by: matk (Mathew Kanner)
Tested by: Gordon Bergling <gbergling AT 0xfce3.net>
device that doesn't exists. I'm using my discretion and
committing without mentor approval since Seigo is away.
Noticed by: Maxime Henrion <mux@freebsd.org>
This takes us a lot closer to refcounting dev_t.
This patch originally by cg@ with a few minor changes by me.
It is largely untested, but has been HEADSUP'ed twice, so presumably
people have not found any issues with it.
Submitted by: cg@
I started with a year-old patch by Orlando Bassotto
<orlando.bassotto@ieo-research.it>, and ported it to 5.2-CURRENT along with
fixing the problems working with pre-Audigy cards.
dsp_open: rearrange to only hold one lock at a time
dsp_close: ditto
mixer_hwvol_init: delete locking, the only consumer seems to
be the ess driver and it only call it a creation time, I
think the device will be stable across the sleepable malloc.
cmi interrupt routine: Release locks while caller chn_intr,
either this or do what emu10k1 does which is have no locks
at in the interrupt handler.
Submitted by: mat@cnd.mcgill.ca
thread being waken up. The thread waken up can run at a priority as
high as after tsleep().
- Replace selwakeup()s with selwakeuppri()s and pass appropriate
priorities.
- Add cv_broadcastpri() which raises the priority of the broadcast
threads. Used by selwakeuppri() if collision occurs.
Not objected in: -arch, -current
round the result up to a multiple of 4 bytes so that it will always
be a multiple of the sample size. Also use the actual buffer size
from sc->bufsz instead of the default DS1_BUFFSIZE.
This fixes panics and bad distortion I have seen on Yamaha DS-1
hardware, mainly when playing certain Real Audio media.
Reviewed by: orion (an earlier version of the patch)
first sample in the buffer to be ignored. The bug caused a repetitive
glitch in one of the stereo channels when playing mono sound on
configurations that use the monotostereo16 feeder.
Reviewed by: orion
o AD1980 hook.
o ac97_fix_auxout.
and:
o Associate AC97_MIX_AUXOUT with SOUND_MIXER_OGAIN rather than
SOUND_MIXER_MONITOR.
o Add ac97_fix_tone to remove tone controls from mixer if invalid.
tested for playback.
* modify device name strings for ich chips to better conform with their
common names.
* remove superflous 'AC97 controller' from nforce device names.
MFC after: 1 week
Add two new arguments to bus_dma_tag_create(): lockfunc and lockfuncarg.
Lockfunc allows a driver to provide a function for managing its locking
semantics while using busdma. At the moment, this is used for the
asynchronous busdma_swi and callback mechanism. Two lockfunc implementations
are provided: busdma_lock_mutex() performs standard mutex operations on the
mutex that is specified from lockfuncarg. dftl_lock() is a panic
implementation and is defaulted to when NULL, NULL are passed to
bus_dma_tag_create(). The only time that NULL, NULL should ever be used is
when the driver ensures that bus_dmamap_load() will not be deferred.
Drivers that do not provide their own locking can pass
busdma_lock_mutex,&Giant args in order to preserve the former behaviour.
sparc64 and powerpc do not provide real busdma_swi functions, so this is
largely a noop on those platforms. The busdma_swi on is64 is not properly
locked yet, so warnings will be emitted on this platform when busdma
callback deferrals happen.
If anyone gets panics or warnings from dflt_lock() being called, please
let me know right away.
Reviewed by: tmm, gibbs
when the user specifies a maximum fragment size < 2.
This is the behavior that Linux provides and fixes the problem I've
observed in Tribes2 where sounds effects are delayed by 1/2 a second.
