HEADS UP: set_rcvar() removed from rc.subr
Howdy, Per discussion in freebsd-rc@, I have removed set_rcvar() from rc.subr. The concept of set_rcvar() was nice in theory, but the forks it creates are a drag on the startup process, which is especially noticeable on slower systems, such as embedded ones. I have no plans to MFC this change, so it should only affect users who are actually on 10-current. If you have scripts in /usr/local/etc/rc.d (which if you have ports installed you almost certainly do) ... to make the change by hand, change this: name=foo rcvar=`set_rcvar` to: name=foo rcvar=foo_enable I didn't bump PORTREVISIONs because the change only applies to HEAD. But all of the ports are updated, so if you can't figure out how to make the change, just reinstall it. Doug -- You can observe a lot just by watching. -- Yogi Berra Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: HEADS UP: set_rcvar() removed from rc.subr
On Sat, Jan 14, 2012 at 01:05:59AM -0800, Doug Barton wrote: to make the change by hand, change this: name=foo rcvar=`set_rcvar` to: name=foo rcvar=foo_enable The scripts installed by net/avahi-app still use set_rcvar() because they are included in the source. -- Denny Lin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: HEADS UP: set_rcvar() removed from rc.subr
On 14 January 2012 11:11, Denny Lin dennyli...@hs.ntnu.edu.tw wrote: On Sat, Jan 14, 2012 at 01:05:59AM -0800, Doug Barton wrote: to make the change by hand, change this: name=foo rcvar=`set_rcvar` to: name=foo rcvar=foo_enable The scripts installed by net/avahi-app still use set_rcvar() because they are included in the source. I imagine we'll see a few of these, but they'll get fixed quickly enough. Chris ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [RFT] Major snd_hda rewrite
On 14.01.2012 04:10, Michael Schnell wrote:
On Thu, 12 Jan 2012, Yuri Pankov wrote:
On Thu, Jan 12, 2012 at 02:57:52PM +0200, Alexander Motin wrote:
On 01/12/12 14:18, Yuri Pankov wrote:
On Wed, Jan 11, 2012 at 09:33:17PM +0200, Alexander Motin wrote:
I would like request for testing of my work on further HDA sound
driver
improvement.
[...]
Patch can be found here:
http://people.freebsd.org/~mav/hda.rewrite.patch
Patch was generated for 10-CURRENT, but should apply to fresh 9-STABLE
and 8-STABLE branches also.
Patch applied cleanly to r230008 using `svn patch`.
hdacc0:NVidia GT220 HDA CODEC at cad 0 on hdac0
hdaa0:NVidia GT220 HDA CODEC Audio Function Group at nid 1 on hdacc0
pcm0:NVidia GT220 HDA CODEC PCM (DisplayPort 8ch) at nid 5 on hdaa0
hdacc1:NVidia GT220 HDA CODEC at cad 1 on hdac0
hdaa1:NVidia GT220 HDA CODEC Audio Function Group at nid 1 on hdacc1
pcm1:NVidia GT220 HDA CODEC PCM (DisplayPort 8ch) at nid 5 on hdaa1
hdacc2:NVidia GT220 HDA CODEC at cad 2 on hdac0
hdaa2:NVidia GT220 HDA CODEC Audio Function Group at nid 1 on hdacc2
pcm2:NVidia GT220 HDA CODEC PCM (DisplayPort 8ch) at nid 5 on hdaa2
hdacc3:NVidia GT220 HDA CODEC at cad 3 on hdac0
hdaa3:NVidia GT220 HDA CODEC Audio Function Group at nid 1 on hdacc3
pcm3:NVidia GT220 HDA CODEC PCM (DisplayPort 8ch) at nid 5 on hdaa3
hdacc4:IDT 92HD75BX HDA CODEC at cad 0 on hdac1
hdaa4:IDT 92HD75BX HDA CODEC Audio Function Group at nid 1 on hdacc4
pcm4:IDT 92HD75BX HDA CODEC PCM (Analog) at nid 13 and 11 on hdaa4
pcm5:IDT 92HD75BX HDA CODEC PCM (Analog) at nid 15 and 24 on hdaa4
pcm6:IDT 92HD75BX HDA CODEC PCM (Front Digital) at nid 30 on hdaa4
pcm4 (builtin speakers) and pcm5 (headphones) seem to work fine,
however
Thank you.
I'm not getting anything out of pcm0-pcm3 (connected to a TV via HDMI),
mplayer just pauses at the beggining, trying to cat anything to
/dev/dsp{0-3}.0 gives:
pcm0: chn_write(): pcm0:virtual:dsp0.vp0: play interrupt timeout,
channel dead
It was the same with the old driver and I'm not sure if it's (most
likely) my misconfiguration or a driver problem.
It sounds more like a driver problem. HDMI audio is still not very well
discovered area, and, according to ALSA reading, NVidia HDMI is also not
very standard. Probably I'll finally have to buy something to
experiment. What card do you have?
It's a laptop with nVidia Corporation GT216 [GeForce GT 230M] (as
identified by x11/nvidia-driver).
The verbose dmesg is at:
https://www.xvoid.org/stuff/spica.dmesg
I had the same problem for some time and I was going over the code and
honestly I took some inspiration of how the linux kernel handle this and
added some quirks to the code to get it working. However, after some
time I realize that a sysctl
dev.hdac.n.0.polling=1 will do something similar and this also works for
me. I don't think this polling mechanism is a good idea, better would be
some interrupt for state updates but anyway, I was glad that I can here
(digital) music over my receiver with my laptop. I have an NVS 3100M
graphic card and it is connected over a (fragile) Displayport-HDMI adapter.
I would gladly test this with Alexanders patch, but I only have an
9.0-RELEASE and I already tried to port the patch back, but this would
take some effort. In addition this is my production system and I already
messed it up enough. ;)
I also don't like polling, especially in context of new event timers
that are not generating interrupts when not needed. In this patch I
haven't even reimplemented polling support while rewriting that part of
the code, as for several years since implementing it I haven't seen
reports that it was really useful. If it is useful, I'll think of it.
--
Alexander Motin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
netisr ambigios policy
From sys/net/netisr.c
switch (netisr_dispatch_policy) {
case NETISR_DISPATCH_DEFERRED:
netisr_direct_force = 0;
netisr_direct = 0;
break;
case NETISR_DISPATCH_HYBRID:
netisr_direct_force = 0;
netisr_direct = 1;
break;
case NETISR_DISPATCH_DIRECT:
netisr_direct_force = 1;
netisr_direct = 1;
break;
that having direct_force = 0 and direct = 0 it is DISPATCH_DEFFERED
but doing:
# sysctl net.isr
net.isr.numthreads: 4
net.isr.maxprot: 16
net.isr.defaultqlimit: 256
net.isr.maxqlimit: 10240
net.isr.bindthreads: 0
net.isr.maxthreads: 4
net.isr.direct: 0
net.isr.direct_force: 0
net.isr.dispatch: direct
you can see that net.isr.dispatch is 'direct'
I expect 'deffered' as it declared here:
static const struct netisr_dispatch_table_entry netisr_dispatch_table[] = {
{ NETISR_DISPATCH_DEFAULT, default },
{ NETISR_DISPATCH_DEFERRED, deferred },
{ NETISR_DISPATCH_HYBRID, hybrid },
{ NETISR_DISPATCH_DIRECT, direct },
Is this a BUG?
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [RFT] Major snd_hda rewrite
On Thu Jan 12 12, Rainer Hurling wrote: On 12.01.2012 12:18 (UTC+1), Alexander Motin wrote: On 01/12/12 12:52, Gary Jennejohn wrote: On Wed, 11 Jan 2012 21:33:17 +0200 Alexander Motinm...@freebsd.org wrote: I would like request for testing of my work on further HDA sound driver improvement. [big snip] Patch can be found here: http://people.freebsd.org/~mav/hda.rewrite.patch Patch was generated for 10-CURRENT, but should apply to fresh 9-STABLE and 8-STABLE branches also. The patch doesn't apply cleanly to r230008; hdac.c.rej is 15661 bytes in size (mostly the section which deletes all the manufacturer-specific defines at the top of the file). That is probably because of $FreeBSD$ macro resolution. Here is version with present value from 10-CURRENT SVN (sources from CVS or STABLE will need that patch line modified respectively) and some minor additional improvements like CODEC ODs and some more sysctls: http://people.freebsd.org/~mav/hda.rewrite2.patch maybe you could try silencencing these clang warnings? /usr/subversion-src/sys/dev/sound/pci/hda/hdaa.c:5707:25: warning: format string is not a string literal (potentially insecure) [-Wformat-security] snprintf(buf, buflen, chans = 4.0); ^ /usr/subversion-src/sys/dev/sound/pci/hda/hdaa.c:5709:25: warning: format string is not a string literal (potentially insecure) [-Wformat-security] snprintf(buf, buflen, chans = 5.1); ^ /usr/subversion-src/sys/dev/sound/pci/hda/hdaa.c:5711:25: warning: format string is not a string literal (potentially insecure) [-Wformat-security] snprintf(buf, buflen, chans = 7.1); ^~ /usr/subversion-src/sys/dev/sound/pci/hda/hdacc.c:563:52: warning: if statement has empty body [-Wempty-body] if ((child = codec-streams[dir][stream]) != NULL); ^ 4 warning generated. ..i'll report how the changes interact with my system later on. cheers. alex I just patched 10.0-CURRENT (amd64) r230009 against hda.rewrite2.patch. All went fine so far. My box is now running again with following messages: hdacc0: NVidia (Unknown) HDA CODEC at cad 0 on hdac0 hdaa0: NVidia (Unknown) HDA CODEC Audio Function Group at nid 1 on hdacc0 pcm0: NVidia (Unknown) HDA CODEC PCM (DisplayPort 8ch) at nid 5 on hdaa0 hdacc1: NVidia (Unknown) HDA CODEC at cad 1 on hdac0 hdaa1: NVidia (Unknown) HDA CODEC Audio Function Group at nid 1 on hdacc1 pcm1: NVidia (Unknown) HDA CODEC PCM (DisplayPort 8ch) at nid 5 on hdaa1 hdacc2: NVidia (Unknown) HDA CODEC at cad 2 on hdac0 hdaa2: NVidia (Unknown) HDA CODEC Audio Function Group at nid 1 on hdacc2 pcm2: NVidia (Unknown) HDA CODEC PCM (DisplayPort 8ch) at nid 5 on hdaa2 hdacc3: NVidia (Unknown) HDA CODEC at cad 3 on hdac0 hdaa3: NVidia (Unknown) HDA CODEC Audio Function Group at nid 1 on hdacc3 pcm3: NVidia (Unknown) HDA CODEC PCM (DisplayPort 8ch) at nid 5 on hdaa3 hdacc4: Realtek ALC892 HDA CODEC at cad 0 on hdac1 hdaa4: Realtek ALC892 HDA CODEC Audio Function Group at nid 1 on hdacc4 pcm4: Realtek ALC892 HDA CODEC PCM (Rear Analog 7.1/2.0) at nid 20,22,23,21 and 24,26 on hdaa4 pcm5: Realtek ALC892 HDA CODEC PCM (Front Analog) at nid 27 and 25 on hdaa4 pcm6: Realtek ALC892 HDA CODEC PCM (Rear Digital) at nid 30 on hdaa4 pcm7: Realtek ALC892 HDA CODEC PCM (Onboard Digital) at nid 17 on hdaa4 I am using pcm4 with 5.1 surround sound and pulseaudio. All seems to work fine :-) The mainboard is an Asus M4A88TD-V EVO/USB3, the graphics card is a NVidia GeForce GTS 450. The Realtek ALC892 is regocnized by the driver, the NVidia HDMI sound device is not. I am looking forward to the commit of this patch! After fixing that per hand I was able to make a kernel with which sound still works. Here the relevant bits from dmesg: hdac0:NVidia (Unknown) HDA Controller mem 0xfcffc000-0xfcff irq 18 at device 0.1 on pci1 hdac1:ATI SB600 HDA Controller mem 0xfe024000-0xfe027fff irq 16 at device 20.2 on pci0 hdacc0:NVidia GT21x HDA CODEC at cad 0 on hdac0 hdaa0:NVidia GT21x HDA CODEC Audio Function Group at nid 1 on hdacc0 pcm0:NVidia GT21x HDA CODEC PCM (DisplayPort 8ch) at nid 5 on hdaa0 hdacc1:NVidia GT21x HDA CODEC at cad 1 on hdac0 hdaa1:NVidia GT21x HDA CODEC Audio Function Group at nid 1 on hdacc1 pcm1:NVidia GT21x HDA CODEC PCM (DisplayPort 8ch) at nid 5 on hdaa1 hdacc2:NVidia GT21x HDA CODEC at cad 2 on hdac0 hdaa2:NVidia GT21x HDA CODEC Audio Function Group at nid 1 on hdacc2 pcm2:NVidia GT21x HDA CODEC PCM (DisplayPort 8ch) at nid 5 on hdaa2 hdacc3:NVidia GT21x HDA CODEC at cad 3 on hdac0 hdaa3:NVidia GT21x HDA CODEC Audio Function Group at nid 1 on hdacc3 pcm3:NVidia GT21x HDA CODEC PCM (DisplayPort 8ch) at nid 5 on hdaa3 hdacc4:Realtek ALC889A HDA CODEC at cad 0 on hdac1
Re: [RFT] Major snd_hda rewrite
On 01/14/12 15:48, Alexander Best wrote: On Thu Jan 12 12, Rainer Hurling wrote: On 12.01.2012 12:18 (UTC+1), Alexander Motin wrote: On 01/12/12 12:52, Gary Jennejohn wrote: On Wed, 11 Jan 2012 21:33:17 +0200 Alexander Motinm...@freebsd.org wrote: I would like request for testing of my work on further HDA sound driver improvement. [big snip] Patch can be found here: http://people.freebsd.org/~mav/hda.rewrite.patch Patch was generated for 10-CURRENT, but should apply to fresh 9-STABLE and 8-STABLE branches also. The patch doesn't apply cleanly to r230008; hdac.c.rej is 15661 bytes in size (mostly the section which deletes all the manufacturer-specific defines at the top of the file). That is probably because of $FreeBSD$ macro resolution. Here is version with present value from 10-CURRENT SVN (sources from CVS or STABLE will need that patch line modified respectively) and some minor additional improvements like CODEC ODs and some more sysctls: http://people.freebsd.org/~mav/hda.rewrite2.patch maybe you could try silencencing these clang warnings? /usr/subversion-src/sys/dev/sound/pci/hda/hdaa.c:5707:25: warning: format string is not a string literal (potentially insecure) [-Wformat-security] snprintf(buf, buflen, chans = 4.0); ^ /usr/subversion-src/sys/dev/sound/pci/hda/hdaa.c:5709:25: warning: format string is not a string literal (potentially insecure) [-Wformat-security] snprintf(buf, buflen, chans = 5.1); ^ /usr/subversion-src/sys/dev/sound/pci/hda/hdaa.c:5711:25: warning: format string is not a string literal (potentially insecure) [-Wformat-security] snprintf(buf, buflen, chans = 7.1); ^~ /usr/subversion-src/sys/dev/sound/pci/hda/hdacc.c:563:52: warning: if statement has empty body [-Wempty-body] if ((child = codec-streams[dir][stream]) != NULL); ^ 4 warning generated. ..i'll report how the changes interact with my system later on. Thank you! That variable is not even used now, so I'll just remove that assignment. I've passed the code through the clang static analyzer at some point, but probably I've introduced that later. -- Alexander Motin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: HEADS UP: set_rcvar() removed from rc.subr
On Sat, Jan 14, 2012 at 01:05:59AM -0800, Doug Barton wrote: Per discussion in freebsd-rc@, I have removed set_rcvar() from rc.subr. The concept of set_rcvar() was nice in theory, but the forks it creates are a drag on the startup process, which is especially noticeable on slower systems, such as embedded ones. I have no plans to MFC this change, so it should only affect users who are actually on 10-current. If you have scripts in /usr/local/etc/rc.d (which if you have ports installed you almost certainly do) ... to make the change by hand, change this: name=foo rcvar=`set_rcvar` to: name=foo rcvar=foo_enable I didn't bump PORTREVISIONs because the change only applies to HEAD. But all of the ports are updated, so if you can't figure out how to make the change, just reinstall it. Why must the 2-argument form of set_rcvar die at the same time? It is used very differently and does not cause unnecessary forks. Instead, it is called in the same shell environment to define additional rc.conf variables that have defaults and are shown in 'script rcvar'. -- Jilles Tjoelker ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: netisr ambigios policy
Здравствуйте, Коньков.
Вы писали 14 января 2012 г., 15:31:04:
КЕ From sys/net/netisr.c
КЕ switch (netisr_dispatch_policy) {
КЕ case NETISR_DISPATCH_DEFERRED:
КЕ netisr_direct_force = 0;
КЕ netisr_direct = 0;
КЕ break;
КЕ case NETISR_DISPATCH_HYBRID:
КЕ netisr_direct_force = 0;
КЕ netisr_direct = 1;
КЕ break;
КЕ case NETISR_DISPATCH_DIRECT:
КЕ netisr_direct_force = 1;
КЕ netisr_direct = 1;
КЕ break;
КЕ that having direct_force = 0 and direct = 0 it is DISPATCH_DEFFERED
КЕ but doing:
КЕ # sysctl net.isr
КЕ net.isr.numthreads: 4
КЕ net.isr.maxprot: 16
КЕ net.isr.defaultqlimit: 256
КЕ net.isr.maxqlimit: 10240
КЕ net.isr.bindthreads: 0
КЕ net.isr.maxthreads: 4
КЕ net.isr.direct: 0
КЕ net.isr.direct_force: 0
КЕ net.isr.dispatch: direct
КЕ you can see that net.isr.dispatch is 'direct'
КЕ I expect 'deffered' as it declared here:
КЕ static const struct netisr_dispatch_table_entry netisr_dispatch_table[] = {
КЕ { NETISR_DISPATCH_DEFAULT, default },
КЕ { NETISR_DISPATCH_DEFERRED, deferred },
КЕ { NETISR_DISPATCH_HYBRID, hybrid },
КЕ { NETISR_DISPATCH_DIRECT, direct },
КЕ Is this a BUG?
setting this to
net.isr.direct=1
net.isr.direct_force=1
in /boot/loader.conf
has no effect
# sysctl net.isr
net.isr.numthreads: 4
net.isr.maxprot: 16
net.isr.defaultqlimit: 256
net.isr.maxqlimit: 10240
net.isr.bindthreads: 0
net.isr.maxthreads: 4
net.isr.direct: 0
net.isr.direct_force: 0
net.isr.dispatch: direct
It seems has been broken in r49
--
С уважением,
Коньков mailto:kes-...@yandex.ru
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: HEADS UP: set_rcvar() removed from rc.subr
On 14.01.2012 10:05 (UTC+1), Doug Barton wrote:
Howdy,
Per discussion in freebsd-rc@, I have removed set_rcvar() from rc.subr.
The concept of set_rcvar() was nice in theory, but the forks it creates
are a drag on the startup process, which is especially noticeable on
slower systems, such as embedded ones.
I have no plans to MFC this change, so it should only affect users who
are actually on 10-current. If you have scripts in /usr/local/etc/rc.d
(which if you have ports installed you almost certainly do) ...
to make the change by hand, change this:
name=foo
rcvar=`set_rcvar`
to:
name=foo
rcvar=foo_enable
I didn't bump PORTREVISIONs because the change only applies to HEAD. But
all of the ports are updated, so if you can't figure out how to make the
change, just reinstall it.
Doug
Seems that ports-mgmt/tinderbox needs an update like this:
files/patch-etc__rc.d__tinderd
--- etc/rc.d/tinderd.orig 2011-11-20 07:01:09.0 +0100
+++ etc/rc.d/tinderd2012-01-14 16:07:38.0 +0100
@@ -16,7 +16,7 @@
. /etc/rc.subr
name=tinderd
-rcvar=`set_rcvar`
+rcvar=tinderd_enable
# read settings, set default values
load_rc_config ${name}
Have not checked tinderbox-devel.
BTW, is there any reason not to set 'rcvar=${name}_enable' in all that
cases?
Rainer Hurling
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [RFT] Major snd_hda rewrite
On Sat Jan 14 12, Alexander Motin wrote:
On 01/14/12 15:48, Alexander Best wrote:
On Thu Jan 12 12, Rainer Hurling wrote:
On 12.01.2012 12:18 (UTC+1), Alexander Motin wrote:
On 01/12/12 12:52, Gary Jennejohn wrote:
On Wed, 11 Jan 2012 21:33:17 +0200
Alexander Motinm...@freebsd.org wrote:
I would like request for testing of my work on further HDA sound driver
improvement.
[big snip]
Patch can be found here:
http://people.freebsd.org/~mav/hda.rewrite.patch
Patch was generated for 10-CURRENT, but should apply to fresh 9-STABLE
and 8-STABLE branches also.
The patch doesn't apply cleanly to r230008; hdac.c.rej is 15661 bytes
in size (mostly the section which deletes all the manufacturer-specific
defines at the top of the file).
That is probably because of $FreeBSD$ macro resolution. Here is version
with present value from 10-CURRENT SVN (sources from CVS or STABLE will
need that patch line modified respectively) and some minor additional
improvements like CODEC ODs and some more sysctls:
http://people.freebsd.org/~mav/hda.rewrite2.patch
maybe you could try silencencing these clang warnings?
/usr/subversion-src/sys/dev/sound/pci/hda/hdaa.c:5707:25: warning: format
string is not a string literal (potentially insecure) [-Wformat-security]
snprintf(buf, buflen, chans = 4.0);
^
/usr/subversion-src/sys/dev/sound/pci/hda/hdaa.c:5709:25: warning: format
string is not a string literal (potentially insecure) [-Wformat-security]
snprintf(buf, buflen, chans = 5.1);
^
/usr/subversion-src/sys/dev/sound/pci/hda/hdaa.c:5711:25: warning: format
string is not a string literal (potentially insecure) [-Wformat-security]
snprintf(buf, buflen, chans = 7.1);
^~
/usr/subversion-src/sys/dev/sound/pci/hda/hdacc.c:563:52: warning: if
statement has empty body [-Wempty-body]
if ((child = codec-streams[dir][stream]) != NULL);
^
4 warning generated.
..i'll report how the changes interact with my system later on.
Thank you! That variable is not even used now, so I'll just remove that
assignment. I've passed the code through the clang static analyzer at
some point, but probably I've introduced that later.
thanks. :)
the patch works great for me, too.
dmesg -a:
hdacc0: Realtek ALC889A HDA CODEC at cad 2 on hdac0
hdaa0: Realtek ALC889A HDA CODEC Audio Function Group at nid 1 on hdacc0
pcm0: Realtek ALC889A HDA CODEC PCM (Rear Analog 7.1/2.0) at nid 20,22,21,23
and 24,26 on hdaa0
pcm1: Realtek ALC889A HDA CODEC PCM (Front Analog) at nid 27 and 25 on hdaa0
pcm2: Realtek ALC889A HDA CODEC PCM (Rear Digital) at nid 30 and 31 on hdaa0
cat /dev/sndstat:
FreeBSD Audio Driver (newpcm: 64bit 2009061500/amd64)
Installed devices:
pcm0: Realtek ALC889A HDA CODEC PCM (Rear Analog 7.1/2.0) on hdaa0
(1p:1v/2r:1v) default
snddev flags=0x2e6AUTOVCHAN,SOFTPCMVOL,BUSY,MPSAFE,REGISTERED,VPC
[pcm0:play:dsp0.p0]: spd 48000, fmt 0x00200010, flags 0x2108,
0x0004
interrupts 1274, underruns 0, feed 1274, ready 0
[b:16384/8192/2|bs:16384/8192/2]
channel flags=0x2108TRIGGERED,BUSY,HAS_VCHAN
{userland} - feeder_mixer(0x00200010) - {hardware}
pcm0:play:dsp0.p0[pcm0:virtual:dsp0.vp0]: spd 44100/48000, fmt
0x00200010, flags 0x112c, 0x0029, pid 927 (musicpd)
interrupts 0, underruns 0, feed 1859, ready 65536
[b:0/0/0|bs:65536/8192/8]
channel flags=0x112cRUNNING,TRIGGERED,SLEEPING,BUSY,VIRTUAL
{userland} - feeder_root(0x00200010) - feeder_volume(0x00200010) -
feeder_rate(0x00200010 q:1 44100 - 48000) - {hardware}
[pcm0:record:dsp0.r0]: spd 48000, fmt 0x00200010, flags 0x2100,
0x0005
interrupts 0, overruns 0, feed 0, hfree 16384, sfree 16384
[b:16384/8192/2|bs:16384/8192/2]
channel flags=0x2100BUSY,HAS_VCHAN
{hardware} - feeder_root(0x00200010) - feeder_mixer(0x00200010) -
{userland}
[pcm0:record:dsp0.r1]: spd 8000, fmt 0x0018, flags 0x,
0x
interrupts 0, overruns 0, feed 0, hfree 65536, sfree 0
[b:65536/32768/2|bs:0/0/0]
channel flags=0x0
{hardware} - feeder_root(0x) - {userland}
pcm0:record:dsp0.r0[pcm0:virtual:dsp0.vr0]: spd 8000, fmt 0x0018,
flags 0x1000, 0x
interrupts 0, overruns 0, feed 0, hfree 0, sfree 0 [b:0/0/0|bs:0/0/0]
channel flags=0x1000VIRTUAL
{hardware} - feeder_root(0x) - {userland}
pcm1: Realtek ALC889A HDA CODEC PCM (Front Analog) on hdaa0 (1p:1v/1r:1v)
snddev flags=0x2e6AUTOVCHAN,SOFTPCMVOL,BUSY,MPSAFE,REGISTERED,VPC
[pcm1:play:dsp1.p0]: spd 48000, fmt 0x00200010, flags 0x2100,
0x0004
interrupts 0, underruns 0, feed 0, ready 0
Re: HEADS UP: set_rcvar() removed from rc.subr
On 14 January 2012 15:16, Rainer Hurling rhur...@gwdg.de wrote:
On 14.01.2012 10:05 (UTC+1), Doug Barton wrote:
Howdy,
Per discussion in freebsd-rc@, I have removed set_rcvar() from rc.subr.
The concept of set_rcvar() was nice in theory, but the forks it creates
are a drag on the startup process, which is especially noticeable on
slower systems, such as embedded ones.
I have no plans to MFC this change, so it should only affect users who
are actually on 10-current. If you have scripts in /usr/local/etc/rc.d
(which if you have ports installed you almost certainly do) ...
to make the change by hand, change this:
name=foo
rcvar=`set_rcvar`
to:
name=foo
rcvar=foo_enable
I didn't bump PORTREVISIONs because the change only applies to HEAD. But
all of the ports are updated, so if you can't figure out how to make the
change, just reinstall it.
Doug
Seems that ports-mgmt/tinderbox needs an update like this:
files/patch-etc__rc.d__tinderd
--- etc/rc.d/tinderd.orig 2011-11-20 07:01:09.0 +0100
+++ etc/rc.d/tinderd 2012-01-14 16:07:38.0 +0100
@@ -16,7 +16,7 @@
. /etc/rc.subr
name=tinderd
-rcvar=`set_rcvar`
+rcvar=tinderd_enable
# read settings, set default values
load_rc_config ${name}
I'm in the process of fixing this upstream.
Chris
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [RFT] Major snd_hda rewrite
2012/1/11 Alexander Motin m...@freebsd.org Hi. I would like request for testing of my work on further HDA sound driver improvement. List of changes done this time: - Huge old hdac driver was split into three independent pieces: HDA controller driver (hdac), HDA CODEC driver (hdacc) and HDA sudio function driver (hdaa). All drivers are completely independent and talk to each other only via NewBus interfaces. Using more NewBus bells and whistles allows to properly see HDA structure with standard system instruments, such as `devinfo -v`. Biggest driver file size now is 150K, instead of 240K before, and the code is much more clean. - Support for multichannel recording was added. While I've never seen it configured by default, UAA specification tells that it is possible. Now, as specification defines, driver checks input associations for pins with sequence numbers 14 and 15, and if found (usually) -- works as before, mixing signals together. If it doesn't, it configures input association as multichannel. I've found some CODECs doing strange things when configured for multichannel recording, but I've also found successfully working examples. - Signal tracer was improved to look for cases where several DACs/ADCs in CODEC can work with the same audio signal. If such case found, driver registers additional playback/record stream (channel) for the pcm device. Having more then one stream allows to avoid vchans use and so avoid extra conversion to pre-configured vchan rate and sample format. Not many CODECs allow this, especially on playback, but some do. - New controller streams reservation mechanism was implemented. That allows to have more pcm devices then streams supported by the controller (usually 4 in each direction). Now it limits only number of _simultaneously_ transferred audio streams, that is rarely reachable and properly reported if happens. - Codec pins and GPIO signals configuration was exported via set of writable sysctls. Another sysctl dev.hdaa.X.reconfig allows to trigger driver reconfiguration in run-time. The only requirement is that all pcm devices should be closed at the moment, as they will be destroyed and recreated. This should significantly simplify process of fixing CODEC configuration. It should be possible now even to write GUI to do it with few mouse clicks. - Driver now decodes pins location and connector type names. In some cases it allows to hint user where on the system case connectors, related to the pcm device, are located. Number of channels supported by pcm device, reported now (if it is not 2), should also make search easier. - Added fix for digital mic recording on some Asus laptops/netbooks. That is how it may look now in dmesg: hdac0: Intel 5 Series/3400 Series HDA Controller mem 0xf7ef4000-0xf7ef7fff irq 22 at device 27.0 on pci0 hdacc0: VIA VT1708S_0 HDA CODEC at cad 0 on hdac0 hdaa0: VIA VT1708S_0 HDA CODEC Audio Function Group at nid 1 on hdacc0 hdacc1: Intel Ibex Peak HDA CODEC at cad 3 on hdac0 hdaa1: Intel Ibex Peak HDA CODEC Audio Function Group at nid 1 on hdacc1 pcm0: VIA VT1708S_0 HDA CODEC PCM (Analog) at nid 28,29 and 26,30,27 on hdaa0 pcm1: VIA VT1708S_0 HDA CODEC PCM (Digital) at nid 32 on hdaa0 pcm2: Intel Ibex Peak HDA CODEC PCM (DisplayPort 8ch) at nid 6 on hdaa1 Patch can be found here: http://people.freebsd.org/~**mav/hda.rewrite.patchhttp://people.freebsd.org/~mav/hda.rewrite.patch Patch was generated for 10-CURRENT, but should apply to fresh 9-STABLE and 8-STABLE branches also. Special thanks to iXsystems, Inc. for supporting this work. Comments and tests results are welcome! to much work for me to get it work on 8-STABLE (missing MFC of r227701, r227849 and other things) so i'll update my htpc to 9-STABLE. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: HEADS UP: set_rcvar() removed from rc.subr
On 01/14/2012 06:44, Jilles Tjoelker wrote:
Why must the 2-argument form of set_rcvar die at the same time? It is
used very differently and does not cause unnecessary forks. Instead, it
is called in the same shell environment to define additional rc.conf
variables that have defaults and are shown in 'script rcvar'.
Because it can just as easily be accomplished the same way that all the
other rcvar-related things are:
rcvar=foo_enable
: ${foo_enable:=NO}
And before you spend too much time bemoaning its demise, quick question
... how many places was it used?
Doug
--
You can observe a lot just by watching. -- Yogi Berra
Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price. :) http://SupersetSolutions.com/
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
[RESOLVED]: upgrading to r230059 cause slow network throughput
Здравствуйте, Коньков.
Вы писали 13 января 2012 г., 21:32:14:
КЕ I have tryed as ULE as SCHED_4BSD, no changes
КЕ in both cases low throughput
КЕ CPUload
КЕ http://piccy.info/view3/2478224/e5d7f208538d05d813411c34eb493a8f/orig/
КЕ if load
КЕ http://piccy.info/view3/2478228/bf8dca5fad12c1436092f4d6aaf2356f/orig/
КЕ looking on graphs CPU load it seems strange distribution...
КЕ it seems almost not scheduling ng_queue and netisr
КЕ last pid: 54347; load averages: 0.30, 0.28, 0.22 up
0+06:24:06 21:25:11
КЕ 273 processes: 5 running, 237 sleeping, 31 waiting
КЕ CPU 0: 0.0% user, 0.0% nice, 3.1% system, 0.4% interrupt, 96.5% idle
КЕ CPU 1: 3.5% user, 0.0% nice, 1.2% system, 0.4% interrupt, 94.9% idle
КЕ CPU 2: 2.0% user, 0.0% nice, 1.6% system, 0.4% interrupt, 96.1% idle
КЕ CPU 3: 0.0% user, 0.0% nice, 0.8% system, 3.1% interrupt, 96.1% idle
КЕ Mem: 310M Active, 1080M Inact, 179M Wired, 112M Buf, 354M Free
КЕ Swap: 3926M Total, 3926M Free
КЕ PID USERNAME PRI NICE SIZERES STATE C TIME WCPU COMMAND
КЕ11 root 155 ki31 0K32K CPU33 359:26 94.38% idle{idle:
cpu3}
КЕ11 root 155 ki31 0K32K CPU00 356:33 92.77% idle{idle:
cpu0}
КЕ11 root 155 ki31 0K32K RUN 1 345:23 89.60% idle{idle:
cpu1}
КЕ11 root 155 ki31 0K32K CPU22 340:20 85.35% idle{idle:
cpu2}
КЕ 3312 root400 15468K 6488K select 2 15:00 4.25% snmpd
КЕ12 root -60- 0K 248K WAIT0 7:20 1.07% intr{swi4:
clock}
КЕ12 root -92- 0K 248K WAIT3 12:06 0.29%
intr{irq266: re0}
КЕ 0 root -920 0K 152K - 3 6:45 0.05%
kernel{dummynet}
КЕ13 root -92- 0K32K sleep 1 1:39 0.00%
ng_queue{ng_queue1}
КЕ13 root -92- 0K32K sleep 1 1:39 0.00%
ng_queue{ng_queue3}
КЕ13 root -92- 0K32K sleep 3 1:39 0.00%
ng_queue{ng_queue0}
КЕ13 root -92- 0K32K sleep 0 1:39 0.00%
ng_queue{ng_queue2}
КЕ 6880 root 80 9592K 1300K nanslp 1 0:46 0.00% monitord
КЕ 0 root -160 0K 152K sched 1 0:43 0.00%
kernel{swapper}
КЕ 95148 root160 9756K 1452K pause 1 0:37 0.00% netstat
КЕ12 root -72- 0K 248K WAIT3 0:34 0.00% intr{swi1:
netisr 3}
КЕ15 root -16- 0K 8K - 3 0:28 0.00% yarrow
КЕ 1070 root400 10524K 4224K select 1 0:21 0.00% zebra
КЕ 2020 root30 -10 50664K 22824K select 3 0:20 0.00% mpd5{mpd5}
КЕ 7611 firebird30 -10 106M 65780K usem2 0:14 0.00%
fb_smp_server{fb_smp_server}
КЕ 1766 root400 9680K 1480K select 2 0:11 0.00% syslogd
КЕ 1909 bind400 69244K 55360K uwait 1 0:06 0.00% named{named}
КЕ 1909 bind400 69244K 55360K uwait 1 0:06 0.00% named{named}
КЕ 1909 bind400 69244K 55360K uwait 1 0:06 0.00% named{named}
КЕ 1909 bind400 69244K 55360K uwait 3 0:06 0.00% named{named}
КЕ 8 root16- 0K 8K syncer 0 0:06 0.00% syncer
КЕ 1909 bind 40 69244K 55360K kqread 2 0:06 0.00% named{named}
КЕ in compare to FreeBSD-9,
КЕ 10-CURRENT has only one {swi1: netisr 3}
КЕ 9- has four process: {swi1: netisr 0} {swi1: netisr 1}
КЕ {swi1: netisr 2} {swi1: netisr 3}
КЕ last pid: 40679; load averages: 2.38, 2.39, 2.28 up
2+05:31:50 21:23:43
КЕ 294 processes: 7 running, 269 sleeping, 18 waiting
КЕ CPU 0: 1.2% user, 0.0% nice, 20.4% system, 23.9% interrupt, 54.5% idle
КЕ CPU 1: 1.2% user, 0.0% nice, 10.6% system, 29.8% interrupt, 58.4% idle
КЕ CPU 2: 0.4% user, 0.0% nice, 10.2% system, 26.7% interrupt, 62.7% idle
КЕ CPU 3: 1.2% user, 0.0% nice, 16.1% system, 22.4% interrupt, 60.4% idle
КЕ Mem: 750M Active, 2700M Inact, 307M Wired, 83M Cache, 112M Buf, 58M Free
КЕ Swap: 4096M Total, 49M Used, 4047M Free, 1% Inuse
КЕ PID USERNAME PRI NICE SIZERES STATE C TIME WCPU COMMAND
КЕ11 root 155 ki31 0K32K RUN 1 37.1H 59.23% {idle: cpu1}
КЕ11 root 155 ki31 0K32K RUN 3 37.3H 58.79% {idle: cpu3}
КЕ11 root 155 ki31 0K32K RUN 2 36.8H 57.62% {idle: cpu2}
КЕ11 root 155 ki31 0K32K CPU00 34.9H 51.46% {idle: cpu0}
КЕ12 root -72- 0K 160K CPU22 778:00 39.99% {swi1:
netisr 3}
КЕ12 root -72- 0K 160K CPU11 558:58 22.56% {swi1:
netisr 1}
КЕ12 root -92- 0K 160K WAIT0 424:04 16.60% {irq256:
re0}
КЕ12 root -72- 0K 160K WAIT3 204:04 14.36% {swi1:
netisr 0}
КЕ12 root -72- 0K 160K WAIT1 224:14 7.62% {swi1:
netisr 2}
КЕ13 root -16- 0K32K sleep 0 123:28 5.37% {ng_queue0}
КЕ 6907 root230 15392K 5348K select 2 123:59
Re: [RFT] Major snd_hda rewrite
On Thu, Jan 12, 2012 at 01:18:19PM +0200, Alexander Motin wrote:
That is probably because of $FreeBSD$ macro resolution. Here is version
with present value from 10-CURRENT SVN (sources from CVS or STABLE will
need that patch line modified respectively) and some minor additional
improvements like CODEC ODs and some more sysctls:
http://people.freebsd.org/~mav/hda.rewrite2.patch
Patch applied cleanly.
Patch does not fix http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/120780
Putting a dvd into the dvd drive. Executing 'mplayer dvd://', the
movie starts and sound comes from both the speakers and headphones.
Remove dvd insert music cd in drive, 'cdcontrol play'. The
drive is reading the cd and 'cdcontrol status' indicates
that it is playing. No sound.
Verbose dmesg.txt and 'sysctl -a | grep {hda,snd,pcm} {hda,snd,pcm.txt}'
available at http://troutmask.apl.washington.edu/~kargl/hda/
--
Steve
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: HEADS UP: set_rcvar() removed from rc.subr
On 01/14/2012 07:16, Rainer Hurling wrote:
BTW, is there any reason not to set 'rcvar=${name}_enable' in all that
cases?
http://lists.freebsd.org/pipermail/freebsd-rc/2012-January/002660.html
Also, as I pointed out in my commit message, using the literal value is
a tiny bit faster, and every little bit helps. :)
--
You can observe a lot just by watching. -- Yogi Berra
Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price. :) http://SupersetSolutions.com/
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [RFT] Major snd_hda rewrite
On 14.01.2012 23:25, Steve Kargl wrote:
On Thu, Jan 12, 2012 at 01:18:19PM +0200, Alexander Motin wrote:
That is probably because of $FreeBSD$ macro resolution. Here is version
with present value from 10-CURRENT SVN (sources from CVS or STABLE will
need that patch line modified respectively) and some minor additional
improvements like CODEC ODs and some more sysctls:
http://people.freebsd.org/~mav/hda.rewrite2.patch
Patch applied cleanly.
Patch does not fix http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/120780
Putting a dvd into the dvd drive. Executing 'mplayer dvd://', the
movie starts and sound comes from both the speakers and headphones.
You mean that speakers are not disabled when headphones are plugged in?
In PR you've written that no sound goes from speakers, but here tell
opposite. What is right?
Remove dvd insert music cd in drive, 'cdcontrol play'. The
drive is reading the cd and 'cdcontrol status' indicates
that it is playing. No sound.
Most likely analog audio output of your CD is not connected to the
CODEC. At least there are no CODEC pin configured for it. You may try to
configure different pins manually, but if there is no electrical
connection...
Verbose dmesg.txt and 'sysctl -a | grep {hda,snd,pcm} {hda,snd,pcm.txt}'
available at http://troutmask.apl.washington.edu/~kargl/hda/
--
Alexander Motin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: HEADS UP: set_rcvar() removed from rc.subr
On 14.01.2012 22:29 (UTC+1), Doug Barton wrote:
On 01/14/2012 07:16, Rainer Hurling wrote:
BTW, is there any reason not to set 'rcvar=${name}_enable' in all that
cases?
http://lists.freebsd.org/pipermail/freebsd-rc/2012-January/002660.html
Also, as I pointed out in my commit message, using the literal value is
a tiny bit faster, and every little bit helps. :)
OK, I understand. Thanks for answering.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [RFT] Major snd_hda rewrite
On Sat, Jan 14, 2012 at 11:39:43PM +0200, Alexander Motin wrote:
On 14.01.2012 23:25, Steve Kargl wrote:
On Thu, Jan 12, 2012 at 01:18:19PM +0200, Alexander Motin wrote:
That is probably because of $FreeBSD$ macro resolution. Here is version
with present value from 10-CURRENT SVN (sources from CVS or STABLE will
need that patch line modified respectively) and some minor additional
improvements like CODEC ODs and some more sysctls:
http://people.freebsd.org/~mav/hda.rewrite2.patch
Patch applied cleanly.
Patch does not fix http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/120780
Putting a dvd into the dvd drive. Executing 'mplayer dvd://', the
movie starts and sound comes from both the speakers and headphones.
You mean that speakers are not disabled when headphones are plugged in?
No. I mean that sound is available from either the speakers
(ie, no headphones) or from the headphones (ie no sound
from speakers). That is, this is working as expected.
In PR you've written that no sound goes from speakers, but here tell
opposite. What is right?
If the medium is a DVD, sound works. If the medium is a music CD,
then sound does not work.
Remove dvd insert music cd in drive, 'cdcontrol play'. The
drive is reading the cd and 'cdcontrol status' indicates
that it is playing. No sound.
Most likely analog audio output of your CD is not connected to the
CODEC. At least there are no CODEC pin configured for it. You may try to
configure different pins manually, but if there is no electrical
connection...
Works with MS Windows XP. Put music CD into drive. Fire up
MediaPlayer and sound works. So, I would assume that there
is an electrical connection. So, how does one manually
configure the pins?
Verbose dmesg.txt and 'sysctl -a | grep {hda,snd,pcm} {hda,snd,pcm.txt}'
available at http://troutmask.apl.washington.edu/~kargl/hda/
--
Steve
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [RFT] Major snd_hda rewrite
On 01/14/2012 13:25, Steve Kargl wrote: Remove dvd insert music cd in drive, 'cdcontrol play'. The drive is reading the cd and 'cdcontrol status' indicates that it is playing. No sound. The way that this was explained to me (and I'm certainly no expert) is that in the ATA-CAM world the only way the access method used by cdcontrol will be able to play the music is if there is a direct (wired) connection from the cd player to the sound card, like we had back in the 80's. :) Other tools (such as vlc, mplayer, etc.) use the cdda:// method of access, which does not rely on the wire. (As I understand it) this also explains why dvds work, but cds don't. hth, Doug -- You can observe a lot just by watching. -- Yogi Berra Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [RFT] Major snd_hda rewrite
On 15.01.2012 00:10, Steve Kargl wrote:
On Sat, Jan 14, 2012 at 11:39:43PM +0200, Alexander Motin wrote:
On 14.01.2012 23:25, Steve Kargl wrote:
On Thu, Jan 12, 2012 at 01:18:19PM +0200, Alexander Motin wrote:
That is probably because of $FreeBSD$ macro resolution. Here is version
with present value from 10-CURRENT SVN (sources from CVS or STABLE will
need that patch line modified respectively) and some minor additional
improvements like CODEC ODs and some more sysctls:
http://people.freebsd.org/~mav/hda.rewrite2.patch
Patch applied cleanly.
Patch does not fix http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/120780
Putting a dvd into the dvd drive. Executing 'mplayer dvd://', the
movie starts and sound comes from both the speakers and headphones.
You mean that speakers are not disabled when headphones are plugged in?
No. I mean that sound is available from either the speakers
(ie, no headphones) or from the headphones (ie no sound
from speakers). That is, this is working as expected.
In PR you've written that no sound goes from speakers, but here tell
opposite. What is right?
If the medium is a DVD, sound works. If the medium is a music CD,
then sound does not work.
Audio from DVDs always played by software after reading if from the disk
as usual data. Audio CDs instead could be played either by the CD drive
itself via analog audio connection or by software using digital audio
extraction (reading from the disk).
Remove dvd insert music cd in drive, 'cdcontrol play'. The
drive is reading the cd and 'cdcontrol status' indicates
that it is playing. No sound.
Most likely analog audio output of your CD is not connected to the
CODEC. At least there are no CODEC pin configured for it. You may try to
configure different pins manually, but if there is no electrical
connection...
Works with MS Windows XP. Put music CD into drive. Fire up
MediaPlayer and sound works. So, I would assume that there
is an electrical connection.
I think no. Windows Media Player is able to play Audio CDs via digital
audio extraction. 'cdcontrol play' just commands drive to play Audio CD.
To play Audio CD via digital audio extraction use 'mplayer cdda://'.
So, how does one manually configure the pins?
Read man snd_hda, try, try, try, ... But most likely it is just not
implemented in hardware.
Verbose dmesg.txt and 'sysctl -a | grep {hda,snd,pcm} {hda,snd,pcm.txt}'
available at http://troutmask.apl.washington.edu/~kargl/hda/
--
Alexander Motin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [RFT] Major snd_hda rewrite
On Sun, Jan 15, 2012 at 12:31:51AM +0200, Alexander Motin wrote: Audio from DVDs always played by software after reading if from the disk as usual data. Audio CDs instead could be played either by the CD drive itself via analog audio connection or by software using digital audio extraction (reading from the disk). Thanks for the explanation. -- Steve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [RFT] Major snd_hda rewrite
Alexander Motin m...@freebsd.org writes: I would like request for testing of my work on further HDA sound driver improvement. [...] - Codec pins and GPIO signals configuration was exported via set of writable sysctls. Another sysctl dev.hdaa.X.reconfig allows to trigger driver reconfiguration in run-time. The only requirement is that all pcm devices should be closed at the moment, as they will be destroyed and recreated. This should significantly simplify process of fixing CODEC configuration. It should be possible now even to write GUI to do it with few mouse clicks. reconfig seems to not honor hw.snd.default_unit sysctl. After reconfiguration the sysctl was reset to `0' (default). Is this expected? Even if it is specified as a tunable in loader.conf? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [RFT] Major snd_hda rewrite
On 01/15/12 03:06, Jan Beich wrote: Alexander Motinm...@freebsd.org writes: I would like request for testing of my work on further HDA sound driver improvement. [...] - Codec pins and GPIO signals configuration was exported via set of writable sysctls. Another sysctl dev.hdaa.X.reconfig allows to trigger driver reconfiguration in run-time. The only requirement is that all pcm devices should be closed at the moment, as they will be destroyed and recreated. This should significantly simplify process of fixing CODEC configuration. It should be possible now even to write GUI to do it with few mouse clicks. reconfig seems to not honor hw.snd.default_unit sysctl. After reconfiguration the sysctl was reset to `0' (default). Is this expected? Even if it is specified as a tunable in loader.conf? Audio drivers know nothing about default_unit. reconfig destroys pcm devices and that probably changes default_unit. -- Alexander Motin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
