at r230551.
Also while there, make sense polling use reported for each node separately
instead of reporting accumulated total status.
Submitted by: Barbara <barbara.freebsd@gmail.com> (1)
MFC after: 3 days
names to shorten them. PulseAudio reported to have problems with names
longer then 63 chars and at least in XMMS long names are inconvinient.
Reported by: hselasky
MFC after: 3 days
another process is in open() or stat() for the device node, then
close() from the owning process does not result in cdevsw close
method call. This fixes the pemanent "Device busy" seen.
Changed the sndstat_lock from mutex to sx. This allows to extend
the region covered by the lock, to include the uiomove() call in
sndstat_read() and bufptr increment. This fixes the "panic:
sbuf_put_byte called with finished or corrupt sbuf" seen.
In collaboration with: kib
MFC after: 1 week
MOD_SHUTDOWN is not an end of existence, and there is a life after it.
In particular, code previously called on MOD_SHUTDOWN grabbed lock and
deallocated unit numbering. That caused infinite wait loop if snd_uaudio
tried to destroy its PCM device after that point.
MFC after: 3 days
Code should just use the devtoname() function to obtain the name of a
character device. Also add const keywords to pieces of code that need it
to build properly.
MFC after: 2 weeks
The cs driver requires a table with firmware values. An
alternative firmware is available in a similar Open Sound
System driver. This is actually a partial revert of
Revision 77504.
Special thanks to joel@ for patiently testing several
replacement attempts.
The csa driver and the complete sound system are now free
of the GPL.
Tested by: joel
Approved by: jhb (mentor)
MFC after: 3 weeks
hardware imposes strict limitations on hard buffer and block sizes.
Previous code set soft buffer to be no smaller then hard buffer. On some
cards with fixed 64K physical buffer that caused up to 800ms play latency.
New code allows to set soft buffer size down to just two blocks of the hard
buffer and to not write more then that size ahead to the hardware buffer.
As result of that change I was able to reduce full practically measured
record-playback loop delay in those conditions down to only about 115ms
with theoretical playback latency of only about 50ms.
New code works fine for both vchans and direct cases. In both cases sound(4)
tries to follow hw.snd.latency_profile and hw.snd.latency values and
application-requested buffer and block sizes as much as limitation of two
hardware blocks allows.
Reviewed by: silence on multimedia@
Remove unneeded temporary variable (data) to better match the OSS code.
Remove some unused constants and type definitions.
Tested by: joel
Approved by: jhb (mentor)
MFC after: 3 weeks
- add "+HP" in case of headphones redirection;
- add device type for analog devices, if all pins have the same.
As result now it may look like "Analog 5.1+HP/2.0" or "Front Analog Mic".
I hope it will be more useful than long and confusing.
MFC after: 2 months
Sponsored by: iXsystems, Inc.
selection in snd_hda(4) driver.
Now driver tracks jack presence detection status for every CODEC pin. For
playback associations, when configured, that information, same as before,
can be used to automatically redirect audio to headphones. Also same as
before, these events are used to track digital display connection status
and fetch ELD. Now in addition to that driver uses that information to
automatically switch recording source of the mixer to the connected input.
When there are devices with no jack detection and with one both connected,
last ones will have the precedence. As result, on most laptops after boot
internal microphone should be automatically selected. But if external one
(for example, headset) connected, it will be selected automatically.
When external mic disconnected, internal one will be selected again.
Automatic recording source selection is enabled by default now to make
recording work out of the box without touching mixer. But it can be
disabled or limited only to attach time using hint.pcm.X.rec.autosrc loader
tunables or dev.pcm.X.rec.autosrc sysctls.
MFC after: 2 months
Sponsored by: iXsystems, Inc.
(HDMI and HBR bits set) and needed (AC3 format used with 8 channels).
This should allow DTS-HD/TrueHD pass-through with rates above 6.144Mbps.
MFC after: 2 months
Sponsored by: iXsystems, Inc.
widgets. I am not sure if S/PDIF supports 32bit samples, but my Marantz
SR4001 doesn't, producing only single clicks on playback start/stop.
Because HDA controller requires 32bit alignment for all samples above 16bit,
we can't handle this situation in regular way and have to set 32bit format
in sound(4) for anything above 16bit. To workaround the problem, prefer
to setup hardware to use 24/20bit samples when 32bit format requested. Add
dev.pcm.X.play.32bit and dev.pcm.X.rec.32bit sysctls to control what format
really use for 32bit samples.
MFC after: 2 months
Sponsored by: iXsystems, Inc.
maximal from 64K to 256K.
We usually don't need 750 sound interrupts per second (1.3ms latency)
when playing 192K/24/8 stream. 187 should be better. On usual 48K/16/2
it is just enough for hw.snd.latency=9 at hw.snd.latency_profile=1 with
23 and 6 interrupts per second.
MFC after: 2 weeks
Sponsored by: iXsystems, Inc.
Previous code was relatively dumb. During CODEC probe it was tracing signals
and statically binding amplifier controls to the OSS mixer controls. To set
volume it just set all bound amplifier controls proportionally to mixer
level, not looking on their hierarchy and amplification levels/offsets.
New code is much smarter. It also traces signals during probe, but mostly
to find out possible amplification control rages in dB for each specific
signal. To set volume it retraces each affected signal again and sets
amplifiers controls recursively to reach desired amplification level in dB.
It would be nice to export values in dB to user, but unluckily our OSS mixer
API is too simple for that.
As result of this change:
- cascaded amplifiers will work together to reach maximal precision.
If some input has 0/+40dB preamplifier with 10dB step and -10/+10dB mixer
with 1dB step after it, new code will use both to provide 0/+40dB control
with 1dB step! We could even get -10/+50dB range there, but that is
intentionally blocked for now.
- different channels of multichannel associations on non-uniform CODECs
such as VIA VT1708S will have the same volume, not looking that control
ranges are different. It was not good when fronts were 12dB louder.
- for multiplexed recording, when we can record from only one source at
a time, we can now use recording amplifier controls to set different
volume levels for different inputs if they have no own controls of they
are less precise. If recording source change, amplifiers will be
reconfigured.
To improve out-of-the-box behavior, ignore default volume levels set by
sound(4) and use own, more reasonable: +20dB for mics, -10dB for analog
output volume and 0dB for the rest of controls. sound(4) defaults of 75%
mean absolutely random things for different controls of different CODECs
because of very different control ranges.
Together with further planned automatic recording source selection this
should allow users to get fine playback and recording without touching
mixer first.
Note that existing users should delete /var/db/mixer*-state and reboot
or trigger CODEC reconfiguration to get new default values.
MFC after: 2 months
Sponsored by: iXsystems, Inc.
versions derived from /usr/ports/audio/oss.
The particular headers used were taken from the
attic/drv/oss_allegro directory and are mostly identical
to the previous files.
The Maestro3 driver is now free from the GPL.
NOTE: due to lack of testers this driver is being
considered for deprecation and removal.
PR: kern/153920
Approved by: jhb (mentor)
MFC after: 2 weeks
frightening "unknown" word. In most cases we don't need to know chips
to properly handle them, but having IDs in logs may simplify debugging.
MFC after: 2 weeks
Sponsored by: iXsystems, Inc.
of HDA bus. Handle that from two directions:
- Add support for "striping" (using several SDO lines), if supported.
- Account HDA bus utilization and return error on new stream allocation
attempt if remaining bandwidth is unsifficient.
Most of HDA controllers have one SDO line with 46Mbps output bandwidth.
NVIDIA GF210 has 2 lines - 92Mbps. NVIDIA GF520 has 4 lines - 184Mbps!
MFC after: 2 months
Sponsored by: iXsystems, Inc.
- Enable and handle unsolicited responses from digital display pins,
reporting connection and EDID-Like Data (ELD) validity status changes.
- Fetch ELD data, describing connected digital display device audio
capabilities. These data not really used at the moment (user is not
denied to use audio formats not supported by the device), only printed to
verbose logs. But they are useful for debugging. The fact that ELD was
received tells that HDMI link was established and video driver enabled
HDMI audio passthrough. Some old chips may not return ELD, so lack of it
is not necessary a problem.
- Add some more points to CODEC configuration sequence:
- For converter widgets, supporting more then two channels (HDMI/DP
converter widgets support 8), set number of channels to handle.
- For digital display pins (HDMI/DP) fill audio infoframe, reporting
connected device about number of channels and speakers allocation.
- For digital display pins (HDMI/DP) set mapping between channels seen
by software and channels transferred via HDMI/DisplayPort.
- Allow more audio formats, not used for analog connections because of
stereo pairs orientation, but easily applicable to HDMI/DisplayPort: 2.1,
3.0, 3.1, 4.1, 5.0, 6.0, 6.1, 7.0. That list may be filtered later using
info from ELD.
- Disable MSI interrupts for NVIDIA HDA controllers before GT520.
At this point I can successfully play audio over HDMI from NVIDIA GT210
and GT520 cards with nvidia-driver-290.10 driver to Marantz SR4001
receiver in 2.0, 2.1, 3.0, 4.0, 4.1, 5.0 and 5.1 PCM formats at 44, 48,
88 and 96KHz at 16 and 24 bits, same as do AC3/DTS passthrough.
6.0, 6.1, 7.0 and 7.1 PCM formats are not working for me, but I think
it is because of receiver age.
MFC after: 2 months
Sponsored by: iXsystems, Inc.
- Huge old hdac driver was split into three independent pieces: HDA
controller driver (hdac), HDA CODEC driver (hdacc) and HDA sudio function
driver (hdaa).
- Support for multichannel recording was added. Now, as specification
defines, driver checks input associations for pins with sequence numbers
14 and 15, and if found (usually) -- works as before, mixing signals
together. If it doesn't, it configures input association as multichannel.
- Signal tracer was improved to look for cases where several DACs/ADCs in
CODEC can work with the same audio signal. If such case found, driver
registers additional playback/record stream (channel) for the pcm device.
- New controller streams reservation mechanism was implemented. That
allows to have more pcm devices then streams supported by the controller
(usually 4 in each direction). Now it limits only number of simultaneously
transferred audio streams, that is rarely reachable and properly reported
if happens.
- Codec pins and GPIO signals configuration was exported via set of
writable sysctls. Another sysctl dev.hdaa.X.reconfig allows to trigger
driver reconfiguration in run-time.
- Driver now decodes pins location and connector type names. In some cases
it allows to hint user where on the system case connectors, related to the
pcm device, are located. Number of channels supported by pcm device,
reported now (if it is not 2), should also make search easier.
- Added workaround for digital mic on some Asus laptops/netbooks.
MFC after: 2 months
Sponsored by: iXsystems, Inc.
This uses the emuxkireg.h already used in the emu10k1
snd driver. Special thanks go to Alexander Motin as
he was able to find some errors and reverse engineer
some wrong values in the emuxkireg header.
The emu10kx driver is now free from the GPL.
PR: 153901
Tested by: mav, joel
Approved by: jhb (mentor)
MFC after: 2 weeks
This brings in the emuxkireg.h from NetBSD (dev/pci) which
is used for the same purpose but is smaller. The emu10k1
is now free from the GPL.
PR: 153901
Obtained from: NetBSD
Approved by: core (mentor implicit)
MFC after: 2 weeks
will time out and close opened /dev/dspX.Y device(s), if
any. This is a workaround because we cannot unregister PCM
devices while the audio character device is in use.
Add a missing inclusion guard.
MFC after: 1 weeks
one. Interestingly, these are actually the default for quite some time
(bus_generic_driver_added(9) since r52045 and bus_generic_print_child(9)
since r52045) but even recently added device drivers do this unnecessarily.
Discussed with: jhb, marcel
- While at it, use DEVMETHOD_END.
Discussed with: jhb
- Also while at it, use __FBSDID.
The SYSCTL_NODE macro defines a list that stores all child-elements of
that node. If there's no SYSCTL_DECL macro anywhere else, there's no
reason why it shouldn't be static.
patch modifies makesyscalls.sh to prefix all of the non-compatibility
calls (e.g. not linux_, freebsd32_) with sys_ and updates the kernel
entry points and all places in the code that use them. It also
fixes an additional name space collision between the kernel function
psignal and the libc function of the same name by renaming the kernel
psignal kern_psignal(). By introducing this change now we will ease future
MFCs that change syscalls.
Reviewed by: rwatson
Approved by: re (bz)
LED controller used to run the load graph on the server's front panel.
Reported by: Paul Mather <paul at gromit dot dlib dot vt dot edu>
MFC after: 3 days
sorted according to the mode which they support:
host, device or dual mode
- Add generic tool to extract these data:
tools/bus_autoconf
Discussed with: imp
Suggested by: Robert Millan <rmh@debian.org>
PR: misc/157903
MFC after: 14 days
of just setting it to the first registered device, reevaluate it for each
device registered, trying to choose best candidate, unless one was forced.
For now use such preference order: play&rec, play, rec.
As side effect, this should workaround the situation when HDMI audio output
of the video card, usually not connected to anything, becomes default, that
requires manual user intervention to make sound working. If at some point
this won't be enough, we can try to fetch some additional priority flags
from the device driver.
This brings USB bus more in line with how newbus is supposed to be used.
Also, because of the two-pass probing the following message was produced
by devd in default configuration when almost any USB device was
connected:
Unknown USB device: vendor <> product <> bus <>
This should be fixed now.
Note that many USB device drivers pass some information from probe
method to attach method via ivars. For this to continue working we rely
on the fact that the subr_bus code calls probe method of a winning driver
again before calling its attach method in the case where multiple
drivers claim to support a device. This is done because device
description is set in successful probe methods and we want to get a correct
device description from a winning driver. So now this logic is re-used
for setting ivars too.
Reviewed by: hselasky
MFC after: 1 month
Casting a pointer to a wide integer is probably not that bad, but I am
still guilty of not testing this.
Pointyhat to: avg
MFC after: 1 week
X-MFC with: r221803
This brings our implementation in line with OSS specification for
systems that support mmap. The change should also improve compatibility
with OSS software not specifically written for FreeBSD, e.g. PulseAudio
OSS plugin.
Reviewed by: kib, jhb
MFC after: 1 week
Rationale:
- unlike current behavior this seems to be compliant with OSS
specification:
http://manuals.opensound.com/developer/SNDCTL_DSP_GETIPTR.html
- this seems to meet expectations of some OSS programs compiled for or
ported from Linux, e.g. ALSA OSS plugin
- this doesn't seem to break any programs as far as current testing
shows
Tested by: nox, hselasky
MFC after: 4 days
also does this for sound drivers it's probably not necessary for all
combinations of controllers and drivers. However, given that our sound
drivers completely lack bus_dmamap_sync(9) calls this at least serves
as a workaround when enabling use of the IOMMU streaming buffers on
sparc64 and generally for arm and mips.
MFC after: 2 weeks
means of allowing vendor specific interface class for audio and MIDI devices.
- Add new quirks for this. The vendor and product list in OpenBSD's
dev/usb/umidi_quirks.c was used as reference.
MFC after: 14 days
Approved by: thompsa (mentor)
- Use the USB stack's builtin clear-stall feature.
- Wrap some long lines.
- Use memcpy() instead of bcopy().
- Use memset() instead of bzero().
- Tested applications:
/usr/ports/audio/fluidsynth
MFC after: 7 days
Approved by: thompsa (mentor)
- SMBus Controller
- SATA Controller
- HD Audio Controller
- Watchdog Controller
Thanks to Seth Heasley (seth.heasley@intel.com) for providing us code.
MFC after 3 days
the original amd64 and i386 headers with stubs.
Rename (AMD64|I386)_BUS_SPACE_* to X86_BUS_SPACE_* everywhere.
Reviewed by: imp (previous version), jhb
Approved by: kib (mentor)
configuration registers directly.
Remove pci_enable_io calls where they are redundant. The PCI bus driver
will set the right bits when the corresponding bus resource is activated.
Remove redundant pci_* function calls from suspend/resume methods. The
bus driver already saves and restores the PCI configuration.
Reviewed by: jhb
Approved by: kib (mentor)
infrastructure, not us. This appears to be a leftover from an older
version of the driver.
Submitted by: avg
Tested by: Anton Shterenlikht <mexas bristol.ac.uk>
MFC after: 1 week
X-MFC-Note: To stable/8 and stable/7 only
properly short terminate their transfers. This fixes a problem where input
appears several seconds late.
Reported by: Alexander Yerenkow
Submitted by: Hans Petter Selasky
Although the sysctls are marked with CTLFLAG_RD and the values will stay
immutable, current sysctl implementation stores value pointer in
void* type, which means that const qualifier is discarded anyway
and some newer compilers complaint about that.
We can't use de-const trick in sysctl implementation, because in that
case we could miss an opposite situation where a const value is used
with CTLFLAG_RW sysctl.
Complaint from: gcc 4.4, clang
MFC after: 2 weeks
by zero of the second argument 'from'.
- Prefer u_int32_t over unsigned int to make its intention more clearer.
- Move the function to a header file and make it a static inline function.
Pointed out by: Andrew Reilly (areilly at bigpond dot net dot au)[1]
MFC after: 3 days
On top of that, LLVM+Clang mis-compiles this code because of its register
allocator bug.
Analyzed by: Andrew Reilly (areilly at bigpond dot net dot au)
Reviewed by: ariff, rdivacky
MFC after: 3 days
volumes were incorrectly calculated.
I've tested this with one of my es1370 cards and I can confirm that it
works.
PR: 98167
Submitted by: Joseph Terner <jtsn@gmx.de>
Approved by: kib
loopback.
- Change the meaning of "mix" OSS control. Now it controls loopback level,
according to comments in soundcard.h.
- Allow AD1981HD codecs to use playback mixer. Now driver should be able to
really use it.
- Fix bug in shared muters operation.
as different nearby ones, and was grabbed by MIXER_xxx() handler.
While there, replace '(cmd & MIXER_xxx(0)) == MIXER_xxx(0)' expressions
with more correct '(cmd & ~0xff) == MIXER_READ(0)'. Use of bit operations
to compare numeric fields doesn't looks sane.
MFC after: 1 month
now due to unidentified synchonization problem. For 7.1 soundcards 5.1
support handled correctly via software upmix done by sound(4).
Stereo stream is no more duplicated to all ports. If you loose sound, check
you are using right connectors. Front speakers connector is usually green,
center/LFE - orange, rear - black, side - gray.
This replaces d_mmap() with the d_mmap2() implementation and also
changes the type of offset to vm_ooffset_t.
Purge d_mmap2().
All driver modules will need to be rebuilt since D_VERSION is also
bumped.
Reviewed by: jhb@
MFC after: Not in this lifetime...
Fix some wrong usages.
Note: this does not affect generated binaries as this argument is not used.
PR: 137213
Submitted by: Eygene Ryabinkin (initial version)
MFC after: 1 month
- fix issues regarding the mixer, where the interface number was not set in
time.
- fix wrong use of resolution parameter.
Submitted by: Hans Petter Selasky
30-bit like the reset of the controllers supported by this driver.
Actually ALi M5451 can be setup up to generate 32-bit addresses by
setting the 31st bit via the accompanying ISA bridge, which allows
it to work in sparc64 machines whose IOMMU require at least 32-bit
DMA. Even though other architectures would also benefit from 32-bit
DMA, enabling this bit is limited to sparc64 as bus_dma(9) doesn't
generally guarantee that a low address of BUS_SPACE_MAXADDR_32BIT
results in a buffer in the 32-bit range.
- According to Tatsuo YOKOGAWA's ali(4), the the DMA transfer size of
ALi M5451 is fixed to 64k and in fact using the default size of 4k
- The 4DWAVE DX and NX require the recording buffer to be 8-byte
aligned so adjust the bus_dma_tag_create(9) accordingly.
- Unlike the rest of the controllers supported by this driver, the
ALi M5451 only has 32 hardware channels instead of 64 so limit the
loop in tr_intr() accordingly. [1]
Submitted by: yongari [1]
Reviewed by: yongari (superset of what is committed)
MFC after: 3 days
The newbus lock is responsible for protecting newbus internIal structures,
device states and devclass flags. It is necessary to hold it when all
such datas are accessed. For the other operations, softc locking should
ensure enough protection to avoid races.
Newbus lock is automatically held when virtual operations on the device
and bus are invoked when loading the driver or when the suspend/resume
take place. For other 'spourious' operations trying to access/modify
the newbus topology, newbus lock needs to be automatically acquired and
dropped.
For the moment Giant is also acquired in some key point (modules subsystem)
in order to avoid problems before the 8.0 release as module handlers could
make assumptions about it. This Giant locking should go just after
the release happens.
Please keep in mind that the public interface can be expanded in order
to provide more support, if there are really necessities at some point
and also some bugs could arise as long as the patch needs a bit of
further testing.
Bump __FreeBSD_version in order to reflect the newbus lock introduction.
Reviewed by: ed, hps, jhb, imp, mav, scottl
No answer by: ariff, thompsa, yongari
Tested by: pho,
G. Trematerra <giovanni dot trematerra at gmail dot com>,
Brandon Gooch <jamesbrandongooch at gmail dot com>
Sponsored by: Yahoo! Incorporated
Approved by: re (ksmith)
This dramatically pushing 99.9% interpolations and quantizations
error _below_ -180dB on 32bit dynamic range, resulting extremely
high quality conversion.
- Use BSPLINE interpolator for filter oversampling factor greater or
equal than 64 (log2 6).
Approved by: re (kib)
This cause dramatic effect in overall precision and conversion quality
by pushing down most aliasing artifacts around -180 dB.
Spectrogram analysis/comparison:
http://people.freebsd.org/~ariff/z_comparison/z_28vs30/
- Guard against possible 64bit overflow during accumulation process by
slightly normalize and saturate sample and coefficient multiplication,
possible during extreme 32bit downsampling (eg. 380KHz -> 8KHz) with
custom preset that require more than ~7000 taps filter (which is
overkill).
- Add knobs through FEEDER_RATE_PRESETS to set dynamic range of filter
coefficients/accumulator and prefered polynomial interpolator:
COEFFICIENT_BIT:X
(where 1 <= X <= 30, default: 30)
ACCUMULATOR_BIT:X
(where 32 <= X <=64, default: 58)
INTERPOLATOR:I
(where I = ZOH, LINEAR, QUADRATIC, HERMITE, BSPLINE,
OPT32X, OPT16X, OPT8X, OPT4X, OPT2X)
Approved by: re (kib)
Note that this does not actually enable full-range i/o requests for
64 architectures, and is done now to update KBI only.
Tested by: pho
Reviewed by: jhb, bde (as part of the review of the bigger patch)
- honor parent DMA tag limitations, as man page requires,
- allow data buffer to be allocated within full 64bit address range, when
support is announced by hardware,
- add quirk, disabling 64bit addresses for broken chips, use it for MCP78.