2006-10-01 11:13:00 +00:00
|
|
|
/*-
|
|
|
|
* Copyright (c) 2006 Stephane E. Potvin <sepotvin@videotron.ca>
|
|
|
|
* Copyright (c) 2006 Ariff Abdullah <ariff@FreeBSD.org>
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
* Copyright (c) 2008 Alexander Motin <mav@FreeBSD.org>
|
2006-10-01 11:13:00 +00:00
|
|
|
* All rights reserved.
|
|
|
|
*
|
|
|
|
* Redistribution and use in source and binary forms, with or without
|
|
|
|
* modification, are permitted provided that the following conditions
|
|
|
|
* are met:
|
|
|
|
* 1. Redistributions of source code must retain the above copyright
|
|
|
|
* notice, this list of conditions and the following disclaimer.
|
|
|
|
* 2. Redistributions in binary form must reproduce the above copyright
|
|
|
|
* notice, this list of conditions and the following disclaimer in the
|
|
|
|
* documentation and/or other materials provided with the distribution.
|
|
|
|
*
|
|
|
|
* THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
|
|
|
|
* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
|
|
|
|
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
|
|
|
|
* ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
|
|
|
|
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
|
|
|
|
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
|
|
|
|
* OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
|
|
|
|
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
|
|
|
|
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
|
|
|
|
* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
|
|
|
|
* SUCH DAMAGE.
|
|
|
|
*/
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Intel High Definition Audio (Controller) driver for FreeBSD. Be advised
|
|
|
|
* that this driver still in its early stage, and possible of rewrite are
|
|
|
|
* pretty much guaranteed. There are supposedly several distinct parent/child
|
|
|
|
* busses to make this "perfect", but as for now and for the sake of
|
|
|
|
* simplicity, everything is gobble up within single source.
|
|
|
|
*
|
|
|
|
* List of subsys:
|
|
|
|
* 1) HDA Controller support
|
|
|
|
* 2) HDA Codecs support, which may include
|
|
|
|
* - HDA
|
|
|
|
* - Modem
|
|
|
|
* - HDMI
|
|
|
|
* 3) Widget parser - the real magic of why this driver works on so
|
|
|
|
* many hardwares with minimal vendor specific quirk. The original
|
|
|
|
* parser was written using Ruby and can be found at
|
|
|
|
* http://people.freebsd.org/~ariff/HDA/parser.rb . This crude
|
|
|
|
* ruby parser take the verbose dmesg dump as its input. Refer to
|
|
|
|
* http://www.microsoft.com/whdc/device/audio/default.mspx for various
|
Welcome to Once-a-year Sound Mega-Commit. Enjoy numerous updates and fixes
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.
2006-11-26 12:24:06 +00:00
|
|
|
* interesting documents, especially UAA (Universal Audio Architecture).
|
2006-10-01 11:13:00 +00:00
|
|
|
* 4) Possible vendor specific support.
|
|
|
|
* (snd_hda_intel, snd_hda_ati, etc..)
|
|
|
|
*
|
|
|
|
* Thanks to Ahmad Ubaidah Omar @ Defenxis Sdn. Bhd. for the
|
|
|
|
* Compaq V3000 with Conexant HDA.
|
|
|
|
*
|
|
|
|
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
|
|
|
|
* * *
|
|
|
|
* * This driver is a 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> *
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
* * Alexander Motin <mav@FreeBSD.org> *
|
2006-10-01 11:13:00 +00:00
|
|
|
* * *
|
|
|
|
* * ....and various people from freebsd-multimedia@FreeBSD.org *
|
|
|
|
* * *
|
|
|
|
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include <dev/sound/pcm/sound.h>
|
|
|
|
#include <dev/pci/pcireg.h>
|
|
|
|
#include <dev/pci/pcivar.h>
|
|
|
|
|
2007-07-01 17:31:20 +00:00
|
|
|
#include <sys/ctype.h>
|
|
|
|
#include <sys/taskqueue.h>
|
|
|
|
|
2006-10-01 11:13:00 +00:00
|
|
|
#include <dev/sound/pci/hda/hdac_private.h>
|
|
|
|
#include <dev/sound/pci/hda/hdac_reg.h>
|
|
|
|
#include <dev/sound/pci/hda/hda_reg.h>
|
|
|
|
#include <dev/sound/pci/hda/hdac.h>
|
|
|
|
|
|
|
|
#include "mixer_if.h"
|
|
|
|
|
2008-09-16 20:03:34 +00:00
|
|
|
#define HDA_DRV_TEST_REV "20080916_0112"
|
2006-10-01 11:13:00 +00:00
|
|
|
|
|
|
|
SND_DECLARE_FILE("$FreeBSD$");
|
|
|
|
|
2007-05-05 09:17:36 +00:00
|
|
|
#define HDA_BOOTVERBOSE(stmt) do { \
|
|
|
|
if (bootverbose != 0 || snd_verbose > 3) { \
|
|
|
|
stmt \
|
|
|
|
} \
|
2006-10-01 11:13:00 +00:00
|
|
|
} while(0)
|
|
|
|
|
2008-09-16 20:03:34 +00:00
|
|
|
#define HDA_BOOTHVERBOSE(stmt) do { \
|
|
|
|
if (snd_verbose > 3) { \
|
|
|
|
stmt \
|
|
|
|
} \
|
|
|
|
} while(0)
|
|
|
|
|
2006-10-02 16:30:04 +00:00
|
|
|
#if 1
|
2006-10-01 11:13:00 +00:00
|
|
|
#undef HDAC_INTR_EXTRA
|
|
|
|
#define HDAC_INTR_EXTRA 1
|
|
|
|
#endif
|
|
|
|
|
2006-10-02 16:30:04 +00:00
|
|
|
#define hdac_lock(sc) snd_mtxlock((sc)->lock)
|
|
|
|
#define hdac_unlock(sc) snd_mtxunlock((sc)->lock)
|
- Fix wrong id for ALC882, add ALC883 id.
- 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"
2006-10-06 18:59:27 +00:00
|
|
|
#define hdac_lockassert(sc) snd_mtxassert((sc)->lock)
|
|
|
|
#define hdac_lockowned(sc) mtx_owned((sc)->lock)
|
2006-10-02 16:30:04 +00:00
|
|
|
|
2008-04-12 15:07:32 +00:00
|
|
|
#undef HDAC_MSI_ENABLED
|
|
|
|
#if __FreeBSD_version >= 700026 || \
|
|
|
|
(__FreeBSD_version < 700000 && __FreeBSD_version >= 602106)
|
|
|
|
#define HDAC_MSI_ENABLED 1
|
|
|
|
#endif
|
|
|
|
|
2006-10-02 16:30:04 +00:00
|
|
|
#define HDA_FLAG_MATCH(fl, v) (((fl) & (v)) == (v))
|
2006-10-12 04:19:37 +00:00
|
|
|
#define HDA_DEV_MATCH(fl, v) ((fl) == (v) || \
|
|
|
|
(fl) == 0xffffffff || \
|
|
|
|
(((fl) & 0xffff0000) == 0xffff0000 && \
|
|
|
|
((fl) & 0x0000ffff) == ((v) & 0x0000ffff)) || \
|
|
|
|
(((fl) & 0x0000ffff) == 0x0000ffff && \
|
|
|
|
((fl) & 0xffff0000) == ((v) & 0xffff0000)))
|
2006-10-02 16:30:04 +00:00
|
|
|
#define HDA_MATCH_ALL 0xffffffff
|
|
|
|
#define HDAC_INVALID 0xffffffff
|
2006-10-01 11:13:00 +00:00
|
|
|
|
2007-05-05 09:17:36 +00:00
|
|
|
/* Default controller / jack sense poll: 250ms */
|
|
|
|
#define HDAC_POLL_INTERVAL max(hz >> 2, 1)
|
|
|
|
|
2007-07-01 17:31:20 +00:00
|
|
|
/*
|
|
|
|
* Make room for possible 4096 playback/record channels, in 100 years to come.
|
|
|
|
*/
|
|
|
|
#define HDAC_TRIGGER_NONE 0x00000000
|
|
|
|
#define HDAC_TRIGGER_PLAY 0x00000fff
|
|
|
|
#define HDAC_TRIGGER_REC 0x00fff000
|
|
|
|
#define HDAC_TRIGGER_UNSOL 0x80000000
|
|
|
|
|
2006-10-01 11:13:00 +00:00
|
|
|
#define HDA_MODEL_CONSTRUCT(vendor, model) \
|
|
|
|
(((uint32_t)(model) << 16) | ((vendor##_VENDORID) & 0xffff))
|
|
|
|
|
|
|
|
/* Controller models */
|
|
|
|
|
|
|
|
/* Intel */
|
|
|
|
#define INTEL_VENDORID 0x8086
|
|
|
|
#define HDA_INTEL_82801F HDA_MODEL_CONSTRUCT(INTEL, 0x2668)
|
2007-07-09 20:42:11 +00:00
|
|
|
#define HDA_INTEL_63XXESB HDA_MODEL_CONSTRUCT(INTEL, 0x269a)
|
2006-10-01 11:13:00 +00:00
|
|
|
#define HDA_INTEL_82801G HDA_MODEL_CONSTRUCT(INTEL, 0x27d8)
|
2006-10-08 18:51:58 +00:00
|
|
|
#define HDA_INTEL_82801H HDA_MODEL_CONSTRUCT(INTEL, 0x284b)
|
2007-07-09 20:42:11 +00:00
|
|
|
#define HDA_INTEL_82801I HDA_MODEL_CONSTRUCT(INTEL, 0x293e)
|
2006-10-01 11:13:00 +00:00
|
|
|
#define HDA_INTEL_ALL HDA_MODEL_CONSTRUCT(INTEL, 0xffff)
|
|
|
|
|
|
|
|
/* Nvidia */
|
|
|
|
#define NVIDIA_VENDORID 0x10de
|
|
|
|
#define HDA_NVIDIA_MCP51 HDA_MODEL_CONSTRUCT(NVIDIA, 0x026c)
|
|
|
|
#define HDA_NVIDIA_MCP55 HDA_MODEL_CONSTRUCT(NVIDIA, 0x0371)
|
2007-11-21 11:39:27 +00:00
|
|
|
#define HDA_NVIDIA_MCP61_1 HDA_MODEL_CONSTRUCT(NVIDIA, 0x03e4)
|
|
|
|
#define HDA_NVIDIA_MCP61_2 HDA_MODEL_CONSTRUCT(NVIDIA, 0x03f0)
|
|
|
|
#define HDA_NVIDIA_MCP65_1 HDA_MODEL_CONSTRUCT(NVIDIA, 0x044a)
|
|
|
|
#define HDA_NVIDIA_MCP65_2 HDA_MODEL_CONSTRUCT(NVIDIA, 0x044b)
|
|
|
|
#define HDA_NVIDIA_MCP67_1 HDA_MODEL_CONSTRUCT(NVIDIA, 0x055c)
|
|
|
|
#define HDA_NVIDIA_MCP67_2 HDA_MODEL_CONSTRUCT(NVIDIA, 0x055d)
|
2006-10-01 11:13:00 +00:00
|
|
|
#define HDA_NVIDIA_ALL HDA_MODEL_CONSTRUCT(NVIDIA, 0xffff)
|
|
|
|
|
|
|
|
/* ATI */
|
|
|
|
#define ATI_VENDORID 0x1002
|
|
|
|
#define HDA_ATI_SB450 HDA_MODEL_CONSTRUCT(ATI, 0x437b)
|
2006-10-08 18:51:58 +00:00
|
|
|
#define HDA_ATI_SB600 HDA_MODEL_CONSTRUCT(ATI, 0x4383)
|
2006-10-01 11:13:00 +00:00
|
|
|
#define HDA_ATI_ALL HDA_MODEL_CONSTRUCT(ATI, 0xffff)
|
|
|
|
|
2006-10-08 18:51:58 +00:00
|
|
|
/* VIA */
|
|
|
|
#define VIA_VENDORID 0x1106
|
|
|
|
#define HDA_VIA_VT82XX HDA_MODEL_CONSTRUCT(VIA, 0x3288)
|
|
|
|
#define HDA_VIA_ALL HDA_MODEL_CONSTRUCT(VIA, 0xffff)
|
|
|
|
|
|
|
|
/* SiS */
|
|
|
|
#define SIS_VENDORID 0x1039
|
|
|
|
#define HDA_SIS_966 HDA_MODEL_CONSTRUCT(SIS, 0x7502)
|
|
|
|
#define HDA_SIS_ALL HDA_MODEL_CONSTRUCT(SIS, 0xffff)
|
|
|
|
|
2006-10-01 11:13:00 +00:00
|
|
|
/* OEM/subvendors */
|
|
|
|
|
2006-12-22 11:55:59 +00:00
|
|
|
/* Intel */
|
|
|
|
#define INTEL_D101GGC_SUBVENDOR HDA_MODEL_CONSTRUCT(INTEL, 0xd600)
|
|
|
|
|
2006-10-01 11:13:00 +00:00
|
|
|
/* HP/Compaq */
|
|
|
|
#define HP_VENDORID 0x103c
|
|
|
|
#define HP_V3000_SUBVENDOR HDA_MODEL_CONSTRUCT(HP, 0x30b5)
|
|
|
|
#define HP_NX7400_SUBVENDOR HDA_MODEL_CONSTRUCT(HP, 0x30a2)
|
|
|
|
#define HP_NX6310_SUBVENDOR HDA_MODEL_CONSTRUCT(HP, 0x30aa)
|
2006-12-16 09:14:58 +00:00
|
|
|
#define HP_NX6325_SUBVENDOR HDA_MODEL_CONSTRUCT(HP, 0x30b0)
|
2007-01-28 03:16:54 +00:00
|
|
|
#define HP_XW4300_SUBVENDOR HDA_MODEL_CONSTRUCT(HP, 0x3013)
|
2007-05-05 09:17:36 +00:00
|
|
|
#define HP_3010_SUBVENDOR HDA_MODEL_CONSTRUCT(HP, 0x3010)
|
|
|
|
#define HP_DV5000_SUBVENDOR HDA_MODEL_CONSTRUCT(HP, 0x30a5)
|
2007-12-13 15:48:45 +00:00
|
|
|
#define HP_DC7700S_SUBVENDOR HDA_MODEL_CONSTRUCT(HP, 0x2801)
|
2007-10-19 15:49:39 +00:00
|
|
|
#define HP_DC7700_SUBVENDOR HDA_MODEL_CONSTRUCT(HP, 0x2802)
|
2006-10-01 11:13:00 +00:00
|
|
|
#define HP_ALL_SUBVENDOR HDA_MODEL_CONSTRUCT(HP, 0xffff)
|
2006-12-16 09:14:58 +00:00
|
|
|
/* What is wrong with XN 2563 anyway? (Got the picture ?) */
|
|
|
|
#define HP_NX6325_SUBVENDORX 0x103c30b0
|
2006-10-01 11:13:00 +00:00
|
|
|
|
|
|
|
/* Dell */
|
|
|
|
#define DELL_VENDORID 0x1028
|
2008-07-15 02:34:44 +00:00
|
|
|
#define DELL_D630_SUBVENDOR HDA_MODEL_CONSTRUCT(DELL, 0x01f9)
|
2006-10-01 11:13:00 +00:00
|
|
|
#define DELL_D820_SUBVENDOR HDA_MODEL_CONSTRUCT(DELL, 0x01cc)
|
2008-04-12 15:07:32 +00:00
|
|
|
#define DELL_V1500_SUBVENDOR HDA_MODEL_CONSTRUCT(DELL, 0x0228)
|
2006-10-01 11:13:00 +00:00
|
|
|
#define DELL_I1300_SUBVENDOR HDA_MODEL_CONSTRUCT(DELL, 0x01c9)
|
2007-05-05 09:17:36 +00:00
|
|
|
#define DELL_XPSM1210_SUBVENDOR HDA_MODEL_CONSTRUCT(DELL, 0x01d7)
|
|
|
|
#define DELL_OPLX745_SUBVENDOR HDA_MODEL_CONSTRUCT(DELL, 0x01da)
|
2006-10-01 11:13:00 +00:00
|
|
|
#define DELL_ALL_SUBVENDOR HDA_MODEL_CONSTRUCT(DELL, 0xffff)
|
|
|
|
|
|
|
|
/* Clevo */
|
|
|
|
#define CLEVO_VENDORID 0x1558
|
|
|
|
#define CLEVO_D900T_SUBVENDOR HDA_MODEL_CONSTRUCT(CLEVO, 0x0900)
|
|
|
|
#define CLEVO_ALL_SUBVENDOR HDA_MODEL_CONSTRUCT(CLEVO, 0xffff)
|
|
|
|
|
|
|
|
/* Acer */
|
|
|
|
#define ACER_VENDORID 0x1025
|
2007-01-13 00:24:44 +00:00
|
|
|
#define ACER_A5050_SUBVENDOR HDA_MODEL_CONSTRUCT(ACER, 0x010f)
|
2007-11-21 11:39:27 +00:00
|
|
|
#define ACER_A4520_SUBVENDOR HDA_MODEL_CONSTRUCT(ACER, 0x0127)
|
2007-12-02 16:38:28 +00:00
|
|
|
#define ACER_A4710_SUBVENDOR HDA_MODEL_CONSTRUCT(ACER, 0x012f)
|
2008-09-07 20:25:19 +00:00
|
|
|
#define ACER_A4715_SUBVENDOR HDA_MODEL_CONSTRUCT(ACER, 0x0133)
|
2007-05-05 09:17:36 +00:00
|
|
|
#define ACER_3681WXM_SUBVENDOR HDA_MODEL_CONSTRUCT(ACER, 0x0110)
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
#define ACER_T6292_SUBVENDOR HDA_MODEL_CONSTRUCT(ACER, 0x011b)
|
2006-10-01 11:13:00 +00:00
|
|
|
#define ACER_ALL_SUBVENDOR HDA_MODEL_CONSTRUCT(ACER, 0xffff)
|
|
|
|
|
2006-10-02 16:30:04 +00:00
|
|
|
/* Asus */
|
|
|
|
#define ASUS_VENDORID 0x1043
|
2008-04-12 15:07:32 +00:00
|
|
|
#define ASUS_A8X_SUBVENDOR HDA_MODEL_CONSTRUCT(ASUS, 0x1153)
|
2006-10-12 15:37:43 +00:00
|
|
|
#define ASUS_U5F_SUBVENDOR HDA_MODEL_CONSTRUCT(ASUS, 0x1263)
|
2008-04-12 15:07:32 +00:00
|
|
|
#define ASUS_W6F_SUBVENDOR HDA_MODEL_CONSTRUCT(ASUS, 0x1263)
|
2006-12-16 09:14:58 +00:00
|
|
|
#define ASUS_A7M_SUBVENDOR HDA_MODEL_CONSTRUCT(ASUS, 0x1323)
|
2008-04-12 15:07:32 +00:00
|
|
|
#define ASUS_F3JC_SUBVENDOR HDA_MODEL_CONSTRUCT(ASUS, 0x1338)
|
|
|
|
#define ASUS_G2K_SUBVENDOR HDA_MODEL_CONSTRUCT(ASUS, 0x1339)
|
2007-03-16 01:44:21 +00:00
|
|
|
#define ASUS_A7T_SUBVENDOR HDA_MODEL_CONSTRUCT(ASUS, 0x13c2)
|
2007-05-05 09:17:36 +00:00
|
|
|
#define ASUS_W2J_SUBVENDOR HDA_MODEL_CONSTRUCT(ASUS, 0x1971)
|
2008-04-12 15:07:32 +00:00
|
|
|
#define ASUS_M5200_SUBVENDOR HDA_MODEL_CONSTRUCT(ASUS, 0x1993)
|
|
|
|
#define ASUS_P1AH2_SUBVENDOR HDA_MODEL_CONSTRUCT(ASUS, 0x81cb)
|
2007-05-05 09:17:36 +00:00
|
|
|
#define ASUS_M2NPVMX_SUBVENDOR HDA_MODEL_CONSTRUCT(ASUS, 0x81cb)
|
2008-04-12 15:07:32 +00:00
|
|
|
#define ASUS_M2V_SUBVENDOR HDA_MODEL_CONSTRUCT(ASUS, 0x81e7)
|
2007-06-10 23:01:40 +00:00
|
|
|
#define ASUS_P5BWD_SUBVENDOR HDA_MODEL_CONSTRUCT(ASUS, 0x81ec)
|
2008-04-12 15:07:32 +00:00
|
|
|
#define ASUS_M2N_SUBVENDOR HDA_MODEL_CONSTRUCT(ASUS, 0x8234)
|
2007-07-01 17:31:20 +00:00
|
|
|
#define ASUS_A8NVMCSM_SUBVENDOR HDA_MODEL_CONSTRUCT(NVIDIA, 0xcb84)
|
2006-10-02 16:30:04 +00:00
|
|
|
#define ASUS_ALL_SUBVENDOR HDA_MODEL_CONSTRUCT(ASUS, 0xffff)
|
|
|
|
|
2006-10-12 04:19:37 +00:00
|
|
|
/* IBM / Lenovo */
|
|
|
|
#define IBM_VENDORID 0x1014
|
|
|
|
#define IBM_M52_SUBVENDOR HDA_MODEL_CONSTRUCT(IBM, 0x02f6)
|
|
|
|
#define IBM_ALL_SUBVENDOR HDA_MODEL_CONSTRUCT(IBM, 0xffff)
|
|
|
|
|
Welcome to Once-a-year Sound Mega-Commit. Enjoy numerous updates and fixes
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.
2006-11-26 12:24:06 +00:00
|
|
|
/* Lenovo */
|
2006-11-27 06:16:36 +00:00
|
|
|
#define LENOVO_VENDORID 0x17aa
|
|
|
|
#define LENOVO_3KN100_SUBVENDOR HDA_MODEL_CONSTRUCT(LENOVO, 0x2066)
|
2008-09-07 20:25:19 +00:00
|
|
|
#define LENOVO_3KN200_SUBVENDOR HDA_MODEL_CONSTRUCT(LENOVO, 0x384e)
|
2007-10-19 15:49:39 +00:00
|
|
|
#define LENOVO_TCA55_SUBVENDOR HDA_MODEL_CONSTRUCT(LENOVO, 0x1015)
|
2006-11-27 06:16:36 +00:00
|
|
|
#define LENOVO_ALL_SUBVENDOR HDA_MODEL_CONSTRUCT(LENOVO, 0xffff)
|
Welcome to Once-a-year Sound Mega-Commit. Enjoy numerous updates and fixes
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.
2006-11-26 12:24:06 +00:00
|
|
|
|
2006-11-27 06:16:36 +00:00
|
|
|
/* Samsung */
|
|
|
|
#define SAMSUNG_VENDORID 0x144d
|
|
|
|
#define SAMSUNG_Q1_SUBVENDOR HDA_MODEL_CONSTRUCT(SAMSUNG, 0xc027)
|
|
|
|
#define SAMSUNG_ALL_SUBVENDOR HDA_MODEL_CONSTRUCT(SAMSUNG, 0xffff)
|
2006-10-01 11:13:00 +00:00
|
|
|
|
2006-11-29 15:15:30 +00:00
|
|
|
/* Medion ? */
|
|
|
|
#define MEDION_VENDORID 0x161f
|
|
|
|
#define MEDION_MD95257_SUBVENDOR HDA_MODEL_CONSTRUCT(MEDION, 0x203d)
|
|
|
|
#define MEDION_ALL_SUBVENDOR HDA_MODEL_CONSTRUCT(MEDION, 0xffff)
|
|
|
|
|
2007-11-21 11:39:27 +00:00
|
|
|
/* Apple Computer Inc. */
|
|
|
|
#define APPLE_VENDORID 0x106b
|
|
|
|
#define APPLE_MB3_SUBVENDOR HDA_MODEL_CONSTRUCT(APPLE, 0x00a1)
|
|
|
|
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
/* Sony */
|
|
|
|
#define SONY_VENDORID 0x104d
|
|
|
|
#define SONY_S5_SUBVENDOR HDA_MODEL_CONSTRUCT(SONY, 0x81cc)
|
|
|
|
#define SONY_ALL_SUBVENDOR HDA_MODEL_CONSTRUCT(SONY, 0xffff)
|
|
|
|
|
2006-12-02 17:12:24 +00:00
|
|
|
/*
|
|
|
|
* Apple Intel MacXXXX seems using Sigmatel codec/vendor id
|
|
|
|
* instead of their own, which is beyond my comprehension
|
|
|
|
* (see HDA_CODEC_STAC9221 below).
|
|
|
|
*/
|
|
|
|
#define APPLE_INTEL_MAC 0x76808384
|
|
|
|
|
2006-12-16 09:14:58 +00:00
|
|
|
/* LG Electronics */
|
|
|
|
#define LG_VENDORID 0x1854
|
|
|
|
#define LG_LW20_SUBVENDOR HDA_MODEL_CONSTRUCT(LG, 0x0018)
|
|
|
|
#define LG_ALL_SUBVENDOR HDA_MODEL_CONSTRUCT(LG, 0xffff)
|
|
|
|
|
2006-12-19 16:52:09 +00:00
|
|
|
/* Fujitsu Siemens */
|
|
|
|
#define FS_VENDORID 0x1734
|
|
|
|
#define FS_PA1510_SUBVENDOR HDA_MODEL_CONSTRUCT(FS, 0x10b8)
|
2007-10-19 15:49:39 +00:00
|
|
|
#define FS_SI1848_SUBVENDOR HDA_MODEL_CONSTRUCT(FS, 0x10cd)
|
2006-12-19 16:52:09 +00:00
|
|
|
#define FS_ALL_SUBVENDOR HDA_MODEL_CONSTRUCT(FS, 0xffff)
|
|
|
|
|
2007-10-19 15:49:39 +00:00
|
|
|
/* Fujitsu Limited */
|
|
|
|
#define FL_VENDORID 0x10cf
|
|
|
|
#define FL_S7020D_SUBVENDOR HDA_MODEL_CONSTRUCT(FL, 0x1326)
|
2008-09-07 20:25:19 +00:00
|
|
|
#define FL_U1010_SUBVENDOR HDA_MODEL_CONSTRUCT(FL, 0x142d)
|
2007-10-19 15:49:39 +00:00
|
|
|
#define FL_ALL_SUBVENDOR HDA_MODEL_CONSTRUCT(FL, 0xffff)
|
|
|
|
|
2007-01-04 18:13:04 +00:00
|
|
|
/* Toshiba */
|
|
|
|
#define TOSHIBA_VENDORID 0x1179
|
|
|
|
#define TOSHIBA_U200_SUBVENDOR HDA_MODEL_CONSTRUCT(TOSHIBA, 0x0001)
|
2007-11-21 11:39:27 +00:00
|
|
|
#define TOSHIBA_A135_SUBVENDOR HDA_MODEL_CONSTRUCT(TOSHIBA, 0xff01)
|
2007-01-04 18:13:04 +00:00
|
|
|
#define TOSHIBA_ALL_SUBVENDOR HDA_MODEL_CONSTRUCT(TOSHIBA, 0xffff)
|
|
|
|
|
2007-01-13 00:24:44 +00:00
|
|
|
/* Micro-Star International (MSI) */
|
|
|
|
#define MSI_VENDORID 0x1462
|
|
|
|
#define MSI_MS1034_SUBVENDOR HDA_MODEL_CONSTRUCT(MSI, 0x0349)
|
2007-10-19 15:49:39 +00:00
|
|
|
#define MSI_MS034A_SUBVENDOR HDA_MODEL_CONSTRUCT(MSI, 0x034a)
|
2007-01-13 00:24:44 +00:00
|
|
|
#define MSI_ALL_SUBVENDOR HDA_MODEL_CONSTRUCT(MSI, 0xffff)
|
|
|
|
|
2007-10-19 15:49:39 +00:00
|
|
|
/* Giga-Byte Technology */
|
|
|
|
#define GB_VENDORID 0x1458
|
|
|
|
#define GB_G33S2H_SUBVENDOR HDA_MODEL_CONSTRUCT(GB, 0xa022)
|
|
|
|
#define GP_ALL_SUBVENDOR HDA_MODEL_CONSTRUCT(GB, 0xffff)
|
|
|
|
|
2007-05-05 09:17:36 +00:00
|
|
|
/* Uniwill ? */
|
|
|
|
#define UNIWILL_VENDORID 0x1584
|
|
|
|
#define UNIWILL_9075_SUBVENDOR HDA_MODEL_CONSTRUCT(UNIWILL, 0x9075)
|
2007-06-18 22:39:27 +00:00
|
|
|
#define UNIWILL_9080_SUBVENDOR HDA_MODEL_CONSTRUCT(UNIWILL, 0x9080)
|
2007-05-05 09:17:36 +00:00
|
|
|
|
|
|
|
|
2006-10-01 11:13:00 +00:00
|
|
|
/* Misc constants.. */
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
#define HDA_AMP_VOL_DEFAULT (-1)
|
2006-10-01 11:13:00 +00:00
|
|
|
#define HDA_AMP_MUTE_DEFAULT (0xffffffff)
|
|
|
|
#define HDA_AMP_MUTE_NONE (0)
|
|
|
|
#define HDA_AMP_MUTE_LEFT (1 << 0)
|
|
|
|
#define HDA_AMP_MUTE_RIGHT (1 << 1)
|
|
|
|
#define HDA_AMP_MUTE_ALL (HDA_AMP_MUTE_LEFT | HDA_AMP_MUTE_RIGHT)
|
|
|
|
|
|
|
|
#define HDA_AMP_LEFT_MUTED(v) ((v) & (HDA_AMP_MUTE_LEFT))
|
|
|
|
#define HDA_AMP_RIGHT_MUTED(v) (((v) & HDA_AMP_MUTE_RIGHT) >> 1)
|
|
|
|
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
#define HDA_ADC_MONITOR (1 << 0)
|
2007-05-05 09:17:36 +00:00
|
|
|
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
#define HDA_CTL_OUT 1
|
|
|
|
#define HDA_CTL_IN 2
|
2006-10-01 11:13:00 +00:00
|
|
|
|
2007-05-05 09:17:36 +00:00
|
|
|
#define HDA_GPIO_MAX 8
|
|
|
|
/* 0 - 7 = GPIO , 8 = Flush */
|
- Fix wrong id for ALC882, add ALC883 id.
- 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"
2006-10-06 18:59:27 +00:00
|
|
|
#define HDA_QUIRK_GPIO0 (1 << 0)
|
|
|
|
#define HDA_QUIRK_GPIO1 (1 << 1)
|
|
|
|
#define HDA_QUIRK_GPIO2 (1 << 2)
|
2007-05-05 09:17:36 +00:00
|
|
|
#define HDA_QUIRK_GPIO3 (1 << 3)
|
|
|
|
#define HDA_QUIRK_GPIO4 (1 << 4)
|
|
|
|
#define HDA_QUIRK_GPIO5 (1 << 5)
|
|
|
|
#define HDA_QUIRK_GPIO6 (1 << 6)
|
|
|
|
#define HDA_QUIRK_GPIO7 (1 << 7)
|
|
|
|
#define HDA_QUIRK_GPIOFLUSH (1 << 8)
|
|
|
|
|
|
|
|
/* 9 - 25 = anything else */
|
|
|
|
#define HDA_QUIRK_SOFTPCMVOL (1 << 9)
|
|
|
|
#define HDA_QUIRK_FIXEDRATE (1 << 10)
|
|
|
|
#define HDA_QUIRK_FORCESTEREO (1 << 11)
|
|
|
|
#define HDA_QUIRK_EAPDINV (1 << 12)
|
|
|
|
#define HDA_QUIRK_DMAPOS (1 << 13)
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
#define HDA_QUIRK_SENSEINV (1 << 14)
|
2007-05-05 09:17:36 +00:00
|
|
|
|
|
|
|
/* 26 - 31 = vrefs */
|
|
|
|
#define HDA_QUIRK_IVREF50 (1 << 26)
|
|
|
|
#define HDA_QUIRK_IVREF80 (1 << 27)
|
|
|
|
#define HDA_QUIRK_IVREF100 (1 << 28)
|
|
|
|
#define HDA_QUIRK_OVREF50 (1 << 29)
|
|
|
|
#define HDA_QUIRK_OVREF80 (1 << 30)
|
|
|
|
#define HDA_QUIRK_OVREF100 (1 << 31)
|
|
|
|
|
|
|
|
#define HDA_QUIRK_IVREF (HDA_QUIRK_IVREF50 | HDA_QUIRK_IVREF80 | \
|
|
|
|
HDA_QUIRK_IVREF100)
|
|
|
|
#define HDA_QUIRK_OVREF (HDA_QUIRK_OVREF50 | HDA_QUIRK_OVREF80 | \
|
|
|
|
HDA_QUIRK_OVREF100)
|
|
|
|
#define HDA_QUIRK_VREF (HDA_QUIRK_IVREF | HDA_QUIRK_OVREF)
|
|
|
|
|
2007-07-01 17:31:20 +00:00
|
|
|
#if __FreeBSD_version < 600000
|
|
|
|
#define taskqueue_drain(...)
|
|
|
|
#endif
|
|
|
|
|
- Fix wrong id for ALC882, add ALC883 id.
- 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"
2006-10-06 18:59:27 +00:00
|
|
|
static const struct {
|
|
|
|
char *key;
|
|
|
|
uint32_t value;
|
|
|
|
} hdac_quirks_tab[] = {
|
|
|
|
{ "gpio0", HDA_QUIRK_GPIO0 },
|
|
|
|
{ "gpio1", HDA_QUIRK_GPIO1 },
|
|
|
|
{ "gpio2", HDA_QUIRK_GPIO2 },
|
2007-05-05 09:17:36 +00:00
|
|
|
{ "gpio3", HDA_QUIRK_GPIO3 },
|
|
|
|
{ "gpio4", HDA_QUIRK_GPIO4 },
|
|
|
|
{ "gpio5", HDA_QUIRK_GPIO5 },
|
|
|
|
{ "gpio6", HDA_QUIRK_GPIO6 },
|
|
|
|
{ "gpio7", HDA_QUIRK_GPIO7 },
|
2006-12-09 17:52:54 +00:00
|
|
|
{ "gpioflush", HDA_QUIRK_GPIOFLUSH },
|
- Fix wrong id for ALC882, add ALC883 id.
- 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"
2006-10-06 18:59:27 +00:00
|
|
|
{ "softpcmvol", HDA_QUIRK_SOFTPCMVOL },
|
|
|
|
{ "fixedrate", HDA_QUIRK_FIXEDRATE },
|
2006-10-08 18:51:58 +00:00
|
|
|
{ "forcestereo", HDA_QUIRK_FORCESTEREO },
|
2006-10-12 15:37:43 +00:00
|
|
|
{ "eapdinv", HDA_QUIRK_EAPDINV },
|
2007-05-05 09:17:36 +00:00
|
|
|
{ "dmapos", HDA_QUIRK_DMAPOS },
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
{ "senseinv", HDA_QUIRK_SENSEINV },
|
2007-05-05 09:17:36 +00:00
|
|
|
{ "ivref50", HDA_QUIRK_IVREF50 },
|
|
|
|
{ "ivref80", HDA_QUIRK_IVREF80 },
|
|
|
|
{ "ivref100", HDA_QUIRK_IVREF100 },
|
|
|
|
{ "ovref50", HDA_QUIRK_OVREF50 },
|
|
|
|
{ "ovref80", HDA_QUIRK_OVREF80 },
|
|
|
|
{ "ovref100", HDA_QUIRK_OVREF100 },
|
|
|
|
{ "ivref", HDA_QUIRK_IVREF },
|
|
|
|
{ "ovref", HDA_QUIRK_OVREF },
|
2006-12-10 06:13:41 +00:00
|
|
|
{ "vref", HDA_QUIRK_VREF },
|
- Fix wrong id for ALC882, add ALC883 id.
- 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"
2006-10-06 18:59:27 +00:00
|
|
|
};
|
|
|
|
#define HDAC_QUIRKS_TAB_LEN \
|
|
|
|
(sizeof(hdac_quirks_tab) / sizeof(hdac_quirks_tab[0]))
|
2006-10-01 11:13:00 +00:00
|
|
|
|
|
|
|
#define HDA_BDL_MIN 2
|
|
|
|
#define HDA_BDL_MAX 256
|
|
|
|
#define HDA_BDL_DEFAULT HDA_BDL_MIN
|
|
|
|
|
2007-05-05 09:17:36 +00:00
|
|
|
#define HDA_BLK_MIN HDAC_DMA_ALIGNMENT
|
2007-03-16 17:18:17 +00:00
|
|
|
#define HDA_BLK_ALIGN (~(HDA_BLK_MIN - 1))
|
|
|
|
|
2006-10-01 11:13:00 +00:00
|
|
|
#define HDA_BUFSZ_MIN 4096
|
|
|
|
#define HDA_BUFSZ_MAX 65536
|
|
|
|
#define HDA_BUFSZ_DEFAULT 16384
|
|
|
|
|
|
|
|
#define HDA_PARSE_MAXDEPTH 10
|
|
|
|
|
2007-05-05 09:17:36 +00:00
|
|
|
#define HDAC_UNSOLTAG_EVENT_HP 0x00
|
2006-10-01 11:13:00 +00:00
|
|
|
|
2006-12-15 05:15:17 +00:00
|
|
|
MALLOC_DEFINE(M_HDAC, "hdac", "High Definition Audio Controller");
|
2006-10-01 11:13:00 +00:00
|
|
|
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
const char *HDA_COLORS[16] = {"Unknown", "Black", "Grey", "Blue", "Green", "Red",
|
|
|
|
"Orange", "Yellow", "Purple", "Pink", "Res.A", "Res.B", "Res.C", "Res.D",
|
|
|
|
"White", "Other"};
|
|
|
|
|
|
|
|
const char *HDA_DEVS[16] = {"Line-out", "Speaker", "Headphones", "CD",
|
|
|
|
"SPDIF-out", "Digital-out", "Modem-line", "Modem-handset", "Line-in",
|
|
|
|
"AUX", "Mic", "Telephony", "SPDIF-in", "Digital-in", "Res.E", "Other"};
|
|
|
|
|
|
|
|
const char *HDA_CONNS[4] = {"Jack", "None", "Fixed", "Both"};
|
2006-10-01 11:13:00 +00:00
|
|
|
|
|
|
|
/* Default */
|
|
|
|
static uint32_t hdac_fmt[] = {
|
|
|
|
AFMT_STEREO | AFMT_S16_LE,
|
|
|
|
0
|
|
|
|
};
|
|
|
|
|
|
|
|
static struct pcmchan_caps hdac_caps = {48000, 48000, hdac_fmt, 0};
|
|
|
|
|
|
|
|
static const struct {
|
|
|
|
uint32_t model;
|
|
|
|
char *desc;
|
|
|
|
} hdac_devices[] = {
|
|
|
|
{ HDA_INTEL_82801F, "Intel 82801F" },
|
2007-07-09 20:42:11 +00:00
|
|
|
{ HDA_INTEL_63XXESB, "Intel 631x/632xESB" },
|
2006-10-01 11:13:00 +00:00
|
|
|
{ HDA_INTEL_82801G, "Intel 82801G" },
|
2006-10-08 18:51:58 +00:00
|
|
|
{ HDA_INTEL_82801H, "Intel 82801H" },
|
2007-07-09 20:42:11 +00:00
|
|
|
{ HDA_INTEL_82801I, "Intel 82801I" },
|
2006-10-01 11:13:00 +00:00
|
|
|
{ HDA_NVIDIA_MCP51, "NVidia MCP51" },
|
|
|
|
{ HDA_NVIDIA_MCP55, "NVidia MCP55" },
|
2007-11-21 11:39:27 +00:00
|
|
|
{ HDA_NVIDIA_MCP61_1, "NVidia MCP61" },
|
|
|
|
{ HDA_NVIDIA_MCP61_2, "NVidia MCP61" },
|
|
|
|
{ HDA_NVIDIA_MCP65_1, "NVidia MCP65" },
|
2007-11-28 02:13:20 +00:00
|
|
|
{ HDA_NVIDIA_MCP65_2, "NVidia MCP65" },
|
2007-11-21 11:39:27 +00:00
|
|
|
{ HDA_NVIDIA_MCP67_1, "NVidia MCP67" },
|
|
|
|
{ HDA_NVIDIA_MCP67_2, "NVidia MCP67" },
|
2006-10-01 11:13:00 +00:00
|
|
|
{ HDA_ATI_SB450, "ATI SB450" },
|
2006-10-08 18:51:58 +00:00
|
|
|
{ HDA_ATI_SB600, "ATI SB600" },
|
|
|
|
{ HDA_VIA_VT82XX, "VIA VT8251/8237A" },
|
|
|
|
{ HDA_SIS_966, "SiS 966" },
|
2006-10-01 11:13:00 +00:00
|
|
|
/* Unknown */
|
|
|
|
{ HDA_INTEL_ALL, "Intel (Unknown)" },
|
|
|
|
{ HDA_NVIDIA_ALL, "NVidia (Unknown)" },
|
|
|
|
{ HDA_ATI_ALL, "ATI (Unknown)" },
|
2006-10-08 18:51:58 +00:00
|
|
|
{ HDA_VIA_ALL, "VIA (Unknown)" },
|
|
|
|
{ HDA_SIS_ALL, "SiS (Unknown)" },
|
2006-10-01 11:13:00 +00:00
|
|
|
};
|
|
|
|
#define HDAC_DEVICES_LEN (sizeof(hdac_devices) / sizeof(hdac_devices[0]))
|
|
|
|
|
2007-05-05 09:17:36 +00:00
|
|
|
static const struct {
|
|
|
|
uint16_t vendor;
|
|
|
|
uint8_t reg;
|
|
|
|
uint8_t mask;
|
|
|
|
uint8_t enable;
|
|
|
|
} hdac_pcie_snoop[] = {
|
|
|
|
{ INTEL_VENDORID, 0x00, 0x00, 0x00 },
|
|
|
|
{ ATI_VENDORID, 0x42, 0xf8, 0x02 },
|
|
|
|
{ NVIDIA_VENDORID, 0x4e, 0xf0, 0x0f },
|
|
|
|
};
|
|
|
|
#define HDAC_PCIESNOOP_LEN \
|
|
|
|
(sizeof(hdac_pcie_snoop) / sizeof(hdac_pcie_snoop[0]))
|
|
|
|
|
2006-10-01 11:13:00 +00:00
|
|
|
static const struct {
|
|
|
|
uint32_t rate;
|
|
|
|
int valid;
|
|
|
|
uint16_t base;
|
|
|
|
uint16_t mul;
|
|
|
|
uint16_t div;
|
|
|
|
} hda_rate_tab[] = {
|
|
|
|
{ 8000, 1, 0x0000, 0x0000, 0x0500 }, /* (48000 * 1) / 6 */
|
|
|
|
{ 9600, 0, 0x0000, 0x0000, 0x0400 }, /* (48000 * 1) / 5 */
|
|
|
|
{ 12000, 0, 0x0000, 0x0000, 0x0300 }, /* (48000 * 1) / 4 */
|
|
|
|
{ 16000, 1, 0x0000, 0x0000, 0x0200 }, /* (48000 * 1) / 3 */
|
|
|
|
{ 18000, 0, 0x0000, 0x1000, 0x0700 }, /* (48000 * 3) / 8 */
|
|
|
|
{ 19200, 0, 0x0000, 0x0800, 0x0400 }, /* (48000 * 2) / 5 */
|
|
|
|
{ 24000, 0, 0x0000, 0x0000, 0x0100 }, /* (48000 * 1) / 2 */
|
|
|
|
{ 28800, 0, 0x0000, 0x1000, 0x0400 }, /* (48000 * 3) / 5 */
|
|
|
|
{ 32000, 1, 0x0000, 0x0800, 0x0200 }, /* (48000 * 2) / 3 */
|
|
|
|
{ 36000, 0, 0x0000, 0x1000, 0x0300 }, /* (48000 * 3) / 4 */
|
|
|
|
{ 38400, 0, 0x0000, 0x1800, 0x0400 }, /* (48000 * 4) / 5 */
|
|
|
|
{ 48000, 1, 0x0000, 0x0000, 0x0000 }, /* (48000 * 1) / 1 */
|
|
|
|
{ 64000, 0, 0x0000, 0x1800, 0x0200 }, /* (48000 * 4) / 3 */
|
|
|
|
{ 72000, 0, 0x0000, 0x1000, 0x0100 }, /* (48000 * 3) / 2 */
|
|
|
|
{ 96000, 1, 0x0000, 0x0800, 0x0000 }, /* (48000 * 2) / 1 */
|
|
|
|
{ 144000, 0, 0x0000, 0x1000, 0x0000 }, /* (48000 * 3) / 1 */
|
|
|
|
{ 192000, 1, 0x0000, 0x1800, 0x0000 }, /* (48000 * 4) / 1 */
|
|
|
|
{ 8820, 0, 0x4000, 0x0000, 0x0400 }, /* (44100 * 1) / 5 */
|
|
|
|
{ 11025, 1, 0x4000, 0x0000, 0x0300 }, /* (44100 * 1) / 4 */
|
|
|
|
{ 12600, 0, 0x4000, 0x0800, 0x0600 }, /* (44100 * 2) / 7 */
|
|
|
|
{ 14700, 0, 0x4000, 0x0000, 0x0200 }, /* (44100 * 1) / 3 */
|
|
|
|
{ 17640, 0, 0x4000, 0x0800, 0x0400 }, /* (44100 * 2) / 5 */
|
|
|
|
{ 18900, 0, 0x4000, 0x1000, 0x0600 }, /* (44100 * 3) / 7 */
|
|
|
|
{ 22050, 1, 0x4000, 0x0000, 0x0100 }, /* (44100 * 1) / 2 */
|
|
|
|
{ 25200, 0, 0x4000, 0x1800, 0x0600 }, /* (44100 * 4) / 7 */
|
|
|
|
{ 26460, 0, 0x4000, 0x1000, 0x0400 }, /* (44100 * 3) / 5 */
|
|
|
|
{ 29400, 0, 0x4000, 0x0800, 0x0200 }, /* (44100 * 2) / 3 */
|
|
|
|
{ 33075, 0, 0x4000, 0x1000, 0x0300 }, /* (44100 * 3) / 4 */
|
|
|
|
{ 35280, 0, 0x4000, 0x1800, 0x0400 }, /* (44100 * 4) / 5 */
|
|
|
|
{ 44100, 1, 0x4000, 0x0000, 0x0000 }, /* (44100 * 1) / 1 */
|
|
|
|
{ 58800, 0, 0x4000, 0x1800, 0x0200 }, /* (44100 * 4) / 3 */
|
|
|
|
{ 66150, 0, 0x4000, 0x1000, 0x0100 }, /* (44100 * 3) / 2 */
|
|
|
|
{ 88200, 1, 0x4000, 0x0800, 0x0000 }, /* (44100 * 2) / 1 */
|
|
|
|
{ 132300, 0, 0x4000, 0x1000, 0x0000 }, /* (44100 * 3) / 1 */
|
|
|
|
{ 176400, 1, 0x4000, 0x1800, 0x0000 }, /* (44100 * 4) / 1 */
|
|
|
|
};
|
|
|
|
#define HDA_RATE_TAB_LEN (sizeof(hda_rate_tab) / sizeof(hda_rate_tab[0]))
|
|
|
|
|
|
|
|
/* All codecs you can eat... */
|
|
|
|
#define HDA_CODEC_CONSTRUCT(vendor, id) \
|
|
|
|
(((uint32_t)(vendor##_VENDORID) << 16) | ((id) & 0xffff))
|
|
|
|
|
|
|
|
/* Realtek */
|
|
|
|
#define REALTEK_VENDORID 0x10ec
|
|
|
|
#define HDA_CODEC_ALC260 HDA_CODEC_CONSTRUCT(REALTEK, 0x0260)
|
2007-05-05 09:17:36 +00:00
|
|
|
#define HDA_CODEC_ALC262 HDA_CODEC_CONSTRUCT(REALTEK, 0x0262)
|
2008-09-14 17:37:34 +00:00
|
|
|
#define HDA_CODEC_ALC267 HDA_CODEC_CONSTRUCT(REALTEK, 0x0267)
|
2007-07-09 20:42:11 +00:00
|
|
|
#define HDA_CODEC_ALC268 HDA_CODEC_CONSTRUCT(REALTEK, 0x0268)
|
2008-09-14 17:37:34 +00:00
|
|
|
#define HDA_CODEC_ALC269 HDA_CODEC_CONSTRUCT(REALTEK, 0x0269)
|
|
|
|
#define HDA_CODEC_ALC272 HDA_CODEC_CONSTRUCT(REALTEK, 0x0272)
|
2007-06-10 23:01:40 +00:00
|
|
|
#define HDA_CODEC_ALC660 HDA_CODEC_CONSTRUCT(REALTEK, 0x0660)
|
2008-09-14 17:37:34 +00:00
|
|
|
#define HDA_CODEC_ALC662 HDA_CODEC_CONSTRUCT(REALTEK, 0x0662)
|
2008-09-14 17:40:53 +00:00
|
|
|
#define HDA_CODEC_ALC663 HDA_CODEC_CONSTRUCT(REALTEK, 0x0663)
|
2006-10-01 11:13:00 +00:00
|
|
|
#define HDA_CODEC_ALC861 HDA_CODEC_CONSTRUCT(REALTEK, 0x0861)
|
2007-05-05 09:17:36 +00:00
|
|
|
#define HDA_CODEC_ALC861VD HDA_CODEC_CONSTRUCT(REALTEK, 0x0862)
|
2006-10-01 11:13:00 +00:00
|
|
|
#define HDA_CODEC_ALC880 HDA_CODEC_CONSTRUCT(REALTEK, 0x0880)
|
- Fix wrong id for ALC882, add ALC883 id.
- 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"
2006-10-06 18:59:27 +00:00
|
|
|
#define HDA_CODEC_ALC882 HDA_CODEC_CONSTRUCT(REALTEK, 0x0882)
|
|
|
|
#define HDA_CODEC_ALC883 HDA_CODEC_CONSTRUCT(REALTEK, 0x0883)
|
2007-05-05 09:17:36 +00:00
|
|
|
#define HDA_CODEC_ALC885 HDA_CODEC_CONSTRUCT(REALTEK, 0x0885)
|
2006-12-17 15:19:33 +00:00
|
|
|
#define HDA_CODEC_ALC888 HDA_CODEC_CONSTRUCT(REALTEK, 0x0888)
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
#define HDA_CODEC_ALC889 HDA_CODEC_CONSTRUCT(REALTEK, 0x0889)
|
2006-10-01 11:13:00 +00:00
|
|
|
#define HDA_CODEC_ALCXXXX HDA_CODEC_CONSTRUCT(REALTEK, 0xffff)
|
|
|
|
|
2007-05-05 09:17:36 +00:00
|
|
|
/* Analog Devices */
|
|
|
|
#define ANALOGDEVICES_VENDORID 0x11d4
|
|
|
|
#define HDA_CODEC_AD1981HD HDA_CODEC_CONSTRUCT(ANALOGDEVICES, 0x1981)
|
|
|
|
#define HDA_CODEC_AD1983 HDA_CODEC_CONSTRUCT(ANALOGDEVICES, 0x1983)
|
2007-11-28 15:27:22 +00:00
|
|
|
#define HDA_CODEC_AD1984 HDA_CODEC_CONSTRUCT(ANALOGDEVICES, 0x1984)
|
2007-05-05 09:17:36 +00:00
|
|
|
#define HDA_CODEC_AD1986A HDA_CODEC_CONSTRUCT(ANALOGDEVICES, 0x1986)
|
|
|
|
#define HDA_CODEC_AD1988 HDA_CODEC_CONSTRUCT(ANALOGDEVICES, 0x1988)
|
2007-06-10 23:01:40 +00:00
|
|
|
#define HDA_CODEC_AD1988B HDA_CODEC_CONSTRUCT(ANALOGDEVICES, 0x198b)
|
2007-05-05 09:17:36 +00:00
|
|
|
#define HDA_CODEC_ADXXXX HDA_CODEC_CONSTRUCT(ANALOGDEVICES, 0xffff)
|
2006-10-01 11:13:00 +00:00
|
|
|
|
|
|
|
/* CMedia */
|
|
|
|
#define CMEDIA_VENDORID 0x434d
|
|
|
|
#define HDA_CODEC_CMI9880 HDA_CODEC_CONSTRUCT(CMEDIA, 0x4980)
|
|
|
|
#define HDA_CODEC_CMIXXXX HDA_CODEC_CONSTRUCT(CMEDIA, 0xffff)
|
|
|
|
|
|
|
|
/* Sigmatel */
|
|
|
|
#define SIGMATEL_VENDORID 0x8384
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
#define HDA_CODEC_STAC9230X HDA_CODEC_CONSTRUCT(SIGMATEL, 0x7612)
|
|
|
|
#define HDA_CODEC_STAC9230D HDA_CODEC_CONSTRUCT(SIGMATEL, 0x7613)
|
|
|
|
#define HDA_CODEC_STAC9229X HDA_CODEC_CONSTRUCT(SIGMATEL, 0x7614)
|
|
|
|
#define HDA_CODEC_STAC9229D HDA_CODEC_CONSTRUCT(SIGMATEL, 0x7615)
|
|
|
|
#define HDA_CODEC_STAC9228X HDA_CODEC_CONSTRUCT(SIGMATEL, 0x7616)
|
|
|
|
#define HDA_CODEC_STAC9228D HDA_CODEC_CONSTRUCT(SIGMATEL, 0x7617)
|
|
|
|
#define HDA_CODEC_STAC9227X HDA_CODEC_CONSTRUCT(SIGMATEL, 0x7618)
|
|
|
|
#define HDA_CODEC_STAC9227D HDA_CODEC_CONSTRUCT(SIGMATEL, 0x7619)
|
|
|
|
#define HDA_CODEC_STAC9271D HDA_CODEC_CONSTRUCT(SIGMATEL, 0x7627)
|
|
|
|
#define HDA_CODEC_STAC9872AK HDA_CODEC_CONSTRUCT(SIGMATEL, 0x7662)
|
2006-10-01 11:13:00 +00:00
|
|
|
#define HDA_CODEC_STAC9221 HDA_CODEC_CONSTRUCT(SIGMATEL, 0x7680)
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
#define HDA_CODEC_STAC922XD HDA_CODEC_CONSTRUCT(SIGMATEL, 0x7681)
|
2006-10-01 11:13:00 +00:00
|
|
|
#define HDA_CODEC_STAC9221D HDA_CODEC_CONSTRUCT(SIGMATEL, 0x7683)
|
|
|
|
#define HDA_CODEC_STAC9220 HDA_CODEC_CONSTRUCT(SIGMATEL, 0x7690)
|
2008-04-12 15:07:32 +00:00
|
|
|
#define HDA_CODEC_STAC9205 HDA_CODEC_CONSTRUCT(SIGMATEL, 0x76a0)
|
2006-10-01 11:13:00 +00:00
|
|
|
#define HDA_CODEC_STACXXXX HDA_CODEC_CONSTRUCT(SIGMATEL, 0xffff)
|
|
|
|
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
/* Silicon Image */
|
|
|
|
#define SII_VENDORID 0x1095
|
|
|
|
#define HDA_CODEC_SIIXXXX HDA_CODEC_CONSTRUCT(SII, 0xffff)
|
|
|
|
|
|
|
|
/* Lucent/Agere */
|
|
|
|
#define AGERE_VENDORID 0x11c1
|
|
|
|
#define HDA_CODEC_AGEREXXXX HDA_CODEC_CONSTRUCT(AGERE, 0xffff)
|
|
|
|
|
2006-10-01 11:13:00 +00:00
|
|
|
/*
|
|
|
|
* Conexant
|
|
|
|
*
|
|
|
|
* Ok, the truth is, I don't have any idea at all whether
|
|
|
|
* it is "Venice" or "Waikiki" or other unnamed CXyadayada. The only
|
|
|
|
* place that tell me it is "Venice" is from its Windows driver INF.
|
- Fix wrong id for ALC882, add ALC883 id.
- 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"
2006-10-06 18:59:27 +00:00
|
|
|
*
|
|
|
|
* Venice - CX?????
|
|
|
|
* Waikiki - CX20551-22
|
2006-10-01 11:13:00 +00:00
|
|
|
*/
|
|
|
|
#define CONEXANT_VENDORID 0x14f1
|
|
|
|
#define HDA_CODEC_CXVENICE HDA_CODEC_CONSTRUCT(CONEXANT, 0x5045)
|
- Fix wrong id for ALC882, add ALC883 id.
- 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"
2006-10-06 18:59:27 +00:00
|
|
|
#define HDA_CODEC_CXWAIKIKI HDA_CODEC_CONSTRUCT(CONEXANT, 0x5047)
|
2006-10-01 11:13:00 +00:00
|
|
|
#define HDA_CODEC_CXXXXX HDA_CODEC_CONSTRUCT(CONEXANT, 0xffff)
|
|
|
|
|
2007-05-05 09:17:36 +00:00
|
|
|
/* VIA */
|
|
|
|
#define HDA_CODEC_VT1708_8 HDA_CODEC_CONSTRUCT(VIA, 0x1708)
|
|
|
|
#define HDA_CODEC_VT1708_9 HDA_CODEC_CONSTRUCT(VIA, 0x1709)
|
|
|
|
#define HDA_CODEC_VT1708_A HDA_CODEC_CONSTRUCT(VIA, 0x170a)
|
|
|
|
#define HDA_CODEC_VT1708_B HDA_CODEC_CONSTRUCT(VIA, 0x170b)
|
|
|
|
#define HDA_CODEC_VT1709_0 HDA_CODEC_CONSTRUCT(VIA, 0xe710)
|
|
|
|
#define HDA_CODEC_VT1709_1 HDA_CODEC_CONSTRUCT(VIA, 0xe711)
|
|
|
|
#define HDA_CODEC_VT1709_2 HDA_CODEC_CONSTRUCT(VIA, 0xe712)
|
|
|
|
#define HDA_CODEC_VT1709_3 HDA_CODEC_CONSTRUCT(VIA, 0xe713)
|
|
|
|
#define HDA_CODEC_VT1709_4 HDA_CODEC_CONSTRUCT(VIA, 0xe714)
|
|
|
|
#define HDA_CODEC_VT1709_5 HDA_CODEC_CONSTRUCT(VIA, 0xe715)
|
|
|
|
#define HDA_CODEC_VT1709_6 HDA_CODEC_CONSTRUCT(VIA, 0xe716)
|
|
|
|
#define HDA_CODEC_VT1709_7 HDA_CODEC_CONSTRUCT(VIA, 0xe717)
|
|
|
|
#define HDA_CODEC_VTXXXX HDA_CODEC_CONSTRUCT(VIA, 0xffff)
|
|
|
|
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
/* ATI */
|
|
|
|
#define HDA_CODEC_ATIXXXX HDA_CODEC_CONSTRUCT(ATI, 0xffff)
|
|
|
|
|
|
|
|
/* NVIDIA */
|
|
|
|
#define HDA_CODEC_NVIDIAXXXX HDA_CODEC_CONSTRUCT(NVIDIA, 0xffff)
|
2006-10-01 11:13:00 +00:00
|
|
|
|
|
|
|
/* Codecs */
|
|
|
|
static const struct {
|
|
|
|
uint32_t id;
|
|
|
|
char *name;
|
|
|
|
} hdac_codecs[] = {
|
|
|
|
{ HDA_CODEC_ALC260, "Realtek ALC260" },
|
2007-05-05 09:17:36 +00:00
|
|
|
{ HDA_CODEC_ALC262, "Realtek ALC262" },
|
2008-09-14 17:37:34 +00:00
|
|
|
{ HDA_CODEC_ALC267, "Realtek ALC267" },
|
2007-07-09 20:42:11 +00:00
|
|
|
{ HDA_CODEC_ALC268, "Realtek ALC268" },
|
2008-09-14 17:37:34 +00:00
|
|
|
{ HDA_CODEC_ALC269, "Realtek ALC269" },
|
|
|
|
{ HDA_CODEC_ALC272, "Realtek ALC272" },
|
2007-06-10 23:01:40 +00:00
|
|
|
{ HDA_CODEC_ALC660, "Realtek ALC660" },
|
2008-09-14 17:37:34 +00:00
|
|
|
{ HDA_CODEC_ALC662, "Realtek ALC662" },
|
|
|
|
{ HDA_CODEC_ALC663, "Realtek ALC663" },
|
2006-10-01 11:13:00 +00:00
|
|
|
{ HDA_CODEC_ALC861, "Realtek ALC861" },
|
2007-05-05 09:17:36 +00:00
|
|
|
{ HDA_CODEC_ALC861VD, "Realtek ALC861-VD" },
|
2006-10-01 11:13:00 +00:00
|
|
|
{ HDA_CODEC_ALC880, "Realtek ALC880" },
|
|
|
|
{ HDA_CODEC_ALC882, "Realtek ALC882" },
|
- Fix wrong id for ALC882, add ALC883 id.
- 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"
2006-10-06 18:59:27 +00:00
|
|
|
{ HDA_CODEC_ALC883, "Realtek ALC883" },
|
2007-05-05 09:17:36 +00:00
|
|
|
{ HDA_CODEC_ALC885, "Realtek ALC885" },
|
2006-12-17 15:19:33 +00:00
|
|
|
{ HDA_CODEC_ALC888, "Realtek ALC888" },
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
{ HDA_CODEC_ALC889, "Realtek ALC889" },
|
2007-05-05 09:17:36 +00:00
|
|
|
{ HDA_CODEC_AD1981HD, "Analog Devices AD1981HD" },
|
|
|
|
{ HDA_CODEC_AD1983, "Analog Devices AD1983" },
|
2007-11-28 15:27:22 +00:00
|
|
|
{ HDA_CODEC_AD1984, "Analog Devices AD1984" },
|
2007-05-05 09:17:36 +00:00
|
|
|
{ HDA_CODEC_AD1986A, "Analog Devices AD1986A" },
|
|
|
|
{ HDA_CODEC_AD1988, "Analog Devices AD1988" },
|
2007-06-10 23:01:40 +00:00
|
|
|
{ HDA_CODEC_AD1988B, "Analog Devices AD1988B" },
|
2006-10-01 11:13:00 +00:00
|
|
|
{ HDA_CODEC_CMI9880, "CMedia CMI9880" },
|
|
|
|
{ HDA_CODEC_STAC9221, "Sigmatel STAC9221" },
|
|
|
|
{ HDA_CODEC_STAC9221D, "Sigmatel STAC9221D" },
|
|
|
|
{ HDA_CODEC_STAC9220, "Sigmatel STAC9220" },
|
|
|
|
{ HDA_CODEC_STAC922XD, "Sigmatel STAC9220D/9223D" },
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
{ HDA_CODEC_STAC9230X, "Sigmatel STAC9230X" },
|
|
|
|
{ HDA_CODEC_STAC9230D, "Sigmatel STAC9230D" },
|
|
|
|
{ HDA_CODEC_STAC9229X, "Sigmatel STAC9229X" },
|
|
|
|
{ HDA_CODEC_STAC9229D, "Sigmatel STAC9229D" },
|
|
|
|
{ HDA_CODEC_STAC9228X, "Sigmatel STAC9228X" },
|
|
|
|
{ HDA_CODEC_STAC9228D, "Sigmatel STAC9228D" },
|
|
|
|
{ HDA_CODEC_STAC9227X, "Sigmatel STAC9227X" },
|
|
|
|
{ HDA_CODEC_STAC9227D, "Sigmatel STAC9227D" },
|
2007-02-16 17:43:29 +00:00
|
|
|
{ HDA_CODEC_STAC9271D, "Sigmatel STAC9271D" },
|
2008-04-12 15:07:32 +00:00
|
|
|
{ HDA_CODEC_STAC9205, "Sigmatel STAC9205" },
|
2008-05-22 09:14:12 +00:00
|
|
|
{ HDA_CODEC_STAC9872AK,"Sigmatel STAC9872AK" },
|
2006-10-01 11:13:00 +00:00
|
|
|
{ HDA_CODEC_CXVENICE, "Conexant Venice" },
|
- Fix wrong id for ALC882, add ALC883 id.
- 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"
2006-10-06 18:59:27 +00:00
|
|
|
{ HDA_CODEC_CXWAIKIKI, "Conexant Waikiki" },
|
2007-05-05 09:17:36 +00:00
|
|
|
{ HDA_CODEC_VT1708_8, "VIA VT1708_8" },
|
|
|
|
{ HDA_CODEC_VT1708_9, "VIA VT1708_9" },
|
|
|
|
{ HDA_CODEC_VT1708_A, "VIA VT1708_A" },
|
|
|
|
{ HDA_CODEC_VT1708_B, "VIA VT1708_B" },
|
|
|
|
{ HDA_CODEC_VT1709_0, "VIA VT1709_0" },
|
|
|
|
{ HDA_CODEC_VT1709_1, "VIA VT1709_1" },
|
|
|
|
{ HDA_CODEC_VT1709_2, "VIA VT1709_2" },
|
|
|
|
{ HDA_CODEC_VT1709_3, "VIA VT1709_3" },
|
|
|
|
{ HDA_CODEC_VT1709_4, "VIA VT1709_4" },
|
|
|
|
{ HDA_CODEC_VT1709_5, "VIA VT1709_5" },
|
|
|
|
{ HDA_CODEC_VT1709_6, "VIA VT1709_6" },
|
|
|
|
{ HDA_CODEC_VT1709_7, "VIA VT1709_7" },
|
2006-10-01 11:13:00 +00:00
|
|
|
/* Unknown codec */
|
|
|
|
{ HDA_CODEC_ALCXXXX, "Realtek (Unknown)" },
|
2007-05-05 09:17:36 +00:00
|
|
|
{ HDA_CODEC_ADXXXX, "Analog Devices (Unknown)" },
|
2006-10-01 11:13:00 +00:00
|
|
|
{ HDA_CODEC_CMIXXXX, "CMedia (Unknown)" },
|
|
|
|
{ HDA_CODEC_STACXXXX, "Sigmatel (Unknown)" },
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
{ HDA_CODEC_SIIXXXX, "Silicon Image (Unknown)" },
|
|
|
|
{ HDA_CODEC_AGEREXXXX, "Lucent/Agere Systems (Unknown)" },
|
2006-10-01 11:13:00 +00:00
|
|
|
{ HDA_CODEC_CXXXXX, "Conexant (Unknown)" },
|
2007-05-05 09:17:36 +00:00
|
|
|
{ HDA_CODEC_VTXXXX, "VIA (Unknown)" },
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
{ HDA_CODEC_ATIXXXX, "ATI (Unknown)" },
|
|
|
|
{ HDA_CODEC_NVIDIAXXXX,"NVidia (Unknown)" },
|
2006-10-01 11:13:00 +00:00
|
|
|
};
|
|
|
|
#define HDAC_CODECS_LEN (sizeof(hdac_codecs) / sizeof(hdac_codecs[0]))
|
|
|
|
|
|
|
|
|
|
|
|
/****************************************************************************
|
|
|
|
* Function prototypes
|
|
|
|
****************************************************************************/
|
|
|
|
static void hdac_intr_handler(void *);
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
static int hdac_reset(struct hdac_softc *, int);
|
2006-10-01 11:13:00 +00:00
|
|
|
static int hdac_get_capabilities(struct hdac_softc *);
|
|
|
|
static void hdac_dma_cb(void *, bus_dma_segment_t *, int, int);
|
|
|
|
static int hdac_dma_alloc(struct hdac_softc *,
|
|
|
|
struct hdac_dma *, bus_size_t);
|
2007-05-05 09:17:36 +00:00
|
|
|
static void hdac_dma_free(struct hdac_softc *, struct hdac_dma *);
|
2006-10-01 11:13:00 +00:00
|
|
|
static int hdac_mem_alloc(struct hdac_softc *);
|
|
|
|
static void hdac_mem_free(struct hdac_softc *);
|
|
|
|
static int hdac_irq_alloc(struct hdac_softc *);
|
|
|
|
static void hdac_irq_free(struct hdac_softc *);
|
|
|
|
static void hdac_corb_init(struct hdac_softc *);
|
|
|
|
static void hdac_rirb_init(struct hdac_softc *);
|
|
|
|
static void hdac_corb_start(struct hdac_softc *);
|
|
|
|
static void hdac_rirb_start(struct hdac_softc *);
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
static void hdac_scan_codecs(struct hdac_softc *);
|
|
|
|
static void hdac_probe_codec(struct hdac_codec *);
|
|
|
|
static void hdac_probe_function(struct hdac_codec *, nid_t);
|
|
|
|
static int hdac_pcmchannel_setup(struct hdac_chan *);
|
2006-10-01 11:13:00 +00:00
|
|
|
|
|
|
|
static void hdac_attach2(void *);
|
|
|
|
|
|
|
|
static uint32_t hdac_command_sendone_internal(struct hdac_softc *,
|
|
|
|
uint32_t, int);
|
|
|
|
static void hdac_command_send_internal(struct hdac_softc *,
|
|
|
|
struct hdac_command_list *, int);
|
|
|
|
|
|
|
|
static int hdac_probe(device_t);
|
|
|
|
static int hdac_attach(device_t);
|
|
|
|
static int hdac_detach(device_t);
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
static int hdac_suspend(device_t);
|
|
|
|
static int hdac_resume(device_t);
|
2006-10-01 11:13:00 +00:00
|
|
|
static void hdac_widget_connection_select(struct hdac_widget *, uint8_t);
|
|
|
|
static void hdac_audio_ctl_amp_set(struct hdac_audio_ctl *,
|
|
|
|
uint32_t, int, int);
|
|
|
|
static struct hdac_audio_ctl *hdac_audio_ctl_amp_get(struct hdac_devinfo *,
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
nid_t, int, int, int);
|
2006-10-01 11:13:00 +00:00
|
|
|
static void hdac_audio_ctl_amp_set_internal(struct hdac_softc *,
|
|
|
|
nid_t, nid_t, int, int, int, int, int, int);
|
|
|
|
static struct hdac_widget *hdac_widget_get(struct hdac_devinfo *, nid_t);
|
|
|
|
|
Welcome to Once-a-year Sound Mega-Commit. Enjoy numerous updates and fixes
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.
2006-11-26 12:24:06 +00:00
|
|
|
static int hdac_rirb_flush(struct hdac_softc *sc);
|
|
|
|
static int hdac_unsolq_flush(struct hdac_softc *sc);
|
|
|
|
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
static void hdac_dump_pin_config(struct hdac_widget *w, uint32_t conf);
|
|
|
|
|
2006-10-01 11:13:00 +00:00
|
|
|
#define hdac_command(a1, a2, a3) \
|
|
|
|
hdac_command_sendone_internal(a1, a2, a3)
|
|
|
|
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
#define hdac_codec_id(c) \
|
|
|
|
((uint32_t)((c == NULL) ? 0x00000000 : \
|
|
|
|
((((uint32_t)(c)->vendor_id & 0x0000ffff) << 16) | \
|
|
|
|
((uint32_t)(c)->device_id & 0x0000ffff))))
|
2006-10-01 11:13:00 +00:00
|
|
|
|
|
|
|
static char *
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
hdac_codec_name(struct hdac_codec *codec)
|
2006-10-01 11:13:00 +00:00
|
|
|
{
|
|
|
|
uint32_t id;
|
|
|
|
int i;
|
|
|
|
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
id = hdac_codec_id(codec);
|
2006-10-01 11:13:00 +00:00
|
|
|
|
|
|
|
for (i = 0; i < HDAC_CODECS_LEN; i++) {
|
2006-10-12 04:19:37 +00:00
|
|
|
if (HDA_DEV_MATCH(hdac_codecs[i].id, id))
|
2006-10-01 11:13:00 +00:00
|
|
|
return (hdac_codecs[i].name);
|
|
|
|
}
|
|
|
|
|
|
|
|
return ((id == 0x00000000) ? "NULL Codec" : "Unknown Codec");
|
|
|
|
}
|
|
|
|
|
|
|
|
static char *
|
|
|
|
hdac_audio_ctl_ossmixer_mask2allname(uint32_t mask, char *buf, size_t len)
|
|
|
|
{
|
|
|
|
static char *ossname[] = SOUND_DEVICE_NAMES;
|
|
|
|
int i, first = 1;
|
|
|
|
|
|
|
|
bzero(buf, len);
|
|
|
|
for (i = 0; i < SOUND_MIXER_NRDEVICES; i++) {
|
|
|
|
if (mask & (1 << i)) {
|
|
|
|
if (first == 0)
|
|
|
|
strlcat(buf, ", ", len);
|
|
|
|
strlcat(buf, ossname[i], len);
|
|
|
|
first = 0;
|
|
|
|
}
|
|
|
|
}
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
return (buf);
|
2006-10-01 11:13:00 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static struct hdac_audio_ctl *
|
|
|
|
hdac_audio_ctl_each(struct hdac_devinfo *devinfo, int *index)
|
|
|
|
{
|
|
|
|
if (devinfo == NULL ||
|
|
|
|
devinfo->node_type != HDA_PARAM_FCT_GRP_TYPE_NODE_TYPE_AUDIO ||
|
|
|
|
index == NULL || devinfo->function.audio.ctl == NULL ||
|
|
|
|
devinfo->function.audio.ctlcnt < 1 ||
|
|
|
|
*index < 0 || *index >= devinfo->function.audio.ctlcnt)
|
|
|
|
return (NULL);
|
|
|
|
return (&devinfo->function.audio.ctl[(*index)++]);
|
|
|
|
}
|
|
|
|
|
|
|
|
static struct hdac_audio_ctl *
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
hdac_audio_ctl_amp_get(struct hdac_devinfo *devinfo, nid_t nid, int dir,
|
2006-10-01 11:13:00 +00:00
|
|
|
int index, int cnt)
|
|
|
|
{
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
struct hdac_audio_ctl *ctl;
|
|
|
|
int i, found = 0;
|
2006-10-01 11:13:00 +00:00
|
|
|
|
|
|
|
if (devinfo == NULL || devinfo->function.audio.ctl == NULL)
|
|
|
|
return (NULL);
|
|
|
|
|
|
|
|
i = 0;
|
|
|
|
while ((ctl = hdac_audio_ctl_each(devinfo, &i)) != NULL) {
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
if (ctl->enable == 0)
|
|
|
|
continue;
|
|
|
|
if (ctl->widget->nid != nid)
|
|
|
|
continue;
|
|
|
|
if (dir && ctl->ndir != dir)
|
2006-10-01 11:13:00 +00:00
|
|
|
continue;
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
if (index >= 0 && ctl->ndir == HDA_CTL_IN &&
|
|
|
|
ctl->dir == ctl->ndir && ctl->index != index)
|
2006-10-01 11:13:00 +00:00
|
|
|
continue;
|
|
|
|
found++;
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
if (found == cnt || cnt <= 0)
|
2006-10-01 11:13:00 +00:00
|
|
|
return (ctl);
|
|
|
|
}
|
|
|
|
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
return (NULL);
|
2006-10-01 11:13:00 +00:00
|
|
|
}
|
|
|
|
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
/*
|
|
|
|
* Jack detection (Speaker/HP redirection) event handler.
|
|
|
|
*/
|
2006-10-01 11:13:00 +00:00
|
|
|
static void
|
|
|
|
hdac_hp_switch_handler(struct hdac_devinfo *devinfo)
|
|
|
|
{
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
struct hdac_audio_as *as;
|
2006-10-01 11:13:00 +00:00
|
|
|
struct hdac_softc *sc;
|
|
|
|
struct hdac_widget *w;
|
|
|
|
struct hdac_audio_ctl *ctl;
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
uint32_t val, res;
|
|
|
|
int i, j;
|
2006-10-01 11:13:00 +00:00
|
|
|
nid_t cad;
|
|
|
|
|
|
|
|
if (devinfo == NULL || devinfo->codec == NULL ||
|
|
|
|
devinfo->codec->sc == NULL)
|
|
|
|
return;
|
|
|
|
|
|
|
|
sc = devinfo->codec->sc;
|
|
|
|
cad = devinfo->codec->cad;
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
as = devinfo->function.audio.as;
|
|
|
|
for (i = 0; i < devinfo->function.audio.ascnt; i++) {
|
|
|
|
if (as[i].hpredir < 0)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
w = hdac_widget_get(devinfo, as[i].pins[15]);
|
|
|
|
if (w == NULL || w->enable == 0 || w->type !=
|
|
|
|
HDA_PARAM_AUDIO_WIDGET_CAP_TYPE_PIN_COMPLEX)
|
|
|
|
continue;
|
2007-07-01 17:31:20 +00:00
|
|
|
|
|
|
|
res = hdac_command(sc,
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
HDA_CMD_GET_PIN_SENSE(cad, as[i].pins[15]), cad);
|
2007-07-01 17:31:20 +00:00
|
|
|
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
HDA_BOOTVERBOSE(
|
|
|
|
device_printf(sc->dev,
|
|
|
|
"Pin sense: nid=%d res=0x%08x\n",
|
|
|
|
as[i].pins[15], res);
|
|
|
|
);
|
2007-07-01 17:31:20 +00:00
|
|
|
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
res = HDA_CMD_GET_PIN_SENSE_PRESENCE_DETECT(res);
|
|
|
|
if (devinfo->function.audio.quirks & HDA_QUIRK_SENSEINV)
|
|
|
|
res ^= 1;
|
2006-10-01 11:13:00 +00:00
|
|
|
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
/* (Un)Mute headphone pin. */
|
2006-10-01 11:13:00 +00:00
|
|
|
ctl = hdac_audio_ctl_amp_get(devinfo,
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
as[i].pins[15], HDA_CTL_IN, -1, 1);
|
|
|
|
if (ctl != NULL && ctl->mute) {
|
|
|
|
/* If pin has muter - use it. */
|
|
|
|
val = (res != 0) ? 0 : 1;
|
|
|
|
if (val != ctl->forcemute) {
|
|
|
|
ctl->forcemute = val;
|
2006-10-01 11:13:00 +00:00
|
|
|
hdac_audio_ctl_amp_set(ctl,
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
HDA_AMP_MUTE_DEFAULT,
|
|
|
|
HDA_AMP_VOL_DEFAULT, HDA_AMP_VOL_DEFAULT);
|
2006-10-01 11:13:00 +00:00
|
|
|
}
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
} else {
|
|
|
|
/* If there is no muter - disable pin output. */
|
|
|
|
w = hdac_widget_get(devinfo, as[i].pins[15]);
|
- Fix wrong id for ALC882, add ALC883 id.
- 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"
2006-10-06 18:59:27 +00:00
|
|
|
if (w != NULL && w->type ==
|
|
|
|
HDA_PARAM_AUDIO_WIDGET_CAP_TYPE_PIN_COMPLEX) {
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
if (res != 0)
|
2007-05-05 09:17:36 +00:00
|
|
|
val = w->wclass.pin.ctrl |
|
2006-10-01 11:13:00 +00:00
|
|
|
HDA_CMD_SET_PIN_WIDGET_CTRL_OUT_ENABLE;
|
|
|
|
else
|
2007-05-05 09:17:36 +00:00
|
|
|
val = w->wclass.pin.ctrl &
|
2006-10-01 11:13:00 +00:00
|
|
|
~HDA_CMD_SET_PIN_WIDGET_CTRL_OUT_ENABLE;
|
2007-05-05 09:17:36 +00:00
|
|
|
if (val != w->wclass.pin.ctrl) {
|
|
|
|
w->wclass.pin.ctrl = val;
|
|
|
|
hdac_command(sc,
|
|
|
|
HDA_CMD_SET_PIN_WIDGET_CTRL(cad,
|
|
|
|
w->nid, w->wclass.pin.ctrl), cad);
|
|
|
|
}
|
2006-10-01 11:13:00 +00:00
|
|
|
}
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
}
|
|
|
|
/* (Un)Mute other pins. */
|
|
|
|
for (j = 0; j < 15; j++) {
|
|
|
|
if (as[i].pins[j] <= 0)
|
|
|
|
continue;
|
|
|
|
ctl = hdac_audio_ctl_amp_get(devinfo,
|
|
|
|
as[i].pins[j], HDA_CTL_IN, -1, 1);
|
|
|
|
if (ctl != NULL && ctl->mute) {
|
|
|
|
/* If pin has muter - use it. */
|
|
|
|
val = (res != 0) ? 1 : 0;
|
|
|
|
if (val == ctl->forcemute)
|
2007-05-05 09:17:36 +00:00
|
|
|
continue;
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
ctl->forcemute = val;
|
|
|
|
hdac_audio_ctl_amp_set(ctl,
|
|
|
|
HDA_AMP_MUTE_DEFAULT,
|
|
|
|
HDA_AMP_VOL_DEFAULT, HDA_AMP_VOL_DEFAULT);
|
|
|
|
continue;
|
2006-10-01 11:13:00 +00:00
|
|
|
}
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
/* If there is no muter - disable pin output. */
|
|
|
|
w = hdac_widget_get(devinfo, as[i].pins[j]);
|
- Fix wrong id for ALC882, add ALC883 id.
- 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"
2006-10-06 18:59:27 +00:00
|
|
|
if (w != NULL && w->type ==
|
|
|
|
HDA_PARAM_AUDIO_WIDGET_CAP_TYPE_PIN_COMPLEX) {
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
if (res != 0)
|
|
|
|
val = w->wclass.pin.ctrl &
|
|
|
|
~HDA_CMD_SET_PIN_WIDGET_CTRL_OUT_ENABLE;
|
|
|
|
else
|
|
|
|
val = w->wclass.pin.ctrl |
|
|
|
|
HDA_CMD_SET_PIN_WIDGET_CTRL_OUT_ENABLE;
|
2007-05-05 09:17:36 +00:00
|
|
|
if (val != w->wclass.pin.ctrl) {
|
|
|
|
w->wclass.pin.ctrl = val;
|
|
|
|
hdac_command(sc,
|
|
|
|
HDA_CMD_SET_PIN_WIDGET_CTRL(cad,
|
|
|
|
w->nid, w->wclass.pin.ctrl), cad);
|
|
|
|
}
|
2006-10-01 11:13:00 +00:00
|
|
|
}
|
|
|
|
}
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Callback for poll based jack detection.
|
|
|
|
*/
|
|
|
|
static void
|
|
|
|
hdac_jack_poll_callback(void *arg)
|
|
|
|
{
|
|
|
|
struct hdac_devinfo *devinfo = arg;
|
|
|
|
struct hdac_softc *sc;
|
|
|
|
|
|
|
|
if (devinfo == NULL || devinfo->codec == NULL ||
|
|
|
|
devinfo->codec->sc == NULL)
|
|
|
|
return;
|
|
|
|
sc = devinfo->codec->sc;
|
|
|
|
hdac_lock(sc);
|
|
|
|
if (sc->poll_ival == 0) {
|
|
|
|
hdac_unlock(sc);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
hdac_hp_switch_handler(devinfo);
|
|
|
|
callout_reset(&sc->poll_jack, sc->poll_ival,
|
|
|
|
hdac_jack_poll_callback, devinfo);
|
|
|
|
hdac_unlock(sc);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Jack detection initializer.
|
|
|
|
*/
|
|
|
|
static void
|
|
|
|
hdac_hp_switch_init(struct hdac_devinfo *devinfo)
|
|
|
|
{
|
|
|
|
struct hdac_softc *sc = devinfo->codec->sc;
|
|
|
|
struct hdac_audio_as *as = devinfo->function.audio.as;
|
|
|
|
struct hdac_widget *w;
|
|
|
|
uint32_t id;
|
|
|
|
int i, enable = 0, poll = 0;
|
|
|
|
nid_t cad;
|
|
|
|
|
|
|
|
id = hdac_codec_id(devinfo->codec);
|
|
|
|
cad = devinfo->codec->cad;
|
|
|
|
for (i = 0; i < devinfo->function.audio.ascnt; i++) {
|
|
|
|
if (as[i].hpredir < 0)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
w = hdac_widget_get(devinfo, as[i].pins[15]);
|
|
|
|
if (w == NULL || w->enable == 0 || w->type !=
|
|
|
|
HDA_PARAM_AUDIO_WIDGET_CAP_TYPE_PIN_COMPLEX)
|
|
|
|
continue;
|
|
|
|
if (HDA_PARAM_PIN_CAP_PRESENCE_DETECT_CAP(w->wclass.pin.cap) == 0 ||
|
|
|
|
(HDA_CONFIG_DEFAULTCONF_MISC(w->wclass.pin.config) & 1) != 0) {
|
|
|
|
device_printf(sc->dev,
|
|
|
|
"No jack detection support at pin %d\n",
|
|
|
|
as[i].pins[15]);
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
enable = 1;
|
|
|
|
if (HDA_PARAM_AUDIO_WIDGET_CAP_UNSOL_CAP(w->param.widget_cap)) {
|
2007-05-05 09:17:36 +00:00
|
|
|
hdac_command(sc,
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
HDA_CMD_SET_UNSOLICITED_RESPONSE(cad, w->nid,
|
|
|
|
HDA_CMD_SET_UNSOLICITED_RESPONSE_ENABLE |
|
|
|
|
HDAC_UNSOLTAG_EVENT_HP), cad);
|
|
|
|
} else
|
|
|
|
poll = 1;
|
|
|
|
HDA_BOOTVERBOSE(
|
2007-05-05 09:17:36 +00:00
|
|
|
device_printf(sc->dev,
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
"Enabling headphone/speaker "
|
|
|
|
"audio routing switching:\n");
|
|
|
|
device_printf(sc->dev, "\tas=%d sense nid=%d [%s]\n",
|
|
|
|
i, w->nid, (poll != 0) ? "POLL" : "UNSOL");
|
|
|
|
);
|
|
|
|
}
|
|
|
|
if (enable) {
|
|
|
|
hdac_hp_switch_handler(devinfo);
|
|
|
|
if (poll) {
|
|
|
|
callout_reset(&sc->poll_jack, 1,
|
|
|
|
hdac_jack_poll_callback, devinfo);
|
2007-05-05 09:17:36 +00:00
|
|
|
}
|
2006-10-01 11:13:00 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
/*
|
|
|
|
* Unsolicited messages handler.
|
|
|
|
*/
|
2006-10-01 11:13:00 +00:00
|
|
|
static void
|
|
|
|
hdac_unsolicited_handler(struct hdac_codec *codec, uint32_t tag)
|
|
|
|
{
|
|
|
|
struct hdac_softc *sc;
|
|
|
|
struct hdac_devinfo *devinfo = NULL;
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
int i;
|
2006-10-01 11:13:00 +00:00
|
|
|
|
|
|
|
if (codec == NULL || codec->sc == NULL)
|
|
|
|
return;
|
|
|
|
|
|
|
|
sc = codec->sc;
|
|
|
|
|
- Fix wrong id for ALC882, add ALC883 id.
- 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"
2006-10-06 18:59:27 +00:00
|
|
|
HDA_BOOTVERBOSE(
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
device_printf(sc->dev, "Unsol Tag: 0x%08x\n", tag);
|
2006-10-01 11:13:00 +00:00
|
|
|
);
|
|
|
|
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
for (i = 0; i < codec->num_fgs; i++) {
|
|
|
|
if (codec->fgs[i].node_type ==
|
|
|
|
HDA_PARAM_FCT_GRP_TYPE_NODE_TYPE_AUDIO) {
|
|
|
|
devinfo = &codec->fgs[i];
|
2006-10-02 16:30:04 +00:00
|
|
|
break;
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
}
|
2006-10-01 11:13:00 +00:00
|
|
|
}
|
2006-10-02 16:30:04 +00:00
|
|
|
|
2006-10-01 11:13:00 +00:00
|
|
|
if (devinfo == NULL)
|
|
|
|
return;
|
|
|
|
|
|
|
|
switch (tag) {
|
|
|
|
case HDAC_UNSOLTAG_EVENT_HP:
|
|
|
|
hdac_hp_switch_handler(devinfo);
|
|
|
|
break;
|
|
|
|
default:
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
device_printf(sc->dev, "Unknown unsol tag: 0x%08x!\n", tag);
|
2006-10-01 11:13:00 +00:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
Welcome to Once-a-year Sound Mega-Commit. Enjoy numerous updates and fixes
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.
2006-11-26 12:24:06 +00:00
|
|
|
static int
|
2006-10-01 11:13:00 +00:00
|
|
|
hdac_stream_intr(struct hdac_softc *sc, struct hdac_chan *ch)
|
|
|
|
{
|
|
|
|
/* XXX to be removed */
|
|
|
|
#ifdef HDAC_INTR_EXTRA
|
|
|
|
uint32_t res;
|
|
|
|
#endif
|
|
|
|
|
2007-07-09 20:42:11 +00:00
|
|
|
if (!(ch->flags & HDAC_CHN_RUNNING))
|
Welcome to Once-a-year Sound Mega-Commit. Enjoy numerous updates and fixes
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.
2006-11-26 12:24:06 +00:00
|
|
|
return (0);
|
2006-10-01 11:13:00 +00:00
|
|
|
|
|
|
|
/* XXX to be removed */
|
|
|
|
#ifdef HDAC_INTR_EXTRA
|
|
|
|
res = HDAC_READ_1(&sc->mem, ch->off + HDAC_SDSTS);
|
|
|
|
#endif
|
|
|
|
|
|
|
|
/* XXX to be removed */
|
|
|
|
#ifdef HDAC_INTR_EXTRA
|
- Fix wrong id for ALC882, add ALC883 id.
- 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"
2006-10-06 18:59:27 +00:00
|
|
|
HDA_BOOTVERBOSE(
|
|
|
|
if (res & (HDAC_SDSTS_DESE | HDAC_SDSTS_FIFOE))
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
device_printf(ch->pdevinfo->dev,
|
- Fix wrong id for ALC882, add ALC883 id.
- 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"
2006-10-06 18:59:27 +00:00
|
|
|
"PCMDIR_%s intr triggered beyond stream boundary:"
|
|
|
|
"%08x\n",
|
|
|
|
(ch->dir == PCMDIR_PLAY) ? "PLAY" : "REC", res);
|
|
|
|
);
|
2006-10-01 11:13:00 +00:00
|
|
|
#endif
|
|
|
|
|
|
|
|
HDAC_WRITE_1(&sc->mem, ch->off + HDAC_SDSTS,
|
- Fix wrong id for ALC882, add ALC883 id.
- 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"
2006-10-06 18:59:27 +00:00
|
|
|
HDAC_SDSTS_DESE | HDAC_SDSTS_FIFOE | HDAC_SDSTS_BCIS );
|
2006-10-01 11:13:00 +00:00
|
|
|
|
|
|
|
/* XXX to be removed */
|
|
|
|
#ifdef HDAC_INTR_EXTRA
|
|
|
|
if (res & HDAC_SDSTS_BCIS) {
|
|
|
|
#endif
|
Welcome to Once-a-year Sound Mega-Commit. Enjoy numerous updates and fixes
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.
2006-11-26 12:24:06 +00:00
|
|
|
return (1);
|
2006-10-01 11:13:00 +00:00
|
|
|
/* XXX to be removed */
|
|
|
|
#ifdef HDAC_INTR_EXTRA
|
|
|
|
}
|
|
|
|
#endif
|
Welcome to Once-a-year Sound Mega-Commit. Enjoy numerous updates and fixes
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.
2006-11-26 12:24:06 +00:00
|
|
|
|
|
|
|
return (0);
|
2006-10-01 11:13:00 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/****************************************************************************
|
|
|
|
* void hdac_intr_handler(void *)
|
|
|
|
*
|
|
|
|
* Interrupt handler. Processes interrupts received from the hdac.
|
|
|
|
****************************************************************************/
|
|
|
|
static void
|
|
|
|
hdac_intr_handler(void *context)
|
|
|
|
{
|
|
|
|
struct hdac_softc *sc;
|
|
|
|
uint32_t intsts;
|
|
|
|
uint8_t rirbsts;
|
Welcome to Once-a-year Sound Mega-Commit. Enjoy numerous updates and fixes
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.
2006-11-26 12:24:06 +00:00
|
|
|
struct hdac_rirb *rirb_base;
|
2007-07-01 17:31:20 +00:00
|
|
|
uint32_t trigger;
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
int i;
|
2006-10-01 11:13:00 +00:00
|
|
|
|
|
|
|
sc = (struct hdac_softc *)context;
|
|
|
|
|
|
|
|
hdac_lock(sc);
|
Welcome to Once-a-year Sound Mega-Commit. Enjoy numerous updates and fixes
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.
2006-11-26 12:24:06 +00:00
|
|
|
if (sc->polling != 0) {
|
|
|
|
hdac_unlock(sc);
|
|
|
|
return;
|
|
|
|
}
|
2007-07-01 17:31:20 +00:00
|
|
|
|
2006-10-01 11:13:00 +00:00
|
|
|
/* Do we have anything to do? */
|
|
|
|
intsts = HDAC_READ_4(&sc->mem, HDAC_INTSTS);
|
- Fix wrong id for ALC882, add ALC883 id.
- 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"
2006-10-06 18:59:27 +00:00
|
|
|
if (!HDA_FLAG_MATCH(intsts, HDAC_INTSTS_GIS)) {
|
2006-10-01 11:13:00 +00:00
|
|
|
hdac_unlock(sc);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2007-07-01 17:31:20 +00:00
|
|
|
trigger = 0;
|
|
|
|
|
2006-10-01 11:13:00 +00:00
|
|
|
/* Was this a controller interrupt? */
|
- Fix wrong id for ALC882, add ALC883 id.
- 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"
2006-10-06 18:59:27 +00:00
|
|
|
if (HDA_FLAG_MATCH(intsts, HDAC_INTSTS_CIS)) {
|
2006-10-01 11:13:00 +00:00
|
|
|
rirb_base = (struct hdac_rirb *)sc->rirb_dma.dma_vaddr;
|
|
|
|
rirbsts = HDAC_READ_1(&sc->mem, HDAC_RIRBSTS);
|
|
|
|
/* Get as many responses that we can */
|
- Fix wrong id for ALC882, add ALC883 id.
- 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"
2006-10-06 18:59:27 +00:00
|
|
|
while (HDA_FLAG_MATCH(rirbsts, HDAC_RIRBSTS_RINTFL)) {
|
Welcome to Once-a-year Sound Mega-Commit. Enjoy numerous updates and fixes
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.
2006-11-26 12:24:06 +00:00
|
|
|
HDAC_WRITE_1(&sc->mem,
|
|
|
|
HDAC_RIRBSTS, HDAC_RIRBSTS_RINTFL);
|
2007-07-01 17:31:20 +00:00
|
|
|
if (hdac_rirb_flush(sc) != 0)
|
|
|
|
trigger |= HDAC_TRIGGER_UNSOL;
|
2006-10-01 11:13:00 +00:00
|
|
|
rirbsts = HDAC_READ_1(&sc->mem, HDAC_RIRBSTS);
|
|
|
|
}
|
|
|
|
/* XXX to be removed */
|
|
|
|
/* Clear interrupt and exit */
|
|
|
|
#ifdef HDAC_INTR_EXTRA
|
|
|
|
HDAC_WRITE_4(&sc->mem, HDAC_INTSTS, HDAC_INTSTS_CIS);
|
|
|
|
#endif
|
|
|
|
}
|
Welcome to Once-a-year Sound Mega-Commit. Enjoy numerous updates and fixes
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.
2006-11-26 12:24:06 +00:00
|
|
|
|
- Fix wrong id for ALC882, add ALC883 id.
- 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"
2006-10-06 18:59:27 +00:00
|
|
|
if (intsts & HDAC_INTSTS_SIS_MASK) {
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
for (i = 0; i < sc->num_chans; i++) {
|
|
|
|
if ((intsts & (1 << (sc->chans[i].off >> 5))) &&
|
|
|
|
hdac_stream_intr(sc, &sc->chans[i]) != 0)
|
|
|
|
trigger |= (1 << i);
|
|
|
|
}
|
2006-10-01 11:13:00 +00:00
|
|
|
/* XXX to be removed */
|
|
|
|
#ifdef HDAC_INTR_EXTRA
|
Welcome to Once-a-year Sound Mega-Commit. Enjoy numerous updates and fixes
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.
2006-11-26 12:24:06 +00:00
|
|
|
HDAC_WRITE_4(&sc->mem, HDAC_INTSTS, intsts &
|
|
|
|
HDAC_INTSTS_SIS_MASK);
|
2006-10-01 11:13:00 +00:00
|
|
|
#endif
|
|
|
|
}
|
|
|
|
|
|
|
|
hdac_unlock(sc);
|
Welcome to Once-a-year Sound Mega-Commit. Enjoy numerous updates and fixes
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.
2006-11-26 12:24:06 +00:00
|
|
|
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
for (i = 0; i < sc->num_chans; i++) {
|
|
|
|
if (trigger & (1 << i))
|
|
|
|
chn_intr(sc->chans[i].c);
|
|
|
|
}
|
2007-07-01 17:31:20 +00:00
|
|
|
if (trigger & HDAC_TRIGGER_UNSOL)
|
|
|
|
taskqueue_enqueue(taskqueue_thread, &sc->unsolq_task);
|
2006-10-01 11:13:00 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/****************************************************************************
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
* int hdac_reset(hdac_softc *, int)
|
2006-10-01 11:13:00 +00:00
|
|
|
*
|
|
|
|
* Reset the hdac to a quiescent and known state.
|
|
|
|
****************************************************************************/
|
|
|
|
static int
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
hdac_reset(struct hdac_softc *sc, int wakeup)
|
2006-10-01 11:13:00 +00:00
|
|
|
{
|
|
|
|
uint32_t gctl;
|
|
|
|
int count, i;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Stop all Streams DMA engine
|
|
|
|
*/
|
|
|
|
for (i = 0; i < sc->num_iss; i++)
|
|
|
|
HDAC_WRITE_4(&sc->mem, HDAC_ISDCTL(sc, i), 0x0);
|
|
|
|
for (i = 0; i < sc->num_oss; i++)
|
|
|
|
HDAC_WRITE_4(&sc->mem, HDAC_OSDCTL(sc, i), 0x0);
|
|
|
|
for (i = 0; i < sc->num_bss; i++)
|
|
|
|
HDAC_WRITE_4(&sc->mem, HDAC_BSDCTL(sc, i), 0x0);
|
|
|
|
|
|
|
|
/*
|
2007-05-05 09:17:36 +00:00
|
|
|
* Stop Control DMA engines.
|
2006-10-01 11:13:00 +00:00
|
|
|
*/
|
|
|
|
HDAC_WRITE_1(&sc->mem, HDAC_CORBCTL, 0x0);
|
|
|
|
HDAC_WRITE_1(&sc->mem, HDAC_RIRBCTL, 0x0);
|
|
|
|
|
2007-05-05 09:17:36 +00:00
|
|
|
/*
|
|
|
|
* Reset DMA position buffer.
|
|
|
|
*/
|
|
|
|
HDAC_WRITE_4(&sc->mem, HDAC_DPIBLBASE, 0x0);
|
|
|
|
HDAC_WRITE_4(&sc->mem, HDAC_DPIBUBASE, 0x0);
|
|
|
|
|
2006-10-01 11:13:00 +00:00
|
|
|
/*
|
|
|
|
* Reset the controller. The reset must remain asserted for
|
|
|
|
* a minimum of 100us.
|
|
|
|
*/
|
|
|
|
gctl = HDAC_READ_4(&sc->mem, HDAC_GCTL);
|
|
|
|
HDAC_WRITE_4(&sc->mem, HDAC_GCTL, gctl & ~HDAC_GCTL_CRST);
|
|
|
|
count = 10000;
|
|
|
|
do {
|
|
|
|
gctl = HDAC_READ_4(&sc->mem, HDAC_GCTL);
|
|
|
|
if (!(gctl & HDAC_GCTL_CRST))
|
|
|
|
break;
|
|
|
|
DELAY(10);
|
|
|
|
} while (--count);
|
|
|
|
if (gctl & HDAC_GCTL_CRST) {
|
|
|
|
device_printf(sc->dev, "Unable to put hdac in reset\n");
|
|
|
|
return (ENXIO);
|
|
|
|
}
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
|
|
|
|
/* If wakeup is not requested - leave the controller in reset state. */
|
|
|
|
if (!wakeup)
|
|
|
|
return (0);
|
|
|
|
|
2006-10-01 11:13:00 +00:00
|
|
|
DELAY(100);
|
|
|
|
gctl = HDAC_READ_4(&sc->mem, HDAC_GCTL);
|
|
|
|
HDAC_WRITE_4(&sc->mem, HDAC_GCTL, gctl | HDAC_GCTL_CRST);
|
|
|
|
count = 10000;
|
|
|
|
do {
|
|
|
|
gctl = HDAC_READ_4(&sc->mem, HDAC_GCTL);
|
- Fix wrong id for ALC882, add ALC883 id.
- 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"
2006-10-06 18:59:27 +00:00
|
|
|
if (gctl & HDAC_GCTL_CRST)
|
2006-10-01 11:13:00 +00:00
|
|
|
break;
|
|
|
|
DELAY(10);
|
|
|
|
} while (--count);
|
|
|
|
if (!(gctl & HDAC_GCTL_CRST)) {
|
|
|
|
device_printf(sc->dev, "Device stuck in reset\n");
|
|
|
|
return (ENXIO);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Wait for codecs to finish their own reset sequence. The delay here
|
|
|
|
* should be of 250us but for some reasons, on it's not enough on my
|
|
|
|
* computer. Let's use twice as much as necessary to make sure that
|
|
|
|
* it's reset properly.
|
|
|
|
*/
|
|
|
|
DELAY(1000);
|
|
|
|
|
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/****************************************************************************
|
|
|
|
* int hdac_get_capabilities(struct hdac_softc *);
|
|
|
|
*
|
|
|
|
* Retreive the general capabilities of the hdac;
|
|
|
|
* Number of Input Streams
|
|
|
|
* Number of Output Streams
|
|
|
|
* Number of bidirectional Streams
|
|
|
|
* 64bit ready
|
|
|
|
* CORB and RIRB sizes
|
|
|
|
****************************************************************************/
|
|
|
|
static int
|
|
|
|
hdac_get_capabilities(struct hdac_softc *sc)
|
|
|
|
{
|
|
|
|
uint16_t gcap;
|
|
|
|
uint8_t corbsize, rirbsize;
|
|
|
|
|
|
|
|
gcap = HDAC_READ_2(&sc->mem, HDAC_GCAP);
|
|
|
|
sc->num_iss = HDAC_GCAP_ISS(gcap);
|
|
|
|
sc->num_oss = HDAC_GCAP_OSS(gcap);
|
|
|
|
sc->num_bss = HDAC_GCAP_BSS(gcap);
|
|
|
|
|
- Fix wrong id for ALC882, add ALC883 id.
- 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"
2006-10-06 18:59:27 +00:00
|
|
|
sc->support_64bit = HDA_FLAG_MATCH(gcap, HDAC_GCAP_64OK);
|
2006-10-01 11:13:00 +00:00
|
|
|
|
|
|
|
corbsize = HDAC_READ_1(&sc->mem, HDAC_CORBSIZE);
|
|
|
|
if ((corbsize & HDAC_CORBSIZE_CORBSZCAP_256) ==
|
|
|
|
HDAC_CORBSIZE_CORBSZCAP_256)
|
|
|
|
sc->corb_size = 256;
|
|
|
|
else if ((corbsize & HDAC_CORBSIZE_CORBSZCAP_16) ==
|
|
|
|
HDAC_CORBSIZE_CORBSZCAP_16)
|
|
|
|
sc->corb_size = 16;
|
|
|
|
else if ((corbsize & HDAC_CORBSIZE_CORBSZCAP_2) ==
|
|
|
|
HDAC_CORBSIZE_CORBSZCAP_2)
|
|
|
|
sc->corb_size = 2;
|
|
|
|
else {
|
|
|
|
device_printf(sc->dev, "%s: Invalid corb size (%x)\n",
|
|
|
|
__func__, corbsize);
|
|
|
|
return (ENXIO);
|
|
|
|
}
|
|
|
|
|
|
|
|
rirbsize = HDAC_READ_1(&sc->mem, HDAC_RIRBSIZE);
|
|
|
|
if ((rirbsize & HDAC_RIRBSIZE_RIRBSZCAP_256) ==
|
|
|
|
HDAC_RIRBSIZE_RIRBSZCAP_256)
|
|
|
|
sc->rirb_size = 256;
|
|
|
|
else if ((rirbsize & HDAC_RIRBSIZE_RIRBSZCAP_16) ==
|
|
|
|
HDAC_RIRBSIZE_RIRBSZCAP_16)
|
|
|
|
sc->rirb_size = 16;
|
|
|
|
else if ((rirbsize & HDAC_RIRBSIZE_RIRBSZCAP_2) ==
|
|
|
|
HDAC_RIRBSIZE_RIRBSZCAP_2)
|
|
|
|
sc->rirb_size = 2;
|
|
|
|
else {
|
|
|
|
device_printf(sc->dev, "%s: Invalid rirb size (%x)\n",
|
|
|
|
__func__, rirbsize);
|
|
|
|
return (ENXIO);
|
|
|
|
}
|
|
|
|
|
2008-09-16 20:03:34 +00:00
|
|
|
HDA_BOOTHVERBOSE(
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
device_printf(sc->dev, " CORB size: %d\n", sc->corb_size);
|
|
|
|
device_printf(sc->dev, " RIRB size: %d\n", sc->rirb_size);
|
|
|
|
device_printf(sc->dev, " Streams: ISS=%d OSS=%d BSS=%d\n",
|
|
|
|
sc->num_iss, sc->num_oss, sc->num_bss);
|
|
|
|
);
|
|
|
|
|
2006-10-01 11:13:00 +00:00
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/****************************************************************************
|
|
|
|
* void hdac_dma_cb
|
|
|
|
*
|
|
|
|
* This function is called by bus_dmamap_load when the mapping has been
|
|
|
|
* established. We just record the physical address of the mapping into
|
|
|
|
* the struct hdac_dma passed in.
|
|
|
|
****************************************************************************/
|
|
|
|
static void
|
|
|
|
hdac_dma_cb(void *callback_arg, bus_dma_segment_t *segs, int nseg, int error)
|
|
|
|
{
|
|
|
|
struct hdac_dma *dma;
|
|
|
|
|
|
|
|
if (error == 0) {
|
|
|
|
dma = (struct hdac_dma *)callback_arg;
|
|
|
|
dma->dma_paddr = segs[0].ds_addr;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/****************************************************************************
|
|
|
|
* int hdac_dma_alloc
|
|
|
|
*
|
|
|
|
* This function allocate and setup a dma region (struct hdac_dma).
|
|
|
|
* It must be freed by a corresponding hdac_dma_free.
|
|
|
|
****************************************************************************/
|
|
|
|
static int
|
|
|
|
hdac_dma_alloc(struct hdac_softc *sc, struct hdac_dma *dma, bus_size_t size)
|
|
|
|
{
|
2007-05-05 09:17:36 +00:00
|
|
|
bus_size_t roundsz;
|
2006-10-01 11:13:00 +00:00
|
|
|
int result;
|
|
|
|
int lowaddr;
|
|
|
|
|
2007-05-05 09:17:36 +00:00
|
|
|
roundsz = roundup2(size, HDAC_DMA_ALIGNMENT);
|
2006-10-01 11:13:00 +00:00
|
|
|
lowaddr = (sc->support_64bit) ? BUS_SPACE_MAXADDR :
|
|
|
|
BUS_SPACE_MAXADDR_32BIT;
|
|
|
|
bzero(dma, sizeof(*dma));
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Create a DMA tag
|
|
|
|
*/
|
|
|
|
result = bus_dma_tag_create(NULL, /* parent */
|
|
|
|
HDAC_DMA_ALIGNMENT, /* alignment */
|
|
|
|
0, /* boundary */
|
|
|
|
lowaddr, /* lowaddr */
|
|
|
|
BUS_SPACE_MAXADDR, /* highaddr */
|
|
|
|
NULL, /* filtfunc */
|
|
|
|
NULL, /* fistfuncarg */
|
2007-05-05 09:17:36 +00:00
|
|
|
roundsz, /* maxsize */
|
2006-10-01 11:13:00 +00:00
|
|
|
1, /* nsegments */
|
2007-05-05 09:17:36 +00:00
|
|
|
roundsz, /* maxsegsz */
|
2006-10-01 11:13:00 +00:00
|
|
|
0, /* flags */
|
|
|
|
NULL, /* lockfunc */
|
|
|
|
NULL, /* lockfuncarg */
|
|
|
|
&dma->dma_tag); /* dmat */
|
|
|
|
if (result != 0) {
|
|
|
|
device_printf(sc->dev, "%s: bus_dma_tag_create failed (%x)\n",
|
|
|
|
__func__, result);
|
2007-03-21 18:17:03 +00:00
|
|
|
goto hdac_dma_alloc_fail;
|
2006-10-01 11:13:00 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Allocate DMA memory
|
|
|
|
*/
|
2006-10-02 16:30:04 +00:00
|
|
|
result = bus_dmamem_alloc(dma->dma_tag, (void **)&dma->dma_vaddr,
|
2007-05-05 09:17:36 +00:00
|
|
|
BUS_DMA_NOWAIT | BUS_DMA_ZERO |
|
2007-07-09 20:42:11 +00:00
|
|
|
((sc->flags & HDAC_F_DMA_NOCACHE) ? BUS_DMA_NOCACHE : 0),
|
|
|
|
&dma->dma_map);
|
2006-10-01 11:13:00 +00:00
|
|
|
if (result != 0) {
|
|
|
|
device_printf(sc->dev, "%s: bus_dmamem_alloc failed (%x)\n",
|
|
|
|
__func__, result);
|
2007-03-21 18:17:03 +00:00
|
|
|
goto hdac_dma_alloc_fail;
|
2006-10-01 11:13:00 +00:00
|
|
|
}
|
|
|
|
|
2007-05-05 09:17:36 +00:00
|
|
|
dma->dma_size = roundsz;
|
|
|
|
|
2006-10-01 11:13:00 +00:00
|
|
|
/*
|
|
|
|
* Map the memory
|
|
|
|
*/
|
|
|
|
result = bus_dmamap_load(dma->dma_tag, dma->dma_map,
|
2007-05-05 09:17:36 +00:00
|
|
|
(void *)dma->dma_vaddr, roundsz, hdac_dma_cb, (void *)dma, 0);
|
2006-10-01 11:13:00 +00:00
|
|
|
if (result != 0 || dma->dma_paddr == 0) {
|
2007-03-21 18:17:03 +00:00
|
|
|
if (result == 0)
|
|
|
|
result = ENOMEM;
|
2006-10-01 11:13:00 +00:00
|
|
|
device_printf(sc->dev, "%s: bus_dmamem_load failed (%x)\n",
|
|
|
|
__func__, result);
|
2007-03-21 18:17:03 +00:00
|
|
|
goto hdac_dma_alloc_fail;
|
2006-10-01 11:13:00 +00:00
|
|
|
}
|
2007-05-05 09:17:36 +00:00
|
|
|
|
2008-09-16 20:03:34 +00:00
|
|
|
HDA_BOOTHVERBOSE(
|
2007-05-05 09:17:36 +00:00
|
|
|
device_printf(sc->dev, "%s: size=%ju -> roundsz=%ju\n",
|
|
|
|
__func__, (uintmax_t)size, (uintmax_t)roundsz);
|
|
|
|
);
|
2006-10-01 11:13:00 +00:00
|
|
|
|
|
|
|
return (0);
|
2007-05-05 09:17:36 +00:00
|
|
|
|
2007-03-21 18:17:03 +00:00
|
|
|
hdac_dma_alloc_fail:
|
2007-05-05 09:17:36 +00:00
|
|
|
hdac_dma_free(sc, dma);
|
2007-03-21 18:17:03 +00:00
|
|
|
|
2006-10-01 11:13:00 +00:00
|
|
|
return (result);
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/****************************************************************************
|
2007-05-05 09:17:36 +00:00
|
|
|
* void hdac_dma_free(struct hdac_softc *, struct hdac_dma *)
|
2006-10-01 11:13:00 +00:00
|
|
|
*
|
|
|
|
* Free a struct dhac_dma that has been previously allocated via the
|
|
|
|
* hdac_dma_alloc function.
|
|
|
|
****************************************************************************/
|
|
|
|
static void
|
2007-05-05 09:17:36 +00:00
|
|
|
hdac_dma_free(struct hdac_softc *sc, struct hdac_dma *dma)
|
2006-10-01 11:13:00 +00:00
|
|
|
{
|
2007-03-21 18:17:03 +00:00
|
|
|
if (dma->dma_map != NULL) {
|
2007-05-05 09:17:36 +00:00
|
|
|
#if 0
|
2006-10-01 11:13:00 +00:00
|
|
|
/* Flush caches */
|
|
|
|
bus_dmamap_sync(dma->dma_tag, dma->dma_map,
|
|
|
|
BUS_DMASYNC_POSTREAD | BUS_DMASYNC_POSTWRITE);
|
2007-05-05 09:17:36 +00:00
|
|
|
#endif
|
2006-10-01 11:13:00 +00:00
|
|
|
bus_dmamap_unload(dma->dma_tag, dma->dma_map);
|
2007-03-21 18:17:03 +00:00
|
|
|
}
|
|
|
|
if (dma->dma_vaddr != NULL) {
|
2006-10-01 11:13:00 +00:00
|
|
|
bus_dmamem_free(dma->dma_tag, dma->dma_vaddr, dma->dma_map);
|
2007-03-21 18:17:03 +00:00
|
|
|
dma->dma_vaddr = NULL;
|
|
|
|
}
|
|
|
|
dma->dma_map = NULL;
|
|
|
|
if (dma->dma_tag != NULL) {
|
2006-10-01 11:13:00 +00:00
|
|
|
bus_dma_tag_destroy(dma->dma_tag);
|
2007-03-21 18:17:03 +00:00
|
|
|
dma->dma_tag = NULL;
|
2006-10-01 11:13:00 +00:00
|
|
|
}
|
2007-03-21 18:17:03 +00:00
|
|
|
dma->dma_size = 0;
|
2006-10-01 11:13:00 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/****************************************************************************
|
|
|
|
* int hdac_mem_alloc(struct hdac_softc *)
|
|
|
|
*
|
|
|
|
* Allocate all the bus resources necessary to speak with the physical
|
|
|
|
* controller.
|
|
|
|
****************************************************************************/
|
|
|
|
static int
|
|
|
|
hdac_mem_alloc(struct hdac_softc *sc)
|
|
|
|
{
|
|
|
|
struct hdac_mem *mem;
|
|
|
|
|
|
|
|
mem = &sc->mem;
|
|
|
|
mem->mem_rid = PCIR_BAR(0);
|
|
|
|
mem->mem_res = bus_alloc_resource_any(sc->dev, SYS_RES_MEMORY,
|
|
|
|
&mem->mem_rid, RF_ACTIVE);
|
|
|
|
if (mem->mem_res == NULL) {
|
|
|
|
device_printf(sc->dev,
|
|
|
|
"%s: Unable to allocate memory resource\n", __func__);
|
|
|
|
return (ENOMEM);
|
|
|
|
}
|
|
|
|
mem->mem_tag = rman_get_bustag(mem->mem_res);
|
|
|
|
mem->mem_handle = rman_get_bushandle(mem->mem_res);
|
|
|
|
|
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
|
|
|
|
/****************************************************************************
|
|
|
|
* void hdac_mem_free(struct hdac_softc *)
|
|
|
|
*
|
|
|
|
* Free up resources previously allocated by hdac_mem_alloc.
|
|
|
|
****************************************************************************/
|
|
|
|
static void
|
|
|
|
hdac_mem_free(struct hdac_softc *sc)
|
|
|
|
{
|
|
|
|
struct hdac_mem *mem;
|
|
|
|
|
|
|
|
mem = &sc->mem;
|
|
|
|
if (mem->mem_res != NULL)
|
|
|
|
bus_release_resource(sc->dev, SYS_RES_MEMORY, mem->mem_rid,
|
|
|
|
mem->mem_res);
|
Welcome to Once-a-year Sound Mega-Commit. Enjoy numerous updates and fixes
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.
2006-11-26 12:24:06 +00:00
|
|
|
mem->mem_res = NULL;
|
2006-10-01 11:13:00 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/****************************************************************************
|
|
|
|
* int hdac_irq_alloc(struct hdac_softc *)
|
|
|
|
*
|
|
|
|
* Allocate and setup the resources necessary for interrupt handling.
|
|
|
|
****************************************************************************/
|
|
|
|
static int
|
|
|
|
hdac_irq_alloc(struct hdac_softc *sc)
|
|
|
|
{
|
|
|
|
struct hdac_irq *irq;
|
|
|
|
int result;
|
|
|
|
|
|
|
|
irq = &sc->irq;
|
|
|
|
irq->irq_rid = 0x0;
|
2007-07-09 20:42:11 +00:00
|
|
|
|
2008-04-12 15:07:32 +00:00
|
|
|
#ifdef HDAC_MSI_ENABLED
|
2007-07-09 20:42:11 +00:00
|
|
|
if ((sc->flags & HDAC_F_MSI) &&
|
|
|
|
(result = pci_msi_count(sc->dev)) == 1 &&
|
|
|
|
pci_alloc_msi(sc->dev, &result) == 0)
|
|
|
|
irq->irq_rid = 0x1;
|
|
|
|
else
|
|
|
|
#endif
|
|
|
|
sc->flags &= ~HDAC_F_MSI;
|
|
|
|
|
2006-10-01 11:13:00 +00:00
|
|
|
irq->irq_res = bus_alloc_resource_any(sc->dev, SYS_RES_IRQ,
|
|
|
|
&irq->irq_rid, RF_SHAREABLE | RF_ACTIVE);
|
|
|
|
if (irq->irq_res == NULL) {
|
|
|
|
device_printf(sc->dev, "%s: Unable to allocate irq\n",
|
|
|
|
__func__);
|
2007-03-21 18:17:03 +00:00
|
|
|
goto hdac_irq_alloc_fail;
|
2006-10-01 11:13:00 +00:00
|
|
|
}
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
result = bus_setup_intr(sc->dev, irq->irq_res, INTR_MPSAFE | INTR_TYPE_AV,
|
|
|
|
NULL, hdac_intr_handler, sc, &irq->irq_handle);
|
2006-10-01 11:13:00 +00:00
|
|
|
if (result != 0) {
|
|
|
|
device_printf(sc->dev,
|
|
|
|
"%s: Unable to setup interrupt handler (%x)\n",
|
|
|
|
__func__, result);
|
2007-03-21 18:17:03 +00:00
|
|
|
goto hdac_irq_alloc_fail;
|
2006-10-01 11:13:00 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
return (0);
|
|
|
|
|
2007-03-21 18:17:03 +00:00
|
|
|
hdac_irq_alloc_fail:
|
Welcome to Once-a-year Sound Mega-Commit. Enjoy numerous updates and fixes
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.
2006-11-26 12:24:06 +00:00
|
|
|
hdac_irq_free(sc);
|
|
|
|
|
2006-10-01 11:13:00 +00:00
|
|
|
return (ENXIO);
|
|
|
|
}
|
|
|
|
|
|
|
|
/****************************************************************************
|
|
|
|
* void hdac_irq_free(struct hdac_softc *)
|
|
|
|
*
|
|
|
|
* Free up resources previously allocated by hdac_irq_alloc.
|
|
|
|
****************************************************************************/
|
|
|
|
static void
|
|
|
|
hdac_irq_free(struct hdac_softc *sc)
|
|
|
|
{
|
|
|
|
struct hdac_irq *irq;
|
|
|
|
|
|
|
|
irq = &sc->irq;
|
Welcome to Once-a-year Sound Mega-Commit. Enjoy numerous updates and fixes
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.
2006-11-26 12:24:06 +00:00
|
|
|
if (irq->irq_res != NULL && irq->irq_handle != NULL)
|
2006-10-01 11:13:00 +00:00
|
|
|
bus_teardown_intr(sc->dev, irq->irq_res, irq->irq_handle);
|
|
|
|
if (irq->irq_res != NULL)
|
|
|
|
bus_release_resource(sc->dev, SYS_RES_IRQ, irq->irq_rid,
|
|
|
|
irq->irq_res);
|
2008-04-12 15:07:32 +00:00
|
|
|
#ifdef HDAC_MSI_ENABLED
|
2007-07-09 20:42:11 +00:00
|
|
|
if ((sc->flags & HDAC_F_MSI) && irq->irq_rid == 0x1)
|
|
|
|
pci_release_msi(sc->dev);
|
|
|
|
#endif
|
Welcome to Once-a-year Sound Mega-Commit. Enjoy numerous updates and fixes
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.
2006-11-26 12:24:06 +00:00
|
|
|
irq->irq_handle = NULL;
|
|
|
|
irq->irq_res = NULL;
|
2007-07-09 20:42:11 +00:00
|
|
|
irq->irq_rid = 0x0;
|
2006-10-01 11:13:00 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/****************************************************************************
|
|
|
|
* void hdac_corb_init(struct hdac_softc *)
|
|
|
|
*
|
|
|
|
* Initialize the corb registers for operations but do not start it up yet.
|
|
|
|
* The CORB engine must not be running when this function is called.
|
|
|
|
****************************************************************************/
|
|
|
|
static void
|
|
|
|
hdac_corb_init(struct hdac_softc *sc)
|
|
|
|
{
|
|
|
|
uint8_t corbsize;
|
|
|
|
uint64_t corbpaddr;
|
|
|
|
|
|
|
|
/* Setup the CORB size. */
|
|
|
|
switch (sc->corb_size) {
|
|
|
|
case 256:
|
|
|
|
corbsize = HDAC_CORBSIZE_CORBSIZE(HDAC_CORBSIZE_CORBSIZE_256);
|
|
|
|
break;
|
|
|
|
case 16:
|
|
|
|
corbsize = HDAC_CORBSIZE_CORBSIZE(HDAC_CORBSIZE_CORBSIZE_16);
|
|
|
|
break;
|
|
|
|
case 2:
|
|
|
|
corbsize = HDAC_CORBSIZE_CORBSIZE(HDAC_CORBSIZE_CORBSIZE_2);
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
panic("%s: Invalid CORB size (%x)\n", __func__, sc->corb_size);
|
|
|
|
}
|
|
|
|
HDAC_WRITE_1(&sc->mem, HDAC_CORBSIZE, corbsize);
|
|
|
|
|
|
|
|
/* Setup the CORB Address in the hdac */
|
|
|
|
corbpaddr = (uint64_t)sc->corb_dma.dma_paddr;
|
|
|
|
HDAC_WRITE_4(&sc->mem, HDAC_CORBLBASE, (uint32_t)corbpaddr);
|
|
|
|
HDAC_WRITE_4(&sc->mem, HDAC_CORBUBASE, (uint32_t)(corbpaddr >> 32));
|
|
|
|
|
|
|
|
/* Set the WP and RP */
|
|
|
|
sc->corb_wp = 0;
|
|
|
|
HDAC_WRITE_2(&sc->mem, HDAC_CORBWP, sc->corb_wp);
|
|
|
|
HDAC_WRITE_2(&sc->mem, HDAC_CORBRP, HDAC_CORBRP_CORBRPRST);
|
|
|
|
/*
|
|
|
|
* The HDA specification indicates that the CORBRPRST bit will always
|
|
|
|
* read as zero. Unfortunately, it seems that at least the 82801G
|
|
|
|
* doesn't reset the bit to zero, which stalls the corb engine.
|
|
|
|
* manually reset the bit to zero before continuing.
|
|
|
|
*/
|
|
|
|
HDAC_WRITE_2(&sc->mem, HDAC_CORBRP, 0x0);
|
|
|
|
|
|
|
|
/* Enable CORB error reporting */
|
|
|
|
#if 0
|
|
|
|
HDAC_WRITE_1(&sc->mem, HDAC_CORBCTL, HDAC_CORBCTL_CMEIE);
|
|
|
|
#endif
|
|
|
|
}
|
|
|
|
|
|
|
|
/****************************************************************************
|
|
|
|
* void hdac_rirb_init(struct hdac_softc *)
|
|
|
|
*
|
|
|
|
* Initialize the rirb registers for operations but do not start it up yet.
|
|
|
|
* The RIRB engine must not be running when this function is called.
|
|
|
|
****************************************************************************/
|
|
|
|
static void
|
|
|
|
hdac_rirb_init(struct hdac_softc *sc)
|
|
|
|
{
|
|
|
|
uint8_t rirbsize;
|
|
|
|
uint64_t rirbpaddr;
|
|
|
|
|
|
|
|
/* Setup the RIRB size. */
|
|
|
|
switch (sc->rirb_size) {
|
|
|
|
case 256:
|
|
|
|
rirbsize = HDAC_RIRBSIZE_RIRBSIZE(HDAC_RIRBSIZE_RIRBSIZE_256);
|
|
|
|
break;
|
|
|
|
case 16:
|
|
|
|
rirbsize = HDAC_RIRBSIZE_RIRBSIZE(HDAC_RIRBSIZE_RIRBSIZE_16);
|
|
|
|
break;
|
|
|
|
case 2:
|
|
|
|
rirbsize = HDAC_RIRBSIZE_RIRBSIZE(HDAC_RIRBSIZE_RIRBSIZE_2);
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
panic("%s: Invalid RIRB size (%x)\n", __func__, sc->rirb_size);
|
|
|
|
}
|
|
|
|
HDAC_WRITE_1(&sc->mem, HDAC_RIRBSIZE, rirbsize);
|
|
|
|
|
|
|
|
/* Setup the RIRB Address in the hdac */
|
|
|
|
rirbpaddr = (uint64_t)sc->rirb_dma.dma_paddr;
|
|
|
|
HDAC_WRITE_4(&sc->mem, HDAC_RIRBLBASE, (uint32_t)rirbpaddr);
|
|
|
|
HDAC_WRITE_4(&sc->mem, HDAC_RIRBUBASE, (uint32_t)(rirbpaddr >> 32));
|
|
|
|
|
|
|
|
/* Setup the WP and RP */
|
|
|
|
sc->rirb_rp = 0;
|
|
|
|
HDAC_WRITE_2(&sc->mem, HDAC_RIRBWP, HDAC_RIRBWP_RIRBWPRST);
|
|
|
|
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
/* Setup the interrupt threshold */
|
|
|
|
HDAC_WRITE_2(&sc->mem, HDAC_RINTCNT, sc->rirb_size / 2);
|
2006-10-01 11:13:00 +00:00
|
|
|
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
/* Enable Overrun and response received reporting */
|
2006-10-01 11:13:00 +00:00
|
|
|
#if 0
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
HDAC_WRITE_1(&sc->mem, HDAC_RIRBCTL,
|
|
|
|
HDAC_RIRBCTL_RIRBOIC | HDAC_RIRBCTL_RINTCTL);
|
2006-10-01 11:13:00 +00:00
|
|
|
#else
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
HDAC_WRITE_1(&sc->mem, HDAC_RIRBCTL, HDAC_RIRBCTL_RINTCTL);
|
2006-10-01 11:13:00 +00:00
|
|
|
#endif
|
|
|
|
|
2007-05-05 09:17:36 +00:00
|
|
|
#if 0
|
2006-10-01 11:13:00 +00:00
|
|
|
/*
|
|
|
|
* Make sure that the Host CPU cache doesn't contain any dirty
|
|
|
|
* cache lines that falls in the rirb. If I understood correctly, it
|
|
|
|
* should be sufficient to do this only once as the rirb is purely
|
|
|
|
* read-only from now on.
|
|
|
|
*/
|
|
|
|
bus_dmamap_sync(sc->rirb_dma.dma_tag, sc->rirb_dma.dma_map,
|
|
|
|
BUS_DMASYNC_PREREAD);
|
2007-05-05 09:17:36 +00:00
|
|
|
#endif
|
2006-10-01 11:13:00 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/****************************************************************************
|
|
|
|
* void hdac_corb_start(hdac_softc *)
|
|
|
|
*
|
|
|
|
* Startup the corb DMA engine
|
|
|
|
****************************************************************************/
|
|
|
|
static void
|
|
|
|
hdac_corb_start(struct hdac_softc *sc)
|
|
|
|
{
|
|
|
|
uint32_t corbctl;
|
|
|
|
|
|
|
|
corbctl = HDAC_READ_1(&sc->mem, HDAC_CORBCTL);
|
|
|
|
corbctl |= HDAC_CORBCTL_CORBRUN;
|
|
|
|
HDAC_WRITE_1(&sc->mem, HDAC_CORBCTL, corbctl);
|
|
|
|
}
|
|
|
|
|
|
|
|
/****************************************************************************
|
|
|
|
* void hdac_rirb_start(hdac_softc *)
|
|
|
|
*
|
|
|
|
* Startup the rirb DMA engine
|
|
|
|
****************************************************************************/
|
|
|
|
static void
|
|
|
|
hdac_rirb_start(struct hdac_softc *sc)
|
|
|
|
{
|
|
|
|
uint32_t rirbctl;
|
|
|
|
|
|
|
|
rirbctl = HDAC_READ_1(&sc->mem, HDAC_RIRBCTL);
|
|
|
|
rirbctl |= HDAC_RIRBCTL_RIRBDMAEN;
|
|
|
|
HDAC_WRITE_1(&sc->mem, HDAC_RIRBCTL, rirbctl);
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/****************************************************************************
|
2007-10-19 15:49:39 +00:00
|
|
|
* void hdac_scan_codecs(struct hdac_softc *, int)
|
2006-10-01 11:13:00 +00:00
|
|
|
*
|
2007-10-19 15:49:39 +00:00
|
|
|
* Scan the bus for available codecs, starting with num.
|
2006-10-01 11:13:00 +00:00
|
|
|
****************************************************************************/
|
|
|
|
static void
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
hdac_scan_codecs(struct hdac_softc *sc)
|
2006-10-01 11:13:00 +00:00
|
|
|
{
|
|
|
|
struct hdac_codec *codec;
|
|
|
|
int i;
|
|
|
|
uint16_t statests;
|
|
|
|
|
|
|
|
statests = HDAC_READ_2(&sc->mem, HDAC_STATESTS);
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
for (i = 0; i < HDAC_CODEC_MAX; i++) {
|
2006-10-01 11:13:00 +00:00
|
|
|
if (HDAC_STATESTS_SDIWAKE(statests, i)) {
|
|
|
|
/* We have found a codec. */
|
|
|
|
codec = (struct hdac_codec *)malloc(sizeof(*codec),
|
|
|
|
M_HDAC, M_ZERO | M_NOWAIT);
|
|
|
|
if (codec == NULL) {
|
|
|
|
device_printf(sc->dev,
|
|
|
|
"Unable to allocate memory for codec\n");
|
|
|
|
continue;
|
|
|
|
}
|
Welcome to Once-a-year Sound Mega-Commit. Enjoy numerous updates and fixes
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.
2006-11-26 12:24:06 +00:00
|
|
|
codec->commands = NULL;
|
|
|
|
codec->responses_received = 0;
|
2006-10-01 11:13:00 +00:00
|
|
|
codec->verbs_sent = 0;
|
|
|
|
codec->sc = sc;
|
|
|
|
codec->cad = i;
|
|
|
|
sc->codecs[i] = codec;
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
hdac_probe_codec(codec);
|
2006-10-01 11:13:00 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
/* All codecs have been probed, now try to attach drivers to them */
|
- Fix wrong id for ALC882, add ALC883 id.
- 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"
2006-10-06 18:59:27 +00:00
|
|
|
/* bus_generic_attach(sc->dev); */
|
2006-10-01 11:13:00 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/****************************************************************************
|
|
|
|
* void hdac_probe_codec(struct hdac_softc *, int)
|
|
|
|
*
|
|
|
|
* Probe a the given codec_id for available function groups.
|
|
|
|
****************************************************************************/
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
static void
|
2006-10-01 11:13:00 +00:00
|
|
|
hdac_probe_codec(struct hdac_codec *codec)
|
|
|
|
{
|
|
|
|
struct hdac_softc *sc = codec->sc;
|
|
|
|
uint32_t vendorid, revisionid, subnode;
|
|
|
|
int startnode;
|
|
|
|
int endnode;
|
|
|
|
int i;
|
|
|
|
nid_t cad = codec->cad;
|
|
|
|
|
- Fix wrong id for ALC882, add ALC883 id.
- 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"
2006-10-06 18:59:27 +00:00
|
|
|
HDA_BOOTVERBOSE(
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
device_printf(sc->dev, "Probing codec %d...\n", cad);
|
2006-10-01 11:13:00 +00:00
|
|
|
);
|
|
|
|
vendorid = hdac_command(sc,
|
|
|
|
HDA_CMD_GET_PARAMETER(cad, 0x0, HDA_PARAM_VENDOR_ID),
|
|
|
|
cad);
|
|
|
|
revisionid = hdac_command(sc,
|
|
|
|
HDA_CMD_GET_PARAMETER(cad, 0x0, HDA_PARAM_REVISION_ID),
|
|
|
|
cad);
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
codec->vendor_id = HDA_PARAM_VENDOR_ID_VENDOR_ID(vendorid);
|
|
|
|
codec->device_id = HDA_PARAM_VENDOR_ID_DEVICE_ID(vendorid);
|
|
|
|
codec->revision_id = HDA_PARAM_REVISION_ID_REVISION_ID(revisionid);
|
|
|
|
codec->stepping_id = HDA_PARAM_REVISION_ID_STEPPING_ID(revisionid);
|
|
|
|
|
|
|
|
if (vendorid == HDAC_INVALID && revisionid == HDAC_INVALID) {
|
|
|
|
device_printf(sc->dev, "Codec #%d is not responding!"
|
|
|
|
" Probing aborted.\n", cad);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
device_printf(sc->dev, "<HDA Codec #%d: %s>\n",
|
|
|
|
cad, hdac_codec_name(codec));
|
|
|
|
HDA_BOOTVERBOSE(
|
|
|
|
device_printf(sc->dev, "<HDA Codec ID: 0x%08x>\n",
|
|
|
|
hdac_codec_id(codec));
|
|
|
|
device_printf(sc->dev, " Vendor: 0x%04x\n",
|
|
|
|
codec->vendor_id);
|
|
|
|
device_printf(sc->dev, " Device: 0x%04x\n",
|
|
|
|
codec->device_id);
|
|
|
|
device_printf(sc->dev, " Revision: 0x%02x\n",
|
|
|
|
codec->revision_id);
|
|
|
|
device_printf(sc->dev, " Stepping: 0x%02x\n",
|
|
|
|
codec->stepping_id);
|
|
|
|
device_printf(sc->dev, "PCI Subvendor: 0x%08x\n",
|
|
|
|
sc->pci_subvendor);
|
|
|
|
);
|
2006-10-01 11:13:00 +00:00
|
|
|
subnode = hdac_command(sc,
|
|
|
|
HDA_CMD_GET_PARAMETER(cad, 0x0, HDA_PARAM_SUB_NODE_COUNT),
|
|
|
|
cad);
|
|
|
|
startnode = HDA_PARAM_SUB_NODE_COUNT_START(subnode);
|
|
|
|
endnode = startnode + HDA_PARAM_SUB_NODE_COUNT_TOTAL(subnode);
|
|
|
|
|
2008-09-16 20:03:34 +00:00
|
|
|
HDA_BOOTHVERBOSE(
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
device_printf(sc->dev, "\tstartnode=%d endnode=%d\n",
|
- Fix wrong id for ALC882, add ALC883 id.
- 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"
2006-10-06 18:59:27 +00:00
|
|
|
startnode, endnode);
|
2006-10-01 11:13:00 +00:00
|
|
|
);
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
|
|
|
|
codec->fgs = (struct hdac_devinfo *)malloc(sizeof(struct hdac_devinfo) *
|
|
|
|
(endnode - startnode), M_HDAC, M_NOWAIT | M_ZERO);
|
|
|
|
if (codec->fgs == NULL) {
|
2008-09-14 17:37:34 +00:00
|
|
|
device_printf(sc->dev, "%s: Unable to allocate function groups\n",
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
__func__);
|
|
|
|
return;
|
2006-10-01 11:13:00 +00:00
|
|
|
}
|
|
|
|
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
for (i = startnode; i < endnode; i++)
|
|
|
|
hdac_probe_function(codec, i);
|
|
|
|
return;
|
2006-10-01 11:13:00 +00:00
|
|
|
}
|
|
|
|
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
/*
|
|
|
|
* Probe codec function and add it to the list.
|
|
|
|
*/
|
|
|
|
static void
|
2006-10-01 11:13:00 +00:00
|
|
|
hdac_probe_function(struct hdac_codec *codec, nid_t nid)
|
|
|
|
{
|
|
|
|
struct hdac_softc *sc = codec->sc;
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
struct hdac_devinfo *devinfo = &codec->fgs[codec->num_fgs];
|
2006-10-01 11:13:00 +00:00
|
|
|
uint32_t fctgrptype;
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
uint32_t res;
|
2006-10-01 11:13:00 +00:00
|
|
|
nid_t cad = codec->cad;
|
|
|
|
|
2006-10-02 16:30:04 +00:00
|
|
|
fctgrptype = HDA_PARAM_FCT_GRP_TYPE_NODE_TYPE(hdac_command(sc,
|
|
|
|
HDA_CMD_GET_PARAMETER(cad, nid, HDA_PARAM_FCT_GRP_TYPE), cad));
|
2006-10-01 11:13:00 +00:00
|
|
|
|
|
|
|
devinfo->nid = nid;
|
2006-10-02 16:30:04 +00:00
|
|
|
devinfo->node_type = fctgrptype;
|
2006-10-01 11:13:00 +00:00
|
|
|
devinfo->codec = codec;
|
|
|
|
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
res = hdac_command(sc,
|
|
|
|
HDA_CMD_GET_PARAMETER(cad , nid, HDA_PARAM_SUB_NODE_COUNT), cad);
|
2006-10-01 11:13:00 +00:00
|
|
|
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
devinfo->nodecnt = HDA_PARAM_SUB_NODE_COUNT_TOTAL(res);
|
|
|
|
devinfo->startnode = HDA_PARAM_SUB_NODE_COUNT_START(res);
|
|
|
|
devinfo->endnode = devinfo->startnode + devinfo->nodecnt;
|
2006-10-01 11:13:00 +00:00
|
|
|
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
HDA_BOOTVERBOSE(
|
|
|
|
device_printf(sc->dev,
|
|
|
|
"\tFound %s FG nid=%d startnode=%d endnode=%d total=%d\n",
|
|
|
|
(fctgrptype == HDA_PARAM_FCT_GRP_TYPE_NODE_TYPE_AUDIO) ? "audio":
|
|
|
|
(fctgrptype == HDA_PARAM_FCT_GRP_TYPE_NODE_TYPE_MODEM) ? "modem":
|
|
|
|
"unknown", nid, devinfo->startnode, devinfo->endnode,
|
|
|
|
devinfo->nodecnt);
|
|
|
|
);
|
|
|
|
|
|
|
|
if (devinfo->nodecnt > 0)
|
|
|
|
devinfo->widget = (struct hdac_widget *)malloc(
|
|
|
|
sizeof(*(devinfo->widget)) * devinfo->nodecnt, M_HDAC,
|
|
|
|
M_NOWAIT | M_ZERO);
|
|
|
|
else
|
|
|
|
devinfo->widget = NULL;
|
|
|
|
|
|
|
|
if (devinfo->widget == NULL) {
|
|
|
|
device_printf(sc->dev, "unable to allocate widgets!\n");
|
|
|
|
devinfo->endnode = devinfo->startnode;
|
|
|
|
devinfo->nodecnt = 0;
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
codec->num_fgs++;
|
2006-10-01 11:13:00 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
hdac_widget_connection_parse(struct hdac_widget *w)
|
|
|
|
{
|
|
|
|
struct hdac_softc *sc = w->devinfo->codec->sc;
|
|
|
|
uint32_t res;
|
2007-05-05 09:17:36 +00:00
|
|
|
int i, j, max, ents, entnum;
|
2006-10-01 11:13:00 +00:00
|
|
|
nid_t cad = w->devinfo->codec->cad;
|
|
|
|
nid_t nid = w->nid;
|
2007-05-05 09:17:36 +00:00
|
|
|
nid_t cnid, addcnid, prevcnid;
|
|
|
|
|
|
|
|
w->nconns = 0;
|
2006-10-01 11:13:00 +00:00
|
|
|
|
|
|
|
res = hdac_command(sc,
|
|
|
|
HDA_CMD_GET_PARAMETER(cad, nid, HDA_PARAM_CONN_LIST_LENGTH), cad);
|
|
|
|
|
2007-05-05 09:17:36 +00:00
|
|
|
ents = HDA_PARAM_CONN_LIST_LENGTH_LIST_LENGTH(res);
|
2006-10-01 11:13:00 +00:00
|
|
|
|
2007-05-05 09:17:36 +00:00
|
|
|
if (ents < 1)
|
2006-10-01 11:13:00 +00:00
|
|
|
return;
|
|
|
|
|
|
|
|
entnum = HDA_PARAM_CONN_LIST_LENGTH_LONG_FORM(res) ? 2 : 4;
|
|
|
|
max = (sizeof(w->conns) / sizeof(w->conns[0])) - 1;
|
2007-05-05 09:17:36 +00:00
|
|
|
prevcnid = 0;
|
2006-10-01 11:13:00 +00:00
|
|
|
|
2007-05-05 09:17:36 +00:00
|
|
|
#define CONN_RMASK(e) (1 << ((32 / (e)) - 1))
|
|
|
|
#define CONN_NMASK(e) (CONN_RMASK(e) - 1)
|
|
|
|
#define CONN_RESVAL(r, e, n) ((r) >> ((32 / (e)) * (n)))
|
|
|
|
#define CONN_RANGE(r, e, n) (CONN_RESVAL(r, e, n) & CONN_RMASK(e))
|
|
|
|
#define CONN_CNID(r, e, n) (CONN_RESVAL(r, e, n) & CONN_NMASK(e))
|
|
|
|
|
|
|
|
for (i = 0; i < ents; i += entnum) {
|
2006-10-01 11:13:00 +00:00
|
|
|
res = hdac_command(sc,
|
|
|
|
HDA_CMD_GET_CONN_LIST_ENTRY(cad, nid, i), cad);
|
|
|
|
for (j = 0; j < entnum; j++) {
|
2007-05-05 09:17:36 +00:00
|
|
|
cnid = CONN_CNID(res, entnum, j);
|
|
|
|
if (cnid == 0) {
|
|
|
|
if (w->nconns < ents)
|
|
|
|
device_printf(sc->dev,
|
|
|
|
"%s: nid=%d WARNING: zero cnid "
|
|
|
|
"entnum=%d j=%d index=%d "
|
|
|
|
"entries=%d found=%d res=0x%08x\n",
|
|
|
|
__func__, nid, entnum, j, i,
|
|
|
|
ents, w->nconns, res);
|
|
|
|
else
|
|
|
|
goto getconns_out;
|
|
|
|
}
|
|
|
|
if (cnid < w->devinfo->startnode ||
|
|
|
|
cnid >= w->devinfo->endnode) {
|
|
|
|
HDA_BOOTVERBOSE(
|
|
|
|
device_printf(sc->dev,
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
"GHOST: nid=%d j=%d "
|
2007-05-05 09:17:36 +00:00
|
|
|
"entnum=%d index=%d res=0x%08x\n",
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
nid, j, entnum, i, res);
|
2007-05-05 09:17:36 +00:00
|
|
|
);
|
|
|
|
}
|
|
|
|
if (CONN_RANGE(res, entnum, j) == 0)
|
|
|
|
addcnid = cnid;
|
|
|
|
else if (prevcnid == 0 || prevcnid >= cnid) {
|
2006-10-01 11:13:00 +00:00
|
|
|
device_printf(sc->dev,
|
2007-05-05 09:17:36 +00:00
|
|
|
"%s: WARNING: Invalid child range "
|
|
|
|
"nid=%d index=%d j=%d entnum=%d "
|
|
|
|
"prevcnid=%d cnid=%d res=0x%08x\n",
|
|
|
|
__func__, nid, i, j, entnum, prevcnid,
|
|
|
|
cnid, res);
|
|
|
|
addcnid = cnid;
|
|
|
|
} else
|
|
|
|
addcnid = prevcnid + 1;
|
|
|
|
while (addcnid <= cnid) {
|
|
|
|
if (w->nconns > max) {
|
|
|
|
device_printf(sc->dev,
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
"Adding %d (nid=%d): "
|
2007-05-05 09:17:36 +00:00
|
|
|
"Max connection reached! max=%d\n",
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
addcnid, nid, max + 1);
|
2007-05-05 09:17:36 +00:00
|
|
|
goto getconns_out;
|
|
|
|
}
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
w->connsenable[w->nconns] = 1;
|
2007-05-05 09:17:36 +00:00
|
|
|
w->conns[w->nconns++] = addcnid++;
|
2006-10-01 11:13:00 +00:00
|
|
|
}
|
2007-05-05 09:17:36 +00:00
|
|
|
prevcnid = cnid;
|
2006-10-01 11:13:00 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2007-05-05 09:17:36 +00:00
|
|
|
getconns_out:
|
|
|
|
return;
|
2006-10-01 11:13:00 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static uint32_t
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
hdac_widget_pin_patch(uint32_t config, const char *str)
|
2006-10-01 11:13:00 +00:00
|
|
|
{
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
char buf[256];
|
|
|
|
char *key, *value, *rest, *bad;
|
|
|
|
int ival, i;
|
|
|
|
|
|
|
|
strlcpy(buf, str, sizeof(buf));
|
|
|
|
rest = buf;
|
|
|
|
while ((key = strsep(&rest, "=")) != NULL) {
|
|
|
|
value = strsep(&rest, " \t");
|
|
|
|
if (value == NULL)
|
|
|
|
break;
|
|
|
|
ival = strtol(value, &bad, 10);
|
|
|
|
if (strcmp(key, "seq") == 0) {
|
|
|
|
config &= ~HDA_CONFIG_DEFAULTCONF_SEQUENCE_MASK;
|
|
|
|
config |= ((ival << HDA_CONFIG_DEFAULTCONF_SEQUENCE_SHIFT) &
|
|
|
|
HDA_CONFIG_DEFAULTCONF_SEQUENCE_MASK);
|
|
|
|
} else if (strcmp(key, "as") == 0) {
|
|
|
|
config &= ~HDA_CONFIG_DEFAULTCONF_ASSOCIATION_MASK;
|
|
|
|
config |= ((ival << HDA_CONFIG_DEFAULTCONF_ASSOCIATION_SHIFT) &
|
|
|
|
HDA_CONFIG_DEFAULTCONF_ASSOCIATION_MASK);
|
|
|
|
} else if (strcmp(key, "misc") == 0) {
|
|
|
|
config &= ~HDA_CONFIG_DEFAULTCONF_MISC_MASK;
|
|
|
|
config |= ((ival << HDA_CONFIG_DEFAULTCONF_MISC_SHIFT) &
|
|
|
|
HDA_CONFIG_DEFAULTCONF_MISC_MASK);
|
|
|
|
} else if (strcmp(key, "color") == 0) {
|
|
|
|
config &= ~HDA_CONFIG_DEFAULTCONF_COLOR_MASK;
|
|
|
|
if (bad[0] == 0) {
|
|
|
|
config |= ((ival << HDA_CONFIG_DEFAULTCONF_COLOR_SHIFT) &
|
|
|
|
HDA_CONFIG_DEFAULTCONF_COLOR_MASK);
|
|
|
|
};
|
|
|
|
for (i = 0; i < 16; i++) {
|
|
|
|
if (strcasecmp(HDA_COLORS[i], value) == 0) {
|
|
|
|
config |= (i << HDA_CONFIG_DEFAULTCONF_COLOR_SHIFT);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
} else if (strcmp(key, "ctype") == 0) {
|
|
|
|
config &= ~HDA_CONFIG_DEFAULTCONF_CONNECTION_TYPE_MASK;
|
|
|
|
config |= ((ival << HDA_CONFIG_DEFAULTCONF_CONNECTION_TYPE_SHIFT) &
|
|
|
|
HDA_CONFIG_DEFAULTCONF_CONNECTION_TYPE_MASK);
|
|
|
|
} else if (strcmp(key, "device") == 0) {
|
|
|
|
config &= ~HDA_CONFIG_DEFAULTCONF_DEVICE_MASK;
|
|
|
|
if (bad[0] == 0) {
|
|
|
|
config |= ((ival << HDA_CONFIG_DEFAULTCONF_DEVICE_SHIFT) &
|
|
|
|
HDA_CONFIG_DEFAULTCONF_DEVICE_MASK);
|
|
|
|
continue;
|
|
|
|
};
|
|
|
|
for (i = 0; i < 16; i++) {
|
|
|
|
if (strcasecmp(HDA_DEVS[i], value) == 0) {
|
|
|
|
config |= (i << HDA_CONFIG_DEFAULTCONF_DEVICE_SHIFT);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
} else if (strcmp(key, "loc") == 0) {
|
|
|
|
config &= ~HDA_CONFIG_DEFAULTCONF_LOCATION_MASK;
|
|
|
|
config |= ((ival << HDA_CONFIG_DEFAULTCONF_LOCATION_SHIFT) &
|
|
|
|
HDA_CONFIG_DEFAULTCONF_LOCATION_MASK);
|
|
|
|
} else if (strcmp(key, "conn") == 0) {
|
|
|
|
config &= ~HDA_CONFIG_DEFAULTCONF_CONNECTIVITY_MASK;
|
|
|
|
if (bad[0] == 0) {
|
|
|
|
config |= ((ival << HDA_CONFIG_DEFAULTCONF_CONNECTIVITY_SHIFT) &
|
|
|
|
HDA_CONFIG_DEFAULTCONF_CONNECTIVITY_MASK);
|
|
|
|
continue;
|
|
|
|
};
|
|
|
|
for (i = 0; i < 4; i++) {
|
|
|
|
if (strcasecmp(HDA_CONNS[i], value) == 0) {
|
|
|
|
config |= (i << HDA_CONFIG_DEFAULTCONF_CONNECTIVITY_SHIFT);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return (config);
|
|
|
|
}
|
|
|
|
|
|
|
|
static uint32_t
|
|
|
|
hdac_widget_pin_getconfig(struct hdac_widget *w)
|
|
|
|
{
|
|
|
|
struct hdac_softc *sc;
|
|
|
|
uint32_t config, orig, id;
|
|
|
|
nid_t cad, nid;
|
|
|
|
char buf[32];
|
|
|
|
const char *res = NULL, *patch = NULL;
|
|
|
|
|
|
|
|
sc = w->devinfo->codec->sc;
|
|
|
|
cad = w->devinfo->codec->cad;
|
|
|
|
nid = w->nid;
|
|
|
|
id = hdac_codec_id(w->devinfo->codec);
|
|
|
|
|
|
|
|
config = hdac_command(sc,
|
2006-10-01 11:13:00 +00:00
|
|
|
HDA_CMD_GET_CONFIGURATION_DEFAULT(cad, nid),
|
|
|
|
cad);
|
2007-02-25 06:17:56 +00:00
|
|
|
orig = config;
|
|
|
|
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
HDA_BOOTVERBOSE(
|
|
|
|
hdac_dump_pin_config(w, orig);
|
|
|
|
);
|
|
|
|
|
|
|
|
/* XXX: Old patches require complete review.
|
|
|
|
* Now they may create more problem then solve due to
|
|
|
|
* incorrect associations.
|
2006-10-02 16:30:04 +00:00
|
|
|
*/
|
2006-12-16 09:14:58 +00:00
|
|
|
if (id == HDA_CODEC_ALC880 && sc->pci_subvendor == LG_LW20_SUBVENDOR) {
|
|
|
|
switch (nid) {
|
|
|
|
case 26:
|
|
|
|
config &= ~HDA_CONFIG_DEFAULTCONF_DEVICE_MASK;
|
|
|
|
config |= HDA_CONFIG_DEFAULTCONF_DEVICE_LINE_IN;
|
|
|
|
break;
|
|
|
|
case 27:
|
|
|
|
config &= ~HDA_CONFIG_DEFAULTCONF_DEVICE_MASK;
|
|
|
|
config |= HDA_CONFIG_DEFAULTCONF_DEVICE_HP_OUT;
|
|
|
|
break;
|
2007-03-15 17:35:04 +00:00
|
|
|
default:
|
|
|
|
break;
|
2006-12-16 09:14:58 +00:00
|
|
|
}
|
|
|
|
} else if (id == HDA_CODEC_ALC880 &&
|
2006-10-02 16:30:04 +00:00
|
|
|
(sc->pci_subvendor == CLEVO_D900T_SUBVENDOR ||
|
|
|
|
sc->pci_subvendor == ASUS_M5200_SUBVENDOR)) {
|
2006-10-01 11:13:00 +00:00
|
|
|
/*
|
2006-10-02 16:30:04 +00:00
|
|
|
* Super broken BIOS
|
2006-10-01 11:13:00 +00:00
|
|
|
*/
|
|
|
|
switch (nid) {
|
|
|
|
case 24: /* MIC1 */
|
|
|
|
config &= ~HDA_CONFIG_DEFAULTCONF_DEVICE_MASK;
|
|
|
|
config |= HDA_CONFIG_DEFAULTCONF_DEVICE_MIC_IN;
|
|
|
|
break;
|
|
|
|
case 25: /* XXX MIC2 */
|
|
|
|
config &= ~HDA_CONFIG_DEFAULTCONF_DEVICE_MASK;
|
|
|
|
config |= HDA_CONFIG_DEFAULTCONF_DEVICE_MIC_IN;
|
|
|
|
break;
|
|
|
|
case 26: /* LINE1 */
|
|
|
|
config &= ~HDA_CONFIG_DEFAULTCONF_DEVICE_MASK;
|
|
|
|
config |= HDA_CONFIG_DEFAULTCONF_DEVICE_LINE_IN;
|
|
|
|
break;
|
|
|
|
case 27: /* XXX LINE2 */
|
|
|
|
config &= ~HDA_CONFIG_DEFAULTCONF_DEVICE_MASK;
|
|
|
|
config |= HDA_CONFIG_DEFAULTCONF_DEVICE_LINE_IN;
|
|
|
|
break;
|
|
|
|
case 28: /* CD */
|
|
|
|
config &= ~HDA_CONFIG_DEFAULTCONF_DEVICE_MASK;
|
|
|
|
config |= HDA_CONFIG_DEFAULTCONF_DEVICE_CD;
|
|
|
|
break;
|
|
|
|
}
|
2007-02-25 06:17:56 +00:00
|
|
|
} else if (id == HDA_CODEC_ALC883 &&
|
2007-10-19 15:49:39 +00:00
|
|
|
(sc->pci_subvendor == MSI_MS034A_SUBVENDOR ||
|
|
|
|
HDA_DEV_MATCH(ACER_ALL_SUBVENDOR, sc->pci_subvendor))) {
|
2007-02-25 06:17:56 +00:00
|
|
|
switch (nid) {
|
|
|
|
case 25:
|
|
|
|
config &= ~(HDA_CONFIG_DEFAULTCONF_DEVICE_MASK |
|
|
|
|
HDA_CONFIG_DEFAULTCONF_CONNECTIVITY_MASK);
|
|
|
|
config |= (HDA_CONFIG_DEFAULTCONF_DEVICE_MIC_IN |
|
|
|
|
HDA_CONFIG_DEFAULTCONF_CONNECTIVITY_FIXED);
|
|
|
|
break;
|
2007-05-05 09:17:36 +00:00
|
|
|
case 28:
|
|
|
|
config &= ~(HDA_CONFIG_DEFAULTCONF_DEVICE_MASK |
|
|
|
|
HDA_CONFIG_DEFAULTCONF_CONNECTIVITY_MASK);
|
|
|
|
config |= (HDA_CONFIG_DEFAULTCONF_DEVICE_CD |
|
|
|
|
HDA_CONFIG_DEFAULTCONF_CONNECTIVITY_FIXED);
|
|
|
|
break;
|
2007-02-25 06:17:56 +00:00
|
|
|
}
|
|
|
|
} else if (id == HDA_CODEC_CXVENICE && sc->pci_subvendor ==
|
|
|
|
HP_V3000_SUBVENDOR) {
|
|
|
|
switch (nid) {
|
|
|
|
case 18:
|
|
|
|
config &= ~HDA_CONFIG_DEFAULTCONF_CONNECTIVITY_MASK;
|
|
|
|
config |= HDA_CONFIG_DEFAULTCONF_CONNECTIVITY_NONE;
|
|
|
|
break;
|
|
|
|
case 20:
|
|
|
|
config &= ~(HDA_CONFIG_DEFAULTCONF_DEVICE_MASK |
|
|
|
|
HDA_CONFIG_DEFAULTCONF_CONNECTIVITY_MASK);
|
|
|
|
config |= (HDA_CONFIG_DEFAULTCONF_DEVICE_MIC_IN |
|
|
|
|
HDA_CONFIG_DEFAULTCONF_CONNECTIVITY_FIXED);
|
|
|
|
break;
|
2007-03-11 15:26:49 +00:00
|
|
|
case 21:
|
|
|
|
config &= ~(HDA_CONFIG_DEFAULTCONF_DEVICE_MASK |
|
|
|
|
HDA_CONFIG_DEFAULTCONF_CONNECTIVITY_MASK);
|
|
|
|
config |= (HDA_CONFIG_DEFAULTCONF_DEVICE_CD |
|
|
|
|
HDA_CONFIG_DEFAULTCONF_CONNECTIVITY_FIXED);
|
|
|
|
break;
|
2007-02-25 06:17:56 +00:00
|
|
|
}
|
2007-05-05 09:17:36 +00:00
|
|
|
} else if (id == HDA_CODEC_CXWAIKIKI && sc->pci_subvendor ==
|
|
|
|
HP_DV5000_SUBVENDOR) {
|
|
|
|
switch (nid) {
|
|
|
|
case 20:
|
|
|
|
case 21:
|
|
|
|
config &= ~HDA_CONFIG_DEFAULTCONF_CONNECTIVITY_MASK;
|
|
|
|
config |= HDA_CONFIG_DEFAULTCONF_CONNECTIVITY_NONE;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
} else if (id == HDA_CODEC_ALC861 && sc->pci_subvendor ==
|
|
|
|
ASUS_W6F_SUBVENDOR) {
|
|
|
|
switch (nid) {
|
|
|
|
case 11:
|
|
|
|
config &= ~(HDA_CONFIG_DEFAULTCONF_DEVICE_MASK |
|
|
|
|
HDA_CONFIG_DEFAULTCONF_CONNECTIVITY_MASK);
|
|
|
|
config |= (HDA_CONFIG_DEFAULTCONF_DEVICE_LINE_OUT |
|
|
|
|
HDA_CONFIG_DEFAULTCONF_CONNECTIVITY_FIXED);
|
|
|
|
break;
|
2008-04-19 22:32:23 +00:00
|
|
|
case 12:
|
|
|
|
case 14:
|
|
|
|
case 16:
|
|
|
|
case 31:
|
|
|
|
case 32:
|
|
|
|
config &= ~(HDA_CONFIG_DEFAULTCONF_DEVICE_MASK |
|
|
|
|
HDA_CONFIG_DEFAULTCONF_CONNECTIVITY_MASK);
|
|
|
|
config |= (HDA_CONFIG_DEFAULTCONF_DEVICE_MIC_IN |
|
|
|
|
HDA_CONFIG_DEFAULTCONF_CONNECTIVITY_FIXED);
|
|
|
|
break;
|
2007-05-05 09:17:36 +00:00
|
|
|
case 15:
|
|
|
|
config &= ~(HDA_CONFIG_DEFAULTCONF_DEVICE_MASK |
|
|
|
|
HDA_CONFIG_DEFAULTCONF_CONNECTIVITY_MASK);
|
|
|
|
config |= (HDA_CONFIG_DEFAULTCONF_DEVICE_HP_OUT |
|
|
|
|
HDA_CONFIG_DEFAULTCONF_CONNECTIVITY_JACK);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
} else if (id == HDA_CODEC_ALC861 && sc->pci_subvendor ==
|
|
|
|
UNIWILL_9075_SUBVENDOR) {
|
|
|
|
switch (nid) {
|
|
|
|
case 15:
|
|
|
|
config &= ~(HDA_CONFIG_DEFAULTCONF_DEVICE_MASK |
|
|
|
|
HDA_CONFIG_DEFAULTCONF_CONNECTIVITY_MASK);
|
|
|
|
config |= (HDA_CONFIG_DEFAULTCONF_DEVICE_HP_OUT |
|
|
|
|
HDA_CONFIG_DEFAULTCONF_CONNECTIVITY_JACK);
|
|
|
|
break;
|
|
|
|
}
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/* New patches */
|
|
|
|
if (id == HDA_CODEC_AD1986A &&
|
2007-07-01 17:31:20 +00:00
|
|
|
(sc->pci_subvendor == ASUS_M2NPVMX_SUBVENDOR ||
|
|
|
|
sc->pci_subvendor == ASUS_A8NVMCSM_SUBVENDOR)) {
|
2007-05-05 09:17:36 +00:00
|
|
|
switch (nid) {
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
case 28: /* 5.1 out => 2.0 out + 2 inputs */
|
|
|
|
patch = "device=Line-in as=8 seq=1";
|
2007-05-05 09:17:36 +00:00
|
|
|
break;
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
case 29:
|
|
|
|
patch = "device=Mic as=8 seq=2";
|
2007-05-05 09:17:36 +00:00
|
|
|
break;
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
case 31: /* Lot of inputs configured with as=15 and unusable */
|
|
|
|
patch = "as=8 seq=3";
|
|
|
|
break;
|
|
|
|
case 32:
|
|
|
|
patch = "as=8 seq=4";
|
|
|
|
break;
|
|
|
|
case 34:
|
|
|
|
patch = "as=8 seq=5";
|
|
|
|
break;
|
|
|
|
case 36:
|
|
|
|
patch = "as=8 seq=6";
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
} else if (id == HDA_CODEC_ALC260 &&
|
|
|
|
HDA_DEV_MATCH(SONY_S5_SUBVENDOR, sc->pci_subvendor)) {
|
|
|
|
switch (nid) {
|
|
|
|
case 16:
|
|
|
|
patch = "seq=15 device=Headphones";
|
2007-12-13 15:44:53 +00:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
} else if (id == HDA_CODEC_ALC268 &&
|
|
|
|
HDA_DEV_MATCH(ACER_ALL_SUBVENDOR, sc->pci_subvendor)) {
|
|
|
|
switch (nid) {
|
|
|
|
case 28:
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
patch = "device=CD conn=fixed";
|
2007-05-05 09:17:36 +00:00
|
|
|
break;
|
|
|
|
}
|
2006-10-01 11:13:00 +00:00
|
|
|
}
|
|
|
|
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
if (patch != NULL)
|
|
|
|
config = hdac_widget_pin_patch(config, patch);
|
|
|
|
|
|
|
|
snprintf(buf, sizeof(buf), "cad%u.nid%u.config", cad, nid);
|
|
|
|
if (resource_string_value(device_get_name(sc->dev),
|
|
|
|
device_get_unit(sc->dev), buf, &res) == 0) {
|
|
|
|
if (strncmp(res, "0x", 2) == 0) {
|
|
|
|
config = strtol(res + 2, NULL, 16);
|
|
|
|
} else {
|
|
|
|
config = hdac_widget_pin_patch(config, res);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2007-02-25 06:17:56 +00:00
|
|
|
HDA_BOOTVERBOSE(
|
|
|
|
if (config != orig)
|
|
|
|
device_printf(sc->dev,
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
"Patching pin config nid=%u 0x%08x -> 0x%08x\n",
|
2007-02-25 06:17:56 +00:00
|
|
|
nid, orig, config);
|
|
|
|
);
|
|
|
|
|
2006-10-01 11:13:00 +00:00
|
|
|
return (config);
|
|
|
|
}
|
|
|
|
|
2007-02-25 06:17:56 +00:00
|
|
|
static uint32_t
|
|
|
|
hdac_widget_pin_getcaps(struct hdac_widget *w)
|
|
|
|
{
|
|
|
|
struct hdac_softc *sc;
|
|
|
|
uint32_t caps, orig, id;
|
|
|
|
nid_t cad, nid;
|
|
|
|
|
|
|
|
sc = w->devinfo->codec->sc;
|
|
|
|
cad = w->devinfo->codec->cad;
|
|
|
|
nid = w->nid;
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
id = hdac_codec_id(w->devinfo->codec);
|
2007-02-25 06:17:56 +00:00
|
|
|
|
|
|
|
caps = hdac_command(sc,
|
|
|
|
HDA_CMD_GET_PARAMETER(cad, nid, HDA_PARAM_PIN_CAP), cad);
|
|
|
|
orig = caps;
|
|
|
|
|
|
|
|
HDA_BOOTVERBOSE(
|
|
|
|
if (caps != orig)
|
|
|
|
device_printf(sc->dev,
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
"Patching pin caps nid=%u 0x%08x -> 0x%08x\n",
|
2007-02-25 06:17:56 +00:00
|
|
|
nid, orig, caps);
|
|
|
|
);
|
|
|
|
|
|
|
|
return (caps);
|
|
|
|
}
|
|
|
|
|
2006-10-01 11:13:00 +00:00
|
|
|
static void
|
|
|
|
hdac_widget_pin_parse(struct hdac_widget *w)
|
|
|
|
{
|
|
|
|
struct hdac_softc *sc = w->devinfo->codec->sc;
|
|
|
|
uint32_t config, pincap;
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
const char *devstr, *connstr;
|
2006-10-01 11:13:00 +00:00
|
|
|
nid_t cad = w->devinfo->codec->cad;
|
|
|
|
nid_t nid = w->nid;
|
|
|
|
|
|
|
|
config = hdac_widget_pin_getconfig(w);
|
|
|
|
w->wclass.pin.config = config;
|
|
|
|
|
2007-02-25 06:17:56 +00:00
|
|
|
pincap = hdac_widget_pin_getcaps(w);
|
2006-10-01 11:13:00 +00:00
|
|
|
w->wclass.pin.cap = pincap;
|
|
|
|
|
|
|
|
w->wclass.pin.ctrl = hdac_command(sc,
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
HDA_CMD_GET_PIN_WIDGET_CTRL(cad, nid), cad);
|
2006-10-01 11:13:00 +00:00
|
|
|
|
|
|
|
if (HDA_PARAM_PIN_CAP_EAPD_CAP(pincap)) {
|
|
|
|
w->param.eapdbtl = hdac_command(sc,
|
|
|
|
HDA_CMD_GET_EAPD_BTL_ENABLE(cad, nid), cad);
|
|
|
|
w->param.eapdbtl &= 0x7;
|
|
|
|
w->param.eapdbtl |= HDA_CMD_SET_EAPD_BTL_ENABLE_EAPD;
|
|
|
|
} else
|
2006-10-02 16:30:04 +00:00
|
|
|
w->param.eapdbtl = HDAC_INVALID;
|
2006-10-01 11:13:00 +00:00
|
|
|
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
devstr = HDA_DEVS[(config & HDA_CONFIG_DEFAULTCONF_DEVICE_MASK) >>
|
|
|
|
HDA_CONFIG_DEFAULTCONF_DEVICE_SHIFT];
|
2006-10-01 11:13:00 +00:00
|
|
|
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
connstr = HDA_CONNS[(config & HDA_CONFIG_DEFAULTCONF_CONNECTIVITY_MASK) >>
|
|
|
|
HDA_CONFIG_DEFAULTCONF_CONNECTIVITY_SHIFT];
|
2006-10-01 11:13:00 +00:00
|
|
|
|
|
|
|
strlcat(w->name, ": ", sizeof(w->name));
|
|
|
|
strlcat(w->name, devstr, sizeof(w->name));
|
|
|
|
strlcat(w->name, " (", sizeof(w->name));
|
|
|
|
strlcat(w->name, connstr, sizeof(w->name));
|
|
|
|
strlcat(w->name, ")", sizeof(w->name));
|
|
|
|
}
|
|
|
|
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
static uint32_t
|
|
|
|
hdac_widget_getcaps(struct hdac_widget *w, int *waspin)
|
|
|
|
{
|
|
|
|
struct hdac_softc *sc;
|
|
|
|
uint32_t caps, orig, id;
|
|
|
|
nid_t cad, nid, beeper = -1;
|
|
|
|
|
|
|
|
sc = w->devinfo->codec->sc;
|
|
|
|
cad = w->devinfo->codec->cad;
|
|
|
|
nid = w->nid;
|
|
|
|
id = hdac_codec_id(w->devinfo->codec);
|
|
|
|
|
|
|
|
caps = hdac_command(sc,
|
|
|
|
HDA_CMD_GET_PARAMETER(cad, nid, HDA_PARAM_AUDIO_WIDGET_CAP),
|
|
|
|
cad);
|
|
|
|
orig = caps;
|
|
|
|
|
|
|
|
/* On some codecs beeper is an input pin, but it is not recordable
|
|
|
|
alone. Also most of BIOSes does not declare beeper pin.
|
|
|
|
Change beeper pin node type to beeper to help parser. */
|
|
|
|
*waspin = 0;
|
|
|
|
switch (id) {
|
|
|
|
case HDA_CODEC_AD1988:
|
|
|
|
case HDA_CODEC_AD1988B:
|
|
|
|
beeper = 26;
|
|
|
|
break;
|
|
|
|
case HDA_CODEC_ALC260:
|
|
|
|
beeper = 23;
|
|
|
|
break;
|
|
|
|
case HDA_CODEC_ALC262:
|
|
|
|
case HDA_CODEC_ALC268:
|
|
|
|
case HDA_CODEC_ALC880:
|
|
|
|
case HDA_CODEC_ALC882:
|
|
|
|
case HDA_CODEC_ALC883:
|
|
|
|
case HDA_CODEC_ALC885:
|
|
|
|
case HDA_CODEC_ALC888:
|
|
|
|
case HDA_CODEC_ALC889:
|
|
|
|
beeper = 29;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
if (nid == beeper) {
|
|
|
|
caps &= ~HDA_PARAM_AUDIO_WIDGET_CAP_TYPE_MASK;
|
|
|
|
caps |= HDA_PARAM_AUDIO_WIDGET_CAP_TYPE_BEEP_WIDGET <<
|
|
|
|
HDA_PARAM_AUDIO_WIDGET_CAP_TYPE_SHIFT;
|
|
|
|
*waspin = 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
HDA_BOOTVERBOSE(
|
|
|
|
if (caps != orig) {
|
|
|
|
device_printf(sc->dev,
|
|
|
|
"Patching widget caps nid=%u 0x%08x -> 0x%08x\n",
|
|
|
|
nid, orig, caps);
|
|
|
|
}
|
|
|
|
);
|
|
|
|
|
|
|
|
return (caps);
|
|
|
|
}
|
|
|
|
|
2006-10-01 11:13:00 +00:00
|
|
|
static void
|
|
|
|
hdac_widget_parse(struct hdac_widget *w)
|
|
|
|
{
|
|
|
|
struct hdac_softc *sc = w->devinfo->codec->sc;
|
|
|
|
uint32_t wcap, cap;
|
|
|
|
char *typestr;
|
|
|
|
nid_t cad = w->devinfo->codec->cad;
|
|
|
|
nid_t nid = w->nid;
|
|
|
|
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
wcap = hdac_widget_getcaps(w, &w->waspin);
|
|
|
|
|
2006-10-01 11:13:00 +00:00
|
|
|
w->param.widget_cap = wcap;
|
|
|
|
w->type = HDA_PARAM_AUDIO_WIDGET_CAP_TYPE(wcap);
|
|
|
|
|
|
|
|
switch (w->type) {
|
|
|
|
case HDA_PARAM_AUDIO_WIDGET_CAP_TYPE_AUDIO_OUTPUT:
|
|
|
|
typestr = "audio output";
|
|
|
|
break;
|
|
|
|
case HDA_PARAM_AUDIO_WIDGET_CAP_TYPE_AUDIO_INPUT:
|
|
|
|
typestr = "audio input";
|
|
|
|
break;
|
|
|
|
case HDA_PARAM_AUDIO_WIDGET_CAP_TYPE_AUDIO_MIXER:
|
|
|
|
typestr = "audio mixer";
|
|
|
|
break;
|
|
|
|
case HDA_PARAM_AUDIO_WIDGET_CAP_TYPE_AUDIO_SELECTOR:
|
|
|
|
typestr = "audio selector";
|
|
|
|
break;
|
|
|
|
case HDA_PARAM_AUDIO_WIDGET_CAP_TYPE_PIN_COMPLEX:
|
|
|
|
typestr = "pin";
|
|
|
|
break;
|
|
|
|
case HDA_PARAM_AUDIO_WIDGET_CAP_TYPE_POWER_WIDGET:
|
|
|
|
typestr = "power widget";
|
|
|
|
break;
|
|
|
|
case HDA_PARAM_AUDIO_WIDGET_CAP_TYPE_VOLUME_WIDGET:
|
|
|
|
typestr = "volume widget";
|
|
|
|
break;
|
|
|
|
case HDA_PARAM_AUDIO_WIDGET_CAP_TYPE_BEEP_WIDGET:
|
|
|
|
typestr = "beep widget";
|
|
|
|
break;
|
|
|
|
case HDA_PARAM_AUDIO_WIDGET_CAP_TYPE_VENDOR_WIDGET:
|
|
|
|
typestr = "vendor widget";
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
typestr = "unknown type";
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
strlcpy(w->name, typestr, sizeof(w->name));
|
|
|
|
|
|
|
|
hdac_widget_connection_parse(w);
|
|
|
|
|
|
|
|
if (HDA_PARAM_AUDIO_WIDGET_CAP_OUT_AMP(wcap)) {
|
|
|
|
if (HDA_PARAM_AUDIO_WIDGET_CAP_AMP_OVR(wcap))
|
|
|
|
w->param.outamp_cap =
|
|
|
|
hdac_command(sc,
|
|
|
|
HDA_CMD_GET_PARAMETER(cad, nid,
|
|
|
|
HDA_PARAM_OUTPUT_AMP_CAP), cad);
|
|
|
|
else
|
|
|
|
w->param.outamp_cap =
|
|
|
|
w->devinfo->function.audio.outamp_cap;
|
|
|
|
} else
|
|
|
|
w->param.outamp_cap = 0;
|
|
|
|
|
|
|
|
if (HDA_PARAM_AUDIO_WIDGET_CAP_IN_AMP(wcap)) {
|
|
|
|
if (HDA_PARAM_AUDIO_WIDGET_CAP_AMP_OVR(wcap))
|
|
|
|
w->param.inamp_cap =
|
|
|
|
hdac_command(sc,
|
|
|
|
HDA_CMD_GET_PARAMETER(cad, nid,
|
|
|
|
HDA_PARAM_INPUT_AMP_CAP), cad);
|
|
|
|
else
|
|
|
|
w->param.inamp_cap =
|
|
|
|
w->devinfo->function.audio.inamp_cap;
|
|
|
|
} else
|
|
|
|
w->param.inamp_cap = 0;
|
|
|
|
|
|
|
|
if (w->type == HDA_PARAM_AUDIO_WIDGET_CAP_TYPE_AUDIO_OUTPUT ||
|
|
|
|
w->type == HDA_PARAM_AUDIO_WIDGET_CAP_TYPE_AUDIO_INPUT) {
|
|
|
|
if (HDA_PARAM_AUDIO_WIDGET_CAP_FORMAT_OVR(wcap)) {
|
|
|
|
cap = hdac_command(sc,
|
|
|
|
HDA_CMD_GET_PARAMETER(cad, nid,
|
|
|
|
HDA_PARAM_SUPP_STREAM_FORMATS), cad);
|
|
|
|
w->param.supp_stream_formats = (cap != 0) ? cap :
|
|
|
|
w->devinfo->function.audio.supp_stream_formats;
|
|
|
|
cap = hdac_command(sc,
|
|
|
|
HDA_CMD_GET_PARAMETER(cad, nid,
|
|
|
|
HDA_PARAM_SUPP_PCM_SIZE_RATE), cad);
|
|
|
|
w->param.supp_pcm_size_rate = (cap != 0) ? cap :
|
|
|
|
w->devinfo->function.audio.supp_pcm_size_rate;
|
|
|
|
} else {
|
|
|
|
w->param.supp_stream_formats =
|
|
|
|
w->devinfo->function.audio.supp_stream_formats;
|
|
|
|
w->param.supp_pcm_size_rate =
|
|
|
|
w->devinfo->function.audio.supp_pcm_size_rate;
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
w->param.supp_stream_formats = 0;
|
|
|
|
w->param.supp_pcm_size_rate = 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (w->type == HDA_PARAM_AUDIO_WIDGET_CAP_TYPE_PIN_COMPLEX)
|
|
|
|
hdac_widget_pin_parse(w);
|
|
|
|
}
|
|
|
|
|
|
|
|
static struct hdac_widget *
|
|
|
|
hdac_widget_get(struct hdac_devinfo *devinfo, nid_t nid)
|
|
|
|
{
|
|
|
|
if (devinfo == NULL || devinfo->widget == NULL ||
|
|
|
|
nid < devinfo->startnode || nid >= devinfo->endnode)
|
|
|
|
return (NULL);
|
|
|
|
return (&devinfo->widget[nid - devinfo->startnode]);
|
|
|
|
}
|
|
|
|
|
Welcome to Once-a-year Sound Mega-Commit. Enjoy numerous updates and fixes
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.
2006-11-26 12:24:06 +00:00
|
|
|
static __inline int
|
|
|
|
hda_poll_channel(struct hdac_chan *ch)
|
|
|
|
{
|
|
|
|
uint32_t sz, delta;
|
|
|
|
volatile uint32_t ptr;
|
|
|
|
|
2007-07-09 20:42:11 +00:00
|
|
|
if (!(ch->flags & HDAC_CHN_RUNNING))
|
Welcome to Once-a-year Sound Mega-Commit. Enjoy numerous updates and fixes
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.
2006-11-26 12:24:06 +00:00
|
|
|
return (0);
|
|
|
|
|
|
|
|
sz = ch->blksz * ch->blkcnt;
|
2007-05-05 09:17:36 +00:00
|
|
|
if (ch->dmapos != NULL)
|
|
|
|
ptr = *(ch->dmapos);
|
|
|
|
else
|
|
|
|
ptr = HDAC_READ_4(&ch->devinfo->codec->sc->mem,
|
|
|
|
ch->off + HDAC_SDLPIB);
|
Welcome to Once-a-year Sound Mega-Commit. Enjoy numerous updates and fixes
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.
2006-11-26 12:24:06 +00:00
|
|
|
ch->ptr = ptr;
|
|
|
|
ptr %= sz;
|
|
|
|
ptr &= ~(ch->blksz - 1);
|
|
|
|
delta = (sz + ptr - ch->prevptr) % sz;
|
|
|
|
|
|
|
|
if (delta < ch->blksz)
|
|
|
|
return (0);
|
|
|
|
|
|
|
|
ch->prevptr = ptr;
|
|
|
|
|
|
|
|
return (1);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
hda_poll_callback(void *arg)
|
|
|
|
{
|
|
|
|
struct hdac_softc *sc = arg;
|
2007-07-01 17:31:20 +00:00
|
|
|
uint32_t trigger;
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
int i, active = 0;
|
Welcome to Once-a-year Sound Mega-Commit. Enjoy numerous updates and fixes
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.
2006-11-26 12:24:06 +00:00
|
|
|
|
|
|
|
if (sc == NULL)
|
|
|
|
return;
|
|
|
|
|
|
|
|
hdac_lock(sc);
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
if (sc->polling == 0) {
|
Welcome to Once-a-year Sound Mega-Commit. Enjoy numerous updates and fixes
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.
2006-11-26 12:24:06 +00:00
|
|
|
hdac_unlock(sc);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2007-07-01 17:31:20 +00:00
|
|
|
trigger = 0;
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
for (i = 0; i < sc->num_chans; i++) {
|
|
|
|
if ((sc->chans[i].flags & HDAC_CHN_RUNNING) == 0)
|
|
|
|
continue;
|
|
|
|
active = 1;
|
|
|
|
if (hda_poll_channel(&sc->chans[i]))
|
|
|
|
trigger |= (1 << i);
|
|
|
|
}
|
Welcome to Once-a-year Sound Mega-Commit. Enjoy numerous updates and fixes
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.
2006-11-26 12:24:06 +00:00
|
|
|
|
|
|
|
/* XXX */
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
if (active)
|
|
|
|
callout_reset(&sc->poll_hda, sc->poll_ticks,
|
|
|
|
hda_poll_callback, sc);
|
Welcome to Once-a-year Sound Mega-Commit. Enjoy numerous updates and fixes
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.
2006-11-26 12:24:06 +00:00
|
|
|
|
|
|
|
hdac_unlock(sc);
|
|
|
|
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
for (i = 0; i < sc->num_chans; i++) {
|
|
|
|
if (trigger & (1 << i))
|
|
|
|
chn_intr(sc->chans[i].c);
|
|
|
|
}
|
Welcome to Once-a-year Sound Mega-Commit. Enjoy numerous updates and fixes
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.
2006-11-26 12:24:06 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static int
|
|
|
|
hdac_rirb_flush(struct hdac_softc *sc)
|
|
|
|
{
|
|
|
|
struct hdac_rirb *rirb_base, *rirb;
|
|
|
|
struct hdac_codec *codec;
|
|
|
|
struct hdac_command_list *commands;
|
|
|
|
nid_t cad;
|
|
|
|
uint32_t resp;
|
|
|
|
uint8_t rirbwp;
|
2007-07-01 17:31:20 +00:00
|
|
|
int ret;
|
Welcome to Once-a-year Sound Mega-Commit. Enjoy numerous updates and fixes
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.
2006-11-26 12:24:06 +00:00
|
|
|
|
|
|
|
rirb_base = (struct hdac_rirb *)sc->rirb_dma.dma_vaddr;
|
|
|
|
rirbwp = HDAC_READ_1(&sc->mem, HDAC_RIRBWP);
|
2007-05-05 09:17:36 +00:00
|
|
|
#if 0
|
Welcome to Once-a-year Sound Mega-Commit. Enjoy numerous updates and fixes
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.
2006-11-26 12:24:06 +00:00
|
|
|
bus_dmamap_sync(sc->rirb_dma.dma_tag, sc->rirb_dma.dma_map,
|
|
|
|
BUS_DMASYNC_POSTREAD);
|
2007-05-05 09:17:36 +00:00
|
|
|
#endif
|
Welcome to Once-a-year Sound Mega-Commit. Enjoy numerous updates and fixes
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.
2006-11-26 12:24:06 +00:00
|
|
|
|
2007-07-01 17:31:20 +00:00
|
|
|
ret = 0;
|
|
|
|
|
Welcome to Once-a-year Sound Mega-Commit. Enjoy numerous updates and fixes
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.
2006-11-26 12:24:06 +00:00
|
|
|
while (sc->rirb_rp != rirbwp) {
|
|
|
|
sc->rirb_rp++;
|
|
|
|
sc->rirb_rp %= sc->rirb_size;
|
|
|
|
rirb = &rirb_base[sc->rirb_rp];
|
|
|
|
cad = HDAC_RIRB_RESPONSE_EX_SDATA_IN(rirb->response_ex);
|
|
|
|
if (cad < 0 || cad >= HDAC_CODEC_MAX ||
|
|
|
|
sc->codecs[cad] == NULL)
|
|
|
|
continue;
|
|
|
|
resp = rirb->response;
|
|
|
|
codec = sc->codecs[cad];
|
|
|
|
commands = codec->commands;
|
|
|
|
if (rirb->response_ex & HDAC_RIRB_RESPONSE_EX_UNSOLICITED) {
|
|
|
|
sc->unsolq[sc->unsolq_wp++] = (cad << 16) |
|
|
|
|
((resp >> 26) & 0xffff);
|
|
|
|
sc->unsolq_wp %= HDAC_UNSOLQ_MAX;
|
|
|
|
} else if (commands != NULL && commands->num_commands > 0 &&
|
|
|
|
codec->responses_received < commands->num_commands)
|
|
|
|
commands->responses[codec->responses_received++] =
|
|
|
|
resp;
|
|
|
|
ret++;
|
|
|
|
}
|
|
|
|
|
|
|
|
return (ret);
|
|
|
|
}
|
|
|
|
|
|
|
|
static int
|
|
|
|
hdac_unsolq_flush(struct hdac_softc *sc)
|
|
|
|
{
|
|
|
|
nid_t cad;
|
|
|
|
uint32_t tag;
|
|
|
|
int ret = 0;
|
|
|
|
|
|
|
|
if (sc->unsolq_st == HDAC_UNSOLQ_READY) {
|
|
|
|
sc->unsolq_st = HDAC_UNSOLQ_BUSY;
|
|
|
|
while (sc->unsolq_rp != sc->unsolq_wp) {
|
|
|
|
cad = sc->unsolq[sc->unsolq_rp] >> 16;
|
|
|
|
tag = sc->unsolq[sc->unsolq_rp++] & 0xffff;
|
|
|
|
sc->unsolq_rp %= HDAC_UNSOLQ_MAX;
|
|
|
|
hdac_unsolicited_handler(sc->codecs[cad], tag);
|
|
|
|
ret++;
|
|
|
|
}
|
|
|
|
sc->unsolq_st = HDAC_UNSOLQ_READY;
|
|
|
|
}
|
|
|
|
|
|
|
|
return (ret);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
hdac_poll_callback(void *arg)
|
|
|
|
{
|
|
|
|
struct hdac_softc *sc = arg;
|
|
|
|
if (sc == NULL)
|
|
|
|
return;
|
2007-02-16 17:43:29 +00:00
|
|
|
|
Welcome to Once-a-year Sound Mega-Commit. Enjoy numerous updates and fixes
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.
2006-11-26 12:24:06 +00:00
|
|
|
hdac_lock(sc);
|
2007-05-05 09:17:36 +00:00
|
|
|
if (sc->polling == 0 || sc->poll_ival == 0) {
|
Welcome to Once-a-year Sound Mega-Commit. Enjoy numerous updates and fixes
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.
2006-11-26 12:24:06 +00:00
|
|
|
hdac_unlock(sc);
|
|
|
|
return;
|
|
|
|
}
|
2007-07-01 17:31:20 +00:00
|
|
|
if (hdac_rirb_flush(sc) != 0)
|
|
|
|
hdac_unsolq_flush(sc);
|
2007-05-05 09:17:36 +00:00
|
|
|
callout_reset(&sc->poll_hdac, sc->poll_ival, hdac_poll_callback, sc);
|
Welcome to Once-a-year Sound Mega-Commit. Enjoy numerous updates and fixes
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.
2006-11-26 12:24:06 +00:00
|
|
|
hdac_unlock(sc);
|
|
|
|
}
|
|
|
|
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
static void
|
|
|
|
hdac_poll_reinit(struct hdac_softc *sc)
|
|
|
|
{
|
|
|
|
int i, pollticks, min = 1000000;
|
|
|
|
struct hdac_chan *ch;
|
|
|
|
|
|
|
|
for (i = 0; i < sc->num_chans; i++) {
|
|
|
|
if ((sc->chans[i].flags & HDAC_CHN_RUNNING) == 0)
|
|
|
|
continue;
|
|
|
|
ch = &sc->chans[i];
|
|
|
|
pollticks = ((uint64_t)hz * ch->blksz) /
|
|
|
|
((uint64_t)sndbuf_getbps(ch->b) *
|
|
|
|
sndbuf_getspd(ch->b));
|
|
|
|
pollticks >>= 1;
|
|
|
|
if (pollticks > hz)
|
|
|
|
pollticks = hz;
|
|
|
|
if (pollticks < 1) {
|
|
|
|
HDA_BOOTVERBOSE(
|
|
|
|
device_printf(sc->dev,
|
|
|
|
"%s: pollticks=%d < 1 !\n",
|
|
|
|
__func__, pollticks);
|
|
|
|
);
|
|
|
|
pollticks = 1;
|
|
|
|
}
|
|
|
|
if (min > pollticks)
|
|
|
|
min = pollticks;
|
|
|
|
}
|
|
|
|
HDA_BOOTVERBOSE(
|
|
|
|
device_printf(sc->dev,
|
|
|
|
"%s: pollticks %d -> %d\n",
|
|
|
|
__func__, sc->poll_ticks, min);
|
|
|
|
);
|
|
|
|
sc->poll_ticks = min;
|
|
|
|
if (min == 1000000)
|
|
|
|
callout_stop(&sc->poll_hda);
|
|
|
|
else
|
|
|
|
callout_reset(&sc->poll_hda, 1, hda_poll_callback, sc);
|
|
|
|
}
|
|
|
|
|
2006-10-01 11:13:00 +00:00
|
|
|
static void
|
|
|
|
hdac_stream_stop(struct hdac_chan *ch)
|
|
|
|
{
|
|
|
|
struct hdac_softc *sc = ch->devinfo->codec->sc;
|
|
|
|
uint32_t ctl;
|
|
|
|
|
|
|
|
ctl = HDAC_READ_1(&sc->mem, ch->off + HDAC_SDCTL0);
|
|
|
|
ctl &= ~(HDAC_SDCTL_IOCE | HDAC_SDCTL_FEIE | HDAC_SDCTL_DEIE |
|
|
|
|
HDAC_SDCTL_RUN);
|
|
|
|
HDAC_WRITE_1(&sc->mem, ch->off + HDAC_SDCTL0, ctl);
|
|
|
|
|
2007-07-09 20:42:11 +00:00
|
|
|
ch->flags &= ~HDAC_CHN_RUNNING;
|
Welcome to Once-a-year Sound Mega-Commit. Enjoy numerous updates and fixes
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.
2006-11-26 12:24:06 +00:00
|
|
|
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
if (sc->polling != 0)
|
|
|
|
hdac_poll_reinit(sc);
|
Welcome to Once-a-year Sound Mega-Commit. Enjoy numerous updates and fixes
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.
2006-11-26 12:24:06 +00:00
|
|
|
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
ctl = HDAC_READ_4(&sc->mem, HDAC_INTCTL);
|
|
|
|
ctl &= ~(1 << (ch->off >> 5));
|
|
|
|
HDAC_WRITE_4(&sc->mem, HDAC_INTCTL, ctl);
|
2006-10-01 11:13:00 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
hdac_stream_start(struct hdac_chan *ch)
|
|
|
|
{
|
|
|
|
struct hdac_softc *sc = ch->devinfo->codec->sc;
|
|
|
|
uint32_t ctl;
|
|
|
|
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
ch->flags |= HDAC_CHN_RUNNING;
|
2006-10-01 11:13:00 +00:00
|
|
|
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
if (sc->polling != 0)
|
|
|
|
hdac_poll_reinit(sc);
|
Welcome to Once-a-year Sound Mega-Commit. Enjoy numerous updates and fixes
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.
2006-11-26 12:24:06 +00:00
|
|
|
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
ctl = HDAC_READ_4(&sc->mem, HDAC_INTCTL);
|
|
|
|
ctl |= 1 << (ch->off >> 5);
|
|
|
|
HDAC_WRITE_4(&sc->mem, HDAC_INTCTL, ctl);
|
|
|
|
|
|
|
|
ctl = HDAC_READ_1(&sc->mem, ch->off + HDAC_SDCTL0);
|
|
|
|
ctl |= HDAC_SDCTL_IOCE | HDAC_SDCTL_FEIE | HDAC_SDCTL_DEIE |
|
|
|
|
HDAC_SDCTL_RUN;
|
|
|
|
HDAC_WRITE_1(&sc->mem, ch->off + HDAC_SDCTL0, ctl);
|
2006-10-01 11:13:00 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
hdac_stream_reset(struct hdac_chan *ch)
|
|
|
|
{
|
|
|
|
struct hdac_softc *sc = ch->devinfo->codec->sc;
|
|
|
|
int timeout = 1000;
|
|
|
|
int to = timeout;
|
|
|
|
uint32_t ctl;
|
|
|
|
|
|
|
|
ctl = HDAC_READ_1(&sc->mem, ch->off + HDAC_SDCTL0);
|
|
|
|
ctl |= HDAC_SDCTL_SRST;
|
|
|
|
HDAC_WRITE_1(&sc->mem, ch->off + HDAC_SDCTL0, ctl);
|
|
|
|
do {
|
|
|
|
ctl = HDAC_READ_1(&sc->mem, ch->off + HDAC_SDCTL0);
|
|
|
|
if (ctl & HDAC_SDCTL_SRST)
|
|
|
|
break;
|
|
|
|
DELAY(10);
|
|
|
|
} while (--to);
|
|
|
|
if (!(ctl & HDAC_SDCTL_SRST)) {
|
|
|
|
device_printf(sc->dev, "timeout in reset\n");
|
|
|
|
}
|
|
|
|
ctl &= ~HDAC_SDCTL_SRST;
|
|
|
|
HDAC_WRITE_1(&sc->mem, ch->off + HDAC_SDCTL0, ctl);
|
|
|
|
to = timeout;
|
|
|
|
do {
|
|
|
|
ctl = HDAC_READ_1(&sc->mem, ch->off + HDAC_SDCTL0);
|
|
|
|
if (!(ctl & HDAC_SDCTL_SRST))
|
|
|
|
break;
|
|
|
|
DELAY(10);
|
|
|
|
} while (--to);
|
- Fix wrong id for ALC882, add ALC883 id.
- 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"
2006-10-06 18:59:27 +00:00
|
|
|
if (ctl & HDAC_SDCTL_SRST)
|
2006-10-01 11:13:00 +00:00
|
|
|
device_printf(sc->dev, "can't reset!\n");
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
hdac_stream_setid(struct hdac_chan *ch)
|
|
|
|
{
|
|
|
|
struct hdac_softc *sc = ch->devinfo->codec->sc;
|
|
|
|
uint32_t ctl;
|
|
|
|
|
|
|
|
ctl = HDAC_READ_1(&sc->mem, ch->off + HDAC_SDCTL2);
|
|
|
|
ctl &= ~HDAC_SDCTL2_STRM_MASK;
|
|
|
|
ctl |= ch->sid << HDAC_SDCTL2_STRM_SHIFT;
|
|
|
|
HDAC_WRITE_1(&sc->mem, ch->off + HDAC_SDCTL2, ctl);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
hdac_bdl_setup(struct hdac_chan *ch)
|
|
|
|
{
|
|
|
|
struct hdac_softc *sc = ch->devinfo->codec->sc;
|
|
|
|
struct hdac_bdle *bdle;
|
Welcome to Once-a-year Sound Mega-Commit. Enjoy numerous updates and fixes
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.
2006-11-26 12:24:06 +00:00
|
|
|
uint64_t addr;
|
|
|
|
uint32_t blksz, blkcnt;
|
2006-10-01 11:13:00 +00:00
|
|
|
int i;
|
|
|
|
|
|
|
|
addr = (uint64_t)sndbuf_getbufaddr(ch->b);
|
Welcome to Once-a-year Sound Mega-Commit. Enjoy numerous updates and fixes
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.
2006-11-26 12:24:06 +00:00
|
|
|
bdle = (struct hdac_bdle *)ch->bdl_dma.dma_vaddr;
|
2006-10-01 11:13:00 +00:00
|
|
|
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
blksz = ch->blksz;
|
|
|
|
blkcnt = ch->blkcnt;
|
Welcome to Once-a-year Sound Mega-Commit. Enjoy numerous updates and fixes
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.
2006-11-26 12:24:06 +00:00
|
|
|
|
|
|
|
for (i = 0; i < blkcnt; i++, bdle++) {
|
2006-10-01 11:13:00 +00:00
|
|
|
bdle->addrl = (uint32_t)addr;
|
|
|
|
bdle->addrh = (uint32_t)(addr >> 32);
|
Welcome to Once-a-year Sound Mega-Commit. Enjoy numerous updates and fixes
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.
2006-11-26 12:24:06 +00:00
|
|
|
bdle->len = blksz;
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
bdle->ioc = 1;
|
Welcome to Once-a-year Sound Mega-Commit. Enjoy numerous updates and fixes
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.
2006-11-26 12:24:06 +00:00
|
|
|
addr += blksz;
|
2006-10-01 11:13:00 +00:00
|
|
|
}
|
|
|
|
|
Welcome to Once-a-year Sound Mega-Commit. Enjoy numerous updates and fixes
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.
2006-11-26 12:24:06 +00:00
|
|
|
HDAC_WRITE_4(&sc->mem, ch->off + HDAC_SDCBL, blksz * blkcnt);
|
|
|
|
HDAC_WRITE_2(&sc->mem, ch->off + HDAC_SDLVI, blkcnt - 1);
|
2006-10-01 11:13:00 +00:00
|
|
|
addr = ch->bdl_dma.dma_paddr;
|
|
|
|
HDAC_WRITE_4(&sc->mem, ch->off + HDAC_SDBDPL, (uint32_t)addr);
|
|
|
|
HDAC_WRITE_4(&sc->mem, ch->off + HDAC_SDBDPU, (uint32_t)(addr >> 32));
|
2007-05-05 09:17:36 +00:00
|
|
|
if (ch->dmapos != NULL &&
|
|
|
|
!(HDAC_READ_4(&sc->mem, HDAC_DPIBLBASE) & 0x00000001)) {
|
|
|
|
addr = sc->pos_dma.dma_paddr;
|
|
|
|
HDAC_WRITE_4(&sc->mem, HDAC_DPIBLBASE,
|
|
|
|
((uint32_t)addr & HDAC_DPLBASE_DPLBASE_MASK) | 0x00000001);
|
|
|
|
HDAC_WRITE_4(&sc->mem, HDAC_DPIBUBASE, (uint32_t)(addr >> 32));
|
|
|
|
}
|
2006-10-01 11:13:00 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static int
|
|
|
|
hdac_bdl_alloc(struct hdac_chan *ch)
|
|
|
|
{
|
|
|
|
struct hdac_softc *sc = ch->devinfo->codec->sc;
|
|
|
|
int rc;
|
|
|
|
|
|
|
|
rc = hdac_dma_alloc(sc, &ch->bdl_dma,
|
|
|
|
sizeof(struct hdac_bdle) * HDA_BDL_MAX);
|
|
|
|
if (rc) {
|
|
|
|
device_printf(sc->dev, "can't alloc bdl\n");
|
|
|
|
return (rc);
|
|
|
|
}
|
|
|
|
|
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
hdac_audio_ctl_amp_set_internal(struct hdac_softc *sc, nid_t cad, nid_t nid,
|
|
|
|
int index, int lmute, int rmute,
|
|
|
|
int left, int right, int dir)
|
|
|
|
{
|
|
|
|
uint16_t v = 0;
|
|
|
|
|
|
|
|
if (sc == NULL)
|
|
|
|
return;
|
|
|
|
|
|
|
|
if (left != right || lmute != rmute) {
|
|
|
|
v = (1 << (15 - dir)) | (1 << 13) | (index << 8) |
|
|
|
|
(lmute << 7) | left;
|
|
|
|
hdac_command(sc,
|
Welcome to Once-a-year Sound Mega-Commit. Enjoy numerous updates and fixes
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.
2006-11-26 12:24:06 +00:00
|
|
|
HDA_CMD_SET_AMP_GAIN_MUTE(cad, nid, v), cad);
|
2006-10-01 11:13:00 +00:00
|
|
|
v = (1 << (15 - dir)) | (1 << 12) | (index << 8) |
|
|
|
|
(rmute << 7) | right;
|
|
|
|
} else
|
|
|
|
v = (1 << (15 - dir)) | (3 << 12) | (index << 8) |
|
|
|
|
(lmute << 7) | left;
|
|
|
|
|
|
|
|
hdac_command(sc,
|
|
|
|
HDA_CMD_SET_AMP_GAIN_MUTE(cad, nid, v), cad);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
hdac_audio_ctl_amp_set(struct hdac_audio_ctl *ctl, uint32_t mute,
|
|
|
|
int left, int right)
|
|
|
|
{
|
|
|
|
struct hdac_softc *sc;
|
|
|
|
nid_t nid, cad;
|
|
|
|
int lmute, rmute;
|
|
|
|
|
|
|
|
sc = ctl->widget->devinfo->codec->sc;
|
|
|
|
cad = ctl->widget->devinfo->codec->cad;
|
|
|
|
nid = ctl->widget->nid;
|
|
|
|
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
/* Save new values if valid. */
|
|
|
|
if (mute != HDA_AMP_MUTE_DEFAULT)
|
|
|
|
ctl->muted = mute;
|
|
|
|
if (left != HDA_AMP_VOL_DEFAULT)
|
|
|
|
ctl->left = left;
|
|
|
|
if (right != HDA_AMP_VOL_DEFAULT)
|
|
|
|
ctl->right = right;
|
|
|
|
/* Prepare effective values */
|
|
|
|
if (ctl->forcemute) {
|
|
|
|
lmute = 1;
|
|
|
|
rmute = 1;
|
|
|
|
left = 0;
|
|
|
|
right = 0;
|
|
|
|
} else {
|
2006-10-01 11:13:00 +00:00
|
|
|
lmute = HDA_AMP_LEFT_MUTED(ctl->muted);
|
|
|
|
rmute = HDA_AMP_RIGHT_MUTED(ctl->muted);
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
left = ctl->left;
|
|
|
|
right = ctl->right;
|
2006-10-01 11:13:00 +00:00
|
|
|
}
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
/* Apply effective values */
|
2006-10-01 11:13:00 +00:00
|
|
|
if (ctl->dir & HDA_CTL_OUT)
|
|
|
|
hdac_audio_ctl_amp_set_internal(sc, cad, nid, ctl->index,
|
|
|
|
lmute, rmute, left, right, 0);
|
|
|
|
if (ctl->dir & HDA_CTL_IN)
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
hdac_audio_ctl_amp_set_internal(sc, cad, nid, ctl->index,
|
2006-10-01 11:13:00 +00:00
|
|
|
lmute, rmute, left, right, 1);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
hdac_widget_connection_select(struct hdac_widget *w, uint8_t index)
|
|
|
|
{
|
|
|
|
if (w == NULL || w->nconns < 1 || index > (w->nconns - 1))
|
|
|
|
return;
|
|
|
|
hdac_command(w->devinfo->codec->sc,
|
|
|
|
HDA_CMD_SET_CONNECTION_SELECT_CONTROL(w->devinfo->codec->cad,
|
|
|
|
w->nid, index), w->devinfo->codec->cad);
|
|
|
|
w->selconn = index;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/****************************************************************************
|
|
|
|
* uint32_t hdac_command_sendone_internal
|
|
|
|
*
|
|
|
|
* Wrapper function that sends only one command to a given codec
|
|
|
|
****************************************************************************/
|
|
|
|
static uint32_t
|
|
|
|
hdac_command_sendone_internal(struct hdac_softc *sc, uint32_t verb, nid_t cad)
|
|
|
|
{
|
|
|
|
struct hdac_command_list cl;
|
2006-10-02 16:30:04 +00:00
|
|
|
uint32_t response = HDAC_INVALID;
|
2006-10-01 11:13:00 +00:00
|
|
|
|
- Fix wrong id for ALC882, add ALC883 id.
- 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"
2006-10-06 18:59:27 +00:00
|
|
|
if (!hdac_lockowned(sc))
|
2006-10-01 11:13:00 +00:00
|
|
|
device_printf(sc->dev, "WARNING!!!! mtx not owned!!!!\n");
|
|
|
|
cl.num_commands = 1;
|
|
|
|
cl.verbs = &verb;
|
|
|
|
cl.responses = &response;
|
|
|
|
|
|
|
|
hdac_command_send_internal(sc, &cl, cad);
|
|
|
|
|
|
|
|
return (response);
|
|
|
|
}
|
|
|
|
|
|
|
|
/****************************************************************************
|
|
|
|
* hdac_command_send_internal
|
|
|
|
*
|
|
|
|
* Send a command list to the codec via the corb. We queue as much verbs as
|
|
|
|
* we can and msleep on the codec. When the interrupt get the responses
|
|
|
|
* back from the rirb, it will wake us up so we can queue the remaining verbs
|
|
|
|
* if any.
|
|
|
|
****************************************************************************/
|
|
|
|
static void
|
|
|
|
hdac_command_send_internal(struct hdac_softc *sc,
|
|
|
|
struct hdac_command_list *commands, nid_t cad)
|
|
|
|
{
|
|
|
|
struct hdac_codec *codec;
|
|
|
|
int corbrp;
|
|
|
|
uint32_t *corb;
|
|
|
|
int timeout;
|
|
|
|
int retry = 10;
|
Welcome to Once-a-year Sound Mega-Commit. Enjoy numerous updates and fixes
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.
2006-11-26 12:24:06 +00:00
|
|
|
struct hdac_rirb *rirb_base;
|
2006-10-01 11:13:00 +00:00
|
|
|
|
Welcome to Once-a-year Sound Mega-Commit. Enjoy numerous updates and fixes
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.
2006-11-26 12:24:06 +00:00
|
|
|
if (sc == NULL || sc->codecs[cad] == NULL || commands == NULL ||
|
|
|
|
commands->num_commands < 1)
|
2006-10-01 11:13:00 +00:00
|
|
|
return;
|
|
|
|
|
|
|
|
codec = sc->codecs[cad];
|
|
|
|
codec->commands = commands;
|
|
|
|
codec->responses_received = 0;
|
|
|
|
codec->verbs_sent = 0;
|
|
|
|
corb = (uint32_t *)sc->corb_dma.dma_vaddr;
|
|
|
|
rirb_base = (struct hdac_rirb *)sc->rirb_dma.dma_vaddr;
|
|
|
|
|
|
|
|
do {
|
|
|
|
if (codec->verbs_sent != commands->num_commands) {
|
|
|
|
/* Queue as many verbs as possible */
|
|
|
|
corbrp = HDAC_READ_2(&sc->mem, HDAC_CORBRP);
|
2007-05-05 09:17:36 +00:00
|
|
|
#if 0
|
2006-10-01 11:13:00 +00:00
|
|
|
bus_dmamap_sync(sc->corb_dma.dma_tag,
|
|
|
|
sc->corb_dma.dma_map, BUS_DMASYNC_PREWRITE);
|
2007-05-05 09:17:36 +00:00
|
|
|
#endif
|
2006-10-01 11:13:00 +00:00
|
|
|
while (codec->verbs_sent != commands->num_commands &&
|
|
|
|
((sc->corb_wp + 1) % sc->corb_size) != corbrp) {
|
|
|
|
sc->corb_wp++;
|
|
|
|
sc->corb_wp %= sc->corb_size;
|
|
|
|
corb[sc->corb_wp] =
|
|
|
|
commands->verbs[codec->verbs_sent++];
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Send the verbs to the codecs */
|
2007-05-05 09:17:36 +00:00
|
|
|
#if 0
|
2006-10-01 11:13:00 +00:00
|
|
|
bus_dmamap_sync(sc->corb_dma.dma_tag,
|
|
|
|
sc->corb_dma.dma_map, BUS_DMASYNC_POSTWRITE);
|
2007-05-05 09:17:36 +00:00
|
|
|
#endif
|
2006-10-01 11:13:00 +00:00
|
|
|
HDAC_WRITE_2(&sc->mem, HDAC_CORBWP, sc->corb_wp);
|
|
|
|
}
|
|
|
|
|
|
|
|
timeout = 1000;
|
Welcome to Once-a-year Sound Mega-Commit. Enjoy numerous updates and fixes
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.
2006-11-26 12:24:06 +00:00
|
|
|
while (hdac_rirb_flush(sc) == 0 && --timeout)
|
2006-10-01 11:13:00 +00:00
|
|
|
DELAY(10);
|
|
|
|
} while ((codec->verbs_sent != commands->num_commands ||
|
Welcome to Once-a-year Sound Mega-Commit. Enjoy numerous updates and fixes
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.
2006-11-26 12:24:06 +00:00
|
|
|
codec->responses_received != commands->num_commands) && --retry);
|
2006-10-01 11:13:00 +00:00
|
|
|
|
|
|
|
if (retry == 0)
|
|
|
|
device_printf(sc->dev,
|
Welcome to Once-a-year Sound Mega-Commit. Enjoy numerous updates and fixes
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.
2006-11-26 12:24:06 +00:00
|
|
|
"%s: TIMEOUT numcmd=%d, sent=%d, received=%d\n",
|
|
|
|
__func__, commands->num_commands, codec->verbs_sent,
|
|
|
|
codec->responses_received);
|
2006-10-01 11:13:00 +00:00
|
|
|
|
Welcome to Once-a-year Sound Mega-Commit. Enjoy numerous updates and fixes
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.
2006-11-26 12:24:06 +00:00
|
|
|
codec->commands = NULL;
|
|
|
|
codec->responses_received = 0;
|
2006-10-01 11:13:00 +00:00
|
|
|
codec->verbs_sent = 0;
|
|
|
|
|
Welcome to Once-a-year Sound Mega-Commit. Enjoy numerous updates and fixes
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.
2006-11-26 12:24:06 +00:00
|
|
|
hdac_unsolq_flush(sc);
|
2006-10-01 11:13:00 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/****************************************************************************
|
|
|
|
* Device Methods
|
|
|
|
****************************************************************************/
|
|
|
|
|
|
|
|
/****************************************************************************
|
|
|
|
* int hdac_probe(device_t)
|
|
|
|
*
|
|
|
|
* Probe for the presence of an hdac. If none is found, check for a generic
|
|
|
|
* match using the subclass of the device.
|
|
|
|
****************************************************************************/
|
|
|
|
static int
|
|
|
|
hdac_probe(device_t dev)
|
|
|
|
{
|
|
|
|
int i, result;
|
2006-10-12 04:19:37 +00:00
|
|
|
uint32_t model;
|
|
|
|
uint16_t class, subclass;
|
2006-10-01 11:13:00 +00:00
|
|
|
char desc[64];
|
|
|
|
|
|
|
|
model = (uint32_t)pci_get_device(dev) << 16;
|
|
|
|
model |= (uint32_t)pci_get_vendor(dev) & 0x0000ffff;
|
|
|
|
class = pci_get_class(dev);
|
|
|
|
subclass = pci_get_subclass(dev);
|
|
|
|
|
|
|
|
bzero(desc, sizeof(desc));
|
|
|
|
result = ENXIO;
|
|
|
|
for (i = 0; i < HDAC_DEVICES_LEN; i++) {
|
|
|
|
if (hdac_devices[i].model == model) {
|
|
|
|
strlcpy(desc, hdac_devices[i].desc, sizeof(desc));
|
|
|
|
result = BUS_PROBE_DEFAULT;
|
|
|
|
break;
|
|
|
|
}
|
2006-10-12 04:19:37 +00:00
|
|
|
if (HDA_DEV_MATCH(hdac_devices[i].model, model) &&
|
2006-10-01 11:13:00 +00:00
|
|
|
class == PCIC_MULTIMEDIA &&
|
|
|
|
subclass == PCIS_MULTIMEDIA_HDA) {
|
|
|
|
strlcpy(desc, hdac_devices[i].desc, sizeof(desc));
|
|
|
|
result = BUS_PROBE_GENERIC;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
if (result == ENXIO && class == PCIC_MULTIMEDIA &&
|
|
|
|
subclass == PCIS_MULTIMEDIA_HDA) {
|
|
|
|
strlcpy(desc, "Generic", sizeof(desc));
|
|
|
|
result = BUS_PROBE_GENERIC;
|
|
|
|
}
|
|
|
|
if (result != ENXIO) {
|
|
|
|
strlcat(desc, " High Definition Audio Controller",
|
|
|
|
sizeof(desc));
|
|
|
|
device_set_desc_copy(dev, desc);
|
|
|
|
}
|
|
|
|
|
|
|
|
return (result);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void *
|
|
|
|
hdac_channel_init(kobj_t obj, void *data, struct snd_dbuf *b,
|
|
|
|
struct pcm_channel *c, int dir)
|
|
|
|
{
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
struct hdac_pcm_devinfo *pdevinfo = data;
|
|
|
|
struct hdac_devinfo *devinfo = pdevinfo->devinfo;
|
2006-10-01 11:13:00 +00:00
|
|
|
struct hdac_softc *sc = devinfo->codec->sc;
|
|
|
|
struct hdac_chan *ch;
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
int i, ord = 0, chid;
|
2006-10-01 11:13:00 +00:00
|
|
|
|
|
|
|
hdac_lock(sc);
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
|
|
|
|
chid = (dir == PCMDIR_PLAY)?pdevinfo->play:pdevinfo->rec;
|
|
|
|
ch = &sc->chans[chid];
|
|
|
|
for (i = 0; i < sc->num_chans && i < chid; i++) {
|
|
|
|
if (ch->dir == sc->chans[i].dir)
|
|
|
|
ord++;
|
|
|
|
}
|
2006-10-01 11:13:00 +00:00
|
|
|
if (dir == PCMDIR_PLAY) {
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
ch->off = (sc->num_iss + ord) << 5;
|
2006-10-01 11:13:00 +00:00
|
|
|
} else {
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
ch->off = ord << 5;
|
2006-10-01 11:13:00 +00:00
|
|
|
}
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
|
2006-10-01 11:13:00 +00:00
|
|
|
if (devinfo->function.audio.quirks & HDA_QUIRK_FIXEDRATE) {
|
|
|
|
ch->caps.minspeed = ch->caps.maxspeed = 48000;
|
|
|
|
ch->pcmrates[0] = 48000;
|
|
|
|
ch->pcmrates[1] = 0;
|
|
|
|
}
|
2007-05-05 09:17:36 +00:00
|
|
|
if (sc->pos_dma.dma_vaddr != NULL)
|
|
|
|
ch->dmapos = (uint32_t *)(sc->pos_dma.dma_vaddr +
|
|
|
|
(sc->streamcnt * 8));
|
|
|
|
else
|
|
|
|
ch->dmapos = NULL;
|
|
|
|
ch->sid = ++sc->streamcnt;
|
|
|
|
ch->dir = dir;
|
2006-10-01 11:13:00 +00:00
|
|
|
ch->b = b;
|
|
|
|
ch->c = c;
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
ch->blksz = pdevinfo->chan_size / pdevinfo->chan_blkcnt;
|
|
|
|
ch->blkcnt = pdevinfo->chan_blkcnt;
|
2006-10-01 11:13:00 +00:00
|
|
|
hdac_unlock(sc);
|
|
|
|
|
|
|
|
if (hdac_bdl_alloc(ch) != 0) {
|
|
|
|
ch->blkcnt = 0;
|
|
|
|
return (NULL);
|
|
|
|
}
|
|
|
|
|
2007-05-05 09:17:36 +00:00
|
|
|
if (sndbuf_alloc(ch->b, sc->chan_dmat,
|
2007-07-09 20:42:11 +00:00
|
|
|
(sc->flags & HDAC_F_DMA_NOCACHE) ? BUS_DMA_NOCACHE : 0,
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
pdevinfo->chan_size) != 0)
|
2006-10-01 11:13:00 +00:00
|
|
|
return (NULL);
|
|
|
|
|
|
|
|
return (ch);
|
|
|
|
}
|
|
|
|
|
|
|
|
static int
|
|
|
|
hdac_channel_setformat(kobj_t obj, void *data, uint32_t format)
|
|
|
|
{
|
|
|
|
struct hdac_chan *ch = data;
|
|
|
|
int i;
|
|
|
|
|
|
|
|
for (i = 0; ch->caps.fmtlist[i] != 0; i++) {
|
|
|
|
if (format == ch->caps.fmtlist[i]) {
|
|
|
|
ch->fmt = format;
|
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return (EINVAL);
|
|
|
|
}
|
|
|
|
|
|
|
|
static int
|
|
|
|
hdac_channel_setspeed(kobj_t obj, void *data, uint32_t speed)
|
|
|
|
{
|
|
|
|
struct hdac_chan *ch = data;
|
Welcome to Once-a-year Sound Mega-Commit. Enjoy numerous updates and fixes
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.
2006-11-26 12:24:06 +00:00
|
|
|
uint32_t spd = 0, threshold;
|
2006-10-01 11:13:00 +00:00
|
|
|
int i;
|
|
|
|
|
|
|
|
for (i = 0; ch->pcmrates[i] != 0; i++) {
|
|
|
|
spd = ch->pcmrates[i];
|
Welcome to Once-a-year Sound Mega-Commit. Enjoy numerous updates and fixes
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.
2006-11-26 12:24:06 +00:00
|
|
|
threshold = spd + ((ch->pcmrates[i + 1] != 0) ?
|
|
|
|
((ch->pcmrates[i + 1] - spd) >> 1) : 0);
|
|
|
|
if (speed < threshold)
|
2006-10-01 11:13:00 +00:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
Welcome to Once-a-year Sound Mega-Commit. Enjoy numerous updates and fixes
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.
2006-11-26 12:24:06 +00:00
|
|
|
if (spd == 0) /* impossible */
|
2006-10-01 11:13:00 +00:00
|
|
|
ch->spd = 48000;
|
|
|
|
else
|
|
|
|
ch->spd = spd;
|
|
|
|
|
|
|
|
return (ch->spd);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
hdac_stream_setup(struct hdac_chan *ch)
|
|
|
|
{
|
|
|
|
struct hdac_softc *sc = ch->devinfo->codec->sc;
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
struct hdac_audio_as *as = &ch->devinfo->function.audio.as[ch->as];
|
2007-11-21 11:39:27 +00:00
|
|
|
struct hdac_widget *w;
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
int i, chn, totalchn, c;
|
2006-10-01 11:13:00 +00:00
|
|
|
nid_t cad = ch->devinfo->codec->cad;
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
uint16_t fmt, dfmt;
|
2006-10-01 11:13:00 +00:00
|
|
|
|
2008-09-16 20:03:34 +00:00
|
|
|
HDA_BOOTHVERBOSE(
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
device_printf(ch->pdevinfo->dev,
|
|
|
|
"PCMDIR_%s: Stream setup fmt=%08x speed=%d\n",
|
|
|
|
(ch->dir == PCMDIR_PLAY) ? "PLAY" : "REC",
|
|
|
|
ch->fmt, ch->spd);
|
|
|
|
);
|
2006-10-01 11:13:00 +00:00
|
|
|
fmt = 0;
|
|
|
|
if (ch->fmt & AFMT_S16_LE)
|
|
|
|
fmt |= ch->bit16 << 4;
|
|
|
|
else if (ch->fmt & AFMT_S32_LE)
|
|
|
|
fmt |= ch->bit32 << 4;
|
|
|
|
else
|
|
|
|
fmt |= 1 << 4;
|
|
|
|
|
|
|
|
for (i = 0; i < HDA_RATE_TAB_LEN; i++) {
|
|
|
|
if (hda_rate_tab[i].valid && ch->spd == hda_rate_tab[i].rate) {
|
|
|
|
fmt |= hda_rate_tab[i].base;
|
|
|
|
fmt |= hda_rate_tab[i].mul;
|
|
|
|
fmt |= hda_rate_tab[i].div;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
if (ch->fmt & (AFMT_STEREO | AFMT_AC3)) {
|
2006-10-01 11:13:00 +00:00
|
|
|
fmt |= 1;
|
2007-11-21 11:39:27 +00:00
|
|
|
totalchn = 2;
|
|
|
|
} else
|
|
|
|
totalchn = 1;
|
2006-10-01 11:13:00 +00:00
|
|
|
|
|
|
|
HDAC_WRITE_2(&sc->mem, ch->off + HDAC_SDFMT, fmt);
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
|
|
|
|
dfmt = HDA_CMD_SET_DIGITAL_CONV_FMT1_DIGEN;
|
|
|
|
if (ch->fmt & AFMT_AC3)
|
|
|
|
dfmt |= HDA_CMD_SET_DIGITAL_CONV_FMT1_NAUDIO;
|
2006-10-01 11:13:00 +00:00
|
|
|
|
2007-11-21 11:39:27 +00:00
|
|
|
chn = 0;
|
2006-10-01 11:13:00 +00:00
|
|
|
for (i = 0; ch->io[i] != -1; i++) {
|
2007-11-21 11:39:27 +00:00
|
|
|
w = hdac_widget_get(ch->devinfo, ch->io[i]);
|
|
|
|
if (w == NULL)
|
|
|
|
continue;
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
|
|
|
|
if (as->hpredir >= 0 && i == as->pincnt)
|
|
|
|
chn = 0;
|
2008-09-16 20:03:34 +00:00
|
|
|
HDA_BOOTHVERBOSE(
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
device_printf(ch->pdevinfo->dev,
|
|
|
|
"PCMDIR_%s: Stream setup nid=%d: "
|
|
|
|
"fmt=0x%04x, dfmt=0x%04x\n",
|
2006-10-01 11:13:00 +00:00
|
|
|
(ch->dir == PCMDIR_PLAY) ? "PLAY" : "REC",
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
ch->io[i], fmt, dfmt);
|
2006-10-01 11:13:00 +00:00
|
|
|
);
|
|
|
|
hdac_command(sc,
|
|
|
|
HDA_CMD_SET_CONV_FMT(cad, ch->io[i], fmt), cad);
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
if (HDA_PARAM_AUDIO_WIDGET_CAP_DIGITAL(w->param.widget_cap)) {
|
2007-11-28 15:27:22 +00:00
|
|
|
hdac_command(sc,
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
HDA_CMD_SET_DIGITAL_CONV_FMT1(cad, ch->io[i], dfmt),
|
2007-11-28 15:27:22 +00:00
|
|
|
cad);
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
}
|
|
|
|
/* If HP redirection is enabled, but failed to use same
|
|
|
|
DAC make last DAC one to duplicate first one. */
|
|
|
|
if (as->hpredir >= 0 && i == as->pincnt) {
|
|
|
|
c = (ch->sid << 4);
|
|
|
|
} else if (chn >= totalchn) {
|
|
|
|
/* This is until OSS will support multichannel.
|
|
|
|
Should be: c = 0; to disable unused DAC */
|
|
|
|
c = (ch->sid << 4);
|
|
|
|
}else {
|
|
|
|
c = (ch->sid << 4) | chn;
|
|
|
|
}
|
|
|
|
hdac_command(sc,
|
|
|
|
HDA_CMD_SET_CONV_STREAM_CHAN(cad, ch->io[i], c), cad);
|
2007-11-21 11:39:27 +00:00
|
|
|
chn +=
|
|
|
|
HDA_PARAM_AUDIO_WIDGET_CAP_STEREO(w->param.widget_cap) ?
|
|
|
|
2 : 1;
|
2006-10-01 11:13:00 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static int
|
2007-03-16 17:18:17 +00:00
|
|
|
hdac_channel_setfragments(kobj_t obj, void *data,
|
|
|
|
uint32_t blksz, uint32_t blkcnt)
|
2006-10-01 11:13:00 +00:00
|
|
|
{
|
|
|
|
struct hdac_chan *ch = data;
|
Welcome to Once-a-year Sound Mega-Commit. Enjoy numerous updates and fixes
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.
2006-11-26 12:24:06 +00:00
|
|
|
struct hdac_softc *sc = ch->devinfo->codec->sc;
|
|
|
|
|
2007-03-16 17:18:17 +00:00
|
|
|
blksz &= HDA_BLK_ALIGN;
|
|
|
|
|
|
|
|
if (blksz > (sndbuf_getmaxsize(ch->b) / HDA_BDL_MIN))
|
|
|
|
blksz = sndbuf_getmaxsize(ch->b) / HDA_BDL_MIN;
|
|
|
|
if (blksz < HDA_BLK_MIN)
|
|
|
|
blksz = HDA_BLK_MIN;
|
|
|
|
if (blkcnt > HDA_BDL_MAX)
|
|
|
|
blkcnt = HDA_BDL_MAX;
|
|
|
|
if (blkcnt < HDA_BDL_MIN)
|
|
|
|
blkcnt = HDA_BDL_MIN;
|
|
|
|
|
|
|
|
while ((blksz * blkcnt) > sndbuf_getmaxsize(ch->b)) {
|
|
|
|
if ((blkcnt >> 1) >= HDA_BDL_MIN)
|
|
|
|
blkcnt >>= 1;
|
|
|
|
else if ((blksz >> 1) >= HDA_BLK_MIN)
|
|
|
|
blksz >>= 1;
|
|
|
|
else
|
|
|
|
break;
|
|
|
|
}
|
Welcome to Once-a-year Sound Mega-Commit. Enjoy numerous updates and fixes
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.
2006-11-26 12:24:06 +00:00
|
|
|
|
|
|
|
if ((sndbuf_getblksz(ch->b) != blksz ||
|
2007-03-16 17:18:17 +00:00
|
|
|
sndbuf_getblkcnt(ch->b) != blkcnt) &&
|
|
|
|
sndbuf_resize(ch->b, blkcnt, blksz) != 0)
|
Welcome to Once-a-year Sound Mega-Commit. Enjoy numerous updates and fixes
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.
2006-11-26 12:24:06 +00:00
|
|
|
device_printf(sc->dev, "%s: failed blksz=%u blkcnt=%u\n",
|
2007-03-16 17:18:17 +00:00
|
|
|
__func__, blksz, blkcnt);
|
Welcome to Once-a-year Sound Mega-Commit. Enjoy numerous updates and fixes
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.
2006-11-26 12:24:06 +00:00
|
|
|
|
|
|
|
ch->blksz = sndbuf_getblksz(ch->b);
|
2007-03-16 17:18:17 +00:00
|
|
|
ch->blkcnt = sndbuf_getblkcnt(ch->b);
|
|
|
|
|
|
|
|
return (1);
|
|
|
|
}
|
|
|
|
|
|
|
|
static int
|
|
|
|
hdac_channel_setblocksize(kobj_t obj, void *data, uint32_t blksz)
|
|
|
|
{
|
|
|
|
struct hdac_chan *ch = data;
|
|
|
|
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
hdac_channel_setfragments(obj, data, blksz, ch->pdevinfo->chan_blkcnt);
|
2006-10-01 11:13:00 +00:00
|
|
|
|
|
|
|
return (ch->blksz);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
hdac_channel_stop(struct hdac_softc *sc, struct hdac_chan *ch)
|
|
|
|
{
|
|
|
|
struct hdac_devinfo *devinfo = ch->devinfo;
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
struct hdac_widget *w;
|
2006-10-01 11:13:00 +00:00
|
|
|
nid_t cad = devinfo->codec->cad;
|
|
|
|
int i;
|
|
|
|
|
|
|
|
hdac_stream_stop(ch);
|
|
|
|
|
|
|
|
for (i = 0; ch->io[i] != -1; i++) {
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
w = hdac_widget_get(ch->devinfo, ch->io[i]);
|
|
|
|
if (w == NULL)
|
|
|
|
continue;
|
|
|
|
if (HDA_PARAM_AUDIO_WIDGET_CAP_DIGITAL(w->param.widget_cap)) {
|
|
|
|
hdac_command(sc,
|
|
|
|
HDA_CMD_SET_DIGITAL_CONV_FMT1(cad, ch->io[i], 0),
|
|
|
|
cad);
|
|
|
|
}
|
|
|
|
hdac_command(sc,
|
|
|
|
HDA_CMD_SET_CONV_STREAM_CHAN(cad, ch->io[i],
|
|
|
|
0), cad);
|
|
|
|
}
|
|
|
|
}
|
2006-10-01 11:13:00 +00:00
|
|
|
|
|
|
|
static void
|
|
|
|
hdac_channel_start(struct hdac_softc *sc, struct hdac_chan *ch)
|
|
|
|
{
|
|
|
|
ch->ptr = 0;
|
|
|
|
ch->prevptr = 0;
|
|
|
|
hdac_stream_stop(ch);
|
|
|
|
hdac_stream_reset(ch);
|
|
|
|
hdac_bdl_setup(ch);
|
|
|
|
hdac_stream_setid(ch);
|
|
|
|
hdac_stream_setup(ch);
|
|
|
|
hdac_stream_start(ch);
|
|
|
|
}
|
|
|
|
|
|
|
|
static int
|
|
|
|
hdac_channel_trigger(kobj_t obj, void *data, int go)
|
|
|
|
{
|
|
|
|
struct hdac_chan *ch = data;
|
|
|
|
struct hdac_softc *sc = ch->devinfo->codec->sc;
|
|
|
|
|
2007-06-11 00:49:46 +00:00
|
|
|
if (!PCMTRIG_COMMON(go))
|
|
|
|
return (0);
|
|
|
|
|
2006-10-01 11:13:00 +00:00
|
|
|
hdac_lock(sc);
|
|
|
|
switch (go) {
|
|
|
|
case PCMTRIG_START:
|
|
|
|
hdac_channel_start(sc, ch);
|
|
|
|
break;
|
|
|
|
case PCMTRIG_STOP:
|
|
|
|
case PCMTRIG_ABORT:
|
|
|
|
hdac_channel_stop(sc, ch);
|
|
|
|
break;
|
2007-03-15 17:35:04 +00:00
|
|
|
default:
|
|
|
|
break;
|
2006-10-01 11:13:00 +00:00
|
|
|
}
|
|
|
|
hdac_unlock(sc);
|
|
|
|
|
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
|
|
|
|
static int
|
|
|
|
hdac_channel_getptr(kobj_t obj, void *data)
|
|
|
|
{
|
|
|
|
struct hdac_chan *ch = data;
|
|
|
|
struct hdac_softc *sc = ch->devinfo->codec->sc;
|
|
|
|
uint32_t ptr;
|
|
|
|
|
|
|
|
hdac_lock(sc);
|
Welcome to Once-a-year Sound Mega-Commit. Enjoy numerous updates and fixes
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.
2006-11-26 12:24:06 +00:00
|
|
|
if (sc->polling != 0)
|
|
|
|
ptr = ch->ptr;
|
2007-05-05 09:17:36 +00:00
|
|
|
else if (ch->dmapos != NULL)
|
|
|
|
ptr = *(ch->dmapos);
|
Welcome to Once-a-year Sound Mega-Commit. Enjoy numerous updates and fixes
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.
2006-11-26 12:24:06 +00:00
|
|
|
else
|
|
|
|
ptr = HDAC_READ_4(&sc->mem, ch->off + HDAC_SDLPIB);
|
2006-10-01 11:13:00 +00:00
|
|
|
hdac_unlock(sc);
|
|
|
|
|
Welcome to Once-a-year Sound Mega-Commit. Enjoy numerous updates and fixes
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.
2006-11-26 12:24:06 +00:00
|
|
|
/*
|
|
|
|
* Round to available space and force 128 bytes aligment.
|
|
|
|
*/
|
|
|
|
ptr %= ch->blksz * ch->blkcnt;
|
2007-03-16 17:18:17 +00:00
|
|
|
ptr &= HDA_BLK_ALIGN;
|
2006-10-01 11:13:00 +00:00
|
|
|
|
|
|
|
return (ptr);
|
|
|
|
}
|
|
|
|
|
|
|
|
static struct pcmchan_caps *
|
|
|
|
hdac_channel_getcaps(kobj_t obj, void *data)
|
|
|
|
{
|
|
|
|
return (&((struct hdac_chan *)data)->caps);
|
|
|
|
}
|
|
|
|
|
|
|
|
static kobj_method_t hdac_channel_methods[] = {
|
|
|
|
KOBJMETHOD(channel_init, hdac_channel_init),
|
|
|
|
KOBJMETHOD(channel_setformat, hdac_channel_setformat),
|
|
|
|
KOBJMETHOD(channel_setspeed, hdac_channel_setspeed),
|
|
|
|
KOBJMETHOD(channel_setblocksize, hdac_channel_setblocksize),
|
2007-03-16 17:18:17 +00:00
|
|
|
KOBJMETHOD(channel_setfragments, hdac_channel_setfragments),
|
2006-10-01 11:13:00 +00:00
|
|
|
KOBJMETHOD(channel_trigger, hdac_channel_trigger),
|
|
|
|
KOBJMETHOD(channel_getptr, hdac_channel_getptr),
|
|
|
|
KOBJMETHOD(channel_getcaps, hdac_channel_getcaps),
|
|
|
|
{ 0, 0 }
|
|
|
|
};
|
|
|
|
CHANNEL_DECLARE(hdac_channel);
|
|
|
|
|
|
|
|
static int
|
|
|
|
hdac_audio_ctl_ossmixer_init(struct snd_mixer *m)
|
|
|
|
{
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
struct hdac_pcm_devinfo *pdevinfo = mix_getdevinfo(m);
|
|
|
|
struct hdac_devinfo *devinfo = pdevinfo->devinfo;
|
2006-10-01 11:13:00 +00:00
|
|
|
struct hdac_softc *sc = devinfo->codec->sc;
|
|
|
|
struct hdac_widget *w, *cw;
|
|
|
|
struct hdac_audio_ctl *ctl;
|
|
|
|
uint32_t mask, recmask, id;
|
|
|
|
int i, j, softpcmvol;
|
|
|
|
|
|
|
|
hdac_lock(sc);
|
|
|
|
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
/* Make sure that in case of soft volume it won't stay muted. */
|
|
|
|
for (i = 0; i < SOUND_MIXER_NRDEVICES; i++) {
|
|
|
|
pdevinfo->left[i] = 100;
|
|
|
|
pdevinfo->right[i] = 100;
|
|
|
|
}
|
|
|
|
|
2006-10-01 11:13:00 +00:00
|
|
|
mask = 0;
|
|
|
|
recmask = 0;
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
id = hdac_codec_id(devinfo->codec);
|
2006-10-01 11:13:00 +00:00
|
|
|
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
/* Declate EAPD as ogain control. */
|
|
|
|
if (pdevinfo->play >= 0) {
|
|
|
|
for (i = devinfo->startnode; i < devinfo->endnode; i++) {
|
|
|
|
w = hdac_widget_get(devinfo, i);
|
|
|
|
if (w == NULL || w->enable == 0)
|
|
|
|
continue;
|
|
|
|
if (w->type != HDA_PARAM_AUDIO_WIDGET_CAP_TYPE_PIN_COMPLEX ||
|
|
|
|
w->param.eapdbtl == HDAC_INVALID ||
|
|
|
|
w->bindas != sc->chans[pdevinfo->play].as)
|
2006-10-01 11:13:00 +00:00
|
|
|
continue;
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
mask |= SOUND_MASK_OGAIN;
|
|
|
|
break;
|
2006-10-01 11:13:00 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
/* Declare volume controls assigned to this association. */
|
2006-10-01 11:13:00 +00:00
|
|
|
i = 0;
|
|
|
|
ctl = NULL;
|
|
|
|
while ((ctl = hdac_audio_ctl_each(devinfo, &i)) != NULL) {
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
if (ctl->enable == 0)
|
2006-10-01 11:13:00 +00:00
|
|
|
continue;
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
if ((pdevinfo->play >= 0 &&
|
|
|
|
ctl->widget->bindas == sc->chans[pdevinfo->play].as) ||
|
|
|
|
(pdevinfo->rec >= 0 &&
|
|
|
|
ctl->widget->bindas == sc->chans[pdevinfo->rec].as) ||
|
|
|
|
(ctl->widget->bindas == -2 && pdevinfo->index == 0))
|
|
|
|
mask |= ctl->ossmask;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Declare record sources available to this association. */
|
|
|
|
if (pdevinfo->rec >= 0) {
|
|
|
|
struct hdac_chan *ch = &sc->chans[pdevinfo->rec];
|
|
|
|
for (i = 0; ch->io[i] != -1; i++) {
|
|
|
|
w = hdac_widget_get(devinfo, ch->io[i]);
|
|
|
|
if (w == NULL || w->enable == 0)
|
|
|
|
continue;
|
|
|
|
for (j = 0; j < w->nconns; j++) {
|
|
|
|
if (w->connsenable[j] == 0)
|
2006-10-01 11:13:00 +00:00
|
|
|
continue;
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
cw = hdac_widget_get(devinfo, w->conns[j]);
|
|
|
|
if (cw == NULL || cw->enable == 0)
|
2007-01-13 00:24:44 +00:00
|
|
|
continue;
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
if (cw->bindas != sc->chans[pdevinfo->rec].as &&
|
|
|
|
cw->bindas != -2)
|
2007-01-13 00:24:44 +00:00
|
|
|
continue;
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
recmask |= cw->ossmask;
|
2007-01-13 00:24:44 +00:00
|
|
|
}
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Declare soft PCM and master volume if needed. */
|
|
|
|
if (pdevinfo->play >= 0) {
|
|
|
|
ctl = NULL;
|
|
|
|
if ((mask & SOUND_MASK_PCM) == 0 ||
|
|
|
|
(devinfo->function.audio.quirks & HDA_QUIRK_SOFTPCMVOL)) {
|
|
|
|
softpcmvol = 1;
|
|
|
|
mask |= SOUND_MASK_PCM;
|
2006-10-01 11:13:00 +00:00
|
|
|
} else {
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
softpcmvol = 0;
|
|
|
|
i = 0;
|
|
|
|
while ((ctl = hdac_audio_ctl_each(devinfo, &i)) != NULL) {
|
|
|
|
if (ctl->enable == 0)
|
|
|
|
continue;
|
|
|
|
if (ctl->widget->bindas != sc->chans[pdevinfo->play].as &&
|
|
|
|
(ctl->widget->bindas != -2 || pdevinfo->index != 0))
|
2006-10-01 11:13:00 +00:00
|
|
|
continue;
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
if (!(ctl->ossmask & SOUND_MASK_PCM))
|
2006-10-01 11:13:00 +00:00
|
|
|
continue;
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
if (ctl->step > 0)
|
|
|
|
break;
|
2006-10-01 11:13:00 +00:00
|
|
|
}
|
|
|
|
}
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
|
|
|
|
if (softpcmvol == 1 || ctl == NULL) {
|
|
|
|
pcm_setflags(pdevinfo->dev, pcm_getflags(pdevinfo->dev) | SD_F_SOFTPCMVOL);
|
|
|
|
HDA_BOOTVERBOSE(
|
|
|
|
device_printf(pdevinfo->dev,
|
|
|
|
"%s Soft PCM volume\n",
|
|
|
|
(softpcmvol == 1) ? "Forcing" : "Enabling");
|
|
|
|
);
|
|
|
|
}
|
|
|
|
|
|
|
|
if ((mask & SOUND_MASK_VOLUME) == 0) {
|
|
|
|
mask |= SOUND_MASK_VOLUME;
|
|
|
|
mix_setparentchild(m, SOUND_MIXER_VOLUME,
|
|
|
|
SOUND_MASK_PCM);
|
|
|
|
mix_setrealdev(m, SOUND_MIXER_VOLUME,
|
|
|
|
SOUND_MIXER_NONE);
|
|
|
|
HDA_BOOTVERBOSE(
|
|
|
|
device_printf(pdevinfo->dev,
|
|
|
|
"Forcing master volume with PCM\n");
|
|
|
|
);
|
|
|
|
}
|
2006-10-01 11:13:00 +00:00
|
|
|
}
|
|
|
|
|
2007-05-05 09:17:36 +00:00
|
|
|
recmask &= (1 << SOUND_MIXER_NRDEVICES) - 1;
|
|
|
|
mask &= (1 << SOUND_MIXER_NRDEVICES) - 1;
|
2006-10-01 11:13:00 +00:00
|
|
|
|
|
|
|
mix_setrecdevs(m, recmask);
|
|
|
|
mix_setdevs(m, mask);
|
|
|
|
|
|
|
|
hdac_unlock(sc);
|
|
|
|
|
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
|
|
|
|
static int
|
|
|
|
hdac_audio_ctl_ossmixer_set(struct snd_mixer *m, unsigned dev,
|
|
|
|
unsigned left, unsigned right)
|
|
|
|
{
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
struct hdac_pcm_devinfo *pdevinfo = mix_getdevinfo(m);
|
|
|
|
struct hdac_devinfo *devinfo = pdevinfo->devinfo;
|
2006-10-01 11:13:00 +00:00
|
|
|
struct hdac_softc *sc = devinfo->codec->sc;
|
|
|
|
struct hdac_widget *w;
|
|
|
|
struct hdac_audio_ctl *ctl;
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
uint32_t mute;
|
|
|
|
int lvol, rvol;
|
|
|
|
int i, j;
|
2006-10-01 11:13:00 +00:00
|
|
|
|
|
|
|
hdac_lock(sc);
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
/* Save new values. */
|
|
|
|
pdevinfo->left[dev] = left;
|
|
|
|
pdevinfo->right[dev] = right;
|
|
|
|
|
|
|
|
/* 'ogain' is the special case implemented with EAPD. */
|
2006-10-01 11:13:00 +00:00
|
|
|
if (dev == SOUND_MIXER_OGAIN) {
|
2006-10-12 04:19:37 +00:00
|
|
|
uint32_t orig;
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
w = NULL;
|
|
|
|
for (i = devinfo->startnode; i < devinfo->endnode; i++) {
|
|
|
|
w = hdac_widget_get(devinfo, i);
|
|
|
|
if (w == NULL || w->enable == 0)
|
|
|
|
continue;
|
|
|
|
if (w->type != HDA_PARAM_AUDIO_WIDGET_CAP_TYPE_PIN_COMPLEX ||
|
|
|
|
w->param.eapdbtl == HDAC_INVALID)
|
|
|
|
continue;
|
|
|
|
break;
|
2006-10-01 11:13:00 +00:00
|
|
|
}
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
if (i >= devinfo->endnode) {
|
2006-10-01 11:13:00 +00:00
|
|
|
hdac_unlock(sc);
|
|
|
|
return (-1);
|
|
|
|
}
|
2006-10-12 04:19:37 +00:00
|
|
|
orig = w->param.eapdbtl;
|
2006-10-16 14:43:22 +00:00
|
|
|
if (left == 0)
|
2006-10-01 11:13:00 +00:00
|
|
|
w->param.eapdbtl &= ~HDA_CMD_SET_EAPD_BTL_ENABLE_EAPD;
|
|
|
|
else
|
|
|
|
w->param.eapdbtl |= HDA_CMD_SET_EAPD_BTL_ENABLE_EAPD;
|
2006-10-12 04:19:37 +00:00
|
|
|
if (orig != w->param.eapdbtl) {
|
2006-10-16 14:43:22 +00:00
|
|
|
uint32_t val;
|
|
|
|
|
|
|
|
val = w->param.eapdbtl;
|
|
|
|
if (devinfo->function.audio.quirks & HDA_QUIRK_EAPDINV)
|
|
|
|
val ^= HDA_CMD_SET_EAPD_BTL_ENABLE_EAPD;
|
2006-10-12 04:19:37 +00:00
|
|
|
hdac_command(sc,
|
|
|
|
HDA_CMD_SET_EAPD_BTL_ENABLE(devinfo->codec->cad,
|
2006-10-16 14:43:22 +00:00
|
|
|
w->nid, val), devinfo->codec->cad);
|
2006-10-12 04:19:37 +00:00
|
|
|
}
|
2006-10-01 11:13:00 +00:00
|
|
|
hdac_unlock(sc);
|
|
|
|
return (left | (left << 8));
|
|
|
|
}
|
|
|
|
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
/* Recalculate all controls related to this OSS device. */
|
2006-10-01 11:13:00 +00:00
|
|
|
i = 0;
|
|
|
|
while ((ctl = hdac_audio_ctl_each(devinfo, &i)) != NULL) {
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
if (ctl->enable == 0 ||
|
2006-10-01 11:13:00 +00:00
|
|
|
!(ctl->ossmask & (1 << dev)))
|
|
|
|
continue;
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
if (!((pdevinfo->play >= 0 &&
|
|
|
|
ctl->widget->bindas == sc->chans[pdevinfo->play].as) ||
|
|
|
|
(pdevinfo->rec >= 0 &&
|
|
|
|
ctl->widget->bindas == sc->chans[pdevinfo->rec].as) ||
|
|
|
|
ctl->widget->bindas == -2))
|
|
|
|
continue;
|
|
|
|
|
|
|
|
lvol = 100;
|
|
|
|
rvol = 100;
|
|
|
|
for (j = 0; j < SOUND_MIXER_NRDEVICES; j++) {
|
|
|
|
if (ctl->ossmask & (1 << j)) {
|
|
|
|
lvol = lvol * pdevinfo->left[j] / 100;
|
|
|
|
rvol = rvol * pdevinfo->right[j] / 100;
|
2006-10-01 11:13:00 +00:00
|
|
|
}
|
|
|
|
}
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
mute = (left == 0) ? HDA_AMP_MUTE_LEFT : 0;
|
|
|
|
mute |= (right == 0) ? HDA_AMP_MUTE_RIGHT : 0;
|
|
|
|
lvol = (lvol * ctl->step + 50) / 100;
|
|
|
|
rvol = (rvol * ctl->step + 50) / 100;
|
2006-10-01 11:13:00 +00:00
|
|
|
hdac_audio_ctl_amp_set(ctl, mute, lvol, rvol);
|
|
|
|
}
|
|
|
|
hdac_unlock(sc);
|
|
|
|
|
|
|
|
return (left | (right << 8));
|
|
|
|
}
|
|
|
|
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
/*
|
|
|
|
* Commutate specified record source.
|
|
|
|
*/
|
|
|
|
static uint32_t
|
|
|
|
hdac_audio_ctl_recsel_comm(struct hdac_pcm_devinfo *pdevinfo, uint32_t src, nid_t nid, int depth)
|
2006-10-01 11:13:00 +00:00
|
|
|
{
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
struct hdac_devinfo *devinfo = pdevinfo->devinfo;
|
2006-10-01 11:13:00 +00:00
|
|
|
struct hdac_widget *w, *cw;
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
struct hdac_audio_ctl *ctl;
|
|
|
|
char buf[64];
|
|
|
|
int i, muted;
|
|
|
|
uint32_t res = 0;
|
2006-10-01 11:13:00 +00:00
|
|
|
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
if (depth > HDA_PARSE_MAXDEPTH)
|
|
|
|
return (0);
|
|
|
|
|
|
|
|
w = hdac_widget_get(devinfo, nid);
|
|
|
|
if (w == NULL || w->enable == 0)
|
|
|
|
return (0);
|
|
|
|
|
|
|
|
for (i = 0; i < w->nconns; i++) {
|
|
|
|
if (w->connsenable[i] == 0)
|
|
|
|
continue;
|
|
|
|
cw = hdac_widget_get(devinfo, w->conns[i]);
|
|
|
|
if (cw == NULL || cw->enable == 0 || cw->bindas == -1)
|
|
|
|
continue;
|
|
|
|
/* Call recursively to trace signal to it's source if needed. */
|
|
|
|
if ((src & cw->ossmask) != 0) {
|
|
|
|
if (cw->ossdev < 0) {
|
|
|
|
res |= hdac_audio_ctl_recsel_comm(pdevinfo, src,
|
|
|
|
w->conns[i], depth + 1);
|
|
|
|
} else {
|
|
|
|
res |= cw->ossmask;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
/* We have two special cases: mixers and others (selectors). */
|
|
|
|
if (w->type == HDA_PARAM_AUDIO_WIDGET_CAP_TYPE_AUDIO_MIXER) {
|
|
|
|
ctl = hdac_audio_ctl_amp_get(devinfo,
|
|
|
|
w->nid, HDA_CTL_IN, i, 1);
|
|
|
|
if (ctl == NULL)
|
|
|
|
continue;
|
|
|
|
/* If we have input control on this node mute them
|
|
|
|
* according to requested sources. */
|
|
|
|
muted = (src & cw->ossmask) ? 0 : 1;
|
|
|
|
if (muted != ctl->forcemute) {
|
|
|
|
ctl->forcemute = muted;
|
|
|
|
hdac_audio_ctl_amp_set(ctl,
|
|
|
|
HDA_AMP_MUTE_DEFAULT,
|
|
|
|
HDA_AMP_VOL_DEFAULT, HDA_AMP_VOL_DEFAULT);
|
|
|
|
}
|
2008-09-16 20:03:34 +00:00
|
|
|
HDA_BOOTHVERBOSE(
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
device_printf(pdevinfo->dev,
|
|
|
|
"Recsel (%s): nid %d source %d %s\n",
|
|
|
|
hdac_audio_ctl_ossmixer_mask2allname(
|
|
|
|
src, buf, sizeof(buf)),
|
|
|
|
nid, i, muted?"mute":"unmute");
|
|
|
|
);
|
|
|
|
} else {
|
|
|
|
if (w->nconns == 1)
|
|
|
|
break;
|
|
|
|
if ((src & cw->ossmask) == 0)
|
|
|
|
continue;
|
|
|
|
/* If we found requested source - select it and exit. */
|
|
|
|
hdac_widget_connection_select(w, i);
|
2008-09-16 20:03:34 +00:00
|
|
|
HDA_BOOTHVERBOSE(
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
device_printf(pdevinfo->dev,
|
|
|
|
"Recsel (%s): nid %d source %d select\n",
|
|
|
|
hdac_audio_ctl_ossmixer_mask2allname(
|
|
|
|
src, buf, sizeof(buf)),
|
|
|
|
nid, i);
|
|
|
|
);
|
2006-10-01 11:13:00 +00:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
return (res);
|
|
|
|
}
|
|
|
|
|
|
|
|
static uint32_t
|
|
|
|
hdac_audio_ctl_ossmixer_setrecsrc(struct snd_mixer *m, uint32_t src)
|
|
|
|
{
|
|
|
|
struct hdac_pcm_devinfo *pdevinfo = mix_getdevinfo(m);
|
|
|
|
struct hdac_devinfo *devinfo = pdevinfo->devinfo;
|
|
|
|
struct hdac_widget *w;
|
|
|
|
struct hdac_softc *sc = devinfo->codec->sc;
|
|
|
|
struct hdac_chan *ch;
|
|
|
|
int i;
|
|
|
|
uint32_t ret = 0xffffffff;
|
2006-10-01 11:13:00 +00:00
|
|
|
|
|
|
|
hdac_lock(sc);
|
|
|
|
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
/* Commutate requested recsrc for each ADC. */
|
|
|
|
ch = &sc->chans[pdevinfo->rec];
|
|
|
|
for (i = 0; ch->io[i] != -1; i++) {
|
|
|
|
w = hdac_widget_get(devinfo, ch->io[i]);
|
2006-10-02 16:30:04 +00:00
|
|
|
if (w == NULL || w->enable == 0)
|
2006-10-01 11:13:00 +00:00
|
|
|
continue;
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
ret &= hdac_audio_ctl_recsel_comm(pdevinfo, src, ch->io[i], 0);
|
2006-10-01 11:13:00 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
hdac_unlock(sc);
|
|
|
|
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
return ((ret == 0xffffffff)? 0 : ret);
|
2006-10-01 11:13:00 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static kobj_method_t hdac_audio_ctl_ossmixer_methods[] = {
|
|
|
|
KOBJMETHOD(mixer_init, hdac_audio_ctl_ossmixer_init),
|
|
|
|
KOBJMETHOD(mixer_set, hdac_audio_ctl_ossmixer_set),
|
|
|
|
KOBJMETHOD(mixer_setrecsrc, hdac_audio_ctl_ossmixer_setrecsrc),
|
|
|
|
{ 0, 0 }
|
|
|
|
};
|
|
|
|
MIXER_DECLARE(hdac_audio_ctl_ossmixer);
|
|
|
|
|
2007-07-01 17:31:20 +00:00
|
|
|
static void
|
|
|
|
hdac_unsolq_task(void *context, int pending)
|
|
|
|
{
|
|
|
|
struct hdac_softc *sc;
|
|
|
|
|
|
|
|
sc = (struct hdac_softc *)context;
|
|
|
|
|
|
|
|
hdac_lock(sc);
|
|
|
|
hdac_unsolq_flush(sc);
|
|
|
|
hdac_unlock(sc);
|
|
|
|
}
|
|
|
|
|
2006-10-01 11:13:00 +00:00
|
|
|
/****************************************************************************
|
|
|
|
* int hdac_attach(device_t)
|
|
|
|
*
|
|
|
|
* Attach the device into the kernel. Interrupts usually won't be enabled
|
|
|
|
* when this function is called. Setup everything that doesn't require
|
|
|
|
* interrupts and defer probing of codecs until interrupts are enabled.
|
|
|
|
****************************************************************************/
|
|
|
|
static int
|
|
|
|
hdac_attach(device_t dev)
|
|
|
|
{
|
|
|
|
struct hdac_softc *sc;
|
|
|
|
int result;
|
2007-05-05 09:17:36 +00:00
|
|
|
int i;
|
|
|
|
uint16_t vendor;
|
|
|
|
uint8_t v;
|
2006-10-01 11:13:00 +00:00
|
|
|
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
device_printf(dev, "<HDA Driver Revision: %s>\n", HDA_DRV_TEST_REV);
|
|
|
|
|
|
|
|
sc = device_get_softc(dev);
|
- Fix wrong id for ALC882, add ALC883 id.
- 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"
2006-10-06 18:59:27 +00:00
|
|
|
sc->lock = snd_mtxcreate(device_get_nameunit(dev), HDAC_MTX_NAME);
|
2006-10-01 11:13:00 +00:00
|
|
|
sc->dev = dev;
|
2006-10-12 04:19:37 +00:00
|
|
|
sc->pci_subvendor = (uint32_t)pci_get_subdevice(sc->dev) << 16;
|
|
|
|
sc->pci_subvendor |= (uint32_t)pci_get_subvendor(sc->dev) & 0x0000ffff;
|
2007-05-05 09:17:36 +00:00
|
|
|
vendor = pci_get_vendor(dev);
|
2006-10-01 11:13:00 +00:00
|
|
|
|
2006-12-16 09:14:58 +00:00
|
|
|
if (sc->pci_subvendor == HP_NX6325_SUBVENDORX) {
|
|
|
|
/* Screw nx6325 - subdevice/subvendor swapped */
|
|
|
|
sc->pci_subvendor = HP_NX6325_SUBVENDOR;
|
|
|
|
}
|
|
|
|
|
Welcome to Once-a-year Sound Mega-Commit. Enjoy numerous updates and fixes
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.
2006-11-26 12:24:06 +00:00
|
|
|
callout_init(&sc->poll_hda, CALLOUT_MPSAFE);
|
|
|
|
callout_init(&sc->poll_hdac, CALLOUT_MPSAFE);
|
2007-05-05 09:17:36 +00:00
|
|
|
callout_init(&sc->poll_jack, CALLOUT_MPSAFE);
|
Welcome to Once-a-year Sound Mega-Commit. Enjoy numerous updates and fixes
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.
2006-11-26 12:24:06 +00:00
|
|
|
|
2007-07-01 17:31:20 +00:00
|
|
|
TASK_INIT(&sc->unsolq_task, 0, hdac_unsolq_task, sc);
|
|
|
|
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
sc->poll_ticks = 1000000;
|
2007-05-05 09:17:36 +00:00
|
|
|
sc->poll_ival = HDAC_POLL_INTERVAL;
|
|
|
|
if (resource_int_value(device_get_name(dev),
|
|
|
|
device_get_unit(dev), "polling", &i) == 0 && i != 0)
|
Welcome to Once-a-year Sound Mega-Commit. Enjoy numerous updates and fixes
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.
2006-11-26 12:24:06 +00:00
|
|
|
sc->polling = 1;
|
|
|
|
else
|
|
|
|
sc->polling = 0;
|
|
|
|
|
2006-10-01 11:13:00 +00:00
|
|
|
result = bus_dma_tag_create(NULL, /* parent */
|
|
|
|
HDAC_DMA_ALIGNMENT, /* alignment */
|
|
|
|
0, /* boundary */
|
|
|
|
BUS_SPACE_MAXADDR_32BIT, /* lowaddr */
|
|
|
|
BUS_SPACE_MAXADDR, /* highaddr */
|
|
|
|
NULL, /* filtfunc */
|
|
|
|
NULL, /* fistfuncarg */
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
HDA_BUFSZ_MAX, /* maxsize */
|
2006-10-01 11:13:00 +00:00
|
|
|
1, /* nsegments */
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
HDA_BUFSZ_MAX, /* maxsegsz */
|
2006-10-01 11:13:00 +00:00
|
|
|
0, /* flags */
|
|
|
|
NULL, /* lockfunc */
|
|
|
|
NULL, /* lockfuncarg */
|
|
|
|
&sc->chan_dmat); /* dmat */
|
|
|
|
if (result != 0) {
|
2007-05-05 09:17:36 +00:00
|
|
|
device_printf(dev, "%s: bus_dma_tag_create failed (%x)\n",
|
2006-10-01 11:13:00 +00:00
|
|
|
__func__, result);
|
- Fix wrong id for ALC882, add ALC883 id.
- 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"
2006-10-06 18:59:27 +00:00
|
|
|
snd_mtxfree(sc->lock);
|
2006-10-01 11:13:00 +00:00
|
|
|
free(sc, M_DEVBUF);
|
|
|
|
return (ENXIO);
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
sc->hdabus = NULL;
|
|
|
|
for (i = 0; i < HDAC_CODEC_MAX; i++)
|
|
|
|
sc->codecs[i] = NULL;
|
|
|
|
|
|
|
|
pci_enable_busmaster(dev);
|
|
|
|
|
2007-05-05 09:17:36 +00:00
|
|
|
if (vendor == INTEL_VENDORID) {
|
|
|
|
/* TCSEL -> TC0 */
|
|
|
|
v = pci_read_config(dev, 0x44, 1);
|
|
|
|
pci_write_config(dev, 0x44, v & 0xf8, 1);
|
2008-09-16 20:03:34 +00:00
|
|
|
HDA_BOOTHVERBOSE(
|
2007-05-05 09:17:36 +00:00
|
|
|
device_printf(dev, "TCSEL: 0x%02d -> 0x%02d\n", v,
|
|
|
|
pci_read_config(dev, 0x44, 1));
|
|
|
|
);
|
|
|
|
}
|
|
|
|
|
2008-04-12 15:07:32 +00:00
|
|
|
#ifdef HDAC_MSI_ENABLED
|
2007-07-09 20:42:11 +00:00
|
|
|
if (resource_int_value(device_get_name(dev),
|
|
|
|
device_get_unit(dev), "msi", &i) == 0 && i != 0 &&
|
|
|
|
pci_msi_count(dev) == 1)
|
|
|
|
sc->flags |= HDAC_F_MSI;
|
|
|
|
else
|
|
|
|
#endif
|
|
|
|
sc->flags &= ~HDAC_F_MSI;
|
|
|
|
|
2007-05-05 09:17:36 +00:00
|
|
|
#if defined(__i386__) || defined(__amd64__)
|
2007-07-09 20:42:11 +00:00
|
|
|
sc->flags |= HDAC_F_DMA_NOCACHE;
|
2007-05-05 09:17:36 +00:00
|
|
|
|
|
|
|
if (resource_int_value(device_get_name(dev),
|
|
|
|
device_get_unit(dev), "snoop", &i) == 0 && i != 0) {
|
|
|
|
#else
|
2007-07-09 20:42:11 +00:00
|
|
|
sc->flags &= ~HDAC_F_DMA_NOCACHE;
|
2007-05-05 09:17:36 +00:00
|
|
|
#endif
|
|
|
|
/*
|
|
|
|
* Try to enable PCIe snoop to avoid messing around with
|
|
|
|
* uncacheable DMA attribute. Since PCIe snoop register
|
|
|
|
* config is pretty much vendor specific, there are no
|
|
|
|
* general solutions on how to enable it, forcing us (even
|
|
|
|
* Microsoft) to enable uncacheable or write combined DMA
|
|
|
|
* by default.
|
|
|
|
*
|
|
|
|
* http://msdn2.microsoft.com/en-us/library/ms790324.aspx
|
|
|
|
*/
|
|
|
|
for (i = 0; i < HDAC_PCIESNOOP_LEN; i++) {
|
|
|
|
if (hdac_pcie_snoop[i].vendor != vendor)
|
|
|
|
continue;
|
2007-07-09 20:42:11 +00:00
|
|
|
sc->flags &= ~HDAC_F_DMA_NOCACHE;
|
2007-05-05 09:17:36 +00:00
|
|
|
if (hdac_pcie_snoop[i].reg == 0x00)
|
|
|
|
break;
|
|
|
|
v = pci_read_config(dev, hdac_pcie_snoop[i].reg, 1);
|
|
|
|
if ((v & hdac_pcie_snoop[i].enable) ==
|
|
|
|
hdac_pcie_snoop[i].enable)
|
|
|
|
break;
|
|
|
|
v &= hdac_pcie_snoop[i].mask;
|
|
|
|
v |= hdac_pcie_snoop[i].enable;
|
|
|
|
pci_write_config(dev, hdac_pcie_snoop[i].reg, v, 1);
|
|
|
|
v = pci_read_config(dev, hdac_pcie_snoop[i].reg, 1);
|
|
|
|
if ((v & hdac_pcie_snoop[i].enable) !=
|
|
|
|
hdac_pcie_snoop[i].enable) {
|
|
|
|
HDA_BOOTVERBOSE(
|
|
|
|
device_printf(dev,
|
|
|
|
"WARNING: Failed to enable PCIe "
|
|
|
|
"snoop!\n");
|
|
|
|
);
|
|
|
|
#if defined(__i386__) || defined(__amd64__)
|
2007-07-09 20:42:11 +00:00
|
|
|
sc->flags |= HDAC_F_DMA_NOCACHE;
|
2007-05-05 09:17:36 +00:00
|
|
|
#endif
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
#if defined(__i386__) || defined(__amd64__)
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
2008-09-16 20:03:34 +00:00
|
|
|
HDA_BOOTHVERBOSE(
|
2007-05-05 09:17:36 +00:00
|
|
|
device_printf(dev, "DMA Coherency: %s / vendor=0x%04x\n",
|
2007-07-09 20:42:11 +00:00
|
|
|
(sc->flags & HDAC_F_DMA_NOCACHE) ?
|
|
|
|
"Uncacheable" : "PCIe snoop", vendor);
|
2007-05-05 09:17:36 +00:00
|
|
|
);
|
|
|
|
|
2006-10-01 11:13:00 +00:00
|
|
|
/* Allocate resources */
|
|
|
|
result = hdac_mem_alloc(sc);
|
|
|
|
if (result != 0)
|
- Fix wrong id for ALC882, add ALC883 id.
- 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"
2006-10-06 18:59:27 +00:00
|
|
|
goto hdac_attach_fail;
|
2006-10-01 11:13:00 +00:00
|
|
|
result = hdac_irq_alloc(sc);
|
|
|
|
if (result != 0)
|
- Fix wrong id for ALC882, add ALC883 id.
- 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"
2006-10-06 18:59:27 +00:00
|
|
|
goto hdac_attach_fail;
|
2006-10-01 11:13:00 +00:00
|
|
|
|
|
|
|
/* Get Capabilities */
|
|
|
|
result = hdac_get_capabilities(sc);
|
|
|
|
if (result != 0)
|
- Fix wrong id for ALC882, add ALC883 id.
- 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"
2006-10-06 18:59:27 +00:00
|
|
|
goto hdac_attach_fail;
|
2006-10-01 11:13:00 +00:00
|
|
|
|
|
|
|
/* Allocate CORB and RIRB dma memory */
|
|
|
|
result = hdac_dma_alloc(sc, &sc->corb_dma,
|
|
|
|
sc->corb_size * sizeof(uint32_t));
|
|
|
|
if (result != 0)
|
- Fix wrong id for ALC882, add ALC883 id.
- 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"
2006-10-06 18:59:27 +00:00
|
|
|
goto hdac_attach_fail;
|
2006-10-01 11:13:00 +00:00
|
|
|
result = hdac_dma_alloc(sc, &sc->rirb_dma,
|
|
|
|
sc->rirb_size * sizeof(struct hdac_rirb));
|
|
|
|
if (result != 0)
|
- Fix wrong id for ALC882, add ALC883 id.
- 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"
2006-10-06 18:59:27 +00:00
|
|
|
goto hdac_attach_fail;
|
2006-10-01 11:13:00 +00:00
|
|
|
|
|
|
|
/* Quiesce everything */
|
2008-09-16 20:03:34 +00:00
|
|
|
HDA_BOOTHVERBOSE(
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
device_printf(dev, "Reset controller...\n");
|
|
|
|
);
|
|
|
|
hdac_reset(sc, 1);
|
2006-10-01 11:13:00 +00:00
|
|
|
|
|
|
|
/* Initialize the CORB and RIRB */
|
|
|
|
hdac_corb_init(sc);
|
|
|
|
hdac_rirb_init(sc);
|
|
|
|
|
|
|
|
/* Defer remaining of initialization until interrupts are enabled */
|
|
|
|
sc->intrhook.ich_func = hdac_attach2;
|
|
|
|
sc->intrhook.ich_arg = (void *)sc;
|
|
|
|
if (cold == 0 || config_intrhook_establish(&sc->intrhook) != 0) {
|
|
|
|
sc->intrhook.ich_func = NULL;
|
|
|
|
hdac_attach2((void *)sc);
|
|
|
|
}
|
|
|
|
|
- Fix wrong id for ALC882, add ALC883 id.
- 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"
2006-10-06 18:59:27 +00:00
|
|
|
return (0);
|
2006-10-01 11:13:00 +00:00
|
|
|
|
- Fix wrong id for ALC882, add ALC883 id.
- 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"
2006-10-06 18:59:27 +00:00
|
|
|
hdac_attach_fail:
|
2006-10-01 11:13:00 +00:00
|
|
|
hdac_irq_free(sc);
|
2007-05-05 09:17:36 +00:00
|
|
|
hdac_dma_free(sc, &sc->rirb_dma);
|
|
|
|
hdac_dma_free(sc, &sc->corb_dma);
|
2006-10-01 11:13:00 +00:00
|
|
|
hdac_mem_free(sc);
|
|
|
|
snd_mtxfree(sc->lock);
|
- Fix wrong id for ALC882, add ALC883 id.
- 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"
2006-10-06 18:59:27 +00:00
|
|
|
free(sc, M_DEVBUF);
|
2006-10-01 11:13:00 +00:00
|
|
|
|
- Fix wrong id for ALC882, add ALC883 id.
- 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"
2006-10-06 18:59:27 +00:00
|
|
|
return (ENXIO);
|
2006-10-01 11:13:00 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
hdac_audio_parse(struct hdac_devinfo *devinfo)
|
|
|
|
{
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
struct hdac_codec *codec = devinfo->codec;
|
|
|
|
struct hdac_softc *sc = codec->sc;
|
2006-10-01 11:13:00 +00:00
|
|
|
struct hdac_widget *w;
|
|
|
|
uint32_t res;
|
|
|
|
int i;
|
|
|
|
nid_t cad, nid;
|
|
|
|
|
|
|
|
cad = devinfo->codec->cad;
|
|
|
|
nid = devinfo->nid;
|
|
|
|
|
2007-05-05 09:17:36 +00:00
|
|
|
res = hdac_command(sc,
|
|
|
|
HDA_CMD_GET_PARAMETER(cad , nid, HDA_PARAM_GPIO_COUNT), cad);
|
|
|
|
devinfo->function.audio.gpio = res;
|
|
|
|
|
- Fix wrong id for ALC882, add ALC883 id.
- 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"
2006-10-06 18:59:27 +00:00
|
|
|
HDA_BOOTVERBOSE(
|
2008-09-16 20:03:34 +00:00
|
|
|
device_printf(sc->dev, "GPIO: 0x%08x "
|
|
|
|
"NumGPIO=%d NumGPO=%d "
|
2007-05-05 09:17:36 +00:00
|
|
|
"NumGPI=%d GPIWake=%d GPIUnsol=%d\n",
|
2008-09-16 20:03:34 +00:00
|
|
|
devinfo->function.audio.gpio,
|
2007-05-05 09:17:36 +00:00
|
|
|
HDA_PARAM_GPIO_COUNT_NUM_GPIO(devinfo->function.audio.gpio),
|
|
|
|
HDA_PARAM_GPIO_COUNT_NUM_GPO(devinfo->function.audio.gpio),
|
|
|
|
HDA_PARAM_GPIO_COUNT_NUM_GPI(devinfo->function.audio.gpio),
|
|
|
|
HDA_PARAM_GPIO_COUNT_GPI_WAKE(devinfo->function.audio.gpio),
|
|
|
|
HDA_PARAM_GPIO_COUNT_GPI_UNSOL(devinfo->function.audio.gpio));
|
2006-10-01 11:13:00 +00:00
|
|
|
);
|
|
|
|
|
|
|
|
res = hdac_command(sc,
|
|
|
|
HDA_CMD_GET_PARAMETER(cad, nid, HDA_PARAM_SUPP_STREAM_FORMATS),
|
|
|
|
cad);
|
|
|
|
devinfo->function.audio.supp_stream_formats = res;
|
|
|
|
|
|
|
|
res = hdac_command(sc,
|
|
|
|
HDA_CMD_GET_PARAMETER(cad, nid, HDA_PARAM_SUPP_PCM_SIZE_RATE),
|
|
|
|
cad);
|
|
|
|
devinfo->function.audio.supp_pcm_size_rate = res;
|
|
|
|
|
|
|
|
res = hdac_command(sc,
|
|
|
|
HDA_CMD_GET_PARAMETER(cad, nid, HDA_PARAM_OUTPUT_AMP_CAP),
|
|
|
|
cad);
|
|
|
|
devinfo->function.audio.outamp_cap = res;
|
|
|
|
|
|
|
|
res = hdac_command(sc,
|
|
|
|
HDA_CMD_GET_PARAMETER(cad, nid, HDA_PARAM_INPUT_AMP_CAP),
|
|
|
|
cad);
|
|
|
|
devinfo->function.audio.inamp_cap = res;
|
|
|
|
|
|
|
|
for (i = devinfo->startnode; i < devinfo->endnode; i++) {
|
|
|
|
w = hdac_widget_get(devinfo, i);
|
|
|
|
if (w == NULL)
|
|
|
|
device_printf(sc->dev, "Ghost widget! nid=%d!\n", i);
|
|
|
|
else {
|
|
|
|
w->devinfo = devinfo;
|
|
|
|
w->nid = i;
|
|
|
|
w->enable = 1;
|
|
|
|
w->selconn = -1;
|
|
|
|
w->pflags = 0;
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
w->ossdev = -1;
|
|
|
|
w->bindas = -1;
|
2006-10-02 16:30:04 +00:00
|
|
|
w->param.eapdbtl = HDAC_INVALID;
|
2006-10-01 11:13:00 +00:00
|
|
|
hdac_widget_parse(w);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
hdac_audio_ctl_parse(struct hdac_devinfo *devinfo)
|
|
|
|
{
|
|
|
|
struct hdac_softc *sc = devinfo->codec->sc;
|
|
|
|
struct hdac_audio_ctl *ctls;
|
|
|
|
struct hdac_widget *w, *cw;
|
|
|
|
int i, j, cnt, max, ocap, icap;
|
- Fix wrong id for ALC882, add ALC883 id.
- 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"
2006-10-06 18:59:27 +00:00
|
|
|
int mute, offset, step, size;
|
2006-10-01 11:13:00 +00:00
|
|
|
|
|
|
|
/* XXX This is redundant */
|
|
|
|
max = 0;
|
|
|
|
for (i = devinfo->startnode; i < devinfo->endnode; i++) {
|
|
|
|
w = hdac_widget_get(devinfo, i);
|
|
|
|
if (w == NULL || w->enable == 0)
|
|
|
|
continue;
|
|
|
|
if (w->param.outamp_cap != 0)
|
|
|
|
max++;
|
|
|
|
if (w->param.inamp_cap != 0) {
|
|
|
|
switch (w->type) {
|
|
|
|
case HDA_PARAM_AUDIO_WIDGET_CAP_TYPE_AUDIO_SELECTOR:
|
|
|
|
case HDA_PARAM_AUDIO_WIDGET_CAP_TYPE_AUDIO_MIXER:
|
|
|
|
for (j = 0; j < w->nconns; j++) {
|
|
|
|
cw = hdac_widget_get(devinfo,
|
|
|
|
w->conns[j]);
|
|
|
|
if (cw == NULL || cw->enable == 0)
|
|
|
|
continue;
|
|
|
|
max++;
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
max++;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
devinfo->function.audio.ctlcnt = max;
|
|
|
|
|
|
|
|
if (max < 1)
|
|
|
|
return;
|
|
|
|
|
|
|
|
ctls = (struct hdac_audio_ctl *)malloc(
|
|
|
|
sizeof(*ctls) * max, M_HDAC, M_ZERO | M_NOWAIT);
|
|
|
|
|
|
|
|
if (ctls == NULL) {
|
|
|
|
/* Blekh! */
|
|
|
|
device_printf(sc->dev, "unable to allocate ctls!\n");
|
|
|
|
devinfo->function.audio.ctlcnt = 0;
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
cnt = 0;
|
|
|
|
for (i = devinfo->startnode; cnt < max && i < devinfo->endnode; i++) {
|
|
|
|
if (cnt >= max) {
|
|
|
|
device_printf(sc->dev, "%s: Ctl overflow!\n",
|
|
|
|
__func__);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
w = hdac_widget_get(devinfo, i);
|
|
|
|
if (w == NULL || w->enable == 0)
|
|
|
|
continue;
|
|
|
|
ocap = w->param.outamp_cap;
|
|
|
|
icap = w->param.inamp_cap;
|
|
|
|
if (ocap != 0) {
|
- Fix wrong id for ALC882, add ALC883 id.
- 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"
2006-10-06 18:59:27 +00:00
|
|
|
mute = HDA_PARAM_OUTPUT_AMP_CAP_MUTE_CAP(ocap);
|
|
|
|
step = HDA_PARAM_OUTPUT_AMP_CAP_NUMSTEPS(ocap);
|
|
|
|
size = HDA_PARAM_OUTPUT_AMP_CAP_STEPSIZE(ocap);
|
|
|
|
offset = HDA_PARAM_OUTPUT_AMP_CAP_OFFSET(ocap);
|
|
|
|
/*if (offset > step) {
|
|
|
|
HDA_BOOTVERBOSE(
|
|
|
|
device_printf(sc->dev,
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
"BUGGY outamp: nid=%d "
|
- Fix wrong id for ALC882, add ALC883 id.
- 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"
2006-10-06 18:59:27 +00:00
|
|
|
"[offset=%d > step=%d]\n",
|
|
|
|
w->nid, offset, step);
|
|
|
|
);
|
|
|
|
offset = step;
|
|
|
|
}*/
|
2006-10-01 11:13:00 +00:00
|
|
|
ctls[cnt].enable = 1;
|
|
|
|
ctls[cnt].widget = w;
|
- Fix wrong id for ALC882, add ALC883 id.
- 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"
2006-10-06 18:59:27 +00:00
|
|
|
ctls[cnt].mute = mute;
|
|
|
|
ctls[cnt].step = step;
|
|
|
|
ctls[cnt].size = size;
|
|
|
|
ctls[cnt].offset = offset;
|
|
|
|
ctls[cnt].left = offset;
|
|
|
|
ctls[cnt].right = offset;
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
if (w->type == HDA_PARAM_AUDIO_WIDGET_CAP_TYPE_PIN_COMPLEX ||
|
|
|
|
w->waspin)
|
|
|
|
ctls[cnt].ndir = HDA_CTL_IN;
|
|
|
|
else
|
|
|
|
ctls[cnt].ndir = HDA_CTL_OUT;
|
2006-10-01 11:13:00 +00:00
|
|
|
ctls[cnt++].dir = HDA_CTL_OUT;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (icap != 0) {
|
- Fix wrong id for ALC882, add ALC883 id.
- 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"
2006-10-06 18:59:27 +00:00
|
|
|
mute = HDA_PARAM_OUTPUT_AMP_CAP_MUTE_CAP(icap);
|
|
|
|
step = HDA_PARAM_OUTPUT_AMP_CAP_NUMSTEPS(icap);
|
|
|
|
size = HDA_PARAM_OUTPUT_AMP_CAP_STEPSIZE(icap);
|
|
|
|
offset = HDA_PARAM_OUTPUT_AMP_CAP_OFFSET(icap);
|
|
|
|
/*if (offset > step) {
|
|
|
|
HDA_BOOTVERBOSE(
|
|
|
|
device_printf(sc->dev,
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
"BUGGY inamp: nid=%d "
|
- Fix wrong id for ALC882, add ALC883 id.
- 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"
2006-10-06 18:59:27 +00:00
|
|
|
"[offset=%d > step=%d]\n",
|
|
|
|
w->nid, offset, step);
|
|
|
|
);
|
|
|
|
offset = step;
|
|
|
|
}*/
|
2006-10-01 11:13:00 +00:00
|
|
|
switch (w->type) {
|
|
|
|
case HDA_PARAM_AUDIO_WIDGET_CAP_TYPE_AUDIO_SELECTOR:
|
|
|
|
case HDA_PARAM_AUDIO_WIDGET_CAP_TYPE_AUDIO_MIXER:
|
|
|
|
for (j = 0; j < w->nconns; j++) {
|
|
|
|
if (cnt >= max) {
|
|
|
|
device_printf(sc->dev,
|
|
|
|
"%s: Ctl overflow!\n",
|
|
|
|
__func__);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
cw = hdac_widget_get(devinfo,
|
|
|
|
w->conns[j]);
|
|
|
|
if (cw == NULL || cw->enable == 0)
|
|
|
|
continue;
|
|
|
|
ctls[cnt].enable = 1;
|
|
|
|
ctls[cnt].widget = w;
|
|
|
|
ctls[cnt].childwidget = cw;
|
|
|
|
ctls[cnt].index = j;
|
- Fix wrong id for ALC882, add ALC883 id.
- 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"
2006-10-06 18:59:27 +00:00
|
|
|
ctls[cnt].mute = mute;
|
|
|
|
ctls[cnt].step = step;
|
|
|
|
ctls[cnt].size = size;
|
|
|
|
ctls[cnt].offset = offset;
|
|
|
|
ctls[cnt].left = offset;
|
|
|
|
ctls[cnt].right = offset;
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
ctls[cnt].ndir = HDA_CTL_IN;
|
2006-10-01 11:13:00 +00:00
|
|
|
ctls[cnt++].dir = HDA_CTL_IN;
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
if (cnt >= max) {
|
|
|
|
device_printf(sc->dev,
|
|
|
|
"%s: Ctl overflow!\n",
|
|
|
|
__func__);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
ctls[cnt].enable = 1;
|
|
|
|
ctls[cnt].widget = w;
|
- Fix wrong id for ALC882, add ALC883 id.
- 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"
2006-10-06 18:59:27 +00:00
|
|
|
ctls[cnt].mute = mute;
|
|
|
|
ctls[cnt].step = step;
|
|
|
|
ctls[cnt].size = size;
|
|
|
|
ctls[cnt].offset = offset;
|
|
|
|
ctls[cnt].left = offset;
|
|
|
|
ctls[cnt].right = offset;
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
if (w->type ==
|
|
|
|
HDA_PARAM_AUDIO_WIDGET_CAP_TYPE_PIN_COMPLEX)
|
|
|
|
ctls[cnt].ndir = HDA_CTL_OUT;
|
|
|
|
else
|
|
|
|
ctls[cnt].ndir = HDA_CTL_IN;
|
2006-10-01 11:13:00 +00:00
|
|
|
ctls[cnt++].dir = HDA_CTL_IN;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
devinfo->function.audio.ctl = ctls;
|
|
|
|
}
|
|
|
|
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
static void
|
|
|
|
hdac_audio_as_parse(struct hdac_devinfo *devinfo)
|
|
|
|
{
|
|
|
|
struct hdac_softc *sc = devinfo->codec->sc;
|
|
|
|
struct hdac_audio_as *as;
|
|
|
|
struct hdac_widget *w;
|
|
|
|
int i, j, cnt, max, type, dir, assoc, seq, first, hpredir;
|
|
|
|
|
|
|
|
/* XXX This is redundant */
|
|
|
|
max = 0;
|
|
|
|
for (j = 0; j < 16; j++) {
|
|
|
|
for (i = devinfo->startnode; i < devinfo->endnode; i++) {
|
|
|
|
w = hdac_widget_get(devinfo, i);
|
|
|
|
if (w == NULL || w->enable == 0)
|
|
|
|
continue;
|
|
|
|
if (w->type != HDA_PARAM_AUDIO_WIDGET_CAP_TYPE_PIN_COMPLEX)
|
|
|
|
continue;
|
|
|
|
if (HDA_CONFIG_DEFAULTCONF_ASSOCIATION(w->wclass.pin.config)
|
|
|
|
!= j)
|
|
|
|
continue;
|
|
|
|
max++;
|
|
|
|
if (j != 15) /* There could be many 1-pin assocs #15 */
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
devinfo->function.audio.ascnt = max;
|
|
|
|
|
|
|
|
if (max < 1)
|
|
|
|
return;
|
|
|
|
|
|
|
|
as = (struct hdac_audio_as *)malloc(
|
|
|
|
sizeof(*as) * max, M_HDAC, M_ZERO | M_NOWAIT);
|
|
|
|
|
|
|
|
if (as == NULL) {
|
|
|
|
/* Blekh! */
|
|
|
|
device_printf(sc->dev, "unable to allocate assocs!\n");
|
|
|
|
devinfo->function.audio.ascnt = 0;
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
for (i = 0; i < max; i++) {
|
|
|
|
as[i].hpredir = -1;
|
|
|
|
as[i].chan = -1;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Scan associations skipping as=0. */
|
|
|
|
cnt = 0;
|
|
|
|
for (j = 1; j < 16; j++) {
|
|
|
|
first = 16;
|
|
|
|
hpredir = 0;
|
|
|
|
for (i = devinfo->startnode; i < devinfo->endnode; i++) {
|
|
|
|
w = hdac_widget_get(devinfo, i);
|
|
|
|
if (w == NULL || w->enable == 0)
|
|
|
|
continue;
|
|
|
|
if (w->type != HDA_PARAM_AUDIO_WIDGET_CAP_TYPE_PIN_COMPLEX)
|
|
|
|
continue;
|
|
|
|
assoc = HDA_CONFIG_DEFAULTCONF_ASSOCIATION(w->wclass.pin.config);
|
|
|
|
seq = HDA_CONFIG_DEFAULTCONF_SEQUENCE(w->wclass.pin.config);
|
|
|
|
if (assoc != j) {
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
KASSERT(cnt < max,
|
|
|
|
("%s: Associations owerflow (%d of %d)",
|
|
|
|
__func__, cnt, max));
|
|
|
|
type = w->wclass.pin.config &
|
|
|
|
HDA_CONFIG_DEFAULTCONF_DEVICE_MASK;
|
|
|
|
/* Get pin direction. */
|
|
|
|
if (type == HDA_CONFIG_DEFAULTCONF_DEVICE_LINE_OUT ||
|
|
|
|
type == HDA_CONFIG_DEFAULTCONF_DEVICE_SPEAKER ||
|
|
|
|
type == HDA_CONFIG_DEFAULTCONF_DEVICE_HP_OUT ||
|
|
|
|
type == HDA_CONFIG_DEFAULTCONF_DEVICE_SPDIF_OUT ||
|
|
|
|
type == HDA_CONFIG_DEFAULTCONF_DEVICE_DIGITAL_OTHER_OUT)
|
|
|
|
dir = HDA_CTL_OUT;
|
|
|
|
else
|
|
|
|
dir = HDA_CTL_IN;
|
|
|
|
/* If this is a first pin - create new association. */
|
|
|
|
if (as[cnt].pincnt == 0) {
|
|
|
|
as[cnt].enable = 1;
|
|
|
|
as[cnt].index = j;
|
|
|
|
as[cnt].dir = dir;
|
|
|
|
}
|
|
|
|
if (seq < first)
|
|
|
|
first = seq;
|
|
|
|
/* Check association correctness. */
|
|
|
|
if (as[cnt].pins[seq] != 0) {
|
|
|
|
device_printf(sc->dev, "%s: Duplicate pin %d (%d) "
|
|
|
|
"in association %d! Disabling association.\n",
|
|
|
|
__func__, seq, w->nid, j);
|
|
|
|
as[cnt].enable = 0;
|
|
|
|
}
|
|
|
|
if (dir != as[cnt].dir) {
|
|
|
|
device_printf(sc->dev, "%s: Pin %d has wrong "
|
|
|
|
"direction for association %d! Disabling "
|
|
|
|
"association.\n",
|
|
|
|
__func__, w->nid, j);
|
|
|
|
as[cnt].enable = 0;
|
|
|
|
}
|
|
|
|
/* Headphones with seq=15 may mean redirection. */
|
|
|
|
if (type == HDA_CONFIG_DEFAULTCONF_DEVICE_HP_OUT &&
|
|
|
|
seq == 15)
|
|
|
|
hpredir = 1;
|
|
|
|
as[cnt].pins[seq] = w->nid;
|
|
|
|
as[cnt].pincnt++;
|
|
|
|
/* Association 15 is a multiple unassociated pins. */
|
|
|
|
if (j == 15)
|
|
|
|
cnt++;
|
|
|
|
}
|
|
|
|
if (j != 15 && as[cnt].pincnt > 0) {
|
|
|
|
if (hpredir && as[cnt].pincnt > 1)
|
|
|
|
as[cnt].hpredir = first;
|
|
|
|
cnt++;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
HDA_BOOTVERBOSE(
|
|
|
|
device_printf(sc->dev,
|
2008-09-16 20:03:34 +00:00
|
|
|
"%d associations found:\n", max);
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
for (i = 0; i < max; i++) {
|
|
|
|
device_printf(sc->dev,
|
|
|
|
"Association %d (%d) %s%s:\n",
|
|
|
|
i, as[i].index, (as[i].dir == HDA_CTL_IN)?"in":"out",
|
|
|
|
as[i].enable?"":" (disabled)");
|
|
|
|
for (j = 0; j < 16; j++) {
|
|
|
|
if (as[i].pins[j] == 0)
|
|
|
|
continue;
|
|
|
|
device_printf(sc->dev,
|
2008-09-16 20:03:34 +00:00
|
|
|
" Pin nid=%d seq=%d\n",
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
as[i].pins[j], j);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
);
|
|
|
|
|
|
|
|
devinfo->function.audio.as = as;
|
|
|
|
}
|
|
|
|
|
|
|
|
static const struct {
|
|
|
|
uint32_t model;
|
|
|
|
uint32_t id;
|
|
|
|
uint32_t set, unset;
|
|
|
|
} hdac_quirks[] = {
|
|
|
|
/*
|
|
|
|
* XXX Force stereo quirk. Monoural recording / playback
|
|
|
|
* on few codecs (especially ALC880) seems broken or
|
|
|
|
* perhaps unsupported.
|
|
|
|
*/
|
|
|
|
{ HDA_MATCH_ALL, HDA_MATCH_ALL,
|
|
|
|
HDA_QUIRK_FORCESTEREO | HDA_QUIRK_IVREF, 0 },
|
|
|
|
{ ACER_ALL_SUBVENDOR, HDA_MATCH_ALL,
|
|
|
|
HDA_QUIRK_GPIO0, 0 },
|
|
|
|
{ ASUS_G2K_SUBVENDOR, HDA_CODEC_ALC660,
|
|
|
|
HDA_QUIRK_GPIO0, 0 },
|
|
|
|
{ ASUS_M5200_SUBVENDOR, HDA_CODEC_ALC880,
|
|
|
|
HDA_QUIRK_GPIO0, 0 },
|
2006-12-16 09:14:58 +00:00
|
|
|
{ ASUS_A7M_SUBVENDOR, HDA_CODEC_ALC880,
|
|
|
|
HDA_QUIRK_GPIO0, 0 },
|
2007-03-16 01:44:21 +00:00
|
|
|
{ ASUS_A7T_SUBVENDOR, HDA_CODEC_ALC882,
|
|
|
|
HDA_QUIRK_GPIO0, 0 },
|
2007-05-05 09:17:36 +00:00
|
|
|
{ ASUS_W2J_SUBVENDOR, HDA_CODEC_ALC882,
|
|
|
|
HDA_QUIRK_GPIO0, 0 },
|
2006-10-12 15:37:43 +00:00
|
|
|
{ ASUS_U5F_SUBVENDOR, HDA_CODEC_AD1986A,
|
|
|
|
HDA_QUIRK_EAPDINV, 0 },
|
2008-04-12 15:07:32 +00:00
|
|
|
{ ASUS_A8X_SUBVENDOR, HDA_CODEC_AD1986A,
|
2006-10-16 14:43:22 +00:00
|
|
|
HDA_QUIRK_EAPDINV, 0 },
|
2007-05-05 09:17:36 +00:00
|
|
|
{ ASUS_F3JC_SUBVENDOR, HDA_CODEC_ALC861,
|
|
|
|
HDA_QUIRK_OVREF, 0 },
|
|
|
|
{ UNIWILL_9075_SUBVENDOR, HDA_CODEC_ALC861,
|
|
|
|
HDA_QUIRK_OVREF, 0 },
|
|
|
|
/*{ ASUS_M2N_SUBVENDOR, HDA_CODEC_AD1988,
|
|
|
|
HDA_QUIRK_IVREF80, HDA_QUIRK_IVREF50 | HDA_QUIRK_IVREF100 },*/
|
2006-12-16 09:14:58 +00:00
|
|
|
{ MEDION_MD95257_SUBVENDOR, HDA_CODEC_ALC880,
|
|
|
|
HDA_QUIRK_GPIO1, 0 },
|
2006-11-27 06:16:36 +00:00
|
|
|
{ LENOVO_3KN100_SUBVENDOR, HDA_CODEC_AD1986A,
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
HDA_QUIRK_EAPDINV | HDA_QUIRK_SENSEINV, 0 },
|
2006-11-27 06:16:36 +00:00
|
|
|
{ SAMSUNG_Q1_SUBVENDOR, HDA_CODEC_AD1986A,
|
Welcome to Once-a-year Sound Mega-Commit. Enjoy numerous updates and fixes
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.
2006-11-26 12:24:06 +00:00
|
|
|
HDA_QUIRK_EAPDINV, 0 },
|
2007-11-21 11:39:27 +00:00
|
|
|
{ APPLE_MB3_SUBVENDOR, HDA_CODEC_ALC885,
|
|
|
|
HDA_QUIRK_GPIO0 | HDA_QUIRK_OVREF50, 0},
|
2006-12-09 17:52:54 +00:00
|
|
|
{ APPLE_INTEL_MAC, HDA_CODEC_STAC9221,
|
|
|
|
HDA_QUIRK_GPIO0 | HDA_QUIRK_GPIO1, 0 },
|
2008-07-15 02:34:44 +00:00
|
|
|
{ DELL_D630_SUBVENDOR, HDA_CODEC_STAC9205,
|
|
|
|
HDA_QUIRK_GPIO0, 0 },
|
2008-04-12 15:07:32 +00:00
|
|
|
{ DELL_V1500_SUBVENDOR, HDA_CODEC_STAC9205,
|
|
|
|
HDA_QUIRK_GPIO0, 0 },
|
2007-05-05 09:17:36 +00:00
|
|
|
{ HDA_MATCH_ALL, HDA_CODEC_AD1988,
|
|
|
|
HDA_QUIRK_IVREF80, HDA_QUIRK_IVREF50 | HDA_QUIRK_IVREF100 },
|
2007-06-10 23:01:40 +00:00
|
|
|
{ HDA_MATCH_ALL, HDA_CODEC_AD1988B,
|
|
|
|
HDA_QUIRK_IVREF80, HDA_QUIRK_IVREF50 | HDA_QUIRK_IVREF100 },
|
2006-10-02 16:30:04 +00:00
|
|
|
{ HDA_MATCH_ALL, HDA_CODEC_CXVENICE,
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
0, HDA_QUIRK_FORCESTEREO }
|
2006-10-02 16:30:04 +00:00
|
|
|
};
|
|
|
|
#define HDAC_QUIRKS_LEN (sizeof(hdac_quirks) / sizeof(hdac_quirks[0]))
|
|
|
|
|
2006-10-01 11:13:00 +00:00
|
|
|
static void
|
|
|
|
hdac_vendor_patch_parse(struct hdac_devinfo *devinfo)
|
|
|
|
{
|
|
|
|
struct hdac_widget *w;
|
2006-10-02 16:30:04 +00:00
|
|
|
uint32_t id, subvendor;
|
2006-10-01 11:13:00 +00:00
|
|
|
int i;
|
|
|
|
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
id = hdac_codec_id(devinfo->codec);
|
2006-10-02 16:30:04 +00:00
|
|
|
subvendor = devinfo->codec->sc->pci_subvendor;
|
- Fix wrong id for ALC882, add ALC883 id.
- 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"
2006-10-06 18:59:27 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Quirks
|
|
|
|
*/
|
|
|
|
for (i = 0; i < HDAC_QUIRKS_LEN; i++) {
|
2006-10-12 04:19:37 +00:00
|
|
|
if (!(HDA_DEV_MATCH(hdac_quirks[i].model, subvendor) &&
|
|
|
|
HDA_DEV_MATCH(hdac_quirks[i].id, id)))
|
- Fix wrong id for ALC882, add ALC883 id.
- 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"
2006-10-06 18:59:27 +00:00
|
|
|
continue;
|
|
|
|
if (hdac_quirks[i].set != 0)
|
|
|
|
devinfo->function.audio.quirks |=
|
|
|
|
hdac_quirks[i].set;
|
|
|
|
if (hdac_quirks[i].unset != 0)
|
|
|
|
devinfo->function.audio.quirks &=
|
|
|
|
~(hdac_quirks[i].unset);
|
|
|
|
}
|
|
|
|
|
2006-10-01 11:13:00 +00:00
|
|
|
switch (id) {
|
2007-02-25 06:17:56 +00:00
|
|
|
case HDA_CODEC_ALC883:
|
|
|
|
/*
|
|
|
|
* nid: 24/25 = External (jack) or Internal (fixed) Mic.
|
|
|
|
* Clear vref cap for jack connectivity.
|
|
|
|
*/
|
|
|
|
w = hdac_widget_get(devinfo, 24);
|
|
|
|
if (w != NULL && w->enable != 0 && w->type ==
|
|
|
|
HDA_PARAM_AUDIO_WIDGET_CAP_TYPE_PIN_COMPLEX &&
|
|
|
|
(w->wclass.pin.config &
|
|
|
|
HDA_CONFIG_DEFAULTCONF_CONNECTIVITY_MASK) ==
|
|
|
|
HDA_CONFIG_DEFAULTCONF_CONNECTIVITY_JACK)
|
|
|
|
w->wclass.pin.cap &= ~(
|
|
|
|
HDA_PARAM_PIN_CAP_VREF_CTRL_100_MASK |
|
|
|
|
HDA_PARAM_PIN_CAP_VREF_CTRL_80_MASK |
|
|
|
|
HDA_PARAM_PIN_CAP_VREF_CTRL_50_MASK);
|
|
|
|
w = hdac_widget_get(devinfo, 25);
|
|
|
|
if (w != NULL && w->enable != 0 && w->type ==
|
|
|
|
HDA_PARAM_AUDIO_WIDGET_CAP_TYPE_PIN_COMPLEX &&
|
|
|
|
(w->wclass.pin.config &
|
|
|
|
HDA_CONFIG_DEFAULTCONF_CONNECTIVITY_MASK) ==
|
|
|
|
HDA_CONFIG_DEFAULTCONF_CONNECTIVITY_JACK)
|
|
|
|
w->wclass.pin.cap &= ~(
|
|
|
|
HDA_PARAM_PIN_CAP_VREF_CTRL_100_MASK |
|
|
|
|
HDA_PARAM_PIN_CAP_VREF_CTRL_80_MASK |
|
|
|
|
HDA_PARAM_PIN_CAP_VREF_CTRL_50_MASK);
|
|
|
|
/*
|
|
|
|
* nid: 26 = Line-in, leave it alone.
|
|
|
|
*/
|
|
|
|
break;
|
2006-10-01 11:13:00 +00:00
|
|
|
case HDA_CODEC_AD1986A:
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
if (subvendor == ASUS_A8X_SUBVENDOR) {
|
2008-04-12 15:07:32 +00:00
|
|
|
/*
|
|
|
|
* This is just plain ridiculous.. There
|
|
|
|
* are several A8 series that share the same
|
|
|
|
* pci id but works differently (EAPD).
|
|
|
|
*/
|
|
|
|
w = hdac_widget_get(devinfo, 26);
|
|
|
|
if (w != NULL && w->type ==
|
|
|
|
HDA_PARAM_AUDIO_WIDGET_CAP_TYPE_PIN_COMPLEX &&
|
|
|
|
(w->wclass.pin.config &
|
|
|
|
HDA_CONFIG_DEFAULTCONF_CONNECTIVITY_MASK) !=
|
|
|
|
HDA_CONFIG_DEFAULTCONF_CONNECTIVITY_NONE)
|
|
|
|
devinfo->function.audio.quirks &=
|
|
|
|
~HDA_QUIRK_EAPDINV;
|
2007-05-05 09:17:36 +00:00
|
|
|
}
|
|
|
|
break;
|
2006-10-01 11:13:00 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
/*
|
|
|
|
* Trace path from DAC to pin.
|
|
|
|
*/
|
|
|
|
static nid_t
|
|
|
|
hdac_audio_trace_dac(struct hdac_devinfo *devinfo, int as, int seq, nid_t nid,
|
|
|
|
int dupseq, int min, int only, int depth)
|
2006-10-01 11:13:00 +00:00
|
|
|
{
|
|
|
|
struct hdac_widget *w;
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
int i, im = -1;
|
|
|
|
nid_t m = 0, ret;
|
2006-10-01 11:13:00 +00:00
|
|
|
|
|
|
|
if (depth > HDA_PARSE_MAXDEPTH)
|
|
|
|
return (0);
|
|
|
|
w = hdac_widget_get(devinfo, nid);
|
|
|
|
if (w == NULL || w->enable == 0)
|
|
|
|
return (0);
|
2008-09-16 20:03:34 +00:00
|
|
|
HDA_BOOTHVERBOSE(
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
if (!only) {
|
|
|
|
device_printf(devinfo->codec->sc->dev,
|
|
|
|
" %*stracing via nid %d\n",
|
|
|
|
depth + 1, "", w->nid);
|
|
|
|
}
|
|
|
|
);
|
|
|
|
/* Use only unused widgets */
|
|
|
|
if (w->bindas >= 0 && w->bindas != as) {
|
2008-09-16 20:03:34 +00:00
|
|
|
HDA_BOOTHVERBOSE(
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
if (!only) {
|
|
|
|
device_printf(devinfo->codec->sc->dev,
|
|
|
|
" %*snid %d busy by association %d\n",
|
|
|
|
depth + 1, "", w->nid, w->bindas);
|
|
|
|
}
|
|
|
|
);
|
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
if (dupseq < 0) {
|
|
|
|
if (w->bindseqmask != 0) {
|
2008-09-16 20:03:34 +00:00
|
|
|
HDA_BOOTHVERBOSE(
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
if (!only) {
|
|
|
|
device_printf(devinfo->codec->sc->dev,
|
|
|
|
" %*snid %d busy by seqmask %x\n",
|
|
|
|
depth + 1, "", w->nid, w->bindseqmask);
|
|
|
|
}
|
|
|
|
);
|
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
/* If this is headphones - allow duplicate first pin. */
|
|
|
|
if (w->bindseqmask != 0 &&
|
|
|
|
(w->bindseqmask & (1 << dupseq)) == 0) {
|
2008-09-16 20:03:34 +00:00
|
|
|
HDA_BOOTHVERBOSE(
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
device_printf(devinfo->codec->sc->dev,
|
|
|
|
" %*snid %d busy by seqmask %x\n",
|
|
|
|
depth + 1, "", w->nid, w->bindseqmask);
|
|
|
|
);
|
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2006-10-01 11:13:00 +00:00
|
|
|
switch (w->type) {
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
case HDA_PARAM_AUDIO_WIDGET_CAP_TYPE_AUDIO_INPUT:
|
|
|
|
/* Do not traverse input. AD1988 has digital monitor
|
|
|
|
for which we are not ready. */
|
|
|
|
break;
|
2006-10-01 11:13:00 +00:00
|
|
|
case HDA_PARAM_AUDIO_WIDGET_CAP_TYPE_AUDIO_OUTPUT:
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
/* If we are tracing HP take only dac of first pin. */
|
|
|
|
if ((only == 0 || only == w->nid) &&
|
|
|
|
(w->nid >= min) && (dupseq < 0 || w->nid ==
|
|
|
|
devinfo->function.audio.as[as].dacs[dupseq]))
|
|
|
|
m = w->nid;
|
2006-10-01 11:13:00 +00:00
|
|
|
break;
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
case HDA_PARAM_AUDIO_WIDGET_CAP_TYPE_PIN_COMPLEX:
|
|
|
|
if (depth > 0)
|
|
|
|
break;
|
|
|
|
/* Fall */
|
|
|
|
default:
|
|
|
|
/* Find reachable DACs with smallest nid respecting constraints. */
|
2006-10-01 11:13:00 +00:00
|
|
|
for (i = 0; i < w->nconns; i++) {
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
if (w->connsenable[i] == 0)
|
|
|
|
continue;
|
|
|
|
if (w->selconn != -1 && w->selconn != i)
|
|
|
|
continue;
|
|
|
|
if ((ret = hdac_audio_trace_dac(devinfo, as, seq,
|
|
|
|
w->conns[i], dupseq, min, only, depth + 1)) != 0) {
|
|
|
|
if (m == 0 || ret < m) {
|
|
|
|
m = ret;
|
|
|
|
im = i;
|
|
|
|
}
|
|
|
|
if (only || dupseq >= 0)
|
|
|
|
break;
|
2006-10-01 11:13:00 +00:00
|
|
|
}
|
|
|
|
}
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
if (m && only && ((w->nconns > 1 &&
|
|
|
|
w->type != HDA_PARAM_AUDIO_WIDGET_CAP_TYPE_AUDIO_MIXER) ||
|
|
|
|
w->type == HDA_PARAM_AUDIO_WIDGET_CAP_TYPE_AUDIO_SELECTOR))
|
|
|
|
w->selconn = im;
|
2006-10-01 11:13:00 +00:00
|
|
|
break;
|
|
|
|
}
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
if (m && only) {
|
|
|
|
w->bindas = as;
|
|
|
|
w->bindseqmask |= (1 << seq);
|
|
|
|
}
|
2008-09-16 20:03:34 +00:00
|
|
|
HDA_BOOTHVERBOSE(
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
if (!only) {
|
|
|
|
device_printf(devinfo->codec->sc->dev,
|
|
|
|
" %*snid %d returned %d\n",
|
|
|
|
depth + 1, "", w->nid, m);
|
|
|
|
}
|
|
|
|
);
|
|
|
|
return (m);
|
2006-10-01 11:13:00 +00:00
|
|
|
}
|
|
|
|
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
/*
|
|
|
|
* Trace path from widget to ADC.
|
|
|
|
*/
|
|
|
|
static nid_t
|
|
|
|
hdac_audio_trace_adc(struct hdac_devinfo *devinfo, int as, int seq, nid_t nid,
|
|
|
|
int only, int depth)
|
2006-10-01 11:13:00 +00:00
|
|
|
{
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
struct hdac_widget *w, *wc;
|
|
|
|
int i, j;
|
|
|
|
nid_t res = 0;
|
2006-10-01 11:13:00 +00:00
|
|
|
|
|
|
|
if (depth > HDA_PARSE_MAXDEPTH)
|
|
|
|
return (0);
|
|
|
|
w = hdac_widget_get(devinfo, nid);
|
|
|
|
if (w == NULL || w->enable == 0)
|
|
|
|
return (0);
|
2008-09-16 20:03:34 +00:00
|
|
|
HDA_BOOTHVERBOSE(
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
device_printf(devinfo->codec->sc->dev,
|
|
|
|
" %*stracing via nid %d\n",
|
|
|
|
depth + 1, "", w->nid);
|
|
|
|
);
|
|
|
|
/* Use only unused widgets */
|
|
|
|
if (w->bindas >= 0 && w->bindas != as) {
|
2008-09-16 20:03:34 +00:00
|
|
|
HDA_BOOTHVERBOSE(
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
device_printf(devinfo->codec->sc->dev,
|
|
|
|
" %*snid %d busy by association %d\n",
|
|
|
|
depth + 1, "", w->nid, w->bindas);
|
|
|
|
);
|
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
|
2006-10-01 11:13:00 +00:00
|
|
|
switch (w->type) {
|
|
|
|
case HDA_PARAM_AUDIO_WIDGET_CAP_TYPE_AUDIO_INPUT:
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
/* If we are tracing HP take only dac of first pin. */
|
|
|
|
if (only == w->nid)
|
|
|
|
res = 1;
|
2006-10-01 11:13:00 +00:00
|
|
|
break;
|
|
|
|
case HDA_PARAM_AUDIO_WIDGET_CAP_TYPE_PIN_COMPLEX:
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
if (depth > 0)
|
|
|
|
break;
|
|
|
|
/* Fall */
|
2006-10-01 11:13:00 +00:00
|
|
|
default:
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
/* Try to find reachable ADCs with specified nid. */
|
|
|
|
for (j = devinfo->startnode; j < devinfo->endnode; j++) {
|
|
|
|
wc = hdac_widget_get(devinfo, j);
|
|
|
|
if (wc == NULL || wc->enable == 0)
|
|
|
|
continue;
|
|
|
|
for (i = 0; i < wc->nconns; i++) {
|
|
|
|
if (wc->connsenable[i] == 0)
|
|
|
|
continue;
|
|
|
|
if (wc->conns[i] != nid)
|
|
|
|
continue;
|
|
|
|
if (hdac_audio_trace_adc(devinfo, as, seq,
|
|
|
|
j, only, depth + 1) != 0) {
|
|
|
|
res = 1;
|
|
|
|
if (((wc->nconns > 1 &&
|
|
|
|
wc->type != HDA_PARAM_AUDIO_WIDGET_CAP_TYPE_AUDIO_MIXER) ||
|
|
|
|
wc->type == HDA_PARAM_AUDIO_WIDGET_CAP_TYPE_AUDIO_SELECTOR) &&
|
|
|
|
wc->selconn == -1)
|
|
|
|
wc->selconn = i;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2006-10-01 11:13:00 +00:00
|
|
|
break;
|
|
|
|
}
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
if (res) {
|
|
|
|
w->bindas = as;
|
|
|
|
w->bindseqmask |= (1 << seq);
|
|
|
|
}
|
2008-09-16 20:03:34 +00:00
|
|
|
HDA_BOOTHVERBOSE(
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
device_printf(devinfo->codec->sc->dev,
|
|
|
|
" %*snid %d returned %d\n",
|
|
|
|
depth + 1, "", w->nid, res);
|
|
|
|
);
|
|
|
|
return (res);
|
2006-10-01 11:13:00 +00:00
|
|
|
}
|
|
|
|
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
/*
|
|
|
|
* Erase trace path of the specified association.
|
|
|
|
*/
|
|
|
|
static void
|
|
|
|
hdac_audio_undo_trace(struct hdac_devinfo *devinfo, int as, int seq)
|
2006-10-01 11:13:00 +00:00
|
|
|
{
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
struct hdac_widget *w;
|
|
|
|
int i;
|
|
|
|
|
|
|
|
for (i = devinfo->startnode; i < devinfo->endnode; i++) {
|
|
|
|
w = hdac_widget_get(devinfo, i);
|
|
|
|
if (w == NULL || w->enable == 0)
|
|
|
|
continue;
|
|
|
|
if (w->bindas == as) {
|
|
|
|
if (seq >= 0) {
|
|
|
|
w->bindseqmask &= ~(1 << seq);
|
|
|
|
if (w->bindseqmask == 0) {
|
|
|
|
w->bindas = -1;
|
|
|
|
w->selconn = -1;
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
w->bindas = -1;
|
|
|
|
w->bindseqmask = 0;
|
|
|
|
w->selconn = -1;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Trace association path from DAC to output
|
|
|
|
*/
|
|
|
|
static int
|
|
|
|
hdac_audio_trace_as_out(struct hdac_devinfo *devinfo, int as, int seq)
|
|
|
|
{
|
|
|
|
struct hdac_audio_as *ases = devinfo->function.audio.as;
|
|
|
|
int i, hpredir;
|
|
|
|
nid_t min, res;
|
|
|
|
|
|
|
|
/* Find next pin */
|
|
|
|
for (i = seq; ases[as].pins[i] == 0 && i < 16; i++)
|
|
|
|
;
|
|
|
|
/* Check if there is no any left. If so - we succeded. */
|
|
|
|
if (i == 16)
|
|
|
|
return (1);
|
|
|
|
|
|
|
|
hpredir = (i == 15 && ases[as].fakeredir == 0)?ases[as].hpredir:-1;
|
|
|
|
min = 0;
|
|
|
|
res = 0;
|
|
|
|
do {
|
2008-09-16 20:03:34 +00:00
|
|
|
HDA_BOOTHVERBOSE(
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
device_printf(devinfo->codec->sc->dev,
|
|
|
|
" Tracing pin %d with min nid %d",
|
|
|
|
ases[as].pins[i], min);
|
|
|
|
if (hpredir >= 0)
|
2008-09-16 20:03:34 +00:00
|
|
|
printf(" and hpredir %d", hpredir);
|
|
|
|
printf("\n");
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
);
|
|
|
|
/* Trace this pin taking min nid into account. */
|
|
|
|
res = hdac_audio_trace_dac(devinfo, as, i,
|
|
|
|
ases[as].pins[i], hpredir, min, 0, 0);
|
|
|
|
if (res == 0) {
|
|
|
|
/* If we failed - return to previous and redo it. */
|
|
|
|
HDA_BOOTVERBOSE(
|
|
|
|
device_printf(devinfo->codec->sc->dev,
|
|
|
|
" Unable to trace pin %d seq %d with min "
|
2008-09-16 20:03:34 +00:00
|
|
|
"nid %d",
|
|
|
|
ases[as].pins[i], i, min);
|
|
|
|
if (hpredir >= 0)
|
|
|
|
printf(" and hpredir %d", hpredir);
|
|
|
|
printf("\n");
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
);
|
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
HDA_BOOTVERBOSE(
|
|
|
|
device_printf(devinfo->codec->sc->dev,
|
2008-09-16 20:03:34 +00:00
|
|
|
" Pin %d traced to DAC %d",
|
|
|
|
ases[as].pins[i], res);
|
|
|
|
if (hpredir >= 0)
|
|
|
|
printf(" and hpredir %d", hpredir);
|
|
|
|
if (ases[as].fakeredir)
|
|
|
|
printf(" with fake redirection");
|
|
|
|
printf("\n");
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
);
|
|
|
|
/* Trace again to mark the path */
|
|
|
|
hdac_audio_trace_dac(devinfo, as, i,
|
|
|
|
ases[as].pins[i], hpredir, min, res, 0);
|
|
|
|
ases[as].dacs[i] = res;
|
|
|
|
/* We succeded, so call next. */
|
|
|
|
if (hdac_audio_trace_as_out(devinfo, as, i + 1))
|
|
|
|
return (1);
|
|
|
|
/* If next failed, we should retry with next min */
|
|
|
|
hdac_audio_undo_trace(devinfo, as, i);
|
|
|
|
ases[as].dacs[i] = 0;
|
|
|
|
min = res + 1;
|
|
|
|
} while (1);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Trace association path from input to ADC
|
|
|
|
*/
|
|
|
|
static int
|
|
|
|
hdac_audio_trace_as_in(struct hdac_devinfo *devinfo, int as)
|
|
|
|
{
|
|
|
|
struct hdac_audio_as *ases = devinfo->function.audio.as;
|
|
|
|
struct hdac_widget *w;
|
|
|
|
int i, j, k;
|
|
|
|
|
|
|
|
for (j = devinfo->startnode; j < devinfo->endnode; j++) {
|
|
|
|
w = hdac_widget_get(devinfo, j);
|
|
|
|
if (w == NULL || w->enable == 0)
|
|
|
|
continue;
|
|
|
|
if (w->type != HDA_PARAM_AUDIO_WIDGET_CAP_TYPE_AUDIO_INPUT)
|
|
|
|
continue;
|
|
|
|
if (w->bindas >= 0 && w->bindas != as)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
/* Find next pin */
|
|
|
|
for (i = 0; i < 16; i++) {
|
|
|
|
if (ases[as].pins[i] == 0)
|
|
|
|
continue;
|
|
|
|
|
2008-09-16 20:03:34 +00:00
|
|
|
HDA_BOOTHVERBOSE(
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
device_printf(devinfo->codec->sc->dev,
|
|
|
|
" Tracing pin %d to ADC %d\n",
|
|
|
|
ases[as].pins[i], j);
|
|
|
|
);
|
|
|
|
/* Trace this pin taking goal into account. */
|
|
|
|
if (hdac_audio_trace_adc(devinfo, as, i,
|
|
|
|
ases[as].pins[i], j, 0) == 0) {
|
|
|
|
/* If we failed - return to previous and redo it. */
|
|
|
|
HDA_BOOTVERBOSE(
|
|
|
|
device_printf(devinfo->codec->sc->dev,
|
2008-09-16 20:03:34 +00:00
|
|
|
" Unable to trace pin %d to ADC %d, undo traces\n",
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
ases[as].pins[i], j);
|
|
|
|
);
|
|
|
|
hdac_audio_undo_trace(devinfo, as, -1);
|
|
|
|
for (k = 0; k < 16; k++)
|
|
|
|
ases[as].dacs[k] = 0;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
HDA_BOOTVERBOSE(
|
|
|
|
device_printf(devinfo->codec->sc->dev,
|
2008-09-16 20:03:34 +00:00
|
|
|
" Pin %d traced to ADC %d\n",
|
|
|
|
ases[as].pins[i], j);
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
);
|
|
|
|
ases[as].dacs[i] = j;
|
|
|
|
}
|
|
|
|
if (i == 16)
|
|
|
|
return (1);
|
|
|
|
}
|
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Trace input monitor path from mixer to output association.
|
|
|
|
*/
|
2008-09-16 20:03:34 +00:00
|
|
|
static int
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
hdac_audio_trace_to_out(struct hdac_devinfo *devinfo, nid_t nid, int depth)
|
|
|
|
{
|
|
|
|
struct hdac_audio_as *ases = devinfo->function.audio.as;
|
|
|
|
struct hdac_widget *w, *wc;
|
|
|
|
int i, j;
|
|
|
|
nid_t res = 0;
|
2006-10-01 11:13:00 +00:00
|
|
|
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
if (depth > HDA_PARSE_MAXDEPTH)
|
|
|
|
return (0);
|
2006-10-01 11:13:00 +00:00
|
|
|
w = hdac_widget_get(devinfo, nid);
|
|
|
|
if (w == NULL || w->enable == 0)
|
|
|
|
return (0);
|
2008-09-16 20:03:34 +00:00
|
|
|
HDA_BOOTHVERBOSE(
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
device_printf(devinfo->codec->sc->dev,
|
|
|
|
" %*stracing via nid %d\n",
|
|
|
|
depth + 1, "", w->nid);
|
|
|
|
);
|
|
|
|
/* Use only unused widgets */
|
|
|
|
if (depth > 0 && w->bindas != -1) {
|
|
|
|
if (w->bindas < 0 || ases[w->bindas].dir == HDA_CTL_OUT) {
|
2008-09-16 20:03:34 +00:00
|
|
|
HDA_BOOTHVERBOSE(
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
device_printf(devinfo->codec->sc->dev,
|
|
|
|
" %*snid %d found output association %d\n",
|
|
|
|
depth + 1, "", w->nid, w->bindas);
|
|
|
|
);
|
|
|
|
return (1);
|
|
|
|
} else {
|
2008-09-16 20:03:34 +00:00
|
|
|
HDA_BOOTHVERBOSE(
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
device_printf(devinfo->codec->sc->dev,
|
|
|
|
" %*snid %d busy by input association %d\n",
|
|
|
|
depth + 1, "", w->nid, w->bindas);
|
|
|
|
);
|
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
switch (w->type) {
|
|
|
|
case HDA_PARAM_AUDIO_WIDGET_CAP_TYPE_AUDIO_INPUT:
|
|
|
|
/* Do not traverse input. AD1988 has digital monitor
|
|
|
|
for which we are not ready. */
|
|
|
|
break;
|
|
|
|
case HDA_PARAM_AUDIO_WIDGET_CAP_TYPE_PIN_COMPLEX:
|
|
|
|
if (depth > 0)
|
|
|
|
break;
|
|
|
|
/* Fall */
|
|
|
|
default:
|
|
|
|
/* Try to find reachable ADCs with specified nid. */
|
|
|
|
for (j = devinfo->startnode; j < devinfo->endnode; j++) {
|
|
|
|
wc = hdac_widget_get(devinfo, j);
|
|
|
|
if (wc == NULL || wc->enable == 0)
|
|
|
|
continue;
|
|
|
|
for (i = 0; i < wc->nconns; i++) {
|
|
|
|
if (wc->connsenable[i] == 0)
|
|
|
|
continue;
|
|
|
|
if (wc->conns[i] != nid)
|
|
|
|
continue;
|
|
|
|
if (hdac_audio_trace_to_out(devinfo,
|
|
|
|
j, depth + 1) != 0) {
|
|
|
|
res = 1;
|
|
|
|
if (wc->type == HDA_PARAM_AUDIO_WIDGET_CAP_TYPE_AUDIO_SELECTOR &&
|
|
|
|
wc->selconn == -1)
|
|
|
|
wc->selconn = i;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
if (res)
|
|
|
|
w->bindas = -2;
|
2006-10-01 11:13:00 +00:00
|
|
|
|
2008-09-16 20:03:34 +00:00
|
|
|
HDA_BOOTHVERBOSE(
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
device_printf(devinfo->codec->sc->dev,
|
|
|
|
" %*snid %d returned %d\n",
|
|
|
|
depth + 1, "", w->nid, res);
|
|
|
|
);
|
|
|
|
return (res);
|
|
|
|
}
|
2006-10-01 11:13:00 +00:00
|
|
|
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
/*
|
|
|
|
* Trace extra associations (beeper, monitor)
|
|
|
|
*/
|
|
|
|
static void
|
|
|
|
hdac_audio_trace_as_extra(struct hdac_devinfo *devinfo)
|
|
|
|
{
|
|
|
|
struct hdac_audio_as *as = devinfo->function.audio.as;
|
|
|
|
struct hdac_widget *w;
|
|
|
|
int j;
|
|
|
|
|
|
|
|
/* Input monitor */
|
|
|
|
/* Find mixer associated with input, but supplying signal
|
|
|
|
for output associations. Hope it will be input monitor. */
|
|
|
|
HDA_BOOTVERBOSE(
|
|
|
|
device_printf(devinfo->codec->sc->dev,
|
|
|
|
"Tracing input monitor\n");
|
|
|
|
);
|
|
|
|
for (j = devinfo->startnode; j < devinfo->endnode; j++) {
|
|
|
|
w = hdac_widget_get(devinfo, j);
|
|
|
|
if (w == NULL || w->enable == 0)
|
|
|
|
continue;
|
|
|
|
if (w->type != HDA_PARAM_AUDIO_WIDGET_CAP_TYPE_AUDIO_MIXER)
|
|
|
|
continue;
|
|
|
|
if (w->bindas < 0 || as[w->bindas].dir != HDA_CTL_IN)
|
|
|
|
continue;
|
|
|
|
HDA_BOOTVERBOSE(
|
|
|
|
device_printf(devinfo->codec->sc->dev,
|
|
|
|
" Tracing nid %d to out\n",
|
|
|
|
j);
|
|
|
|
);
|
|
|
|
if (hdac_audio_trace_to_out(devinfo, w->nid, 0)) {
|
|
|
|
HDA_BOOTVERBOSE(
|
|
|
|
device_printf(devinfo->codec->sc->dev,
|
|
|
|
" nid %d is input monitor\n",
|
|
|
|
w->nid);
|
|
|
|
);
|
|
|
|
w->pflags |= HDA_ADC_MONITOR;
|
|
|
|
w->ossdev = SOUND_MIXER_IMIX;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Beeper */
|
|
|
|
HDA_BOOTVERBOSE(
|
|
|
|
device_printf(devinfo->codec->sc->dev,
|
|
|
|
"Tracing beeper\n");
|
|
|
|
);
|
|
|
|
for (j = devinfo->startnode; j < devinfo->endnode; j++) {
|
|
|
|
w = hdac_widget_get(devinfo, j);
|
|
|
|
if (w == NULL || w->enable == 0)
|
|
|
|
continue;
|
|
|
|
if (w->type != HDA_PARAM_AUDIO_WIDGET_CAP_TYPE_BEEP_WIDGET)
|
|
|
|
continue;
|
2008-09-16 20:03:34 +00:00
|
|
|
HDA_BOOTHVERBOSE(
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
device_printf(devinfo->codec->sc->dev,
|
|
|
|
" Tracing nid %d to out\n",
|
|
|
|
j);
|
|
|
|
);
|
2008-09-16 20:03:34 +00:00
|
|
|
if (hdac_audio_trace_to_out(devinfo, w->nid, 0)) {
|
|
|
|
HDA_BOOTVERBOSE(
|
|
|
|
device_printf(devinfo->codec->sc->dev,
|
|
|
|
" nid %d traced to out\n",
|
|
|
|
j);
|
|
|
|
);
|
|
|
|
}
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
w->bindas = -2;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Bind assotiations to PCM channels
|
|
|
|
*/
|
|
|
|
static void
|
|
|
|
hdac_audio_bind_as(struct hdac_devinfo *devinfo)
|
|
|
|
{
|
|
|
|
struct hdac_softc *sc = devinfo->codec->sc;
|
|
|
|
struct hdac_audio_as *as = devinfo->function.audio.as;
|
|
|
|
int j, cnt = 0, free;
|
|
|
|
|
|
|
|
for (j = 0; j < devinfo->function.audio.ascnt; j++) {
|
|
|
|
if (as[j].enable)
|
|
|
|
cnt++;
|
|
|
|
}
|
|
|
|
if (sc->num_chans == 0) {
|
|
|
|
sc->chans = (struct hdac_chan *)malloc(
|
|
|
|
sizeof(struct hdac_chan) * cnt,
|
|
|
|
M_HDAC, M_ZERO | M_NOWAIT);
|
|
|
|
if (sc->chans == NULL) {
|
|
|
|
device_printf(devinfo->codec->sc->dev,
|
|
|
|
"Channels memory allocation failed!\n");
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
sc->chans = (struct hdac_chan *)realloc(sc->chans,
|
2008-10-12 21:42:21 +00:00
|
|
|
sizeof(struct hdac_chan) * (sc->num_chans + cnt),
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
M_HDAC, M_ZERO | M_NOWAIT);
|
|
|
|
if (sc->chans == NULL) {
|
|
|
|
sc->num_chans = 0;
|
|
|
|
device_printf(devinfo->codec->sc->dev,
|
|
|
|
"Channels memory allocation failed!\n");
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
free = sc->num_chans;
|
|
|
|
sc->num_chans += cnt;
|
|
|
|
|
|
|
|
for (j = free; j < free + cnt; j++) {
|
|
|
|
devinfo->codec->sc->chans[j].devinfo = devinfo;
|
|
|
|
devinfo->codec->sc->chans[j].as = -1;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Assign associations in order of their numbers, */
|
|
|
|
for (j = 0; j < devinfo->function.audio.ascnt; j++) {
|
|
|
|
if (as[j].enable == 0)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
as[j].chan = free;
|
|
|
|
devinfo->codec->sc->chans[free].as = j;
|
|
|
|
if (as[j].dir == HDA_CTL_IN) {
|
|
|
|
devinfo->codec->sc->chans[free].dir = PCMDIR_REC;
|
|
|
|
devinfo->function.audio.reccnt++;
|
|
|
|
} else {
|
|
|
|
devinfo->codec->sc->chans[free].dir = PCMDIR_PLAY;
|
|
|
|
devinfo->function.audio.playcnt++;
|
|
|
|
}
|
|
|
|
hdac_pcmchannel_setup(&devinfo->codec->sc->chans[free]);
|
|
|
|
free++;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
hdac_audio_disable_nonaudio(struct hdac_devinfo *devinfo)
|
|
|
|
{
|
|
|
|
struct hdac_widget *w;
|
|
|
|
int i;
|
|
|
|
|
|
|
|
/* Disable power and volume widgets. */
|
|
|
|
for (i = devinfo->startnode; i < devinfo->endnode; i++) {
|
|
|
|
w = hdac_widget_get(devinfo, i);
|
|
|
|
if (w == NULL || w->enable == 0)
|
|
|
|
continue;
|
|
|
|
if (w->type == HDA_PARAM_AUDIO_WIDGET_CAP_TYPE_POWER_WIDGET ||
|
|
|
|
w->type == HDA_PARAM_AUDIO_WIDGET_CAP_TYPE_VOLUME_WIDGET) {
|
|
|
|
w->enable = 0;
|
2008-09-16 20:03:34 +00:00
|
|
|
HDA_BOOTHVERBOSE(
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
device_printf(devinfo->codec->sc->dev,
|
|
|
|
" Disabling nid %d due to it's"
|
|
|
|
" non-audio type.\n",
|
|
|
|
w->nid);
|
|
|
|
);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
hdac_audio_disable_useless(struct hdac_devinfo *devinfo)
|
|
|
|
{
|
|
|
|
struct hdac_widget *w, *cw;
|
|
|
|
struct hdac_audio_ctl *ctl;
|
|
|
|
int done, found, i, j, k;
|
|
|
|
|
|
|
|
/* Disable useless pins. */
|
|
|
|
for (i = devinfo->startnode; i < devinfo->endnode; i++) {
|
|
|
|
w = hdac_widget_get(devinfo, i);
|
|
|
|
if (w == NULL || w->enable == 0)
|
|
|
|
continue;
|
|
|
|
if (w->type == HDA_PARAM_AUDIO_WIDGET_CAP_TYPE_PIN_COMPLEX &&
|
|
|
|
(w->wclass.pin.config &
|
|
|
|
HDA_CONFIG_DEFAULTCONF_CONNECTIVITY_MASK) ==
|
|
|
|
HDA_CONFIG_DEFAULTCONF_CONNECTIVITY_NONE) {
|
|
|
|
w->enable = 0;
|
2008-09-16 20:03:34 +00:00
|
|
|
HDA_BOOTHVERBOSE(
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
device_printf(devinfo->codec->sc->dev,
|
|
|
|
" Disabling pin nid %d due"
|
|
|
|
" to None connectivity.\n",
|
|
|
|
w->nid);
|
|
|
|
);
|
2006-10-01 11:13:00 +00:00
|
|
|
}
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
}
|
|
|
|
do {
|
|
|
|
done = 1;
|
|
|
|
/* Disable and mute controls for disabled widgets. */
|
2006-10-01 11:13:00 +00:00
|
|
|
i = 0;
|
|
|
|
while ((ctl = hdac_audio_ctl_each(devinfo, &i)) != NULL) {
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
if (ctl->enable == 0)
|
2006-10-01 11:13:00 +00:00
|
|
|
continue;
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
if (ctl->widget->enable == 0 ||
|
|
|
|
(ctl->childwidget != NULL &&
|
|
|
|
ctl->childwidget->enable == 0)) {
|
|
|
|
ctl->forcemute = 1;
|
|
|
|
ctl->muted = HDA_AMP_MUTE_ALL;
|
|
|
|
ctl->left = 0;
|
|
|
|
ctl->right = 0;
|
|
|
|
ctl->enable = 0;
|
|
|
|
if (ctl->ndir == HDA_CTL_IN)
|
|
|
|
ctl->widget->connsenable[ctl->index] = 0;
|
|
|
|
done = 0;
|
2008-09-16 20:03:34 +00:00
|
|
|
HDA_BOOTHVERBOSE(
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
device_printf(devinfo->codec->sc->dev,
|
|
|
|
" Disabling ctl %d nid %d cnid %d due"
|
|
|
|
" to disabled widget.\n", i,
|
|
|
|
ctl->widget->nid,
|
|
|
|
(ctl->childwidget != NULL)?
|
|
|
|
ctl->childwidget->nid:-1);
|
|
|
|
);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
/* Disable useless widgets. */
|
|
|
|
for (i = devinfo->startnode; i < devinfo->endnode; i++) {
|
|
|
|
w = hdac_widget_get(devinfo, i);
|
|
|
|
if (w == NULL || w->enable == 0)
|
|
|
|
continue;
|
|
|
|
/* Disable inputs with disabled child widgets. */
|
|
|
|
for (j = 0; j < w->nconns; j++) {
|
|
|
|
if (w->connsenable[j]) {
|
|
|
|
cw = hdac_widget_get(devinfo, w->conns[j]);
|
|
|
|
if (cw == NULL || cw->enable == 0) {
|
|
|
|
w->connsenable[j] = 0;
|
2008-09-16 20:03:34 +00:00
|
|
|
HDA_BOOTHVERBOSE(
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
device_printf(devinfo->codec->sc->dev,
|
|
|
|
" Disabling nid %d connection %d due"
|
|
|
|
" to disabled child widget.\n",
|
|
|
|
i, j);
|
|
|
|
);
|
- Fix wrong id for ALC882, add ALC883 id.
- 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"
2006-10-06 18:59:27 +00:00
|
|
|
}
|
|
|
|
}
|
2006-10-01 11:13:00 +00:00
|
|
|
}
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
if (w->type != HDA_PARAM_AUDIO_WIDGET_CAP_TYPE_AUDIO_SELECTOR &&
|
|
|
|
w->type != HDA_PARAM_AUDIO_WIDGET_CAP_TYPE_AUDIO_MIXER)
|
2006-10-01 11:13:00 +00:00
|
|
|
continue;
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
/* Disable mixers and selectors without inputs. */
|
|
|
|
found = 0;
|
|
|
|
for (j = 0; j < w->nconns; j++) {
|
|
|
|
if (w->connsenable[j]) {
|
|
|
|
found = 1;
|
2006-10-01 11:13:00 +00:00
|
|
|
break;
|
|
|
|
}
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
}
|
|
|
|
if (found == 0) {
|
|
|
|
w->enable = 0;
|
|
|
|
done = 0;
|
2008-09-16 20:03:34 +00:00
|
|
|
HDA_BOOTHVERBOSE(
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
device_printf(devinfo->codec->sc->dev,
|
|
|
|
" Disabling nid %d due to all it's"
|
|
|
|
" inputs disabled.\n", w->nid);
|
|
|
|
);
|
|
|
|
}
|
|
|
|
/* Disable nodes without consumers. */
|
|
|
|
if (w->type != HDA_PARAM_AUDIO_WIDGET_CAP_TYPE_AUDIO_SELECTOR &&
|
|
|
|
w->type != HDA_PARAM_AUDIO_WIDGET_CAP_TYPE_AUDIO_MIXER)
|
|
|
|
continue;
|
|
|
|
found = 0;
|
|
|
|
for (k = devinfo->startnode; k < devinfo->endnode; k++) {
|
|
|
|
cw = hdac_widget_get(devinfo, k);
|
|
|
|
if (cw == NULL || cw->enable == 0)
|
|
|
|
continue;
|
|
|
|
for (j = 0; j < cw->nconns; j++) {
|
|
|
|
if (cw->connsenable[j] && cw->conns[j] == i) {
|
|
|
|
found = 1;
|
|
|
|
break;
|
|
|
|
}
|
2006-10-01 11:13:00 +00:00
|
|
|
}
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
}
|
|
|
|
if (found == 0) {
|
|
|
|
w->enable = 0;
|
|
|
|
done = 0;
|
2008-09-16 20:03:34 +00:00
|
|
|
HDA_BOOTHVERBOSE(
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
device_printf(devinfo->codec->sc->dev,
|
|
|
|
" Disabling nid %d due to all it's"
|
|
|
|
" consumers disabled.\n", w->nid);
|
|
|
|
);
|
2006-10-01 11:13:00 +00:00
|
|
|
}
|
|
|
|
}
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
} while (done == 0);
|
|
|
|
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
hdac_audio_disable_unas(struct hdac_devinfo *devinfo)
|
|
|
|
{
|
|
|
|
struct hdac_audio_as *as = devinfo->function.audio.as;
|
|
|
|
struct hdac_widget *w, *cw;
|
|
|
|
struct hdac_audio_ctl *ctl;
|
|
|
|
int i, j, k;
|
|
|
|
|
|
|
|
/* Disable unassosiated widgets. */
|
|
|
|
for (i = devinfo->startnode; i < devinfo->endnode; i++) {
|
|
|
|
w = hdac_widget_get(devinfo, i);
|
|
|
|
if (w == NULL || w->enable == 0)
|
|
|
|
continue;
|
|
|
|
if (w->bindas == -1) {
|
|
|
|
w->enable = 0;
|
2008-09-16 20:03:34 +00:00
|
|
|
HDA_BOOTHVERBOSE(
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
device_printf(devinfo->codec->sc->dev,
|
|
|
|
" Disabling unassociated nid %d.\n",
|
|
|
|
w->nid);
|
|
|
|
);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
/* Disable input connections on input pin and
|
|
|
|
* output on output. */
|
|
|
|
for (i = devinfo->startnode; i < devinfo->endnode; i++) {
|
|
|
|
w = hdac_widget_get(devinfo, i);
|
|
|
|
if (w == NULL || w->enable == 0)
|
|
|
|
continue;
|
|
|
|
if (w->type != HDA_PARAM_AUDIO_WIDGET_CAP_TYPE_PIN_COMPLEX)
|
|
|
|
continue;
|
|
|
|
if (w->bindas < 0)
|
|
|
|
continue;
|
|
|
|
if (as[w->bindas].dir == HDA_CTL_IN) {
|
|
|
|
for (j = 0; j < w->nconns; j++) {
|
|
|
|
if (w->connsenable[j] == 0)
|
|
|
|
continue;
|
|
|
|
w->connsenable[j] = 0;
|
2008-09-16 20:03:34 +00:00
|
|
|
HDA_BOOTHVERBOSE(
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
device_printf(devinfo->codec->sc->dev,
|
|
|
|
" Disabling connection to input pin "
|
|
|
|
"nid %d conn %d.\n",
|
|
|
|
i, j);
|
|
|
|
);
|
|
|
|
}
|
|
|
|
ctl = hdac_audio_ctl_amp_get(devinfo, w->nid,
|
|
|
|
HDA_CTL_IN, -1, 1);
|
|
|
|
if (ctl && ctl->enable) {
|
|
|
|
ctl->forcemute = 1;
|
|
|
|
ctl->muted = HDA_AMP_MUTE_ALL;
|
|
|
|
ctl->left = 0;
|
|
|
|
ctl->right = 0;
|
|
|
|
ctl->enable = 0;
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
ctl = hdac_audio_ctl_amp_get(devinfo, w->nid,
|
|
|
|
HDA_CTL_OUT, -1, 1);
|
|
|
|
if (ctl && ctl->enable) {
|
|
|
|
ctl->forcemute = 1;
|
|
|
|
ctl->muted = HDA_AMP_MUTE_ALL;
|
|
|
|
ctl->left = 0;
|
|
|
|
ctl->right = 0;
|
|
|
|
ctl->enable = 0;
|
|
|
|
}
|
|
|
|
for (k = devinfo->startnode; k < devinfo->endnode; k++) {
|
|
|
|
cw = hdac_widget_get(devinfo, k);
|
|
|
|
if (cw == NULL || cw->enable == 0)
|
|
|
|
continue;
|
|
|
|
for (j = 0; j < cw->nconns; j++) {
|
|
|
|
if (cw->connsenable[j] && cw->conns[j] == i) {
|
|
|
|
cw->connsenable[j] = 0;
|
2008-09-16 20:03:34 +00:00
|
|
|
HDA_BOOTHVERBOSE(
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
device_printf(devinfo->codec->sc->dev,
|
|
|
|
" Disabling connection from output pin "
|
|
|
|
"nid %d conn %d cnid %d.\n",
|
|
|
|
k, j, i);
|
|
|
|
);
|
|
|
|
if (cw->type == HDA_PARAM_AUDIO_WIDGET_CAP_TYPE_PIN_COMPLEX &&
|
|
|
|
cw->nconns > 1)
|
|
|
|
continue;
|
|
|
|
ctl = hdac_audio_ctl_amp_get(devinfo, k,
|
|
|
|
HDA_CTL_IN, j, 1);
|
|
|
|
if (ctl && ctl->enable) {
|
|
|
|
ctl->forcemute = 1;
|
|
|
|
ctl->muted = HDA_AMP_MUTE_ALL;
|
|
|
|
ctl->left = 0;
|
|
|
|
ctl->right = 0;
|
|
|
|
ctl->enable = 0;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2006-10-01 11:13:00 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
static void
|
|
|
|
hdac_audio_disable_notselected(struct hdac_devinfo *devinfo)
|
|
|
|
{
|
|
|
|
struct hdac_audio_as *as = devinfo->function.audio.as;
|
|
|
|
struct hdac_widget *w;
|
|
|
|
int i, j;
|
|
|
|
|
|
|
|
/* On playback path we can safely disable all unseleted inputs. */
|
|
|
|
for (i = devinfo->startnode; i < devinfo->endnode; i++) {
|
|
|
|
w = hdac_widget_get(devinfo, i);
|
|
|
|
if (w == NULL || w->enable == 0)
|
|
|
|
continue;
|
|
|
|
if (w->nconns <= 1)
|
|
|
|
continue;
|
|
|
|
if (w->type == HDA_PARAM_AUDIO_WIDGET_CAP_TYPE_AUDIO_MIXER)
|
|
|
|
continue;
|
|
|
|
if (w->bindas < 0 || as[w->bindas].dir == HDA_CTL_IN)
|
|
|
|
continue;
|
|
|
|
for (j = 0; j < w->nconns; j++) {
|
|
|
|
if (w->connsenable[j] == 0)
|
|
|
|
continue;
|
|
|
|
if (w->selconn < 0 || w->selconn == j)
|
|
|
|
continue;
|
|
|
|
w->connsenable[j] = 0;
|
2008-09-16 20:03:34 +00:00
|
|
|
HDA_BOOTHVERBOSE(
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
device_printf(devinfo->codec->sc->dev,
|
|
|
|
" Disabling unselected connection "
|
|
|
|
"nid %d conn %d.\n",
|
|
|
|
i, j);
|
|
|
|
);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
hdac_audio_disable_crossas(struct hdac_devinfo *devinfo)
|
2006-10-01 11:13:00 +00:00
|
|
|
{
|
|
|
|
struct hdac_widget *w, *cw;
|
|
|
|
struct hdac_audio_ctl *ctl;
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
int i, j;
|
2006-10-01 11:13:00 +00:00
|
|
|
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
/* Disable crossassociatement connections. */
|
|
|
|
/* ... using selectors */
|
|
|
|
for (i = devinfo->startnode; i < devinfo->endnode; i++) {
|
|
|
|
w = hdac_widget_get(devinfo, i);
|
|
|
|
if (w == NULL || w->enable == 0)
|
|
|
|
continue;
|
|
|
|
if (w->nconns <= 1)
|
2006-10-01 11:13:00 +00:00
|
|
|
continue;
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
if (w->type == HDA_PARAM_AUDIO_WIDGET_CAP_TYPE_AUDIO_MIXER)
|
|
|
|
continue;
|
|
|
|
if (w->bindas == -2)
|
|
|
|
continue;
|
|
|
|
for (j = 0; j < w->nconns; j++) {
|
|
|
|
if (w->connsenable[j] == 0)
|
|
|
|
continue;
|
|
|
|
cw = hdac_widget_get(devinfo, w->conns[j]);
|
|
|
|
if (cw == NULL || w->enable == 0)
|
|
|
|
continue;
|
|
|
|
if (w->bindas == cw->bindas || cw->bindas == -2)
|
|
|
|
continue;
|
|
|
|
w->connsenable[j] = 0;
|
2008-09-16 20:03:34 +00:00
|
|
|
HDA_BOOTHVERBOSE(
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
device_printf(devinfo->codec->sc->dev,
|
|
|
|
" Disabling crossassociatement connection "
|
|
|
|
"nid %d conn %d cnid %d.\n",
|
|
|
|
i, j, cw->nid);
|
|
|
|
);
|
2006-10-01 11:13:00 +00:00
|
|
|
}
|
|
|
|
}
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
/* ... using controls */
|
|
|
|
i = 0;
|
|
|
|
while ((ctl = hdac_audio_ctl_each(devinfo, &i)) != NULL) {
|
|
|
|
if (ctl->enable == 0 || ctl->childwidget == NULL)
|
2006-10-01 11:13:00 +00:00
|
|
|
continue;
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
if (ctl->widget->bindas == -2 ||
|
|
|
|
ctl->childwidget->bindas == -2)
|
2006-10-01 11:13:00 +00:00
|
|
|
continue;
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
if (ctl->widget->bindas != ctl->childwidget->bindas) {
|
|
|
|
ctl->forcemute = 1;
|
|
|
|
ctl->muted = HDA_AMP_MUTE_ALL;
|
|
|
|
ctl->left = 0;
|
|
|
|
ctl->right = 0;
|
|
|
|
ctl->enable = 0;
|
|
|
|
if (ctl->ndir == HDA_CTL_IN)
|
|
|
|
ctl->widget->connsenable[ctl->index] = 0;
|
2008-09-16 20:03:34 +00:00
|
|
|
HDA_BOOTHVERBOSE(
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
device_printf(devinfo->codec->sc->dev,
|
|
|
|
" Disabling crossassociatement connection "
|
|
|
|
"ctl %d nid %d cnid %d.\n", i,
|
|
|
|
ctl->widget->nid,
|
|
|
|
ctl->childwidget->nid);
|
|
|
|
);
|
2006-10-01 11:13:00 +00:00
|
|
|
}
|
|
|
|
}
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
|
2006-10-01 11:13:00 +00:00
|
|
|
}
|
|
|
|
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
#define HDA_CTL_GIVE(ctl) ((ctl)->step?1:0)
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Find controls to control amplification for source.
|
|
|
|
*/
|
2006-10-01 11:13:00 +00:00
|
|
|
static int
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
hdac_audio_ctl_source_amp(struct hdac_devinfo *devinfo, nid_t nid, int index,
|
|
|
|
int ossdev, int ctlable, int depth, int need)
|
2006-10-01 11:13:00 +00:00
|
|
|
{
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
struct hdac_widget *w, *wc;
|
|
|
|
struct hdac_audio_ctl *ctl;
|
|
|
|
int i, j, conns = 0, rneed;
|
|
|
|
|
2006-10-01 11:13:00 +00:00
|
|
|
if (depth > HDA_PARSE_MAXDEPTH)
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
return (need);
|
2006-10-01 11:13:00 +00:00
|
|
|
|
|
|
|
w = hdac_widget_get(devinfo, nid);
|
|
|
|
if (w == NULL || w->enable == 0)
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
return (need);
|
|
|
|
|
|
|
|
/* Count number of active inputs. */
|
|
|
|
if (depth > 0) {
|
|
|
|
for (j = 0; j < w->nconns; j++) {
|
|
|
|
if (w->connsenable[j])
|
|
|
|
conns++;
|
2006-10-01 11:13:00 +00:00
|
|
|
}
|
|
|
|
}
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
|
|
|
|
/* If this is not a first step - use input mixer.
|
|
|
|
Pins have common input ctl so care must be taken. */
|
|
|
|
if (depth > 0 && ctlable && (conns == 1 ||
|
|
|
|
w->type != HDA_PARAM_AUDIO_WIDGET_CAP_TYPE_PIN_COMPLEX)) {
|
|
|
|
ctl = hdac_audio_ctl_amp_get(devinfo, w->nid, HDA_CTL_IN,
|
|
|
|
index, 1);
|
|
|
|
if (ctl) {
|
|
|
|
if (HDA_CTL_GIVE(ctl) & need)
|
|
|
|
ctl->ossmask |= (1 << ossdev);
|
|
|
|
else
|
|
|
|
ctl->possmask |= (1 << ossdev);
|
|
|
|
need &= ~HDA_CTL_GIVE(ctl);
|
|
|
|
}
|
2006-10-01 11:13:00 +00:00
|
|
|
}
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
|
|
|
|
/* If widget has own ossdev - not traverse it.
|
|
|
|
It will be traversed on it's own. */
|
|
|
|
if (w->ossdev >= 0 && depth > 0)
|
|
|
|
return (need);
|
|
|
|
|
|
|
|
/* We must not traverse pin */
|
|
|
|
if ((w->type == HDA_PARAM_AUDIO_WIDGET_CAP_TYPE_AUDIO_INPUT ||
|
|
|
|
w->type == HDA_PARAM_AUDIO_WIDGET_CAP_TYPE_PIN_COMPLEX) &&
|
|
|
|
depth > 0)
|
|
|
|
return (need);
|
|
|
|
|
|
|
|
/* record that this widget exports such signal, */
|
|
|
|
w->ossmask |= (1 << ossdev);
|
|
|
|
|
|
|
|
/* If signals mixed, we can't assign controls farther.
|
|
|
|
* Ignore this on depth zero. Caller must knows why.
|
|
|
|
* Ignore this for static selectors if this input selected.
|
|
|
|
*/
|
|
|
|
if (conns > 1)
|
|
|
|
ctlable = 0;
|
|
|
|
|
|
|
|
if (ctlable) {
|
|
|
|
ctl = hdac_audio_ctl_amp_get(devinfo, w->nid, HDA_CTL_OUT, -1, 1);
|
|
|
|
if (ctl) {
|
|
|
|
if (HDA_CTL_GIVE(ctl) & need)
|
|
|
|
ctl->ossmask |= (1 << ossdev);
|
|
|
|
else
|
|
|
|
ctl->possmask |= (1 << ossdev);
|
|
|
|
need &= ~HDA_CTL_GIVE(ctl);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
rneed = 0;
|
|
|
|
for (i = devinfo->startnode; i < devinfo->endnode; i++) {
|
|
|
|
wc = hdac_widget_get(devinfo, i);
|
|
|
|
if (wc == NULL || wc->enable == 0)
|
|
|
|
continue;
|
|
|
|
for (j = 0; j < wc->nconns; j++) {
|
|
|
|
if (wc->connsenable[j] && wc->conns[j] == nid) {
|
|
|
|
rneed |= hdac_audio_ctl_source_amp(devinfo,
|
|
|
|
wc->nid, j, ossdev, ctlable, depth + 1, need);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
rneed &= need;
|
|
|
|
|
|
|
|
return (rneed);
|
2006-10-01 11:13:00 +00:00
|
|
|
}
|
|
|
|
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
/*
|
|
|
|
* Find controls to control amplification for destination.
|
|
|
|
*/
|
|
|
|
static void
|
|
|
|
hdac_audio_ctl_dest_amp(struct hdac_devinfo *devinfo, nid_t nid,
|
|
|
|
int ossdev, int depth, int need)
|
2006-10-01 11:13:00 +00:00
|
|
|
{
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
struct hdac_audio_as *as = devinfo->function.audio.as;
|
|
|
|
struct hdac_widget *w, *wc;
|
|
|
|
struct hdac_audio_ctl *ctl;
|
|
|
|
int i, j, consumers;
|
|
|
|
|
|
|
|
if (depth > HDA_PARSE_MAXDEPTH)
|
|
|
|
return;
|
2006-10-01 11:13:00 +00:00
|
|
|
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
w = hdac_widget_get(devinfo, nid);
|
|
|
|
if (w == NULL || w->enable == 0)
|
|
|
|
return;
|
2006-10-01 11:13:00 +00:00
|
|
|
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
if (depth > 0) {
|
|
|
|
/* If this node produce output for several consumers,
|
|
|
|
we can't touch it. */
|
|
|
|
consumers = 0;
|
|
|
|
for (i = devinfo->startnode; i < devinfo->endnode; i++) {
|
|
|
|
wc = hdac_widget_get(devinfo, i);
|
|
|
|
if (wc == NULL || wc->enable == 0)
|
|
|
|
continue;
|
|
|
|
for (j = 0; j < wc->nconns; j++) {
|
|
|
|
if (wc->connsenable[j] && wc->conns[j] == nid)
|
|
|
|
consumers++;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
/* The only exception is if real HP redirection is configured
|
|
|
|
and this is a duplication point.
|
|
|
|
XXX: Actually exception is not completely correct.
|
|
|
|
XXX: Duplication point check is not perfect. */
|
|
|
|
if ((consumers == 2 && (w->bindas < 0 ||
|
|
|
|
as[w->bindas].hpredir < 0 || as[w->bindas].fakeredir ||
|
|
|
|
(w->bindseqmask & (1 << 15)) == 0)) ||
|
|
|
|
consumers > 2)
|
|
|
|
return;
|
|
|
|
|
|
|
|
/* Else use it's output mixer. */
|
|
|
|
ctl = hdac_audio_ctl_amp_get(devinfo, w->nid,
|
|
|
|
HDA_CTL_OUT, -1, 1);
|
|
|
|
if (ctl) {
|
|
|
|
if (HDA_CTL_GIVE(ctl) & need)
|
|
|
|
ctl->ossmask |= (1 << ossdev);
|
|
|
|
else
|
|
|
|
ctl->possmask |= (1 << ossdev);
|
|
|
|
need &= ~HDA_CTL_GIVE(ctl);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/* We must not traverse pin */
|
|
|
|
if (w->type == HDA_PARAM_AUDIO_WIDGET_CAP_TYPE_PIN_COMPLEX &&
|
|
|
|
depth > 0)
|
|
|
|
return;
|
|
|
|
|
|
|
|
for (i = 0; i < w->nconns; i++) {
|
|
|
|
int tneed = need;
|
|
|
|
if (w->connsenable[i] == 0)
|
|
|
|
continue;
|
|
|
|
ctl = hdac_audio_ctl_amp_get(devinfo, w->nid,
|
|
|
|
HDA_CTL_IN, i, 1);
|
|
|
|
if (ctl) {
|
|
|
|
if (HDA_CTL_GIVE(ctl) & tneed)
|
|
|
|
ctl->ossmask |= (1 << ossdev);
|
|
|
|
else
|
|
|
|
ctl->possmask |= (1 << ossdev);
|
|
|
|
tneed &= ~HDA_CTL_GIVE(ctl);
|
|
|
|
}
|
|
|
|
hdac_audio_ctl_dest_amp(devinfo, w->conns[i], ossdev,
|
|
|
|
depth + 1, tneed);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Assign OSS names to sound sources
|
|
|
|
*/
|
|
|
|
static void
|
|
|
|
hdac_audio_assign_names(struct hdac_devinfo *devinfo)
|
|
|
|
{
|
|
|
|
struct hdac_audio_as *as = devinfo->function.audio.as;
|
|
|
|
struct hdac_widget *w;
|
|
|
|
int i, j;
|
|
|
|
int type = -1, use, used = 0;
|
|
|
|
static const int types[7][13] = {
|
|
|
|
{ SOUND_MIXER_LINE, SOUND_MIXER_LINE1, SOUND_MIXER_LINE2,
|
|
|
|
SOUND_MIXER_LINE3, -1 }, /* line */
|
|
|
|
{ SOUND_MIXER_MONITOR, SOUND_MIXER_MIC, -1 }, /* int mic */
|
|
|
|
{ SOUND_MIXER_MIC, SOUND_MIXER_MONITOR, -1 }, /* ext mic */
|
|
|
|
{ SOUND_MIXER_CD, -1 }, /* cd */
|
|
|
|
{ SOUND_MIXER_SPEAKER, -1 }, /* speaker */
|
|
|
|
{ SOUND_MIXER_DIGITAL1, SOUND_MIXER_DIGITAL2, SOUND_MIXER_DIGITAL3,
|
|
|
|
-1 }, /* digital */
|
|
|
|
{ SOUND_MIXER_LINE, SOUND_MIXER_LINE1, SOUND_MIXER_LINE2,
|
|
|
|
SOUND_MIXER_LINE3, SOUND_MIXER_PHONEIN, SOUND_MIXER_PHONEOUT,
|
|
|
|
SOUND_MIXER_VIDEO, SOUND_MIXER_RADIO, SOUND_MIXER_DIGITAL1,
|
|
|
|
SOUND_MIXER_DIGITAL2, SOUND_MIXER_DIGITAL3, SOUND_MIXER_MONITOR,
|
|
|
|
-1 } /* others */
|
|
|
|
};
|
|
|
|
|
|
|
|
/* Surely known names */
|
|
|
|
for (i = devinfo->startnode; i < devinfo->endnode; i++) {
|
|
|
|
w = hdac_widget_get(devinfo, i);
|
|
|
|
if (w == NULL || w->enable == 0)
|
|
|
|
continue;
|
|
|
|
if (w->bindas == -1)
|
|
|
|
continue;
|
|
|
|
use = -1;
|
|
|
|
switch (w->type) {
|
|
|
|
case HDA_PARAM_AUDIO_WIDGET_CAP_TYPE_PIN_COMPLEX:
|
|
|
|
if (as[w->bindas].dir == HDA_CTL_OUT)
|
|
|
|
break;
|
|
|
|
type = -1;
|
|
|
|
switch (w->wclass.pin.config & HDA_CONFIG_DEFAULTCONF_DEVICE_MASK) {
|
|
|
|
case HDA_CONFIG_DEFAULTCONF_DEVICE_LINE_IN:
|
|
|
|
type = 0;
|
|
|
|
break;
|
|
|
|
case HDA_CONFIG_DEFAULTCONF_DEVICE_MIC_IN:
|
|
|
|
if ((w->wclass.pin.config & HDA_CONFIG_DEFAULTCONF_CONNECTIVITY_MASK)
|
|
|
|
== HDA_CONFIG_DEFAULTCONF_CONNECTIVITY_JACK)
|
|
|
|
break;
|
|
|
|
type = 1;
|
|
|
|
break;
|
|
|
|
case HDA_CONFIG_DEFAULTCONF_DEVICE_CD:
|
|
|
|
type = 3;
|
|
|
|
break;
|
|
|
|
case HDA_CONFIG_DEFAULTCONF_DEVICE_SPEAKER:
|
|
|
|
type = 4;
|
|
|
|
break;
|
|
|
|
case HDA_CONFIG_DEFAULTCONF_DEVICE_SPDIF_IN:
|
|
|
|
case HDA_CONFIG_DEFAULTCONF_DEVICE_DIGITAL_OTHER_IN:
|
|
|
|
type = 5;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
if (type == -1)
|
|
|
|
break;
|
|
|
|
j = 0;
|
|
|
|
while (types[type][j] >= 0 &&
|
|
|
|
(used & (1 << types[type][j])) != 0) {
|
|
|
|
j++;
|
|
|
|
}
|
|
|
|
if (types[type][j] >= 0)
|
|
|
|
use = types[type][j];
|
|
|
|
break;
|
|
|
|
case HDA_PARAM_AUDIO_WIDGET_CAP_TYPE_AUDIO_OUTPUT:
|
|
|
|
use = SOUND_MIXER_PCM;
|
|
|
|
break;
|
|
|
|
case HDA_PARAM_AUDIO_WIDGET_CAP_TYPE_BEEP_WIDGET:
|
|
|
|
use = SOUND_MIXER_SPEAKER;
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
if (use >= 0) {
|
|
|
|
w->ossdev = use;
|
|
|
|
used |= (1 << use);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
/* Semi-known names */
|
2006-10-01 11:13:00 +00:00
|
|
|
for (i = devinfo->startnode; i < devinfo->endnode; i++) {
|
|
|
|
w = hdac_widget_get(devinfo, i);
|
|
|
|
if (w == NULL || w->enable == 0)
|
|
|
|
continue;
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
if (w->ossdev >= 0)
|
|
|
|
continue;
|
|
|
|
if (w->bindas == -1)
|
|
|
|
continue;
|
2006-10-01 11:13:00 +00:00
|
|
|
if (w->type != HDA_PARAM_AUDIO_WIDGET_CAP_TYPE_PIN_COMPLEX)
|
|
|
|
continue;
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
if (as[w->bindas].dir == HDA_CTL_OUT)
|
|
|
|
continue;
|
|
|
|
type = -1;
|
|
|
|
switch (w->wclass.pin.config & HDA_CONFIG_DEFAULTCONF_DEVICE_MASK) {
|
|
|
|
case HDA_CONFIG_DEFAULTCONF_DEVICE_LINE_OUT:
|
|
|
|
case HDA_CONFIG_DEFAULTCONF_DEVICE_SPEAKER:
|
|
|
|
case HDA_CONFIG_DEFAULTCONF_DEVICE_HP_OUT:
|
|
|
|
case HDA_CONFIG_DEFAULTCONF_DEVICE_AUX:
|
|
|
|
type = 0;
|
|
|
|
break;
|
|
|
|
case HDA_CONFIG_DEFAULTCONF_DEVICE_MIC_IN:
|
|
|
|
type = 2;
|
|
|
|
break;
|
|
|
|
case HDA_CONFIG_DEFAULTCONF_DEVICE_SPDIF_OUT:
|
|
|
|
case HDA_CONFIG_DEFAULTCONF_DEVICE_DIGITAL_OTHER_OUT:
|
|
|
|
type = 5;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
if (type == -1)
|
|
|
|
break;
|
|
|
|
j = 0;
|
|
|
|
while (types[type][j] >= 0 &&
|
|
|
|
(used & (1 << types[type][j])) != 0) {
|
|
|
|
j++;
|
|
|
|
}
|
|
|
|
if (types[type][j] >= 0) {
|
|
|
|
w->ossdev = types[type][j];
|
|
|
|
used |= (1 << types[type][j]);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
/* Others */
|
|
|
|
for (i = devinfo->startnode; i < devinfo->endnode; i++) {
|
|
|
|
w = hdac_widget_get(devinfo, i);
|
|
|
|
if (w == NULL || w->enable == 0)
|
|
|
|
continue;
|
|
|
|
if (w->ossdev >= 0)
|
2006-10-01 11:13:00 +00:00
|
|
|
continue;
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
if (w->bindas == -1)
|
2006-10-01 11:13:00 +00:00
|
|
|
continue;
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
if (w->type != HDA_PARAM_AUDIO_WIDGET_CAP_TYPE_PIN_COMPLEX)
|
|
|
|
continue;
|
|
|
|
if (as[w->bindas].dir == HDA_CTL_OUT)
|
|
|
|
continue;
|
|
|
|
j = 0;
|
|
|
|
while (types[6][j] >= 0 &&
|
|
|
|
(used & (1 << types[6][j])) != 0) {
|
|
|
|
j++;
|
|
|
|
}
|
|
|
|
if (types[6][j] >= 0) {
|
|
|
|
w->ossdev = types[6][j];
|
|
|
|
used |= (1 << types[6][j]);
|
2006-10-01 11:13:00 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
hdac_audio_build_tree(struct hdac_devinfo *devinfo)
|
|
|
|
{
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
struct hdac_audio_as *as = devinfo->function.audio.as;
|
|
|
|
int j, res;
|
2006-10-01 11:13:00 +00:00
|
|
|
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
/* Trace all associations in order of their numbers, */
|
|
|
|
for (j = 0; j < devinfo->function.audio.ascnt; j++) {
|
|
|
|
if (as[j].enable == 0)
|
|
|
|
continue;
|
- Fix wrong id for ALC882, add ALC883 id.
- 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"
2006-10-06 18:59:27 +00:00
|
|
|
HDA_BOOTVERBOSE(
|
2006-10-01 11:13:00 +00:00
|
|
|
device_printf(devinfo->codec->sc->dev,
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
"Tracing association %d (%d)\n", j, as[j].index);
|
2006-10-01 11:13:00 +00:00
|
|
|
);
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
if (as[j].dir == HDA_CTL_OUT) {
|
|
|
|
retry:
|
|
|
|
res = hdac_audio_trace_as_out(devinfo, j, 0);
|
|
|
|
if (res == 0 && as[j].hpredir >= 0 &&
|
|
|
|
as[j].fakeredir == 0) {
|
|
|
|
/* If codec can't do analog HP redirection
|
|
|
|
try to make it using one more DAC. */
|
|
|
|
as[j].fakeredir = 1;
|
|
|
|
goto retry;
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
res = hdac_audio_trace_as_in(devinfo, j);
|
|
|
|
}
|
|
|
|
if (res) {
|
|
|
|
HDA_BOOTVERBOSE(
|
|
|
|
device_printf(devinfo->codec->sc->dev,
|
|
|
|
"Association %d (%d) trace succeded\n",
|
|
|
|
j, as[j].index);
|
|
|
|
);
|
|
|
|
} else {
|
|
|
|
HDA_BOOTVERBOSE(
|
|
|
|
device_printf(devinfo->codec->sc->dev,
|
|
|
|
"Association %d (%d) trace failed\n",
|
|
|
|
j, as[j].index);
|
|
|
|
);
|
|
|
|
as[j].enable = 0;
|
|
|
|
}
|
2006-10-01 11:13:00 +00:00
|
|
|
}
|
|
|
|
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
/* Trace mixer and beeper pseudo associations. */
|
|
|
|
hdac_audio_trace_as_extra(devinfo);
|
|
|
|
}
|
2006-10-01 11:13:00 +00:00
|
|
|
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
static void
|
|
|
|
hdac_audio_assign_mixers(struct hdac_devinfo *devinfo)
|
|
|
|
{
|
|
|
|
struct hdac_audio_as *as = devinfo->function.audio.as;
|
|
|
|
struct hdac_audio_ctl *ctl;
|
|
|
|
struct hdac_widget *w;
|
|
|
|
int i;
|
2006-10-01 11:13:00 +00:00
|
|
|
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
/* Assign mixers to the tree. */
|
2006-10-01 11:13:00 +00:00
|
|
|
for (i = devinfo->startnode; i < devinfo->endnode; i++) {
|
|
|
|
w = hdac_widget_get(devinfo, i);
|
|
|
|
if (w == NULL || w->enable == 0)
|
|
|
|
continue;
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
if (w->type == HDA_PARAM_AUDIO_WIDGET_CAP_TYPE_AUDIO_OUTPUT ||
|
|
|
|
w->type == HDA_PARAM_AUDIO_WIDGET_CAP_TYPE_BEEP_WIDGET ||
|
|
|
|
(w->type == HDA_PARAM_AUDIO_WIDGET_CAP_TYPE_PIN_COMPLEX &&
|
|
|
|
as[w->bindas].dir == HDA_CTL_IN)) {
|
|
|
|
if (w->ossdev < 0)
|
|
|
|
continue;
|
|
|
|
hdac_audio_ctl_source_amp(devinfo, w->nid, -1,
|
|
|
|
w->ossdev, 1, 0, 1);
|
|
|
|
} else if ((w->pflags & HDA_ADC_MONITOR) != 0) {
|
|
|
|
if (w->ossdev < 0)
|
|
|
|
continue;
|
|
|
|
if (hdac_audio_ctl_source_amp(devinfo, w->nid, -1,
|
|
|
|
w->ossdev, 1, 0, 1)) {
|
|
|
|
/* If we are unable to control input monitor
|
|
|
|
as source - try to control it as destination. */
|
|
|
|
hdac_audio_ctl_dest_amp(devinfo, w->nid,
|
|
|
|
w->ossdev, 0, 1);
|
2006-10-01 11:13:00 +00:00
|
|
|
}
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
} else if (w->type == HDA_PARAM_AUDIO_WIDGET_CAP_TYPE_AUDIO_INPUT) {
|
|
|
|
hdac_audio_ctl_dest_amp(devinfo, w->nid,
|
|
|
|
SOUND_MIXER_RECLEV, 0, 1);
|
|
|
|
} else if (w->type == HDA_PARAM_AUDIO_WIDGET_CAP_TYPE_PIN_COMPLEX &&
|
|
|
|
as[w->bindas].dir == HDA_CTL_OUT) {
|
|
|
|
hdac_audio_ctl_dest_amp(devinfo, w->nid,
|
|
|
|
SOUND_MIXER_VOLUME, 0, 1);
|
2006-10-01 11:13:00 +00:00
|
|
|
}
|
|
|
|
}
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
/* Treat unrequired as possible. */
|
|
|
|
i = 0;
|
|
|
|
while ((ctl = hdac_audio_ctl_each(devinfo, &i)) != NULL) {
|
|
|
|
if (ctl->ossmask == 0)
|
|
|
|
ctl->ossmask = ctl->possmask;
|
|
|
|
}
|
|
|
|
}
|
2006-10-01 11:13:00 +00:00
|
|
|
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
static void
|
|
|
|
hdac_audio_prepare_pin_ctrl(struct hdac_devinfo *devinfo)
|
|
|
|
{
|
|
|
|
struct hdac_audio_as *as = devinfo->function.audio.as;
|
|
|
|
struct hdac_widget *w;
|
|
|
|
uint32_t pincap;
|
|
|
|
int i;
|
|
|
|
|
|
|
|
for (i = 0; i < devinfo->nodecnt; i++) {
|
|
|
|
w = &devinfo->widget[i];
|
|
|
|
if (w == NULL)
|
2006-10-01 11:13:00 +00:00
|
|
|
continue;
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
if (w->type != HDA_PARAM_AUDIO_WIDGET_CAP_TYPE_PIN_COMPLEX)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
pincap = w->wclass.pin.cap;
|
|
|
|
|
|
|
|
/* Disable everything. */
|
|
|
|
w->wclass.pin.ctrl &= ~(
|
|
|
|
HDA_CMD_SET_PIN_WIDGET_CTRL_HPHN_ENABLE |
|
|
|
|
HDA_CMD_SET_PIN_WIDGET_CTRL_OUT_ENABLE |
|
|
|
|
HDA_CMD_SET_PIN_WIDGET_CTRL_IN_ENABLE |
|
|
|
|
HDA_CMD_SET_PIN_WIDGET_CTRL_VREF_ENABLE_MASK);
|
|
|
|
|
|
|
|
if (w->enable == 0 ||
|
|
|
|
w->bindas < 0 || as[w->bindas].enable == 0) {
|
|
|
|
/* Pin is unused so left it disabled. */
|
2006-10-01 11:13:00 +00:00
|
|
|
continue;
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
} else if (as[w->bindas].dir == HDA_CTL_IN) {
|
|
|
|
/* Input pin, configure for input. */
|
|
|
|
if (HDA_PARAM_PIN_CAP_INPUT_CAP(pincap))
|
|
|
|
w->wclass.pin.ctrl |=
|
|
|
|
HDA_CMD_SET_PIN_WIDGET_CTRL_IN_ENABLE;
|
|
|
|
|
|
|
|
if ((devinfo->function.audio.quirks & HDA_QUIRK_IVREF100) &&
|
|
|
|
HDA_PARAM_PIN_CAP_VREF_CTRL_100(pincap))
|
|
|
|
w->wclass.pin.ctrl |=
|
|
|
|
HDA_CMD_SET_PIN_WIDGET_CTRL_VREF_ENABLE(
|
|
|
|
HDA_CMD_PIN_WIDGET_CTRL_VREF_ENABLE_100);
|
|
|
|
else if ((devinfo->function.audio.quirks & HDA_QUIRK_IVREF80) &&
|
|
|
|
HDA_PARAM_PIN_CAP_VREF_CTRL_80(pincap))
|
|
|
|
w->wclass.pin.ctrl |=
|
|
|
|
HDA_CMD_SET_PIN_WIDGET_CTRL_VREF_ENABLE(
|
|
|
|
HDA_CMD_PIN_WIDGET_CTRL_VREF_ENABLE_80);
|
|
|
|
else if ((devinfo->function.audio.quirks & HDA_QUIRK_IVREF50) &&
|
|
|
|
HDA_PARAM_PIN_CAP_VREF_CTRL_50(pincap))
|
|
|
|
w->wclass.pin.ctrl |=
|
|
|
|
HDA_CMD_SET_PIN_WIDGET_CTRL_VREF_ENABLE(
|
|
|
|
HDA_CMD_PIN_WIDGET_CTRL_VREF_ENABLE_50);
|
|
|
|
} else {
|
|
|
|
/* Output pin, configure for output. */
|
|
|
|
if (HDA_PARAM_PIN_CAP_OUTPUT_CAP(pincap))
|
|
|
|
w->wclass.pin.ctrl |=
|
|
|
|
HDA_CMD_SET_PIN_WIDGET_CTRL_OUT_ENABLE;
|
|
|
|
|
|
|
|
if (HDA_PARAM_PIN_CAP_HEADPHONE_CAP(pincap) &&
|
|
|
|
(w->wclass.pin.config &
|
|
|
|
HDA_CONFIG_DEFAULTCONF_DEVICE_MASK) ==
|
|
|
|
HDA_CONFIG_DEFAULTCONF_DEVICE_HP_OUT)
|
|
|
|
w->wclass.pin.ctrl |=
|
|
|
|
HDA_CMD_SET_PIN_WIDGET_CTRL_HPHN_ENABLE;
|
|
|
|
|
|
|
|
if ((devinfo->function.audio.quirks & HDA_QUIRK_OVREF100) &&
|
|
|
|
HDA_PARAM_PIN_CAP_VREF_CTRL_100(pincap))
|
|
|
|
w->wclass.pin.ctrl |=
|
|
|
|
HDA_CMD_SET_PIN_WIDGET_CTRL_VREF_ENABLE(
|
|
|
|
HDA_CMD_PIN_WIDGET_CTRL_VREF_ENABLE_100);
|
|
|
|
else if ((devinfo->function.audio.quirks & HDA_QUIRK_OVREF80) &&
|
|
|
|
HDA_PARAM_PIN_CAP_VREF_CTRL_80(pincap))
|
|
|
|
w->wclass.pin.ctrl |=
|
|
|
|
HDA_CMD_SET_PIN_WIDGET_CTRL_VREF_ENABLE(
|
|
|
|
HDA_CMD_PIN_WIDGET_CTRL_VREF_ENABLE_80);
|
|
|
|
else if ((devinfo->function.audio.quirks & HDA_QUIRK_OVREF50) &&
|
|
|
|
HDA_PARAM_PIN_CAP_VREF_CTRL_50(pincap))
|
|
|
|
w->wclass.pin.ctrl |=
|
|
|
|
HDA_CMD_SET_PIN_WIDGET_CTRL_VREF_ENABLE(
|
|
|
|
HDA_CMD_PIN_WIDGET_CTRL_VREF_ENABLE_50);
|
|
|
|
}
|
2006-10-01 11:13:00 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
hdac_audio_commit(struct hdac_devinfo *devinfo)
|
2006-10-01 11:13:00 +00:00
|
|
|
{
|
|
|
|
struct hdac_softc *sc = devinfo->codec->sc;
|
|
|
|
struct hdac_widget *w;
|
2006-11-29 15:15:30 +00:00
|
|
|
nid_t cad;
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
uint32_t gdata, gmask, gdir;
|
|
|
|
int commitgpio, numgpio;
|
2006-11-29 15:15:30 +00:00
|
|
|
int i;
|
2006-10-01 11:13:00 +00:00
|
|
|
|
|
|
|
cad = devinfo->codec->cad;
|
|
|
|
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
if (sc->pci_subvendor == APPLE_INTEL_MAC)
|
|
|
|
hdac_command(sc, HDA_CMD_12BIT(cad, devinfo->nid,
|
|
|
|
0x7e7, 0), cad);
|
2006-12-09 17:52:54 +00:00
|
|
|
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
gdata = 0;
|
|
|
|
gmask = 0;
|
|
|
|
gdir = 0;
|
|
|
|
commitgpio = 0;
|
2007-02-16 17:43:29 +00:00
|
|
|
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
numgpio = HDA_PARAM_GPIO_COUNT_NUM_GPIO(
|
|
|
|
devinfo->function.audio.gpio);
|
2006-12-09 17:52:54 +00:00
|
|
|
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
if (devinfo->function.audio.quirks & HDA_QUIRK_GPIOFLUSH)
|
|
|
|
commitgpio = (numgpio > 0) ? 1 : 0;
|
|
|
|
else {
|
|
|
|
for (i = 0; i < numgpio && i < HDA_GPIO_MAX; i++) {
|
|
|
|
if (!(devinfo->function.audio.quirks &
|
|
|
|
(1 << i)))
|
|
|
|
continue;
|
|
|
|
if (commitgpio == 0) {
|
|
|
|
commitgpio = 1;
|
|
|
|
HDA_BOOTVERBOSE(
|
|
|
|
gdata = hdac_command(sc,
|
|
|
|
HDA_CMD_GET_GPIO_DATA(cad,
|
|
|
|
devinfo->nid), cad);
|
|
|
|
gmask = hdac_command(sc,
|
|
|
|
HDA_CMD_GET_GPIO_ENABLE_MASK(cad,
|
|
|
|
devinfo->nid), cad);
|
|
|
|
gdir = hdac_command(sc,
|
|
|
|
HDA_CMD_GET_GPIO_DIRECTION(cad,
|
|
|
|
devinfo->nid), cad);
|
|
|
|
device_printf(sc->dev,
|
|
|
|
"GPIO init: data=0x%08x "
|
|
|
|
"mask=0x%08x dir=0x%08x\n",
|
|
|
|
gdata, gmask, gdir);
|
|
|
|
gdata = 0;
|
|
|
|
gmask = 0;
|
|
|
|
gdir = 0;
|
|
|
|
);
|
2006-12-09 17:52:54 +00:00
|
|
|
}
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
gdata |= 1 << i;
|
|
|
|
gmask |= 1 << i;
|
|
|
|
gdir |= 1 << i;
|
2006-12-09 17:52:54 +00:00
|
|
|
}
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
}
|
2006-12-09 17:52:54 +00:00
|
|
|
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
if (commitgpio != 0) {
|
|
|
|
HDA_BOOTVERBOSE(
|
|
|
|
device_printf(sc->dev,
|
|
|
|
"GPIO commit: data=0x%08x mask=0x%08x "
|
|
|
|
"dir=0x%08x\n",
|
|
|
|
gdata, gmask, gdir);
|
|
|
|
);
|
|
|
|
hdac_command(sc,
|
|
|
|
HDA_CMD_SET_GPIO_ENABLE_MASK(cad, devinfo->nid,
|
|
|
|
gmask), cad);
|
|
|
|
hdac_command(sc,
|
|
|
|
HDA_CMD_SET_GPIO_DIRECTION(cad, devinfo->nid,
|
|
|
|
gdir), cad);
|
|
|
|
hdac_command(sc,
|
|
|
|
HDA_CMD_SET_GPIO_DATA(cad, devinfo->nid,
|
|
|
|
gdata), cad);
|
2006-10-01 11:13:00 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
for (i = 0; i < devinfo->nodecnt; i++) {
|
|
|
|
w = &devinfo->widget[i];
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
if (w == NULL)
|
2006-10-01 11:13:00 +00:00
|
|
|
continue;
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
if (w->selconn == -1)
|
|
|
|
w->selconn = 0;
|
|
|
|
if (w->nconns > 0)
|
|
|
|
hdac_widget_connection_select(w, w->selconn);
|
|
|
|
if (w->type == HDA_PARAM_AUDIO_WIDGET_CAP_TYPE_PIN_COMPLEX) {
|
2006-10-01 11:13:00 +00:00
|
|
|
hdac_command(sc,
|
|
|
|
HDA_CMD_SET_PIN_WIDGET_CTRL(cad, w->nid,
|
|
|
|
w->wclass.pin.ctrl), cad);
|
|
|
|
}
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
if (w->param.eapdbtl != HDAC_INVALID) {
|
2006-10-16 14:43:22 +00:00
|
|
|
uint32_t val;
|
|
|
|
|
|
|
|
val = w->param.eapdbtl;
|
2006-10-12 15:37:43 +00:00
|
|
|
if (devinfo->function.audio.quirks &
|
2006-10-16 14:43:22 +00:00
|
|
|
HDA_QUIRK_EAPDINV)
|
|
|
|
val ^= HDA_CMD_SET_EAPD_BTL_ENABLE_EAPD;
|
2006-10-01 11:13:00 +00:00
|
|
|
hdac_command(sc,
|
|
|
|
HDA_CMD_SET_EAPD_BTL_ENABLE(cad, w->nid,
|
2006-10-16 14:43:22 +00:00
|
|
|
val), cad);
|
2006-10-01 11:13:00 +00:00
|
|
|
|
2006-10-12 15:37:43 +00:00
|
|
|
}
|
2006-10-01 11:13:00 +00:00
|
|
|
DELAY(1000);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
hdac_audio_ctl_commit(struct hdac_devinfo *devinfo)
|
|
|
|
{
|
|
|
|
struct hdac_audio_ctl *ctl;
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
int i, z;
|
2006-10-01 11:13:00 +00:00
|
|
|
|
|
|
|
i = 0;
|
|
|
|
while ((ctl = hdac_audio_ctl_each(devinfo, &i)) != NULL) {
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
if (ctl->enable == 0) {
|
|
|
|
/* Mute disabled controls. */
|
|
|
|
hdac_audio_ctl_amp_set(ctl, HDA_AMP_MUTE_ALL, 0, 0);
|
2006-10-01 11:13:00 +00:00
|
|
|
continue;
|
|
|
|
}
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
/* Init controls to 0dB amplification. */
|
|
|
|
z = ctl->offset;
|
|
|
|
if (z > ctl->step)
|
|
|
|
z = ctl->step;
|
|
|
|
hdac_audio_ctl_amp_set(ctl, HDA_AMP_MUTE_NONE, z, z);
|
2006-10-01 11:13:00 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
static void
|
|
|
|
hdac_powerup(struct hdac_devinfo *devinfo)
|
2006-10-01 11:13:00 +00:00
|
|
|
{
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
struct hdac_softc *sc = devinfo->codec->sc;
|
|
|
|
nid_t cad = devinfo->codec->cad;
|
|
|
|
int i;
|
2006-10-01 11:13:00 +00:00
|
|
|
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
hdac_command(sc,
|
|
|
|
HDA_CMD_SET_POWER_STATE(cad,
|
|
|
|
devinfo->nid, HDA_CMD_POWER_STATE_D0),
|
|
|
|
cad);
|
|
|
|
DELAY(100);
|
|
|
|
|
|
|
|
for (i = devinfo->startnode; i < devinfo->endnode; i++) {
|
|
|
|
hdac_command(sc,
|
|
|
|
HDA_CMD_SET_POWER_STATE(cad,
|
|
|
|
i, HDA_CMD_POWER_STATE_D0),
|
|
|
|
cad);
|
2006-10-01 11:13:00 +00:00
|
|
|
}
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
DELAY(1000);
|
|
|
|
}
|
|
|
|
|
|
|
|
static int
|
|
|
|
hdac_pcmchannel_setup(struct hdac_chan *ch)
|
|
|
|
{
|
|
|
|
struct hdac_devinfo *devinfo = ch->devinfo;
|
|
|
|
struct hdac_audio_as *as = devinfo->function.audio.as;
|
|
|
|
struct hdac_widget *w;
|
|
|
|
uint32_t cap, fmtcap, pcmcap;
|
|
|
|
int i, j, ret, max;
|
2006-10-01 11:13:00 +00:00
|
|
|
|
|
|
|
ch->caps = hdac_caps;
|
|
|
|
ch->caps.fmtlist = ch->fmtlist;
|
|
|
|
ch->bit16 = 1;
|
|
|
|
ch->bit32 = 0;
|
|
|
|
ch->pcmrates[0] = 48000;
|
|
|
|
ch->pcmrates[1] = 0;
|
|
|
|
|
|
|
|
ret = 0;
|
|
|
|
fmtcap = devinfo->function.audio.supp_stream_formats;
|
|
|
|
pcmcap = devinfo->function.audio.supp_pcm_size_rate;
|
|
|
|
max = (sizeof(ch->io) / sizeof(ch->io[0])) - 1;
|
|
|
|
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
for (i = 0; i < 16 && ret < max; i++) {
|
|
|
|
/* Check as is correct */
|
|
|
|
if (ch->as < 0)
|
|
|
|
break;
|
|
|
|
/* Cound only present DACs */
|
|
|
|
if (as[ch->as].dacs[i] <= 0)
|
|
|
|
continue;
|
|
|
|
/* Ignore duplicates */
|
|
|
|
for (j = 0; j < ret; j++) {
|
|
|
|
if (ch->io[j] == as[ch->as].dacs[i])
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
if (j < ret)
|
2006-10-01 11:13:00 +00:00
|
|
|
continue;
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
|
|
|
|
w = hdac_widget_get(devinfo, as[ch->as].dacs[i]);
|
|
|
|
if (w == NULL || w->enable == 0)
|
|
|
|
continue;
|
|
|
|
if (!HDA_PARAM_AUDIO_WIDGET_CAP_STEREO(w->param.widget_cap))
|
2006-10-01 11:13:00 +00:00
|
|
|
continue;
|
|
|
|
cap = w->param.supp_stream_formats;
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
/*if (HDA_PARAM_SUPP_STREAM_FORMATS_FLOAT32(cap)) {
|
2006-10-01 11:13:00 +00:00
|
|
|
}*/
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
if (!HDA_PARAM_SUPP_STREAM_FORMATS_PCM(cap) &&
|
|
|
|
!HDA_PARAM_SUPP_STREAM_FORMATS_AC3(cap))
|
2006-10-01 11:13:00 +00:00
|
|
|
continue;
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
/* Many codec does not declare AC3 support on SPDIF.
|
|
|
|
I don't beleave that they doesn't support it! */
|
|
|
|
if (HDA_PARAM_AUDIO_WIDGET_CAP_DIGITAL(w->param.widget_cap))
|
|
|
|
cap |= HDA_PARAM_SUPP_STREAM_FORMATS_AC3_MASK;
|
Welcome to Once-a-year Sound Mega-Commit. Enjoy numerous updates and fixes
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.
2006-11-26 12:24:06 +00:00
|
|
|
if (ret == 0) {
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
fmtcap = cap;
|
Welcome to Once-a-year Sound Mega-Commit. Enjoy numerous updates and fixes
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.
2006-11-26 12:24:06 +00:00
|
|
|
pcmcap = w->param.supp_pcm_size_rate;
|
|
|
|
} else {
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
fmtcap &= cap;
|
Welcome to Once-a-year Sound Mega-Commit. Enjoy numerous updates and fixes
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.
2006-11-26 12:24:06 +00:00
|
|
|
pcmcap &= w->param.supp_pcm_size_rate;
|
|
|
|
}
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
ch->io[ret++] = as[ch->as].dacs[i];
|
2006-10-01 11:13:00 +00:00
|
|
|
}
|
|
|
|
ch->io[ret] = -1;
|
|
|
|
|
|
|
|
ch->supp_stream_formats = fmtcap;
|
|
|
|
ch->supp_pcm_size_rate = pcmcap;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* 8bit = 0
|
|
|
|
* 16bit = 1
|
|
|
|
* 20bit = 2
|
|
|
|
* 24bit = 3
|
|
|
|
* 32bit = 4
|
|
|
|
*/
|
|
|
|
if (ret > 0) {
|
|
|
|
i = 0;
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
if (HDA_PARAM_SUPP_STREAM_FORMATS_PCM(fmtcap)) {
|
|
|
|
if (HDA_PARAM_SUPP_PCM_SIZE_RATE_16BIT(pcmcap))
|
|
|
|
ch->bit16 = 1;
|
|
|
|
else if (HDA_PARAM_SUPP_PCM_SIZE_RATE_8BIT(pcmcap))
|
|
|
|
ch->bit16 = 0;
|
|
|
|
if (HDA_PARAM_SUPP_PCM_SIZE_RATE_32BIT(pcmcap))
|
|
|
|
ch->bit32 = 4;
|
|
|
|
else if (HDA_PARAM_SUPP_PCM_SIZE_RATE_24BIT(pcmcap))
|
|
|
|
ch->bit32 = 3;
|
|
|
|
else if (HDA_PARAM_SUPP_PCM_SIZE_RATE_20BIT(pcmcap))
|
|
|
|
ch->bit32 = 2;
|
|
|
|
if (!(devinfo->function.audio.quirks & HDA_QUIRK_FORCESTEREO))
|
|
|
|
ch->fmtlist[i++] = AFMT_S16_LE;
|
|
|
|
ch->fmtlist[i++] = AFMT_S16_LE | AFMT_STEREO;
|
|
|
|
if (ch->bit32 > 0) {
|
|
|
|
if (!(devinfo->function.audio.quirks &
|
|
|
|
HDA_QUIRK_FORCESTEREO))
|
|
|
|
ch->fmtlist[i++] = AFMT_S32_LE;
|
|
|
|
ch->fmtlist[i++] = AFMT_S32_LE | AFMT_STEREO;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
if (HDA_PARAM_SUPP_STREAM_FORMATS_AC3(fmtcap)) {
|
|
|
|
ch->fmtlist[i++] = AFMT_AC3;
|
2006-10-01 11:13:00 +00:00
|
|
|
}
|
|
|
|
ch->fmtlist[i] = 0;
|
|
|
|
i = 0;
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
if (HDA_PARAM_SUPP_PCM_SIZE_RATE_8KHZ(pcmcap))
|
2006-10-01 11:13:00 +00:00
|
|
|
ch->pcmrates[i++] = 8000;
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
if (HDA_PARAM_SUPP_PCM_SIZE_RATE_11KHZ(pcmcap))
|
2006-10-01 11:13:00 +00:00
|
|
|
ch->pcmrates[i++] = 11025;
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
if (HDA_PARAM_SUPP_PCM_SIZE_RATE_16KHZ(pcmcap))
|
2006-10-01 11:13:00 +00:00
|
|
|
ch->pcmrates[i++] = 16000;
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
if (HDA_PARAM_SUPP_PCM_SIZE_RATE_22KHZ(pcmcap))
|
2006-10-01 11:13:00 +00:00
|
|
|
ch->pcmrates[i++] = 22050;
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
if (HDA_PARAM_SUPP_PCM_SIZE_RATE_32KHZ(pcmcap))
|
2006-10-01 11:13:00 +00:00
|
|
|
ch->pcmrates[i++] = 32000;
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
if (HDA_PARAM_SUPP_PCM_SIZE_RATE_44KHZ(pcmcap))
|
2006-10-01 11:13:00 +00:00
|
|
|
ch->pcmrates[i++] = 44100;
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
/* if (HDA_PARAM_SUPP_PCM_SIZE_RATE_48KHZ(pcmcap)) */
|
2006-10-01 11:13:00 +00:00
|
|
|
ch->pcmrates[i++] = 48000;
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
if (HDA_PARAM_SUPP_PCM_SIZE_RATE_88KHZ(pcmcap))
|
2006-10-01 11:13:00 +00:00
|
|
|
ch->pcmrates[i++] = 88200;
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
if (HDA_PARAM_SUPP_PCM_SIZE_RATE_96KHZ(pcmcap))
|
2006-10-01 11:13:00 +00:00
|
|
|
ch->pcmrates[i++] = 96000;
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
if (HDA_PARAM_SUPP_PCM_SIZE_RATE_176KHZ(pcmcap))
|
2006-10-01 11:13:00 +00:00
|
|
|
ch->pcmrates[i++] = 176400;
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
if (HDA_PARAM_SUPP_PCM_SIZE_RATE_192KHZ(pcmcap))
|
2006-10-01 11:13:00 +00:00
|
|
|
ch->pcmrates[i++] = 192000;
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
/* if (HDA_PARAM_SUPP_PCM_SIZE_RATE_384KHZ(pcmcap)) */
|
2006-10-01 11:13:00 +00:00
|
|
|
ch->pcmrates[i] = 0;
|
|
|
|
if (i > 0) {
|
|
|
|
ch->caps.minspeed = ch->pcmrates[0];
|
|
|
|
ch->caps.maxspeed = ch->pcmrates[i - 1];
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return (ret);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
hdac_dump_ctls(struct hdac_pcm_devinfo *pdevinfo, const char *banner, uint32_t flag)
|
2006-10-01 11:13:00 +00:00
|
|
|
{
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
struct hdac_devinfo *devinfo = pdevinfo->devinfo;
|
2006-10-01 11:13:00 +00:00
|
|
|
struct hdac_audio_ctl *ctl;
|
|
|
|
struct hdac_softc *sc = devinfo->codec->sc;
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
char buf[64];
|
|
|
|
int i, j, printed;
|
2006-10-01 11:13:00 +00:00
|
|
|
|
|
|
|
if (flag == 0) {
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
flag = ~(SOUND_MASK_VOLUME | SOUND_MASK_PCM |
|
2006-10-01 11:13:00 +00:00
|
|
|
SOUND_MASK_CD | SOUND_MASK_LINE | SOUND_MASK_RECLEV |
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
SOUND_MASK_MIC | SOUND_MASK_SPEAKER | SOUND_MASK_OGAIN |
|
|
|
|
SOUND_MASK_IMIX | SOUND_MASK_MONITOR);
|
2006-10-01 11:13:00 +00:00
|
|
|
}
|
|
|
|
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
for (j = 0; j < SOUND_MIXER_NRDEVICES; j++) {
|
|
|
|
if ((flag & (1 << j)) == 0)
|
2006-10-01 11:13:00 +00:00
|
|
|
continue;
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
i = 0;
|
|
|
|
printed = 0;
|
|
|
|
while ((ctl = hdac_audio_ctl_each(devinfo, &i)) != NULL) {
|
|
|
|
if (ctl->enable == 0 ||
|
|
|
|
ctl->widget->enable == 0)
|
|
|
|
continue;
|
|
|
|
if (!((pdevinfo->play >= 0 &&
|
|
|
|
ctl->widget->bindas == sc->chans[pdevinfo->play].as) ||
|
|
|
|
(pdevinfo->rec >= 0 &&
|
|
|
|
ctl->widget->bindas == sc->chans[pdevinfo->rec].as) ||
|
|
|
|
(ctl->widget->bindas == -2 && pdevinfo->index == 0)))
|
|
|
|
continue;
|
|
|
|
if ((ctl->ossmask & (1 << j)) == 0)
|
|
|
|
continue;
|
2006-10-01 11:13:00 +00:00
|
|
|
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
if (printed == 0) {
|
|
|
|
device_printf(pdevinfo->dev, "\n");
|
|
|
|
if (banner != NULL) {
|
|
|
|
device_printf(pdevinfo->dev, "%s", banner);
|
|
|
|
} else {
|
|
|
|
device_printf(pdevinfo->dev, "Unknown Ctl");
|
|
|
|
}
|
|
|
|
printf(" (OSS: %s)\n",
|
|
|
|
hdac_audio_ctl_ossmixer_mask2allname(1 << j,
|
|
|
|
buf, sizeof(buf)));
|
|
|
|
device_printf(pdevinfo->dev, " |\n");
|
|
|
|
printed = 1;
|
|
|
|
}
|
|
|
|
device_printf(pdevinfo->dev, " +- ctl %2d (nid %3d %s", i,
|
|
|
|
ctl->widget->nid,
|
|
|
|
(ctl->ndir == HDA_CTL_IN)?"in ":"out");
|
|
|
|
if (ctl->ndir == HDA_CTL_IN && ctl->ndir == ctl->dir)
|
|
|
|
printf(" %2d): ", ctl->index);
|
|
|
|
else
|
|
|
|
printf("): ");
|
|
|
|
if (ctl->step > 0) {
|
|
|
|
printf("%+d/%+ddB (%d steps)%s\n",
|
|
|
|
(0 - ctl->offset) * (ctl->size + 1) / 4,
|
|
|
|
(ctl->step - ctl->offset) * (ctl->size + 1) / 4,
|
|
|
|
ctl->step + 1,
|
|
|
|
ctl->mute?" + mute":"");
|
|
|
|
} else
|
|
|
|
printf("%s\n", ctl->mute?"mute":"");
|
2006-10-01 11:13:00 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
hdac_dump_audio_formats(device_t dev, uint32_t fcap, uint32_t pcmcap)
|
2006-10-01 11:13:00 +00:00
|
|
|
{
|
|
|
|
uint32_t cap;
|
|
|
|
|
|
|
|
cap = fcap;
|
|
|
|
if (cap != 0) {
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
device_printf(dev, " Stream cap: 0x%08x\n", cap);
|
2008-09-16 20:03:34 +00:00
|
|
|
device_printf(dev, " ");
|
2006-10-01 11:13:00 +00:00
|
|
|
if (HDA_PARAM_SUPP_STREAM_FORMATS_AC3(cap))
|
|
|
|
printf(" AC3");
|
|
|
|
if (HDA_PARAM_SUPP_STREAM_FORMATS_FLOAT32(cap))
|
|
|
|
printf(" FLOAT32");
|
|
|
|
if (HDA_PARAM_SUPP_STREAM_FORMATS_PCM(cap))
|
|
|
|
printf(" PCM");
|
|
|
|
printf("\n");
|
|
|
|
}
|
|
|
|
cap = pcmcap;
|
|
|
|
if (cap != 0) {
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
device_printf(dev, " PCM cap: 0x%08x\n", cap);
|
2008-09-16 20:03:34 +00:00
|
|
|
device_printf(dev, " ");
|
2006-10-01 11:13:00 +00:00
|
|
|
if (HDA_PARAM_SUPP_PCM_SIZE_RATE_8BIT(cap))
|
|
|
|
printf(" 8");
|
|
|
|
if (HDA_PARAM_SUPP_PCM_SIZE_RATE_16BIT(cap))
|
|
|
|
printf(" 16");
|
|
|
|
if (HDA_PARAM_SUPP_PCM_SIZE_RATE_20BIT(cap))
|
|
|
|
printf(" 20");
|
|
|
|
if (HDA_PARAM_SUPP_PCM_SIZE_RATE_24BIT(cap))
|
|
|
|
printf(" 24");
|
|
|
|
if (HDA_PARAM_SUPP_PCM_SIZE_RATE_32BIT(cap))
|
|
|
|
printf(" 32");
|
2008-09-16 20:03:34 +00:00
|
|
|
printf(" bits,");
|
2006-10-01 11:13:00 +00:00
|
|
|
if (HDA_PARAM_SUPP_PCM_SIZE_RATE_8KHZ(cap))
|
|
|
|
printf(" 8");
|
|
|
|
if (HDA_PARAM_SUPP_PCM_SIZE_RATE_11KHZ(cap))
|
|
|
|
printf(" 11");
|
|
|
|
if (HDA_PARAM_SUPP_PCM_SIZE_RATE_16KHZ(cap))
|
|
|
|
printf(" 16");
|
|
|
|
if (HDA_PARAM_SUPP_PCM_SIZE_RATE_22KHZ(cap))
|
|
|
|
printf(" 22");
|
|
|
|
if (HDA_PARAM_SUPP_PCM_SIZE_RATE_32KHZ(cap))
|
|
|
|
printf(" 32");
|
|
|
|
if (HDA_PARAM_SUPP_PCM_SIZE_RATE_44KHZ(cap))
|
|
|
|
printf(" 44");
|
|
|
|
printf(" 48");
|
|
|
|
if (HDA_PARAM_SUPP_PCM_SIZE_RATE_88KHZ(cap))
|
|
|
|
printf(" 88");
|
|
|
|
if (HDA_PARAM_SUPP_PCM_SIZE_RATE_96KHZ(cap))
|
|
|
|
printf(" 96");
|
|
|
|
if (HDA_PARAM_SUPP_PCM_SIZE_RATE_176KHZ(cap))
|
|
|
|
printf(" 176");
|
|
|
|
if (HDA_PARAM_SUPP_PCM_SIZE_RATE_192KHZ(cap))
|
|
|
|
printf(" 192");
|
2008-09-16 20:03:34 +00:00
|
|
|
printf(" KHz\n");
|
2006-10-01 11:13:00 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
hdac_dump_pin(struct hdac_softc *sc, struct hdac_widget *w)
|
|
|
|
{
|
2008-09-16 20:03:34 +00:00
|
|
|
uint32_t pincap;
|
2006-10-01 11:13:00 +00:00
|
|
|
|
|
|
|
pincap = w->wclass.pin.cap;
|
|
|
|
|
|
|
|
device_printf(sc->dev, " Pin cap: 0x%08x\n", pincap);
|
|
|
|
device_printf(sc->dev, " ");
|
|
|
|
if (HDA_PARAM_PIN_CAP_IMP_SENSE_CAP(pincap))
|
|
|
|
printf(" ISC");
|
|
|
|
if (HDA_PARAM_PIN_CAP_TRIGGER_REQD(pincap))
|
|
|
|
printf(" TRQD");
|
|
|
|
if (HDA_PARAM_PIN_CAP_PRESENCE_DETECT_CAP(pincap))
|
|
|
|
printf(" PDC");
|
|
|
|
if (HDA_PARAM_PIN_CAP_HEADPHONE_CAP(pincap))
|
|
|
|
printf(" HP");
|
|
|
|
if (HDA_PARAM_PIN_CAP_OUTPUT_CAP(pincap))
|
|
|
|
printf(" OUT");
|
|
|
|
if (HDA_PARAM_PIN_CAP_INPUT_CAP(pincap))
|
|
|
|
printf(" IN");
|
|
|
|
if (HDA_PARAM_PIN_CAP_BALANCED_IO_PINS(pincap))
|
|
|
|
printf(" BAL");
|
2006-12-10 06:13:41 +00:00
|
|
|
if (HDA_PARAM_PIN_CAP_VREF_CTRL(pincap)) {
|
|
|
|
printf(" VREF[");
|
|
|
|
if (HDA_PARAM_PIN_CAP_VREF_CTRL_50(pincap))
|
|
|
|
printf(" 50");
|
|
|
|
if (HDA_PARAM_PIN_CAP_VREF_CTRL_80(pincap))
|
|
|
|
printf(" 80");
|
|
|
|
if (HDA_PARAM_PIN_CAP_VREF_CTRL_100(pincap))
|
|
|
|
printf(" 100");
|
|
|
|
if (HDA_PARAM_PIN_CAP_VREF_CTRL_GROUND(pincap))
|
|
|
|
printf(" GROUND");
|
|
|
|
if (HDA_PARAM_PIN_CAP_VREF_CTRL_HIZ(pincap))
|
|
|
|
printf(" HIZ");
|
|
|
|
printf(" ]");
|
|
|
|
}
|
2006-10-01 11:13:00 +00:00
|
|
|
if (HDA_PARAM_PIN_CAP_EAPD_CAP(pincap))
|
|
|
|
printf(" EAPD");
|
|
|
|
printf("\n");
|
|
|
|
device_printf(sc->dev, " Pin config: 0x%08x\n",
|
|
|
|
w->wclass.pin.config);
|
|
|
|
device_printf(sc->dev, " Pin control: 0x%08x", w->wclass.pin.ctrl);
|
|
|
|
if (w->wclass.pin.ctrl & HDA_CMD_SET_PIN_WIDGET_CTRL_HPHN_ENABLE)
|
|
|
|
printf(" HP");
|
|
|
|
if (w->wclass.pin.ctrl & HDA_CMD_SET_PIN_WIDGET_CTRL_IN_ENABLE)
|
|
|
|
printf(" IN");
|
|
|
|
if (w->wclass.pin.ctrl & HDA_CMD_SET_PIN_WIDGET_CTRL_OUT_ENABLE)
|
|
|
|
printf(" OUT");
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
if (w->wclass.pin.ctrl & HDA_CMD_SET_PIN_WIDGET_CTRL_VREF_ENABLE_MASK)
|
|
|
|
printf(" VREFs");
|
2006-10-01 11:13:00 +00:00
|
|
|
printf("\n");
|
|
|
|
}
|
|
|
|
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
static void
|
|
|
|
hdac_dump_pin_config(struct hdac_widget *w, uint32_t conf)
|
|
|
|
{
|
|
|
|
struct hdac_softc *sc = w->devinfo->codec->sc;
|
|
|
|
|
2008-09-16 20:03:34 +00:00
|
|
|
device_printf(sc->dev, " nid %d 0x%08x as %2d seq %2d %13s %5s "
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
"jack %2d loc %2d color %7s misc %d%s\n",
|
|
|
|
w->nid, conf,
|
|
|
|
HDA_CONFIG_DEFAULTCONF_ASSOCIATION(conf),
|
|
|
|
HDA_CONFIG_DEFAULTCONF_SEQUENCE(conf),
|
|
|
|
HDA_DEVS[HDA_CONFIG_DEFAULTCONF_DEVICE(conf)],
|
|
|
|
HDA_CONNS[HDA_CONFIG_DEFAULTCONF_CONNECTIVITY(conf)],
|
|
|
|
HDA_CONFIG_DEFAULTCONF_CONNECTION_TYPE(conf),
|
|
|
|
HDA_CONFIG_DEFAULTCONF_LOCATION(conf),
|
|
|
|
HDA_COLORS[HDA_CONFIG_DEFAULTCONF_COLOR(conf)],
|
|
|
|
HDA_CONFIG_DEFAULTCONF_MISC(conf),
|
|
|
|
(w->enable == 0)?" [DISABLED]":"");
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
hdac_dump_pin_configs(struct hdac_devinfo *devinfo)
|
|
|
|
{
|
|
|
|
struct hdac_widget *w;
|
|
|
|
int i;
|
|
|
|
|
|
|
|
for (i = devinfo->startnode; i < devinfo->endnode; i++) {
|
|
|
|
w = hdac_widget_get(devinfo, i);
|
|
|
|
if (w == NULL)
|
|
|
|
continue;
|
|
|
|
if (w->type != HDA_PARAM_AUDIO_WIDGET_CAP_TYPE_PIN_COMPLEX)
|
|
|
|
continue;
|
|
|
|
hdac_dump_pin_config(w, w->wclass.pin.config);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2006-10-01 11:13:00 +00:00
|
|
|
static void
|
|
|
|
hdac_dump_amp(struct hdac_softc *sc, uint32_t cap, char *banner)
|
|
|
|
{
|
- Fix wrong id for ALC882, add ALC883 id.
- 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"
2006-10-06 18:59:27 +00:00
|
|
|
device_printf(sc->dev, " %s amp: 0x%08x\n", banner, cap);
|
2006-10-01 11:13:00 +00:00
|
|
|
device_printf(sc->dev, " "
|
|
|
|
"mute=%d step=%d size=%d offset=%d\n",
|
|
|
|
HDA_PARAM_OUTPUT_AMP_CAP_MUTE_CAP(cap),
|
|
|
|
HDA_PARAM_OUTPUT_AMP_CAP_NUMSTEPS(cap),
|
|
|
|
HDA_PARAM_OUTPUT_AMP_CAP_STEPSIZE(cap),
|
|
|
|
HDA_PARAM_OUTPUT_AMP_CAP_OFFSET(cap));
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
hdac_dump_nodes(struct hdac_devinfo *devinfo)
|
|
|
|
{
|
|
|
|
struct hdac_softc *sc = devinfo->codec->sc;
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
static char *ossname[] = SOUND_DEVICE_NAMES;
|
2006-10-01 11:13:00 +00:00
|
|
|
struct hdac_widget *w, *cw;
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
char buf[64];
|
2006-10-01 11:13:00 +00:00
|
|
|
int i, j;
|
|
|
|
|
|
|
|
device_printf(sc->dev, "\n");
|
|
|
|
device_printf(sc->dev, "Default Parameter\n");
|
|
|
|
device_printf(sc->dev, "-----------------\n");
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
hdac_dump_audio_formats(sc->dev,
|
2006-10-01 11:13:00 +00:00
|
|
|
devinfo->function.audio.supp_stream_formats,
|
|
|
|
devinfo->function.audio.supp_pcm_size_rate);
|
|
|
|
device_printf(sc->dev, " IN amp: 0x%08x\n",
|
|
|
|
devinfo->function.audio.inamp_cap);
|
|
|
|
device_printf(sc->dev, " OUT amp: 0x%08x\n",
|
|
|
|
devinfo->function.audio.outamp_cap);
|
|
|
|
for (i = devinfo->startnode; i < devinfo->endnode; i++) {
|
|
|
|
w = hdac_widget_get(devinfo, i);
|
|
|
|
if (w == NULL) {
|
|
|
|
device_printf(sc->dev, "Ghost widget nid=%d\n", i);
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
device_printf(sc->dev, "\n");
|
2008-09-16 20:03:34 +00:00
|
|
|
device_printf(sc->dev, " nid: %d%s\n", w->nid,
|
2006-10-01 11:13:00 +00:00
|
|
|
(w->enable == 0) ? " [DISABLED]" : "");
|
2008-09-16 20:03:34 +00:00
|
|
|
device_printf(sc->dev, " Name: %s\n", w->name);
|
|
|
|
device_printf(sc->dev, " Widget cap: 0x%08x\n",
|
2006-10-01 11:13:00 +00:00
|
|
|
w->param.widget_cap);
|
2008-09-16 20:03:34 +00:00
|
|
|
if (w->param.widget_cap & 0x0ee1) {
|
|
|
|
device_printf(sc->dev, " ");
|
|
|
|
if (HDA_PARAM_AUDIO_WIDGET_CAP_LR_SWAP(w->param.widget_cap))
|
|
|
|
printf(" LRSWAP");
|
|
|
|
if (HDA_PARAM_AUDIO_WIDGET_CAP_POWER_CTRL(w->param.widget_cap))
|
|
|
|
printf(" PWR");
|
|
|
|
if (HDA_PARAM_AUDIO_WIDGET_CAP_DIGITAL(w->param.widget_cap))
|
|
|
|
printf(" DIGITAL");
|
|
|
|
if (HDA_PARAM_AUDIO_WIDGET_CAP_UNSOL_CAP(w->param.widget_cap))
|
|
|
|
printf(" UNSOL");
|
|
|
|
if (HDA_PARAM_AUDIO_WIDGET_CAP_PROC_WIDGET(w->param.widget_cap))
|
|
|
|
printf(" PROC");
|
|
|
|
if (HDA_PARAM_AUDIO_WIDGET_CAP_STRIPE(w->param.widget_cap))
|
|
|
|
printf(" STRIPE");
|
|
|
|
if (HDA_PARAM_AUDIO_WIDGET_CAP_STEREO(w->param.widget_cap))
|
|
|
|
printf(" STEREO");
|
|
|
|
printf("\n");
|
|
|
|
}
|
|
|
|
if (w->bindas != -1) {
|
|
|
|
device_printf(sc->dev, " Association: %d (0x%08x)\n",
|
|
|
|
w->bindas, w->bindseqmask);
|
|
|
|
}
|
|
|
|
if (w->ossmask != 0 || w->ossdev >= 0) {
|
|
|
|
device_printf(sc->dev, " OSS: %s",
|
|
|
|
hdac_audio_ctl_ossmixer_mask2allname(w->ossmask, buf, sizeof(buf)));
|
|
|
|
if (w->ossdev >= 0)
|
|
|
|
printf(" (%s)", ossname[w->ossdev]);
|
|
|
|
printf("\n");
|
|
|
|
}
|
2006-10-01 11:13:00 +00:00
|
|
|
if (w->type == HDA_PARAM_AUDIO_WIDGET_CAP_TYPE_AUDIO_OUTPUT ||
|
|
|
|
w->type == HDA_PARAM_AUDIO_WIDGET_CAP_TYPE_AUDIO_INPUT) {
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
hdac_dump_audio_formats(sc->dev,
|
2006-10-01 11:13:00 +00:00
|
|
|
w->param.supp_stream_formats,
|
|
|
|
w->param.supp_pcm_size_rate);
|
|
|
|
} else if (w->type ==
|
|
|
|
HDA_PARAM_AUDIO_WIDGET_CAP_TYPE_PIN_COMPLEX)
|
|
|
|
hdac_dump_pin(sc, w);
|
2006-10-02 16:30:04 +00:00
|
|
|
if (w->param.eapdbtl != HDAC_INVALID)
|
2006-10-01 11:13:00 +00:00
|
|
|
device_printf(sc->dev, " EAPD: 0x%08x\n",
|
|
|
|
w->param.eapdbtl);
|
- Fix wrong id for ALC882, add ALC883 id.
- 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"
2006-10-06 18:59:27 +00:00
|
|
|
if (HDA_PARAM_AUDIO_WIDGET_CAP_OUT_AMP(w->param.widget_cap) &&
|
|
|
|
w->param.outamp_cap != 0)
|
2006-10-01 11:13:00 +00:00
|
|
|
hdac_dump_amp(sc, w->param.outamp_cap, "Output");
|
- Fix wrong id for ALC882, add ALC883 id.
- 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"
2006-10-06 18:59:27 +00:00
|
|
|
if (HDA_PARAM_AUDIO_WIDGET_CAP_IN_AMP(w->param.widget_cap) &&
|
|
|
|
w->param.inamp_cap != 0)
|
2006-10-01 11:13:00 +00:00
|
|
|
hdac_dump_amp(sc, w->param.inamp_cap, " Input");
|
2008-09-16 20:03:34 +00:00
|
|
|
if (w->nconns > 0) {
|
|
|
|
device_printf(sc->dev, " connections: %d\n", w->nconns);
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
device_printf(sc->dev, " |\n");
|
2008-09-16 20:03:34 +00:00
|
|
|
}
|
2006-10-01 11:13:00 +00:00
|
|
|
for (j = 0; j < w->nconns; j++) {
|
|
|
|
cw = hdac_widget_get(devinfo, w->conns[j]);
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
device_printf(sc->dev, " + %s<- nid=%d [%s]",
|
|
|
|
(w->connsenable[j] == 0)?"[DISABLED] ":"",
|
2006-10-01 11:13:00 +00:00
|
|
|
w->conns[j], (cw == NULL) ? "GHOST!" : cw->name);
|
|
|
|
if (cw == NULL)
|
|
|
|
printf(" [UNKNOWN]");
|
|
|
|
else if (cw->enable == 0)
|
|
|
|
printf(" [DISABLED]");
|
|
|
|
if (w->nconns > 1 && w->selconn == j && w->type !=
|
|
|
|
HDA_PARAM_AUDIO_WIDGET_CAP_TYPE_AUDIO_MIXER)
|
|
|
|
printf(" (selected)");
|
|
|
|
printf("\n");
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
}
|
|
|
|
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
static void
|
|
|
|
hdac_dump_dst_nid(struct hdac_pcm_devinfo *pdevinfo, nid_t nid, int depth)
|
- Fix wrong id for ALC882, add ALC883 id.
- 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"
2006-10-06 18:59:27 +00:00
|
|
|
{
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
struct hdac_devinfo *devinfo = pdevinfo->devinfo;
|
- Fix wrong id for ALC882, add ALC883 id.
- 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"
2006-10-06 18:59:27 +00:00
|
|
|
struct hdac_widget *w, *cw;
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
char buf[64];
|
|
|
|
int i, printed = 0;
|
- Fix wrong id for ALC882, add ALC883 id.
- 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"
2006-10-06 18:59:27 +00:00
|
|
|
|
|
|
|
if (depth > HDA_PARSE_MAXDEPTH)
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
return;
|
- Fix wrong id for ALC882, add ALC883 id.
- 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"
2006-10-06 18:59:27 +00:00
|
|
|
|
|
|
|
w = hdac_widget_get(devinfo, nid);
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
if (w == NULL || w->enable == 0)
|
|
|
|
return;
|
- Fix wrong id for ALC882, add ALC883 id.
- 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"
2006-10-06 18:59:27 +00:00
|
|
|
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
if (depth == 0)
|
|
|
|
device_printf(pdevinfo->dev, "%*s", 4, "");
|
|
|
|
else
|
|
|
|
device_printf(pdevinfo->dev, "%*s + <- ", 4 + (depth - 1) * 7, "");
|
|
|
|
printf("nid=%d [%s]", w->nid, w->name);
|
- Fix wrong id for ALC882, add ALC883 id.
- 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"
2006-10-06 18:59:27 +00:00
|
|
|
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
if (depth > 0) {
|
|
|
|
if (w->ossmask == 0) {
|
|
|
|
printf("\n");
|
|
|
|
return;
|
- Fix wrong id for ALC882, add ALC883 id.
- 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"
2006-10-06 18:59:27 +00:00
|
|
|
}
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
printf(" [src: %s]",
|
|
|
|
hdac_audio_ctl_ossmixer_mask2allname(
|
|
|
|
w->ossmask, buf, sizeof(buf)));
|
|
|
|
if (w->ossdev >= 0) {
|
|
|
|
printf("\n");
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
printf("\n");
|
|
|
|
|
|
|
|
for (i = 0; i < w->nconns; i++) {
|
|
|
|
if (w->connsenable[i] == 0)
|
|
|
|
continue;
|
|
|
|
cw = hdac_widget_get(devinfo, w->conns[i]);
|
|
|
|
if (cw == NULL || cw->enable == 0 || cw->bindas == -1)
|
|
|
|
continue;
|
|
|
|
if (printed == 0) {
|
|
|
|
device_printf(pdevinfo->dev, "%*s |\n", 4 + (depth) * 7, "");
|
|
|
|
printed = 1;
|
|
|
|
}
|
|
|
|
hdac_dump_dst_nid(pdevinfo, w->conns[i], depth + 1);
|
- Fix wrong id for ALC882, add ALC883 id.
- 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"
2006-10-06 18:59:27 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
}
|
|
|
|
|
2006-10-01 11:13:00 +00:00
|
|
|
static void
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
hdac_dump_dac(struct hdac_pcm_devinfo *pdevinfo)
|
2006-10-01 11:13:00 +00:00
|
|
|
{
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
struct hdac_devinfo *devinfo = pdevinfo->devinfo;
|
- Fix wrong id for ALC882, add ALC883 id.
- 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"
2006-10-06 18:59:27 +00:00
|
|
|
struct hdac_softc *sc = devinfo->codec->sc;
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
struct hdac_widget *w;
|
- Fix wrong id for ALC882, add ALC883 id.
- 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"
2006-10-06 18:59:27 +00:00
|
|
|
int i, printed = 0;
|
|
|
|
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
if (pdevinfo->play < 0)
|
|
|
|
return;
|
|
|
|
|
- Fix wrong id for ALC882, add ALC883 id.
- 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"
2006-10-06 18:59:27 +00:00
|
|
|
for (i = devinfo->startnode; i < devinfo->endnode; i++) {
|
|
|
|
w = hdac_widget_get(devinfo, i);
|
|
|
|
if (w == NULL || w->enable == 0)
|
|
|
|
continue;
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
if (w->type != HDA_PARAM_AUDIO_WIDGET_CAP_TYPE_PIN_COMPLEX)
|
|
|
|
continue;
|
|
|
|
if (w->bindas != sc->chans[pdevinfo->play].as)
|
- Fix wrong id for ALC882, add ALC883 id.
- 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"
2006-10-06 18:59:27 +00:00
|
|
|
continue;
|
|
|
|
if (printed == 0) {
|
|
|
|
printed = 1;
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
device_printf(pdevinfo->dev, "\n");
|
|
|
|
device_printf(pdevinfo->dev, "Playback:\n");
|
- Fix wrong id for ALC882, add ALC883 id.
- 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"
2006-10-06 18:59:27 +00:00
|
|
|
}
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
device_printf(pdevinfo->dev, "\n");
|
|
|
|
hdac_dump_dst_nid(pdevinfo, i, 0);
|
- Fix wrong id for ALC882, add ALC883 id.
- 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"
2006-10-06 18:59:27 +00:00
|
|
|
}
|
2006-10-01 11:13:00 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
hdac_dump_adc(struct hdac_pcm_devinfo *pdevinfo)
|
2006-10-01 11:13:00 +00:00
|
|
|
{
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
struct hdac_devinfo *devinfo = pdevinfo->devinfo;
|
2006-10-01 11:13:00 +00:00
|
|
|
struct hdac_softc *sc = devinfo->codec->sc;
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
struct hdac_widget *w;
|
|
|
|
int i;
|
2006-10-01 11:13:00 +00:00
|
|
|
int printed = 0;
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
|
|
|
|
if (pdevinfo->rec < 0)
|
|
|
|
return;
|
2006-10-01 11:13:00 +00:00
|
|
|
|
|
|
|
for (i = devinfo->startnode; i < devinfo->endnode; i++) {
|
|
|
|
w = hdac_widget_get(devinfo, i);
|
|
|
|
if (w == NULL || w->enable == 0)
|
|
|
|
continue;
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
if (w->type != HDA_PARAM_AUDIO_WIDGET_CAP_TYPE_AUDIO_INPUT)
|
|
|
|
continue;
|
|
|
|
if (w->bindas != sc->chans[pdevinfo->rec].as)
|
2006-10-01 11:13:00 +00:00
|
|
|
continue;
|
|
|
|
if (printed == 0) {
|
|
|
|
printed = 1;
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
device_printf(pdevinfo->dev, "\n");
|
|
|
|
device_printf(pdevinfo->dev, "Record:\n");
|
2006-10-01 11:13:00 +00:00
|
|
|
}
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
device_printf(pdevinfo->dev, "\n");
|
|
|
|
hdac_dump_dst_nid(pdevinfo, i, 0);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
hdac_dump_mix(struct hdac_pcm_devinfo *pdevinfo)
|
|
|
|
{
|
|
|
|
struct hdac_devinfo *devinfo = pdevinfo->devinfo;
|
|
|
|
struct hdac_widget *w;
|
|
|
|
int i;
|
|
|
|
int printed = 0;
|
|
|
|
|
|
|
|
if (pdevinfo->index != 0)
|
|
|
|
return;
|
|
|
|
|
|
|
|
for (i = devinfo->startnode; i < devinfo->endnode; i++) {
|
|
|
|
w = hdac_widget_get(devinfo, i);
|
|
|
|
if (w == NULL || w->enable == 0)
|
|
|
|
continue;
|
|
|
|
if ((w->pflags & HDA_ADC_MONITOR) == 0)
|
|
|
|
continue;
|
|
|
|
if (printed == 0) {
|
|
|
|
printed = 1;
|
|
|
|
device_printf(pdevinfo->dev, "\n");
|
|
|
|
device_printf(pdevinfo->dev, "Input Mix:\n");
|
2006-10-01 11:13:00 +00:00
|
|
|
}
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
device_printf(pdevinfo->dev, "\n");
|
|
|
|
hdac_dump_dst_nid(pdevinfo, i, 0);
|
2006-10-01 11:13:00 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
hdac_dump_pcmchannels(struct hdac_pcm_devinfo *pdevinfo)
|
2006-10-01 11:13:00 +00:00
|
|
|
{
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
struct hdac_softc *sc = pdevinfo->devinfo->codec->sc;
|
2006-10-01 11:13:00 +00:00
|
|
|
nid_t *nids;
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
int i;
|
2006-10-01 11:13:00 +00:00
|
|
|
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
if (pdevinfo->play >= 0) {
|
|
|
|
i = pdevinfo->play;
|
|
|
|
device_printf(pdevinfo->dev, "\n");
|
|
|
|
device_printf(pdevinfo->dev, "Playback:\n");
|
|
|
|
device_printf(pdevinfo->dev, "\n");
|
|
|
|
hdac_dump_audio_formats(pdevinfo->dev, sc->chans[i].supp_stream_formats,
|
|
|
|
sc->chans[i].supp_pcm_size_rate);
|
|
|
|
device_printf(pdevinfo->dev, " DAC:");
|
|
|
|
for (nids = sc->chans[i].io; *nids != -1; nids++)
|
2006-10-01 11:13:00 +00:00
|
|
|
printf(" %d", *nids);
|
|
|
|
printf("\n");
|
|
|
|
}
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
if (pdevinfo->rec >= 0) {
|
|
|
|
i = pdevinfo->rec;
|
|
|
|
device_printf(pdevinfo->dev, "\n");
|
|
|
|
device_printf(pdevinfo->dev, "Record:\n");
|
|
|
|
device_printf(pdevinfo->dev, "\n");
|
|
|
|
hdac_dump_audio_formats(pdevinfo->dev, sc->chans[i].supp_stream_formats,
|
|
|
|
sc->chans[i].supp_pcm_size_rate);
|
|
|
|
device_printf(pdevinfo->dev, " ADC:");
|
|
|
|
for (nids = sc->chans[i].io; *nids != -1; nids++)
|
2006-10-01 11:13:00 +00:00
|
|
|
printf(" %d", *nids);
|
|
|
|
printf("\n");
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
- Fix wrong id for ALC882, add ALC883 id.
- 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"
2006-10-06 18:59:27 +00:00
|
|
|
static void
|
|
|
|
hdac_release_resources(struct hdac_softc *sc)
|
|
|
|
{
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
int i, j;
|
- Fix wrong id for ALC882, add ALC883 id.
- 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"
2006-10-06 18:59:27 +00:00
|
|
|
|
|
|
|
if (sc == NULL)
|
|
|
|
return;
|
|
|
|
|
|
|
|
hdac_lock(sc);
|
2007-05-05 09:17:36 +00:00
|
|
|
sc->polling = 0;
|
|
|
|
sc->poll_ival = 0;
|
2007-06-14 11:13:38 +00:00
|
|
|
callout_stop(&sc->poll_hda);
|
2007-05-05 09:17:36 +00:00
|
|
|
callout_stop(&sc->poll_hdac);
|
|
|
|
callout_stop(&sc->poll_jack);
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
hdac_reset(sc, 0);
|
- Fix wrong id for ALC882, add ALC883 id.
- 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"
2006-10-06 18:59:27 +00:00
|
|
|
hdac_unlock(sc);
|
2007-07-01 17:31:20 +00:00
|
|
|
taskqueue_drain(taskqueue_thread, &sc->unsolq_task);
|
2007-06-14 11:13:38 +00:00
|
|
|
callout_drain(&sc->poll_hda);
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
callout_drain(&sc->poll_hdac);
|
|
|
|
callout_drain(&sc->poll_jack);
|
|
|
|
|
|
|
|
hdac_irq_free(sc);
|
- Fix wrong id for ALC882, add ALC883 id.
- 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"
2006-10-06 18:59:27 +00:00
|
|
|
|
|
|
|
for (i = 0; i < HDAC_CODEC_MAX; i++) {
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
if (sc->codecs[i] == NULL)
|
|
|
|
continue;
|
|
|
|
for (j = 0; j < sc->codecs[i]->num_fgs; j++) {
|
|
|
|
free(sc->codecs[i]->fgs[j].widget, M_HDAC);
|
|
|
|
if (sc->codecs[i]->fgs[j].node_type ==
|
|
|
|
HDA_PARAM_FCT_GRP_TYPE_NODE_TYPE_AUDIO) {
|
|
|
|
free(sc->codecs[i]->fgs[j].function.audio.ctl,
|
|
|
|
M_HDAC);
|
|
|
|
free(sc->codecs[i]->fgs[j].function.audio.as,
|
|
|
|
M_HDAC);
|
|
|
|
free(sc->codecs[i]->fgs[j].function.audio.devs,
|
|
|
|
M_HDAC);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
free(sc->codecs[i]->fgs, M_HDAC);
|
|
|
|
free(sc->codecs[i], M_HDAC);
|
- Fix wrong id for ALC882, add ALC883 id.
- 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"
2006-10-06 18:59:27 +00:00
|
|
|
sc->codecs[i] = NULL;
|
|
|
|
}
|
|
|
|
|
2007-05-05 09:17:36 +00:00
|
|
|
hdac_dma_free(sc, &sc->pos_dma);
|
|
|
|
hdac_dma_free(sc, &sc->rirb_dma);
|
|
|
|
hdac_dma_free(sc, &sc->corb_dma);
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
for (i = 0; i < sc->num_chans; i++) {
|
|
|
|
if (sc->chans[i].blkcnt > 0)
|
|
|
|
hdac_dma_free(sc, &sc->chans[i].bdl_dma);
|
|
|
|
}
|
|
|
|
free(sc->chans, M_HDAC);
|
2007-03-19 16:06:26 +00:00
|
|
|
if (sc->chan_dmat != NULL) {
|
|
|
|
bus_dma_tag_destroy(sc->chan_dmat);
|
|
|
|
sc->chan_dmat = NULL;
|
|
|
|
}
|
- Fix wrong id for ALC882, add ALC883 id.
- 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"
2006-10-06 18:59:27 +00:00
|
|
|
hdac_mem_free(sc);
|
2007-05-05 09:17:36 +00:00
|
|
|
snd_mtxfree(sc->lock);
|
- Fix wrong id for ALC882, add ALC883 id.
- 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"
2006-10-06 18:59:27 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/* This function surely going to make its way into upper level someday. */
|
|
|
|
static void
|
|
|
|
hdac_config_fetch(struct hdac_softc *sc, uint32_t *on, uint32_t *off)
|
|
|
|
{
|
|
|
|
const char *res = NULL;
|
|
|
|
int i = 0, j, k, len, inv;
|
|
|
|
|
|
|
|
if (on != NULL)
|
|
|
|
*on = 0;
|
|
|
|
if (off != NULL)
|
|
|
|
*off = 0;
|
|
|
|
if (sc == NULL)
|
|
|
|
return;
|
|
|
|
if (resource_string_value(device_get_name(sc->dev),
|
|
|
|
device_get_unit(sc->dev), "config", &res) != 0)
|
|
|
|
return;
|
|
|
|
if (!(res != NULL && strlen(res) > 0))
|
|
|
|
return;
|
|
|
|
HDA_BOOTVERBOSE(
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
device_printf(sc->dev, "HDA Config:");
|
- Fix wrong id for ALC882, add ALC883 id.
- 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"
2006-10-06 18:59:27 +00:00
|
|
|
);
|
|
|
|
for (;;) {
|
|
|
|
while (res[i] != '\0' &&
|
|
|
|
(res[i] == ',' || isspace(res[i]) != 0))
|
|
|
|
i++;
|
|
|
|
if (res[i] == '\0') {
|
|
|
|
HDA_BOOTVERBOSE(
|
|
|
|
printf("\n");
|
|
|
|
);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
j = i;
|
|
|
|
while (res[j] != '\0' &&
|
|
|
|
!(res[j] == ',' || isspace(res[j]) != 0))
|
|
|
|
j++;
|
|
|
|
len = j - i;
|
|
|
|
if (len > 2 && strncmp(res + i, "no", 2) == 0)
|
|
|
|
inv = 2;
|
|
|
|
else
|
|
|
|
inv = 0;
|
|
|
|
for (k = 0; len > inv && k < HDAC_QUIRKS_TAB_LEN; k++) {
|
|
|
|
if (strncmp(res + i + inv,
|
|
|
|
hdac_quirks_tab[k].key, len - inv) != 0)
|
|
|
|
continue;
|
|
|
|
if (len - inv != strlen(hdac_quirks_tab[k].key))
|
|
|
|
break;
|
|
|
|
HDA_BOOTVERBOSE(
|
|
|
|
printf(" %s%s", (inv != 0) ? "no" : "",
|
|
|
|
hdac_quirks_tab[k].key);
|
|
|
|
);
|
|
|
|
if (inv == 0 && on != NULL)
|
|
|
|
*on |= hdac_quirks_tab[k].value;
|
|
|
|
else if (inv != 0 && off != NULL)
|
|
|
|
*off |= hdac_quirks_tab[k].value;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
i = j;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
Welcome to Once-a-year Sound Mega-Commit. Enjoy numerous updates and fixes
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.
2006-11-26 12:24:06 +00:00
|
|
|
#ifdef SND_DYNSYSCTL
|
|
|
|
static int
|
|
|
|
sysctl_hdac_polling(SYSCTL_HANDLER_ARGS)
|
|
|
|
{
|
|
|
|
struct hdac_softc *sc;
|
|
|
|
device_t dev;
|
|
|
|
uint32_t ctl;
|
|
|
|
int err, val;
|
|
|
|
|
|
|
|
dev = oidp->oid_arg1;
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
sc = device_get_softc(dev);
|
|
|
|
if (sc == NULL)
|
Welcome to Once-a-year Sound Mega-Commit. Enjoy numerous updates and fixes
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.
2006-11-26 12:24:06 +00:00
|
|
|
return (EINVAL);
|
|
|
|
hdac_lock(sc);
|
|
|
|
val = sc->polling;
|
|
|
|
hdac_unlock(sc);
|
2007-06-04 18:25:08 +00:00
|
|
|
err = sysctl_handle_int(oidp, &val, 0, req);
|
Welcome to Once-a-year Sound Mega-Commit. Enjoy numerous updates and fixes
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.
2006-11-26 12:24:06 +00:00
|
|
|
|
2007-05-05 09:17:36 +00:00
|
|
|
if (err != 0 || req->newptr == NULL)
|
Welcome to Once-a-year Sound Mega-Commit. Enjoy numerous updates and fixes
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.
2006-11-26 12:24:06 +00:00
|
|
|
return (err);
|
|
|
|
if (val < 0 || val > 1)
|
|
|
|
return (EINVAL);
|
|
|
|
|
|
|
|
hdac_lock(sc);
|
|
|
|
if (val != sc->polling) {
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
if (val == 0) {
|
|
|
|
callout_stop(&sc->poll_hda);
|
Welcome to Once-a-year Sound Mega-Commit. Enjoy numerous updates and fixes
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.
2006-11-26 12:24:06 +00:00
|
|
|
callout_stop(&sc->poll_hdac);
|
2007-05-05 09:17:36 +00:00
|
|
|
hdac_unlock(sc);
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
callout_drain(&sc->poll_hda);
|
2007-05-05 09:17:36 +00:00
|
|
|
callout_drain(&sc->poll_hdac);
|
|
|
|
hdac_lock(sc);
|
Welcome to Once-a-year Sound Mega-Commit. Enjoy numerous updates and fixes
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.
2006-11-26 12:24:06 +00:00
|
|
|
sc->polling = 0;
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
ctl = HDAC_READ_4(&sc->mem, HDAC_INTCTL);
|
|
|
|
ctl |= HDAC_INTCTL_GIE;
|
|
|
|
HDAC_WRITE_4(&sc->mem, HDAC_INTCTL, ctl);
|
Welcome to Once-a-year Sound Mega-Commit. Enjoy numerous updates and fixes
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.
2006-11-26 12:24:06 +00:00
|
|
|
} else {
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
ctl = HDAC_READ_4(&sc->mem, HDAC_INTCTL);
|
|
|
|
ctl &= ~HDAC_INTCTL_GIE;
|
|
|
|
HDAC_WRITE_4(&sc->mem, HDAC_INTCTL, ctl);
|
2007-07-01 17:31:20 +00:00
|
|
|
hdac_unlock(sc);
|
|
|
|
taskqueue_drain(taskqueue_thread, &sc->unsolq_task);
|
|
|
|
hdac_lock(sc);
|
Welcome to Once-a-year Sound Mega-Commit. Enjoy numerous updates and fixes
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.
2006-11-26 12:24:06 +00:00
|
|
|
sc->polling = 1;
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
hdac_poll_reinit(sc);
|
|
|
|
callout_reset(&sc->poll_hdac, 1, hdac_poll_callback, sc);
|
Welcome to Once-a-year Sound Mega-Commit. Enjoy numerous updates and fixes
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.
2006-11-26 12:24:06 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
hdac_unlock(sc);
|
|
|
|
|
|
|
|
return (err);
|
|
|
|
}
|
2007-05-05 09:17:36 +00:00
|
|
|
|
|
|
|
static int
|
|
|
|
sysctl_hdac_polling_interval(SYSCTL_HANDLER_ARGS)
|
|
|
|
{
|
|
|
|
struct hdac_softc *sc;
|
|
|
|
device_t dev;
|
|
|
|
int err, val;
|
|
|
|
|
|
|
|
dev = oidp->oid_arg1;
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
sc = device_get_softc(dev);
|
|
|
|
if (sc == NULL)
|
2007-05-05 09:17:36 +00:00
|
|
|
return (EINVAL);
|
|
|
|
hdac_lock(sc);
|
|
|
|
val = ((uint64_t)sc->poll_ival * 1000) / hz;
|
|
|
|
hdac_unlock(sc);
|
2007-06-04 18:25:08 +00:00
|
|
|
err = sysctl_handle_int(oidp, &val, 0, req);
|
2007-05-05 09:17:36 +00:00
|
|
|
|
|
|
|
if (err != 0 || req->newptr == NULL)
|
|
|
|
return (err);
|
|
|
|
|
|
|
|
if (val < 1)
|
|
|
|
val = 1;
|
|
|
|
if (val > 5000)
|
|
|
|
val = 5000;
|
|
|
|
val = ((uint64_t)val * hz) / 1000;
|
|
|
|
if (val < 1)
|
|
|
|
val = 1;
|
|
|
|
if (val > (hz * 5))
|
|
|
|
val = hz * 5;
|
|
|
|
|
|
|
|
hdac_lock(sc);
|
|
|
|
sc->poll_ival = val;
|
|
|
|
hdac_unlock(sc);
|
|
|
|
|
|
|
|
return (err);
|
|
|
|
}
|
|
|
|
|
|
|
|
static int
|
2007-07-01 17:31:20 +00:00
|
|
|
sysctl_hdac_pindump(SYSCTL_HANDLER_ARGS)
|
2007-05-05 09:17:36 +00:00
|
|
|
{
|
|
|
|
struct hdac_softc *sc;
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
struct hdac_codec *codec;
|
2007-05-05 09:17:36 +00:00
|
|
|
struct hdac_devinfo *devinfo;
|
|
|
|
struct hdac_widget *w;
|
|
|
|
device_t dev;
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
uint32_t res, pincap, delay;
|
|
|
|
int codec_index, fg_index;
|
2007-05-05 09:17:36 +00:00
|
|
|
int i, err, val;
|
|
|
|
nid_t cad;
|
|
|
|
|
|
|
|
dev = oidp->oid_arg1;
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
sc = device_get_softc(dev);
|
|
|
|
if (sc == NULL)
|
2007-05-05 09:17:36 +00:00
|
|
|
return (EINVAL);
|
|
|
|
val = 0;
|
2007-06-04 18:25:08 +00:00
|
|
|
err = sysctl_handle_int(oidp, &val, 0, req);
|
2007-05-05 09:17:36 +00:00
|
|
|
if (err != 0 || req->newptr == NULL || val == 0)
|
|
|
|
return (err);
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
|
|
|
|
/* XXX: Temporary. For debugging. */
|
|
|
|
if (val == 100) {
|
|
|
|
hdac_suspend(dev);
|
|
|
|
return (0);
|
|
|
|
} else if (val == 101) {
|
|
|
|
hdac_resume(dev);
|
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
|
2007-05-05 09:17:36 +00:00
|
|
|
hdac_lock(sc);
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
for (codec_index = 0; codec_index < HDAC_CODEC_MAX; codec_index++) {
|
|
|
|
codec = sc->codecs[codec_index];
|
|
|
|
if (codec == NULL)
|
2007-05-05 09:17:36 +00:00
|
|
|
continue;
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
cad = codec->cad;
|
|
|
|
for (fg_index = 0; fg_index < codec->num_fgs; fg_index++) {
|
|
|
|
devinfo = &codec->fgs[fg_index];
|
|
|
|
if (devinfo->node_type !=
|
|
|
|
HDA_PARAM_FCT_GRP_TYPE_NODE_TYPE_AUDIO)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
device_printf(dev, "Dumping AFG cad=%d nid=%d pins:\n",
|
|
|
|
codec_index, devinfo->nid);
|
|
|
|
for (i = devinfo->startnode; i < devinfo->endnode; i++) {
|
|
|
|
w = hdac_widget_get(devinfo, i);
|
|
|
|
if (w == NULL || w->type !=
|
|
|
|
HDA_PARAM_AUDIO_WIDGET_CAP_TYPE_PIN_COMPLEX)
|
|
|
|
continue;
|
|
|
|
hdac_dump_pin_config(w, w->wclass.pin.config);
|
|
|
|
pincap = w->wclass.pin.cap;
|
|
|
|
device_printf(dev, " Caps: %2s %3s %2s %4s %4s",
|
|
|
|
HDA_PARAM_PIN_CAP_INPUT_CAP(pincap)?"IN":"",
|
|
|
|
HDA_PARAM_PIN_CAP_OUTPUT_CAP(pincap)?"OUT":"",
|
|
|
|
HDA_PARAM_PIN_CAP_HEADPHONE_CAP(pincap)?"HP":"",
|
|
|
|
HDA_PARAM_PIN_CAP_EAPD_CAP(pincap)?"EAPD":"",
|
|
|
|
HDA_PARAM_PIN_CAP_VREF_CTRL(pincap)?"VREF":"");
|
|
|
|
if (HDA_PARAM_PIN_CAP_IMP_SENSE_CAP(pincap) ||
|
|
|
|
HDA_PARAM_PIN_CAP_PRESENCE_DETECT_CAP(pincap)) {
|
|
|
|
if (HDA_PARAM_PIN_CAP_TRIGGER_REQD(pincap)) {
|
|
|
|
delay = 0;
|
|
|
|
hdac_command(sc,
|
|
|
|
HDA_CMD_SET_PIN_SENSE(cad, w->nid, 0), cad);
|
|
|
|
do {
|
|
|
|
res = hdac_command(sc,
|
|
|
|
HDA_CMD_GET_PIN_SENSE(cad, w->nid), cad);
|
|
|
|
if (res != 0x7fffffff && res != 0xffffffff)
|
|
|
|
break;
|
|
|
|
DELAY(10);
|
|
|
|
} while (++delay < 10000);
|
|
|
|
} else {
|
|
|
|
delay = 0;
|
|
|
|
res = hdac_command(sc, HDA_CMD_GET_PIN_SENSE(cad,
|
|
|
|
w->nid), cad);
|
|
|
|
}
|
|
|
|
printf(" Sense: 0x%08x", res);
|
|
|
|
if (delay > 0)
|
|
|
|
printf(" delay %dus", delay * 10);
|
|
|
|
}
|
|
|
|
printf("\n");
|
|
|
|
}
|
|
|
|
device_printf(dev,
|
|
|
|
"NumGPIO=%d NumGPO=%d NumGPI=%d GPIWake=%d GPIUnsol=%d\n",
|
|
|
|
HDA_PARAM_GPIO_COUNT_NUM_GPIO(devinfo->function.audio.gpio),
|
|
|
|
HDA_PARAM_GPIO_COUNT_NUM_GPO(devinfo->function.audio.gpio),
|
|
|
|
HDA_PARAM_GPIO_COUNT_NUM_GPI(devinfo->function.audio.gpio),
|
|
|
|
HDA_PARAM_GPIO_COUNT_GPI_WAKE(devinfo->function.audio.gpio),
|
|
|
|
HDA_PARAM_GPIO_COUNT_GPI_UNSOL(devinfo->function.audio.gpio));
|
|
|
|
if (HDA_PARAM_GPIO_COUNT_NUM_GPI(devinfo->function.audio.gpio) > 0) {
|
|
|
|
device_printf(dev, " GPI:");
|
2007-07-01 17:31:20 +00:00
|
|
|
res = hdac_command(sc,
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
HDA_CMD_GET_GPI_DATA(cad, devinfo->nid), cad);
|
|
|
|
printf(" data=0x%08x", res);
|
|
|
|
res = hdac_command(sc,
|
|
|
|
HDA_CMD_GET_GPI_WAKE_ENABLE_MASK(cad, devinfo->nid),
|
|
|
|
cad);
|
|
|
|
printf(" wake=0x%08x", res);
|
|
|
|
res = hdac_command(sc,
|
|
|
|
HDA_CMD_GET_GPI_UNSOLICITED_ENABLE_MASK(cad, devinfo->nid),
|
|
|
|
cad);
|
|
|
|
printf(" unsol=0x%08x", res);
|
|
|
|
res = hdac_command(sc,
|
|
|
|
HDA_CMD_GET_GPI_STICKY_MASK(cad, devinfo->nid), cad);
|
|
|
|
printf(" sticky=0x%08x\n", res);
|
|
|
|
}
|
|
|
|
if (HDA_PARAM_GPIO_COUNT_NUM_GPO(devinfo->function.audio.gpio) > 0) {
|
|
|
|
device_printf(dev, " GPO:");
|
|
|
|
res = hdac_command(sc,
|
|
|
|
HDA_CMD_GET_GPO_DATA(cad, devinfo->nid), cad);
|
|
|
|
printf(" data=0x%08x\n", res);
|
|
|
|
}
|
|
|
|
if (HDA_PARAM_GPIO_COUNT_NUM_GPIO(devinfo->function.audio.gpio) > 0) {
|
|
|
|
device_printf(dev, "GPIO:");
|
|
|
|
res = hdac_command(sc,
|
|
|
|
HDA_CMD_GET_GPIO_DATA(cad, devinfo->nid), cad);
|
|
|
|
printf(" data=0x%08x", res);
|
|
|
|
res = hdac_command(sc,
|
|
|
|
HDA_CMD_GET_GPIO_ENABLE_MASK(cad, devinfo->nid), cad);
|
|
|
|
printf(" enable=0x%08x", res);
|
|
|
|
res = hdac_command(sc,
|
|
|
|
HDA_CMD_GET_GPIO_DIRECTION(cad, devinfo->nid), cad);
|
|
|
|
printf(" direction=0x%08x\n", res);
|
|
|
|
res = hdac_command(sc,
|
|
|
|
HDA_CMD_GET_GPIO_WAKE_ENABLE_MASK(cad, devinfo->nid), cad);
|
|
|
|
device_printf(dev, " wake=0x%08x", res);
|
|
|
|
res = hdac_command(sc,
|
|
|
|
HDA_CMD_GET_GPIO_UNSOLICITED_ENABLE_MASK(cad, devinfo->nid),
|
|
|
|
cad);
|
|
|
|
printf(" unsol=0x%08x", res);
|
|
|
|
res = hdac_command(sc,
|
|
|
|
HDA_CMD_GET_GPIO_STICKY_MASK(cad, devinfo->nid), cad);
|
|
|
|
printf(" sticky=0x%08x\n", res);
|
|
|
|
}
|
2007-07-01 17:31:20 +00:00
|
|
|
}
|
2007-05-05 09:17:36 +00:00
|
|
|
}
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
hdac_unlock(sc);
|
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
|
|
|
static void
|
|
|
|
hdac_attach2(void *arg)
|
|
|
|
{
|
|
|
|
struct hdac_codec *codec;
|
|
|
|
struct hdac_softc *sc;
|
|
|
|
struct hdac_audio_ctl *ctl;
|
|
|
|
uint32_t quirks_on, quirks_off;
|
|
|
|
int codec_index, fg_index;
|
|
|
|
int i, pdev, rdev, dmaalloc = 0;
|
|
|
|
struct hdac_devinfo *devinfo;
|
|
|
|
|
|
|
|
sc = (struct hdac_softc *)arg;
|
|
|
|
|
|
|
|
hdac_config_fetch(sc, &quirks_on, &quirks_off);
|
|
|
|
|
2008-09-16 20:03:34 +00:00
|
|
|
HDA_BOOTHVERBOSE(
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
device_printf(sc->dev, "HDA Config: on=0x%08x off=0x%08x\n",
|
|
|
|
quirks_on, quirks_off);
|
|
|
|
);
|
|
|
|
|
|
|
|
hdac_lock(sc);
|
|
|
|
|
|
|
|
/* Remove ourselves from the config hooks */
|
|
|
|
if (sc->intrhook.ich_func != NULL) {
|
|
|
|
config_intrhook_disestablish(&sc->intrhook);
|
|
|
|
sc->intrhook.ich_func = NULL;
|
2007-05-05 09:17:36 +00:00
|
|
|
}
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
|
|
|
|
/* Start the corb and rirb engines */
|
2008-09-16 20:03:34 +00:00
|
|
|
HDA_BOOTHVERBOSE(
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
device_printf(sc->dev, "Starting CORB Engine...\n");
|
|
|
|
);
|
|
|
|
hdac_corb_start(sc);
|
2008-09-16 20:03:34 +00:00
|
|
|
HDA_BOOTHVERBOSE(
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
device_printf(sc->dev, "Starting RIRB Engine...\n");
|
|
|
|
);
|
|
|
|
hdac_rirb_start(sc);
|
|
|
|
|
2008-09-16 20:03:34 +00:00
|
|
|
HDA_BOOTHVERBOSE(
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
device_printf(sc->dev,
|
|
|
|
"Enabling controller interrupt...\n");
|
|
|
|
);
|
|
|
|
HDAC_WRITE_4(&sc->mem, HDAC_GCTL, HDAC_READ_4(&sc->mem, HDAC_GCTL) |
|
|
|
|
HDAC_GCTL_UNSOL);
|
|
|
|
if (sc->polling == 0) {
|
|
|
|
HDAC_WRITE_4(&sc->mem, HDAC_INTCTL,
|
|
|
|
HDAC_INTCTL_CIE | HDAC_INTCTL_GIE);
|
|
|
|
} else {
|
|
|
|
callout_reset(&sc->poll_hdac, 1, hdac_poll_callback, sc);
|
|
|
|
}
|
|
|
|
DELAY(1000);
|
|
|
|
|
2008-09-16 20:03:34 +00:00
|
|
|
HDA_BOOTHVERBOSE(
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
device_printf(sc->dev,
|
|
|
|
"Scanning HDA codecs ...\n");
|
|
|
|
);
|
|
|
|
hdac_scan_codecs(sc);
|
|
|
|
|
|
|
|
for (codec_index = 0; codec_index < HDAC_CODEC_MAX; codec_index++) {
|
|
|
|
codec = sc->codecs[codec_index];
|
|
|
|
if (codec == NULL)
|
|
|
|
continue;
|
|
|
|
for (fg_index = 0; fg_index < codec->num_fgs; fg_index++) {
|
|
|
|
devinfo = &codec->fgs[fg_index];
|
2008-09-14 15:10:53 +00:00
|
|
|
HDA_BOOTVERBOSE(
|
|
|
|
device_printf(sc->dev, "\n");
|
2008-09-16 20:03:34 +00:00
|
|
|
device_printf(sc->dev,
|
|
|
|
"Processing %s FG cad=%d nid=%d...\n",
|
|
|
|
(devinfo->node_type == HDA_PARAM_FCT_GRP_TYPE_NODE_TYPE_AUDIO) ? "audio":
|
|
|
|
(devinfo->node_type == HDA_PARAM_FCT_GRP_TYPE_NODE_TYPE_MODEM) ? "modem":
|
|
|
|
"unknown",
|
|
|
|
devinfo->codec->cad, devinfo->nid);
|
2008-09-14 15:10:53 +00:00
|
|
|
);
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
if (devinfo->node_type !=
|
|
|
|
HDA_PARAM_FCT_GRP_TYPE_NODE_TYPE_AUDIO) {
|
2008-09-16 20:03:34 +00:00
|
|
|
HDA_BOOTHVERBOSE(
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
device_printf(sc->dev,
|
2008-09-16 20:03:34 +00:00
|
|
|
"Powering down...\n");
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
);
|
|
|
|
hdac_command(sc,
|
|
|
|
HDA_CMD_SET_POWER_STATE(codec->cad,
|
|
|
|
devinfo->nid, HDA_CMD_POWER_STATE_D3),
|
|
|
|
codec->cad);
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
2008-09-16 20:03:34 +00:00
|
|
|
HDA_BOOTHVERBOSE(
|
|
|
|
device_printf(sc->dev, "Powering up...\n");
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
);
|
|
|
|
hdac_powerup(devinfo);
|
2008-09-16 20:03:34 +00:00
|
|
|
HDA_BOOTHVERBOSE(
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
device_printf(sc->dev, "Parsing audio FG...\n");
|
|
|
|
);
|
|
|
|
hdac_audio_parse(devinfo);
|
2008-09-16 20:03:34 +00:00
|
|
|
HDA_BOOTHVERBOSE(
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
device_printf(sc->dev, "Parsing Ctls...\n");
|
|
|
|
);
|
|
|
|
hdac_audio_ctl_parse(devinfo);
|
2008-09-16 20:03:34 +00:00
|
|
|
HDA_BOOTHVERBOSE(
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
device_printf(sc->dev, "Parsing vendor patch...\n");
|
|
|
|
);
|
|
|
|
hdac_vendor_patch_parse(devinfo);
|
|
|
|
devinfo->function.audio.quirks |= quirks_on;
|
|
|
|
devinfo->function.audio.quirks &= ~quirks_off;
|
|
|
|
|
2008-09-16 20:03:34 +00:00
|
|
|
HDA_BOOTHVERBOSE(
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
device_printf(sc->dev, "Disabling nonaudio...\n");
|
|
|
|
);
|
|
|
|
hdac_audio_disable_nonaudio(devinfo);
|
2008-09-16 20:03:34 +00:00
|
|
|
HDA_BOOTHVERBOSE(
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
device_printf(sc->dev, "Disabling useless...\n");
|
|
|
|
);
|
|
|
|
hdac_audio_disable_useless(devinfo);
|
|
|
|
HDA_BOOTVERBOSE(
|
|
|
|
device_printf(sc->dev, "Patched pins configuration:\n");
|
|
|
|
hdac_dump_pin_configs(devinfo);
|
2008-09-16 20:03:34 +00:00
|
|
|
);
|
|
|
|
HDA_BOOTHVERBOSE(
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
device_printf(sc->dev, "Parsing pin associations...\n");
|
|
|
|
);
|
|
|
|
hdac_audio_as_parse(devinfo);
|
2008-09-16 20:03:34 +00:00
|
|
|
HDA_BOOTHVERBOSE(
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
device_printf(sc->dev, "Building AFG tree...\n");
|
|
|
|
);
|
|
|
|
hdac_audio_build_tree(devinfo);
|
2008-09-16 20:03:34 +00:00
|
|
|
HDA_BOOTHVERBOSE(
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
device_printf(sc->dev, "Disabling unassociated "
|
|
|
|
"widgets...\n");
|
|
|
|
);
|
|
|
|
hdac_audio_disable_unas(devinfo);
|
2008-09-16 20:03:34 +00:00
|
|
|
HDA_BOOTHVERBOSE(
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
device_printf(sc->dev, "Disabling nonselected "
|
|
|
|
"inputs...\n");
|
|
|
|
);
|
|
|
|
hdac_audio_disable_notselected(devinfo);
|
2008-09-16 20:03:34 +00:00
|
|
|
HDA_BOOTHVERBOSE(
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
device_printf(sc->dev, "Disabling useless...\n");
|
|
|
|
);
|
|
|
|
hdac_audio_disable_useless(devinfo);
|
2008-09-16 20:03:34 +00:00
|
|
|
HDA_BOOTHVERBOSE(
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
device_printf(sc->dev, "Disabling "
|
|
|
|
"crossassociatement connections...\n");
|
|
|
|
);
|
|
|
|
hdac_audio_disable_crossas(devinfo);
|
2008-09-16 20:03:34 +00:00
|
|
|
HDA_BOOTHVERBOSE(
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
device_printf(sc->dev, "Disabling useless...\n");
|
|
|
|
);
|
|
|
|
hdac_audio_disable_useless(devinfo);
|
2008-09-16 20:03:34 +00:00
|
|
|
HDA_BOOTHVERBOSE(
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
device_printf(sc->dev, "Binding associations to channels...\n");
|
|
|
|
);
|
|
|
|
hdac_audio_bind_as(devinfo);
|
2008-09-16 20:03:34 +00:00
|
|
|
HDA_BOOTHVERBOSE(
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
device_printf(sc->dev, "Assigning names to signal sources...\n");
|
|
|
|
);
|
|
|
|
hdac_audio_assign_names(devinfo);
|
2008-09-16 20:03:34 +00:00
|
|
|
HDA_BOOTHVERBOSE(
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
device_printf(sc->dev, "Assigning mixers to the tree...\n");
|
|
|
|
);
|
|
|
|
hdac_audio_assign_mixers(devinfo);
|
2008-09-16 20:03:34 +00:00
|
|
|
HDA_BOOTHVERBOSE(
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
device_printf(sc->dev, "Preparing pin controls...\n");
|
|
|
|
);
|
|
|
|
hdac_audio_prepare_pin_ctrl(devinfo);
|
2008-09-16 20:03:34 +00:00
|
|
|
HDA_BOOTHVERBOSE(
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
device_printf(sc->dev, "AFG commit...\n");
|
|
|
|
);
|
|
|
|
hdac_audio_commit(devinfo);
|
2008-09-16 20:03:34 +00:00
|
|
|
HDA_BOOTHVERBOSE(
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
device_printf(sc->dev, "Ctls commit...\n");
|
|
|
|
);
|
|
|
|
hdac_audio_ctl_commit(devinfo);
|
2008-09-16 20:03:34 +00:00
|
|
|
HDA_BOOTHVERBOSE(
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
device_printf(sc->dev, "HP switch init...\n");
|
|
|
|
);
|
|
|
|
hdac_hp_switch_init(devinfo);
|
|
|
|
|
|
|
|
if ((devinfo->function.audio.quirks & HDA_QUIRK_DMAPOS) &&
|
|
|
|
dmaalloc == 0) {
|
|
|
|
if (hdac_dma_alloc(sc, &sc->pos_dma,
|
|
|
|
(sc->num_iss + sc->num_oss + sc->num_bss) * 8) != 0) {
|
|
|
|
HDA_BOOTVERBOSE(
|
|
|
|
device_printf(sc->dev, "Failed to "
|
|
|
|
"allocate DMA pos buffer "
|
|
|
|
"(non-fatal)\n");
|
|
|
|
);
|
|
|
|
} else
|
|
|
|
dmaalloc = 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
i = devinfo->function.audio.playcnt;
|
|
|
|
if (devinfo->function.audio.reccnt > i)
|
|
|
|
i = devinfo->function.audio.reccnt;
|
|
|
|
devinfo->function.audio.devs =
|
|
|
|
(struct hdac_pcm_devinfo *)malloc(
|
|
|
|
sizeof(struct hdac_pcm_devinfo) * i,
|
|
|
|
M_HDAC, M_ZERO | M_NOWAIT);
|
|
|
|
if (devinfo->function.audio.devs == NULL) {
|
|
|
|
device_printf(sc->dev,
|
|
|
|
"Unable to allocate memory for devices\n");
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
devinfo->function.audio.num_devs = i;
|
|
|
|
for (i = 0; i < devinfo->function.audio.num_devs; i++) {
|
|
|
|
devinfo->function.audio.devs[i].index = i;
|
|
|
|
devinfo->function.audio.devs[i].devinfo = devinfo;
|
|
|
|
devinfo->function.audio.devs[i].play = -1;
|
|
|
|
devinfo->function.audio.devs[i].rec = -1;
|
|
|
|
}
|
|
|
|
pdev = 0;
|
|
|
|
rdev = 0;
|
|
|
|
for (i = 0; i < devinfo->function.audio.ascnt; i++) {
|
|
|
|
if (devinfo->function.audio.as[i].enable == 0)
|
|
|
|
continue;
|
|
|
|
if (devinfo->function.audio.as[i].dir ==
|
|
|
|
HDA_CTL_IN) {
|
|
|
|
devinfo->function.audio.devs[rdev].rec
|
|
|
|
= devinfo->function.audio.as[i].chan;
|
|
|
|
sc->chans[devinfo->function.audio.as[i].chan].pdevinfo =
|
|
|
|
&devinfo->function.audio.devs[rdev];
|
|
|
|
rdev++;
|
|
|
|
} else {
|
|
|
|
devinfo->function.audio.devs[pdev].play
|
|
|
|
= devinfo->function.audio.as[i].chan;
|
|
|
|
sc->chans[devinfo->function.audio.as[i].chan].pdevinfo =
|
|
|
|
&devinfo->function.audio.devs[pdev];
|
|
|
|
pdev++;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
for (i = 0; i < devinfo->function.audio.num_devs; i++) {
|
|
|
|
struct hdac_pcm_devinfo *pdevinfo =
|
|
|
|
&devinfo->function.audio.devs[i];
|
|
|
|
pdevinfo->dev =
|
|
|
|
device_add_child(sc->dev, "pcm", -1);
|
|
|
|
device_set_ivars(pdevinfo->dev,
|
|
|
|
(void *)pdevinfo);
|
|
|
|
}
|
|
|
|
|
|
|
|
HDA_BOOTVERBOSE(
|
|
|
|
if (devinfo->function.audio.quirks != 0) {
|
2008-09-16 20:03:34 +00:00
|
|
|
device_printf(sc->dev, "FG config/quirks:");
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
for (i = 0; i < HDAC_QUIRKS_TAB_LEN; i++) {
|
|
|
|
if ((devinfo->function.audio.quirks &
|
|
|
|
hdac_quirks_tab[i].value) ==
|
|
|
|
hdac_quirks_tab[i].value)
|
|
|
|
printf(" %s", hdac_quirks_tab[i].key);
|
|
|
|
}
|
|
|
|
printf("\n");
|
|
|
|
}
|
|
|
|
|
|
|
|
device_printf(sc->dev, "\n");
|
|
|
|
device_printf(sc->dev, "+-------------------+\n");
|
|
|
|
device_printf(sc->dev, "| DUMPING HDA NODES |\n");
|
|
|
|
device_printf(sc->dev, "+-------------------+\n");
|
|
|
|
hdac_dump_nodes(devinfo);
|
2008-09-16 20:03:34 +00:00
|
|
|
);
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
|
2008-09-16 20:03:34 +00:00
|
|
|
HDA_BOOTHVERBOSE(
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
device_printf(sc->dev, "\n");
|
|
|
|
device_printf(sc->dev, "+------------------------+\n");
|
|
|
|
device_printf(sc->dev, "| DUMPING HDA AMPLIFIERS |\n");
|
|
|
|
device_printf(sc->dev, "+------------------------+\n");
|
|
|
|
device_printf(sc->dev, "\n");
|
|
|
|
i = 0;
|
|
|
|
while ((ctl = hdac_audio_ctl_each(devinfo, &i)) != NULL) {
|
|
|
|
device_printf(sc->dev, "%3d: nid %3d %s (%s) index %d", i,
|
|
|
|
(ctl->widget != NULL) ? ctl->widget->nid : -1,
|
|
|
|
(ctl->ndir == HDA_CTL_IN)?"in ":"out",
|
|
|
|
(ctl->dir == HDA_CTL_IN)?"in ":"out",
|
|
|
|
ctl->index);
|
|
|
|
if (ctl->childwidget != NULL)
|
|
|
|
printf(" cnid %3d", ctl->childwidget->nid);
|
|
|
|
else
|
|
|
|
printf(" ");
|
|
|
|
printf(" ossmask=0x%08x\n",
|
|
|
|
ctl->ossmask);
|
|
|
|
device_printf(sc->dev,
|
|
|
|
" mute: %d step: %3d size: %3d off: %3d%s\n",
|
|
|
|
ctl->mute, ctl->step, ctl->size, ctl->offset,
|
|
|
|
(ctl->enable == 0) ? " [DISABLED]" :
|
|
|
|
((ctl->ossmask == 0) ? " [UNUSED]" : ""));
|
|
|
|
}
|
|
|
|
);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
hdac_unlock(sc);
|
|
|
|
|
|
|
|
HDA_BOOTVERBOSE(
|
|
|
|
device_printf(sc->dev, "\n");
|
|
|
|
);
|
|
|
|
|
|
|
|
bus_generic_attach(sc->dev);
|
|
|
|
|
|
|
|
#ifdef SND_DYNSYSCTL
|
|
|
|
SYSCTL_ADD_PROC(device_get_sysctl_ctx(sc->dev),
|
|
|
|
SYSCTL_CHILDREN(device_get_sysctl_tree(sc->dev)), OID_AUTO,
|
|
|
|
"polling", CTLTYPE_INT | CTLFLAG_RW, sc->dev, sizeof(sc->dev),
|
|
|
|
sysctl_hdac_polling, "I", "Enable polling mode");
|
|
|
|
SYSCTL_ADD_PROC(device_get_sysctl_ctx(sc->dev),
|
|
|
|
SYSCTL_CHILDREN(device_get_sysctl_tree(sc->dev)), OID_AUTO,
|
|
|
|
"polling_interval", CTLTYPE_INT | CTLFLAG_RW, sc->dev,
|
|
|
|
sizeof(sc->dev), sysctl_hdac_polling_interval, "I",
|
|
|
|
"Controller/Jack Sense polling interval (1-1000 ms)");
|
|
|
|
SYSCTL_ADD_PROC(device_get_sysctl_ctx(sc->dev),
|
|
|
|
SYSCTL_CHILDREN(device_get_sysctl_tree(sc->dev)), OID_AUTO,
|
|
|
|
"pindump", CTLTYPE_INT | CTLFLAG_RW, sc->dev, sizeof(sc->dev),
|
|
|
|
sysctl_hdac_pindump, "I", "Dump pin states/data");
|
|
|
|
#endif
|
|
|
|
}
|
|
|
|
|
|
|
|
/****************************************************************************
|
|
|
|
* int hdac_suspend(device_t)
|
|
|
|
*
|
|
|
|
* Suspend and power down HDA bus and codecs.
|
|
|
|
****************************************************************************/
|
|
|
|
static int
|
|
|
|
hdac_suspend(device_t dev)
|
|
|
|
{
|
|
|
|
struct hdac_softc *sc;
|
|
|
|
struct hdac_codec *codec;
|
|
|
|
struct hdac_devinfo *devinfo;
|
|
|
|
int codec_index, fg_index, i;
|
|
|
|
|
2008-09-16 20:03:34 +00:00
|
|
|
HDA_BOOTHVERBOSE(
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
device_printf(dev, "Suspend...\n");
|
|
|
|
);
|
|
|
|
|
|
|
|
sc = device_get_softc(dev);
|
|
|
|
hdac_lock(sc);
|
|
|
|
|
2008-09-16 20:03:34 +00:00
|
|
|
HDA_BOOTHVERBOSE(
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
device_printf(dev, "Stop streams...\n");
|
|
|
|
);
|
|
|
|
for (i = 0; i < sc->num_chans; i++) {
|
|
|
|
if (sc->chans[i].flags & HDAC_CHN_RUNNING) {
|
|
|
|
sc->chans[i].flags |= HDAC_CHN_SUSPEND;
|
|
|
|
hdac_channel_stop(sc, &sc->chans[i]);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
for (codec_index = 0; codec_index < HDAC_CODEC_MAX; codec_index++) {
|
|
|
|
codec = sc->codecs[codec_index];
|
|
|
|
if (codec == NULL)
|
|
|
|
continue;
|
|
|
|
for (fg_index = 0; fg_index < codec->num_fgs; fg_index++) {
|
|
|
|
devinfo = &codec->fgs[fg_index];
|
2008-09-16 20:03:34 +00:00
|
|
|
HDA_BOOTHVERBOSE(
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
device_printf(dev,
|
|
|
|
"Power down FG"
|
|
|
|
" cad=%d nid=%d to the D3 state...\n",
|
|
|
|
codec->cad, devinfo->nid);
|
|
|
|
);
|
|
|
|
hdac_command(sc,
|
|
|
|
HDA_CMD_SET_POWER_STATE(codec->cad,
|
|
|
|
devinfo->nid, HDA_CMD_POWER_STATE_D3),
|
|
|
|
codec->cad);
|
|
|
|
}
|
2007-05-05 09:17:36 +00:00
|
|
|
}
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
|
2008-09-16 20:03:34 +00:00
|
|
|
HDA_BOOTHVERBOSE(
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
device_printf(dev, "Reset controller...\n");
|
|
|
|
);
|
|
|
|
callout_stop(&sc->poll_hda);
|
|
|
|
callout_stop(&sc->poll_hdac);
|
|
|
|
callout_stop(&sc->poll_jack);
|
|
|
|
hdac_reset(sc, 0);
|
2007-05-05 09:17:36 +00:00
|
|
|
hdac_unlock(sc);
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
taskqueue_drain(taskqueue_thread, &sc->unsolq_task);
|
|
|
|
callout_drain(&sc->poll_hda);
|
|
|
|
callout_drain(&sc->poll_hdac);
|
|
|
|
callout_drain(&sc->poll_jack);
|
|
|
|
|
2008-09-16 20:03:34 +00:00
|
|
|
HDA_BOOTHVERBOSE(
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
device_printf(dev, "Suspend done\n");
|
|
|
|
);
|
|
|
|
|
2007-05-05 09:17:36 +00:00
|
|
|
return (0);
|
|
|
|
}
|
Welcome to Once-a-year Sound Mega-Commit. Enjoy numerous updates and fixes
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.
2006-11-26 12:24:06 +00:00
|
|
|
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
/****************************************************************************
|
|
|
|
* int hdac_resume(device_t)
|
|
|
|
*
|
|
|
|
* Powerup and restore HDA bus and codecs state.
|
|
|
|
****************************************************************************/
|
|
|
|
static int
|
|
|
|
hdac_resume(device_t dev)
|
2006-10-01 11:13:00 +00:00
|
|
|
{
|
|
|
|
struct hdac_softc *sc;
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
struct hdac_codec *codec;
|
|
|
|
struct hdac_devinfo *devinfo;
|
|
|
|
int codec_index, fg_index, i;
|
- Fix wrong id for ALC882, add ALC883 id.
- 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"
2006-10-06 18:59:27 +00:00
|
|
|
|
2008-09-16 20:03:34 +00:00
|
|
|
HDA_BOOTHVERBOSE(
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
device_printf(dev, "Resume...\n");
|
- Fix wrong id for ALC882, add ALC883 id.
- 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"
2006-10-06 18:59:27 +00:00
|
|
|
);
|
2006-10-01 11:13:00 +00:00
|
|
|
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
sc = device_get_softc(dev);
|
2006-10-01 11:13:00 +00:00
|
|
|
hdac_lock(sc);
|
|
|
|
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
/* Quiesce everything */
|
2008-09-16 20:03:34 +00:00
|
|
|
HDA_BOOTHVERBOSE(
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
device_printf(dev, "Reset controller...\n");
|
|
|
|
);
|
|
|
|
hdac_reset(sc, 1);
|
|
|
|
|
|
|
|
/* Initialize the CORB and RIRB */
|
|
|
|
hdac_corb_init(sc);
|
|
|
|
hdac_rirb_init(sc);
|
2006-10-01 11:13:00 +00:00
|
|
|
|
|
|
|
/* Start the corb and rirb engines */
|
2008-09-16 20:03:34 +00:00
|
|
|
HDA_BOOTHVERBOSE(
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
device_printf(dev, "Starting CORB Engine...\n");
|
2006-10-01 11:13:00 +00:00
|
|
|
);
|
|
|
|
hdac_corb_start(sc);
|
2008-09-16 20:03:34 +00:00
|
|
|
HDA_BOOTHVERBOSE(
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
device_printf(dev, "Starting RIRB Engine...\n");
|
2006-10-01 11:13:00 +00:00
|
|
|
);
|
|
|
|
hdac_rirb_start(sc);
|
|
|
|
|
2008-09-16 20:03:34 +00:00
|
|
|
HDA_BOOTHVERBOSE(
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
device_printf(dev,
|
|
|
|
"Enabling controller interrupt...\n");
|
2006-10-01 11:13:00 +00:00
|
|
|
);
|
- Fix wrong id for ALC882, add ALC883 id.
- 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"
2006-10-06 18:59:27 +00:00
|
|
|
HDAC_WRITE_4(&sc->mem, HDAC_GCTL, HDAC_READ_4(&sc->mem, HDAC_GCTL) |
|
|
|
|
HDAC_GCTL_UNSOL);
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
if (sc->polling == 0) {
|
|
|
|
HDAC_WRITE_4(&sc->mem, HDAC_INTCTL,
|
|
|
|
HDAC_INTCTL_CIE | HDAC_INTCTL_GIE);
|
|
|
|
} else {
|
|
|
|
callout_reset(&sc->poll_hdac, 1, hdac_poll_callback, sc);
|
|
|
|
}
|
2006-10-01 11:13:00 +00:00
|
|
|
DELAY(1000);
|
|
|
|
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
for (codec_index = 0; codec_index < HDAC_CODEC_MAX; codec_index++) {
|
|
|
|
codec = sc->codecs[codec_index];
|
|
|
|
if (codec == NULL)
|
|
|
|
continue;
|
|
|
|
for (fg_index = 0; fg_index < codec->num_fgs; fg_index++) {
|
|
|
|
devinfo = &codec->fgs[fg_index];
|
|
|
|
if (devinfo->node_type !=
|
|
|
|
HDA_PARAM_FCT_GRP_TYPE_NODE_TYPE_AUDIO) {
|
2008-09-16 20:03:34 +00:00
|
|
|
HDA_BOOTHVERBOSE(
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
device_printf(dev,
|
|
|
|
"Power down unsupported non-audio FG"
|
|
|
|
" cad=%d nid=%d to the D3 state...\n",
|
|
|
|
codec->cad, devinfo->nid);
|
|
|
|
);
|
|
|
|
hdac_command(sc,
|
|
|
|
HDA_CMD_SET_POWER_STATE(codec->cad,
|
|
|
|
devinfo->nid, HDA_CMD_POWER_STATE_D3),
|
|
|
|
codec->cad);
|
|
|
|
continue;
|
|
|
|
}
|
2006-10-01 11:13:00 +00:00
|
|
|
|
2008-09-16 20:03:34 +00:00
|
|
|
HDA_BOOTHVERBOSE(
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
device_printf(dev,
|
|
|
|
"Power up audio FG cad=%d nid=%d...\n",
|
|
|
|
devinfo->codec->cad, devinfo->nid);
|
|
|
|
);
|
|
|
|
hdac_powerup(devinfo);
|
2008-09-16 20:03:34 +00:00
|
|
|
HDA_BOOTHVERBOSE(
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
device_printf(dev, "AFG commit...\n");
|
|
|
|
);
|
|
|
|
hdac_audio_commit(devinfo);
|
2008-09-16 20:03:34 +00:00
|
|
|
HDA_BOOTHVERBOSE(
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
device_printf(dev, "Ctls commit...\n");
|
|
|
|
);
|
|
|
|
hdac_audio_ctl_commit(devinfo);
|
2008-09-16 20:03:34 +00:00
|
|
|
HDA_BOOTHVERBOSE(
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
device_printf(dev, "HP switch init...\n");
|
|
|
|
);
|
|
|
|
hdac_hp_switch_init(devinfo);
|
2006-10-01 11:13:00 +00:00
|
|
|
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
hdac_unlock(sc);
|
|
|
|
for (i = 0; i < devinfo->function.audio.num_devs; i++) {
|
|
|
|
struct hdac_pcm_devinfo *pdevinfo =
|
|
|
|
&devinfo->function.audio.devs[i];
|
2008-09-16 20:03:34 +00:00
|
|
|
HDA_BOOTHVERBOSE(
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
device_printf(pdevinfo->dev,
|
|
|
|
"OSS mixer reinitialization...\n");
|
|
|
|
);
|
|
|
|
if (mixer_reinit(pdevinfo->dev) == -1)
|
|
|
|
device_printf(pdevinfo->dev,
|
|
|
|
"unable to reinitialize the mixer\n");
|
|
|
|
}
|
|
|
|
hdac_lock(sc);
|
|
|
|
}
|
2006-10-01 11:13:00 +00:00
|
|
|
}
|
|
|
|
|
2008-09-16 20:03:34 +00:00
|
|
|
HDA_BOOTHVERBOSE(
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
device_printf(dev, "Start streams...\n");
|
2006-10-01 11:13:00 +00:00
|
|
|
);
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
for (i = 0; i < sc->num_chans; i++) {
|
|
|
|
if (sc->chans[i].flags & HDAC_CHN_SUSPEND) {
|
|
|
|
sc->chans[i].flags &= ~HDAC_CHN_SUSPEND;
|
|
|
|
hdac_channel_start(sc, &sc->chans[i]);
|
2006-10-01 11:13:00 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
hdac_unlock(sc);
|
2006-10-01 11:13:00 +00:00
|
|
|
|
2008-09-16 20:03:34 +00:00
|
|
|
HDA_BOOTHVERBOSE(
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
device_printf(dev, "Resume done\n");
|
2006-10-01 11:13:00 +00:00
|
|
|
);
|
|
|
|
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
/****************************************************************************
|
|
|
|
* int hdac_detach(device_t)
|
|
|
|
*
|
|
|
|
* Detach and free up resources utilized by the hdac device.
|
|
|
|
****************************************************************************/
|
|
|
|
static int
|
|
|
|
hdac_detach(device_t dev)
|
|
|
|
{
|
|
|
|
struct hdac_softc *sc;
|
|
|
|
device_t *devlist = NULL;
|
|
|
|
int i, devcount;
|
2006-10-01 11:13:00 +00:00
|
|
|
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
sc = device_get_softc(dev);
|
- Fix wrong id for ALC882, add ALC883 id.
- 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"
2006-10-06 18:59:27 +00:00
|
|
|
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
device_get_children(dev, &devlist, &devcount);
|
|
|
|
for (i = 0; devlist != NULL && i < devcount; i++)
|
|
|
|
device_delete_child(dev, devlist[i]);
|
|
|
|
if (devlist != NULL)
|
|
|
|
free(devlist, M_TEMP);
|
2006-10-01 11:13:00 +00:00
|
|
|
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
hdac_release_resources(sc);
|
2006-10-01 11:13:00 +00:00
|
|
|
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
|
|
|
|
static device_method_t hdac_methods[] = {
|
|
|
|
/* device interface */
|
|
|
|
DEVMETHOD(device_probe, hdac_probe),
|
|
|
|
DEVMETHOD(device_attach, hdac_attach),
|
|
|
|
DEVMETHOD(device_detach, hdac_detach),
|
|
|
|
DEVMETHOD(device_suspend, hdac_suspend),
|
|
|
|
DEVMETHOD(device_resume, hdac_resume),
|
|
|
|
{ 0, 0 }
|
|
|
|
};
|
2006-10-01 11:13:00 +00:00
|
|
|
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
static driver_t hdac_driver = {
|
|
|
|
"hdac",
|
|
|
|
hdac_methods,
|
|
|
|
sizeof(struct hdac_softc),
|
|
|
|
};
|
2006-10-01 11:13:00 +00:00
|
|
|
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
static devclass_t hdac_devclass;
|
2007-05-05 09:17:36 +00:00
|
|
|
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
DRIVER_MODULE(snd_hda, pci, hdac_driver, hdac_devclass, 0, 0);
|
|
|
|
MODULE_DEPEND(snd_hda, sound, SOUND_MINVER, SOUND_PREFVER, SOUND_MAXVER);
|
|
|
|
MODULE_VERSION(snd_hda, 1);
|
2006-10-01 11:13:00 +00:00
|
|
|
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
static int
|
|
|
|
hdac_pcm_probe(device_t dev)
|
|
|
|
{
|
|
|
|
struct hdac_pcm_devinfo *pdevinfo =
|
|
|
|
(struct hdac_pcm_devinfo *)device_get_ivars(dev);
|
|
|
|
char buf[128];
|
|
|
|
|
|
|
|
snprintf(buf, sizeof(buf), "HDA codec #%d %s PCM #%d",
|
|
|
|
pdevinfo->devinfo->codec->cad,
|
|
|
|
hdac_codec_name(pdevinfo->devinfo->codec),
|
|
|
|
pdevinfo->index);
|
|
|
|
device_set_desc_copy(dev, buf);
|
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
|
|
|
|
static int
|
|
|
|
hdac_pcm_attach(device_t dev)
|
|
|
|
{
|
|
|
|
struct hdac_pcm_devinfo *pdevinfo =
|
|
|
|
(struct hdac_pcm_devinfo *)device_get_ivars(dev);
|
|
|
|
struct hdac_softc *sc = pdevinfo->devinfo->codec->sc;
|
|
|
|
char status[SND_STATUSLEN];
|
|
|
|
int i;
|
|
|
|
|
|
|
|
pdevinfo->chan_size = pcm_getbuffersize(dev,
|
|
|
|
HDA_BUFSZ_MIN, HDA_BUFSZ_DEFAULT, HDA_BUFSZ_MAX);
|
Welcome to Once-a-year Sound Mega-Commit. Enjoy numerous updates and fixes
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.
2006-11-26 12:24:06 +00:00
|
|
|
|
- Fix wrong id for ALC882, add ALC883 id.
- 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"
2006-10-06 18:59:27 +00:00
|
|
|
HDA_BOOTVERBOSE(
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
device_printf(dev, "+--------------------------------------+\n");
|
|
|
|
device_printf(dev, "| DUMPING PCM Playback/Record Channels |\n");
|
|
|
|
device_printf(dev, "+--------------------------------------+\n");
|
|
|
|
hdac_dump_pcmchannels(pdevinfo);
|
|
|
|
device_printf(dev, "\n");
|
|
|
|
device_printf(dev, "+--------------------------------+\n");
|
|
|
|
device_printf(dev, "| DUMPING Playback/Record Pathes |\n");
|
|
|
|
device_printf(dev, "+--------------------------------+\n");
|
|
|
|
hdac_dump_dac(pdevinfo);
|
|
|
|
hdac_dump_adc(pdevinfo);
|
|
|
|
hdac_dump_mix(pdevinfo);
|
|
|
|
device_printf(dev, "\n");
|
|
|
|
device_printf(dev, "+-------------------------+\n");
|
|
|
|
device_printf(dev, "| DUMPING Volume Controls |\n");
|
|
|
|
device_printf(dev, "+-------------------------+\n");
|
|
|
|
hdac_dump_ctls(pdevinfo, "Master Volume", SOUND_MASK_VOLUME);
|
|
|
|
hdac_dump_ctls(pdevinfo, "PCM Volume", SOUND_MASK_PCM);
|
|
|
|
hdac_dump_ctls(pdevinfo, "CD Volume", SOUND_MASK_CD);
|
|
|
|
hdac_dump_ctls(pdevinfo, "Microphone Volume", SOUND_MASK_MIC);
|
|
|
|
hdac_dump_ctls(pdevinfo, "Microphone2 Volume", SOUND_MASK_MONITOR);
|
|
|
|
hdac_dump_ctls(pdevinfo, "Line-in Volume", SOUND_MASK_LINE);
|
|
|
|
hdac_dump_ctls(pdevinfo, "Speaker/Beep Volume", SOUND_MASK_SPEAKER);
|
|
|
|
hdac_dump_ctls(pdevinfo, "Recording Level", SOUND_MASK_RECLEV);
|
|
|
|
hdac_dump_ctls(pdevinfo, "Input Mix Level", SOUND_MASK_IMIX);
|
|
|
|
hdac_dump_ctls(pdevinfo, NULL, 0);
|
|
|
|
device_printf(dev, "\n");
|
- Fix wrong id for ALC882, add ALC883 id.
- 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"
2006-10-06 18:59:27 +00:00
|
|
|
);
|
2006-10-01 11:13:00 +00:00
|
|
|
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
if (resource_int_value(device_get_name(dev),
|
|
|
|
device_get_unit(dev), "blocksize", &i) == 0 && i > 0) {
|
|
|
|
i &= HDA_BLK_ALIGN;
|
|
|
|
if (i < HDA_BLK_MIN)
|
|
|
|
i = HDA_BLK_MIN;
|
|
|
|
pdevinfo->chan_blkcnt = pdevinfo->chan_size / i;
|
2006-10-01 11:13:00 +00:00
|
|
|
i = 0;
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
while (pdevinfo->chan_blkcnt >> i)
|
|
|
|
i++;
|
|
|
|
pdevinfo->chan_blkcnt = 1 << (i - 1);
|
|
|
|
if (pdevinfo->chan_blkcnt < HDA_BDL_MIN)
|
|
|
|
pdevinfo->chan_blkcnt = HDA_BDL_MIN;
|
|
|
|
else if (pdevinfo->chan_blkcnt > HDA_BDL_MAX)
|
|
|
|
pdevinfo->chan_blkcnt = HDA_BDL_MAX;
|
|
|
|
} else
|
|
|
|
pdevinfo->chan_blkcnt = HDA_BDL_DEFAULT;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* We don't register interrupt handler with snd_setup_intr
|
|
|
|
* in pcm device. Mark pcm device as MPSAFE manually.
|
|
|
|
*/
|
|
|
|
pcm_setflags(dev, pcm_getflags(dev) | SD_F_MPSAFE);
|
|
|
|
|
2008-09-16 20:03:34 +00:00
|
|
|
HDA_BOOTHVERBOSE(
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
device_printf(dev, "OSS mixer initialization...\n");
|
2006-10-01 11:13:00 +00:00
|
|
|
);
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
if (mixer_init(dev, &hdac_audio_ctl_ossmixer_class, pdevinfo) != 0)
|
|
|
|
device_printf(dev, "Can't register mixer\n");
|
Welcome to Once-a-year Sound Mega-Commit. Enjoy numerous updates and fixes
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.
2006-11-26 12:24:06 +00:00
|
|
|
|
2008-09-16 20:03:34 +00:00
|
|
|
HDA_BOOTHVERBOSE(
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
device_printf(dev, "Registering PCM channels...\n");
|
|
|
|
);
|
|
|
|
if (pcm_register(dev, pdevinfo, (pdevinfo->play >= 0)?1:0,
|
|
|
|
(pdevinfo->rec >= 0)?1:0) != 0)
|
|
|
|
device_printf(dev, "Can't register PCM\n");
|
|
|
|
|
|
|
|
pdevinfo->registered++;
|
|
|
|
|
|
|
|
if (pdevinfo->play >= 0)
|
|
|
|
pcm_addchan(dev, PCMDIR_PLAY, &hdac_channel_class, pdevinfo);
|
|
|
|
if (pdevinfo->rec >= 0)
|
|
|
|
pcm_addchan(dev, PCMDIR_REC, &hdac_channel_class, pdevinfo);
|
|
|
|
|
|
|
|
snprintf(status, SND_STATUSLEN, "at %s cad %d %s [%s]",
|
|
|
|
device_get_nameunit(sc->dev), pdevinfo->devinfo->codec->cad,
|
|
|
|
PCM_KLDSTRING(snd_hda), HDA_DRV_TEST_REV);
|
|
|
|
pcm_setstatus(dev, status);
|
|
|
|
|
|
|
|
return (0);
|
2006-10-01 11:13:00 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static int
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
hdac_pcm_detach(device_t dev)
|
2006-10-01 11:13:00 +00:00
|
|
|
{
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
struct hdac_pcm_devinfo *pdevinfo =
|
|
|
|
(struct hdac_pcm_devinfo *)device_get_ivars(dev);
|
- Fix wrong id for ALC882, add ALC883 id.
- 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"
2006-10-06 18:59:27 +00:00
|
|
|
int err;
|
2006-10-01 11:13:00 +00:00
|
|
|
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
if (pdevinfo->registered > 0) {
|
- Fix wrong id for ALC882, add ALC883 id.
- 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"
2006-10-06 18:59:27 +00:00
|
|
|
err = pcm_unregister(dev);
|
|
|
|
if (err != 0)
|
|
|
|
return (err);
|
2006-10-01 11:13:00 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
static device_method_t hdac_pcm_methods[] = {
|
2006-10-01 11:13:00 +00:00
|
|
|
/* device interface */
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
DEVMETHOD(device_probe, hdac_pcm_probe),
|
|
|
|
DEVMETHOD(device_attach, hdac_pcm_attach),
|
|
|
|
DEVMETHOD(device_detach, hdac_pcm_detach),
|
2006-10-01 11:13:00 +00:00
|
|
|
{ 0, 0 }
|
|
|
|
};
|
|
|
|
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
static driver_t hdac_pcm_driver = {
|
2006-10-01 11:13:00 +00:00
|
|
|
"pcm",
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
hdac_pcm_methods,
|
2006-10-01 11:13:00 +00:00
|
|
|
PCM_SOFTC_SIZE,
|
|
|
|
};
|
|
|
|
|
My massive snd_hda driver update.
Because of using more clear and same time more functional codec parser
new driver is able to handle more codecs, use them better then before and
without most of previous quirks. All of tested codecs itself manage playback,
record, input mixing and monitoring quite fine. In all of investigated
trouble cases problem was found or in nonstandard codec usage or incorrect
codec configuration made by BIOS. Most of that cases could be fixed using
device hints, some of which are already included to the driver.
New driver supports multiple codecs per HDA bus, multiple audio function
groups per codec and multiple logical sound devices per audio function group.
So don't worry when you get several PCM devices instead of one, it is normal.
It is usual situation with powerful codecs to provide, for example, 3 PCM
devices: one for 7.1 playback and main recording, one for headset and one
for digital SPDIF I/O.
New driver implements Universal Audio Architecture (UAA) much better then
previous one. Most information about recommended codec usage now taken from
the codec configuration registers initialized by BIOS. User may alter that
configuration using device hints to reconfigure logical audio devices to
his needs in a very broad range up to the limits of the codec functionality.
New driver supports digital PCM playback and AC3 pass-through. I am not sure
about completeness of this implementation, but I have several success stories
including my own. Vchans subsystem does not support AC3 pass-through so it
had to be disabled for that devices at this moment.
New driver is ready for multichannel playback, but until our OSS is unable
to use this it will just duplicate same stereo stream into all channel
pairs.
New driver supports suspend/resume. I am unable to really test this part
myself, but I have got several success stories.
Driver has very informative verbose boot messages. So if you have any
questions or problems - enable and read them first.
Discussed on: freebsd-multimedia@
Tested by: many
2008-09-13 16:56:03 +00:00
|
|
|
DRIVER_MODULE(snd_hda_pcm, hdac, hdac_pcm_driver, pcm_devclass, 0, 0);
|
|
|
|
|