Massive sound changes in 8-CURRENT, testers wanted

[joel@]

Ariff Abdullah (ariff@) has committed some major work to the FreeBSD sound system. All of this will be available in the upcoming 8-RELEASE.

More testers are needed and we would especially like to hear about any regressions. To test this, just upgrade to the latest 8-CURRENT and make sure sound still works. Please report any issues to ariff@ or to the multimedia@freebsd.org mailing list.

Success reports can be made in this thread.

I'm not going to go through all the new stuff, but you can read more about it here: http://people.freebsd.org/~ariff/SOUND_4.TXT.html

[fronclynne]

So far, fine here:
FreeBSD 8.0-CURRENT #0: Sun Jun 14 23:12:33 EDT 2009
excerpted from dmesg -a pcm0: <HDA Realtek ALC268 PCM #0 Analog> at cad 3 nid 1 on hdac0
pcm1: <HDA Realtek ALC268 PCM #1 Analog> at cad 3 nid 1 on hdac0
tail /dev/sndstatFreeBSD Audio Driver (newpcm: 64bit 2009060800/amd64)
Installed devices:
pcm0: <HDA Realtek ALC268 PCM #0 Analog> at cad 3 nid 1 on hdac0 kld snd_hda [MPSAFE] (1p:3v/1r:1v channels duplex default)
pcm1: <HDA Realtek ALC268 PCM #1 Analog> at cad 3 nid 1 on hdac0 kld snd_hda [MPSAFE] (1p:1v/1r:1v channels duplex)

[richardpl]

Everything is excelent here.
I enabled equalizer and set feeder rate quality to 4.

Now I only wait for multichannel support in snd_hda(4)

[roddierod]

How is the parametric equalizer? I'm not running 8 anywhere but I may clear off a disk to test it out for this.

[DrJ]

I was going to let you know about that, Rod. The linked document is all that I've seen, but it includes both a shelving and peak equalizer. You have to select one or the other, of course. I don't know how many frequencies yet (2?).

[roddierod]

Please do! I could never get the one I was working on to stop locking the sound system.

[DrJ]

Please do!
Well, you do seem to know about it already. :)

I don't have -CURRENT installed yet, but it is looking like it will be a very good release. Reworked sound, USB, linux emulation, Baldwin's patches to facilitate a 64-bit nVidia driver, VirtualBox (not part of the OS, I know, I know) and proably lots of stuff I don't know about.

I usually don't install x.0 releases, but this one I probably will.

[roddierod]

OK..I missed the 64 bit nvidia driver info. I've seen your emails on the list for VirtualBox testing.

You convinced me...I'm download a snapshot now and installing it tonight.

I'll let you know about the EQ and sound.

[DrJ]

The nVidia patches are not in quite yet, but they should be in the next few weeks. Then nVidia has to write the driver, but their issue has always been the lack of certain FreeBSD kernel functionality. So writing the actual driver should go pretty quickly.

[gnemmi]

Are the sound system changes present on 8.0-CURRENT-200906-i386-dvd1.iso?
Im downloading it right now and will install it on my Dell 1318 to see how ACPI is doing but I could also take a shot a the sound system as well.
Would you like me running some test in particular?

Regards

[joel@]

Are the sound system changes present on 8.0-CURRENT-200906-i386-dvd1.iso?
No, I don't think so. You have to csup to the latest 8-CURRENT anyway to get a bunch of fixes to sound/ that were committed after the mega-commit by ariff@.

[blah]

You don't have to. There are daily snapshots of 8-CURRENT built for i386 together with BSDInstaller:
http://snapshots.pfsense.org/FreeBSD_8_0/?C=M;O=D

[gnemmi]

Thanks to both of you.
Will install and report back ASAP.

Regards
Gonzalo

[DutchDaemon]

All working well on laptop with 8.0-CURRENT of yesterday (using snd_hda en XFCE4 mixer -- no apparent changes, really).
dmesg:

hdac0: <Intel 82801H High Definition Audio Controller> mem 0xe8044000-0xe8047fff irq 17 at device 27.0 on pci0
hdac0: HDA Driver Revision: 20090614_0135
hdac0: [ITHREAD]
hdac0: HDA Codec #0: Analog Devices AD1981HD
hdac0: hdac_command_send_internal: TIMEOUT numcmd=1, sent=1, received=0
hdac0: hdac_command_send_internal: TIMEOUT numcmd=1, sent=1, received=0
hdac0: Codec #1 is not responding! Probing aborted.
pcm0: <HDA Analog Devices AD1981HD PCM #0 Analog> at cad 0 nid 1 on hdac0
pcm1: <HDA Analog Devices AD1981HD PCM #1 Digital> at cad 0 nid 1 on hdac0

I think I had that "Codec #1 is not responding" previously.

sndstat:

FreeBSD Audio Driver (newpcm: 32bit 2009061500/i386)
Installed devices:
pcm0: <HDA Analog Devices AD1981HD PCM #0 Analog> at cad 0 nid 1 on hdac0 kld snd_hda [MPSAFE] (1p:1v/1r:1v channels duplex default)
pcm1: <HDA Analog Devices AD1981HD PCM #1 Digital> at cad 0 nid 1 on hdac0 kld snd_hda [MPSAFE] (1p:1v/0r:0v channels simplex)

[joel@]

You don't have to. There are daily snapshots of 8-CURRENT built for i386 together with BSDInstaller:
http://snapshots.pfsense.org/FreeBSD_8_0/?C=M;O=D
There are many sites building and publishing snapshots on the web, but remember that these are not built by the FreeBSD Project release engineering team, and are not in any way "official".

[graudeejs]

I Just updated My FreeBSD-8-Current to latest
*default host=cvsup2.lv.FreeBSD.org
*default base=/usr
*default prefix=/usr
*default release=cvs tag=.
*default delete use-rel-suffix
*default compress
src-all


But I'm not sure how to check this with uname it shows:

FreeBSD 192.168.128.100 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Wed Jun 17 17:40:47 EEST 2009 root@192.168.128.100:/usr/obj/usr/src/sys/ANTIGENERIC i386
I was using 8 already.... that's why I feel confused a bit.


Anyway, OSS seams to work good. I haven't noticed any changes.
I'm using snd_ich driver
I have integrated sound card in Abit AS8 / AS8-V (Intel i865-ICH5) motherboard

killasmurf86 $ dmesg | grep pcm
pcm0: <Intel ICH5 (82801EB)> port 0xd800-0xd8ff,0xdc00-0xdc3f mem 0xfa101000-0xfa1011ff,0xfa102000-0xfa1020ff irq 17 at device 31.5 on pci0
pcm0: [ITHREAD]
pcm0: <Avance Logic ALC658 AC97 Codec>

I noticed that i'm the only one here who have 1 pcm. Did I miss anything?

[DrJ]

But I'm not sure how to check this with uname it shows:

FreeBSD 192.168.128.100 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Wed Jun 17 17:40:47 EEST 2009 root@192.168.128.100:/usr/obj/usr/src/sys/ANTIGENERIC i386
I was using 8 already.... that's why I feel confused a bit.

This looks fine. It shows that you built it on Jun 17, at 17:40, which is what you did, right? 8-CURRENT is what you are running, and the #0 means that it is the first kernel you have built from this source. I'd think that's right too.

So you should be good to go.

[graudeejs]

I noticed that snd_audiocs(4) manpage is missing [i saw cross ref to it in sound(4)]

[DutchDaemon]

Tucked away ;)

man /usr/src/share/man/man4/man4.sparc64/snd_audiocs.4

[richardpl]

snd_audiocs(4) is for sparc64 only, probably there should be more that one version of sound(4) manual.

[graudeejs]

snd_audiocs(4) is for sparc64 only, probably there should be more that one version of sound(4) manual.

Or manual should be generated during compilation

[dh]

I cvsupped a few days ago:
FreeBSD xxx 8.0-CURRENT FreeBSD 8.0-CURRENT #5: Mon Jun 15 23:00:48 EEST 2009 root@xxx:/usr/obj/usr/src/sys/DEBUG amd64
Using snd_hda (Gigabyte EX58-UD4 internal sound):
hdac0: <Intel 82801J High Definition Audio Controller> mem 0xfdff4000-0xfdff7fff irq 22 at device 27.0 on pci0
hdac0: HDA Driver Revision: 20090614_0135
hdac0: [ITHREAD]
hdac0: HDA Codec #2: Realtek ALC888
pcm0: <HDA Realtek ALC888 PCM #0 Analog> at cad 2 nid 1 on hdac0
pcm1: <HDA Realtek ALC888 PCM #1 Analog> at cad 2 nid 1 on hdac0
pcm2: <HDA Realtek ALC888 PCM #2 Digital> at cad 2 nid 1 on hdac0


First thing I noticed was that while running audacious and mplayer, I could mute mplayer sound and not affecting audacious \m/. That wasn't possible before.

[joel@]

First thing I noticed was that while running audacious and mplayer, I could mute mplayer sound and not affecting audacious \m/. That wasn't possible before.
Yea, thats the new Volume Per Channel (VPC) stuff.

[oliverh]

The nVidia patches are not in quite yet, but they should be in the next few weeks. Then nVidia has to write the driver, but their issue has always been the lack of certain FreeBSD kernel functionality. So writing the actual driver should go pretty quickly.

I don't think so,

Like I said earlier, I've worked with John Baldwin to test/debug preliminary snapshots of the new kernel interfaces (against an 8.0-CURRENT snapshot). The NVIDIA UNIX graphics driver stack is now mostly functional on FreeBSD/amd64 with John's changes (native 64-bit and 32-bit OpenGL applications work, for example). It'll likely be a little while before everything falls into place, but a lot of progress has been made in the last month.

http://www.nvnews.net/vbulletin/showpost.php?p=2031965&postcount=405

So maybe we will see some alpha/beta driver with the advent of FBSD 8.1 or later.

[DrJ]

Oliver, later in the thread on nvnews Ed Zander of nVidia states:

I'm not aware of an estimated time frame [for the kernel changes], but my guess is the changes will make it into both the FreeBSD 8 and 7 trees over the next few weeks.

That's what I claimed. As far as the driver itself, I'd guess a couple of months thereafter. That may or may not make it into 8.0, but for the first time ever there is reason to believe that there will be a 64-bit nVidia driver.

[ericturgeon]

I know is gone sound weird! But the Massive sound changes it is default or I got to install something.

[DutchDaemon]

I didn't need to change a thing anyway.

[graudeejs]

it seams that after I change volume in mplayer and then seek, volume is reset (this is probably because of mplayer, but I wanted you to know)

[LateNiteTV]

sound works fine for me with snd_hda. firefox is now like half broken for me though.

[DutchDaemon]

it seams that after I change volume in mplayer and then seek, volume is reset (this is probably because of mplayer, but I wanted you to know)

I've seen that. It happens on xmms as well.

[ariff@]

it seams that after I change volume in mplayer and then seek, volume is reset (this is probably because of mplayer, but I wanted you to know)

I've seen that. It happens on xmms as well.

[1]
That's because most of applications are following _official_ 4front/OSS convention. Whenever the state of stream/playback/recording is about to be changed, the application must re-open sound device and re-initialize/restore its state. This is due to feature (or some would say bug/deficiency) of official 4front implementation.

[2]
Enter FreeBSD OSS, it is a different story. Most of the strict requirements such as ioctl ordering or device re-opening does not apply here due to dynamic nature of FreeBSD own implementation (which is why "adaptive" virtual channel is possible). The BAD: We still have to deal with those applications.

Re-opening is the easiest way to untangle the mess of device state [1]. But it comes with price: Everything will be reset, and that includes volume-per-channel too. If you want to preserve the volume settings accross device re-opening, set hw.snd.vpc_autoreset=0 . Why it is not the default?

Consider this:

1) mplayer playing, volume fiddling, etc..
2) mplayer pausing, effectively close() on /dev/dsp.
Since vpc_autoreset=0, the state of volume is preserved.
3) Other application (possibly xine, vlc, xmms) open() on /dev/dsp,
possibly re-using /dev/dsp previously close()ed by mplayer .
4) Listener confuse, why the volume of 2nd application is too low/high.
5) Listener resume mplayer, while letting 2nd application going on
6) Listener confuse even more, why mplayer didn't recover its volume
7) Listener angry, start kicking and cursing mplayer/2nd app, FreeBSD, world.

The definite solution is of course, to somewhat 'fix' both mplayer and xmms.

For xmms:
http://people.freebsd.org/~ariff/ports/multimedia_xmms/patch-xzz

For mplayer:
http://people.freebsd.org/~ariff/ports/multimedia_mplayer/patch-xzz

That way, you can leave alone hw.snd.vpc_autoreset and enjoy volume state persistency. Be advised that the above patches might have reverse effect on official 4front/OSS due to [2], but as long as you're using FreeBSD own OSS, rest assured.

[graudeejs]

does port maintainers, know about this?
They could include this patch optional

[lme@]

The best thing was if the patches would go upstream.

[ariff@]

The best thing was if the patches would go upstream.

This might be a good, or bad idea. I tend to prefer if it would go upstream, but reality check told me otherwise.

Those (xmms, mplayer, etc..) are not broken to begin with. They are just following what was suggested by 4Front. Seems unfair, especially if non-4Front OSS can be implemented better (see above #2 notes).

Let it become part of ports patches seems a better deal.

[joel@]

I updated the pcm(4) manual page yesterday. Now it at least explains some of the new features. If something seems awkward or wrong, please tell us.

To get the latest version of the manpage, you need to use csup to grab a fresh copy of CURRENT. I don't think BETA1 contains the latest version.

[blah]

joel@, do you plan to fix these typos (http://www.freebsd.org/cgi/query-pr.cgi?pr=docs/136408) in pcm(4)?

[joel@]

joel@, do you plan to fix these typos (http://www.freebsd.org/cgi/query-pr.cgi?pr=docs/136408) in pcm(4)?
Fixed, thanks.

[gnemmi]

Bad exprience in here ... -BETA1

No sound and a LOR :(

log in (root)

kldload snd_hda
cat /dev/sndstat

FreeBSD Audio Driver (newpcm: 32 bit 20090615000/i386)
Installed devices:
pcm0: <HDA Sigmatel STAC9228X PCM #0 Analog> at cad 0 nid 1 on hdac0 kld snd_hda
[MPSAFE] (1p:1v/1r:1v channels duplex default)


mixer

Mixer vol is currently set to 75:75
Mixer pcm is currently set to 75:75
Mixer speaker is currently set to 75:75
Mixer mic is currently set to 0:0
Mixer rec is currently set to 0:0


"insert cd"

cdcontrol -f /dev/acd0 play 1

"no sound at all"

cdcontrol eject
kldunload snd_hda

Jul *beep*7 21:44:15 gargoyle login: ROOT LOGIN (root) ON ttyv0
Jul *beep*7 21:54:27 gargoyle kernel: hdac0: <Intel 82801H High Definition Audio Controller> mem 0xf6dfc000-0xf6dfffff irq 21 at device 27.0 on pci0
Jul *beep*7 21:54:27 gargoyle kernel: hdac0: HDA Driver Revision: 20090624_0136
Jul *beep*7 21:54:27 gargoyle kernel: hdac0: [ITHREAD]
Jul *beep*7 21:54:27 gargoyle kernel: hdac0: HDA Codec #0: Sigmatel STAC9228X
Jul *beep*7 21:54:27 gargoyle kernel: pcm0: <HDA Sigmatel STAC9228X PCM #0 Analog> at cad 0 nid 1 on hdac0
Jul *beep*7 22:03:27 gargoyle kernel: lock order reversal:
Jul *beep*7 22:03:27 gargoyle kernel: 1st 0xc0da8cdc kernel linker (kernel linker) @ /usr/src/sys/kern/kern_linker.c:1079
Jul *beep*7 22:03:27 gargoyle kernel: 2nd 0xc0daa4e4 sysctl lock (sysctl lock) @ /usr/src/sys/kern/kern_sysctl.c:255
Jul *beep*7 22:03:27 gargoyle kernel: KDB: stack backtrace:
Jul *beep*7 22:03:27 gargoyle kernel: db_trace_self_wrapper(c0c5b564,e6df7ac0,c08b5b35,c 08a68db,c0c5e3f9,...) at db_trace_self_wrapper+0x26
Jul *beep*7 22:03:27 gargoyle kernel: kdb_backtrace(c08a68db,c0c5e3f9,c452cae8,c452ad40, e6df7b1c,...) at kdb_backtrace+0x29
Jul *beep*7 22:03:27 gargoyle kernel: _witness_debugger(c0c5e3f9,c0daa4e4,c0c58fbb,c452a d40,c0c58ec2,...) at _witness_debugger+0x25
Jul *beep*7 22:03:27 gargoyle kernel: witness_checkorder(c0daa4e4,9,c0c58ec2,ff,0,...) at witness_checkorder+0x839
Jul *beep*7 22:03:27 gargoyle kernel: _sx_xlock(c0daa4e4,0,c0c58ec2,ff,0,...) at _sx_xlock+0x85
Jul *beep*7 22:03:27 gargoyle kernel: sysctl_ctx_free(c4d7379c,0,c4e1c712,4a1,c4ca9480,. ..) at sysctl_ctx_free+0x30
Jul *beep*7 22:03:27 gargoyle kernel: pcm_unregister(c488f800,c4da3860,c0d3b6c8,a3c,c488 7a80,...) at pcm_unregister+0x4e1
Jul *beep*7 22:03:27 gargoyle kernel: device_detach(c488f800,c0865663,c0da9df0,c4dd22d4, c4a95100,...) at device_detach+0x8c
Jul *beep*7 22:03:27 gargoyle kernel: driver_module_handler(c4887a80,1,c4dd22d4,109,0,.. .) at driver_module_handler+0x29c
Jul *beep*7 22:03:27 gargoyle kernel: module_unload(c4887a80,c0c54c7c,273,270,c08592b6,. ..) at module_unload+0x43
Jul *beep*7 22:03:27 gargoyle kernel: linker_file_unload(c4a92600,0,c0c54c7c,437,c4dba00 0,...) at linker_file_unload+0x15e
Jul *beep*7 22:03:27 gargoyle kernel: kern_kldunload(c4ca9480,2,0,e6df7d2c,c0b98e73,...) at kern_kldunload+0xd5
Jul *beep*7 22:03:27 gargoyle kernel: kldunloadf(c4ca9480,e6df7cf8,8,c0c5f4bb,c0d3f0b0,. ..) at kldunloadf+0x2b
Jul *beep*7 22:03:27 gargoyle kernel: syscall(e6df7d38) at syscall+0x2a3
Jul *beep*7 22:03:27 gargoyle kernel: Xint0x80_syscall() at Xint0x80_syscall+0x20
Jul *beep*7 22:03:27 gargoyle kernel: --- syscall (444, FreeBSD ELF32,
kldunloadf), eip = 0x280d573b, esp = 0xbfbfe47c, ebp = 0xbfbfecc8 ---
Jul *beep*7 22:03:27 gargoyle kernel: pcm0: detached
Jul *beep*7 22:03:27 gargoyle kernel: hdac0: detached


Any pointers??

Best Regards
Gonzalo

[richardpl]

And cdcontrol plays CD on older versions?

Correct way to test sound is:
cat /dev/random > /dev/dsp0.1

[gnemmi]

And cdcontrol plays CD on older versions?

Correct way to test sound is:
cat /dev/random > /dev/dsp0.1

Then section 7.2.2 Testing the Sound Card (http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/sound-setup.html) needs to be update ASAP if it is to be taken as the authoritative word on how to get around on a FreeBSD system :\

Anyways, thanks for the hint. It worked. :)
Regards
Gonzalo

[joel@]

Then section 7.2.2 Testing the Sound Card (http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/sound-setup.html) needs to be update ASAP if it is to be taken as the authoritative word on how to get around on a FreeBSD system :\
The entire sound part in the handbook needs to be rewritten. Not going to happen anytime soon though, unless someone else does it.

[aragon]

Success report here. Just got snd_hda(4) working in 8.0-BETA1 on my Dell XPS M1330. I did have to add hint.hdac.0.config="gpio2" to loader.conf to get the built-in speakers working, though.

[Petz]

Seems to detect the devices and work ok for me. By work ok I mean 'cat /dev/random > /dev/dsp0.1' produces hiss/static through my headphones.

I wasn't able to hear a cd play using cdcontrol though. There is probably more config I need to do beside kldload? Either that or it defaulted to the wrong device?

Tested on 8.0 BETA1 x64


# kldload snd_hda
hdac0: <Intel 82801J High Definition Audio Controller> mem 0xeb300000-0xeb303fff
irq 22 at device 27.0 on pci0
hdac0: HDA Driver Revision: 20090624_0136
hdac0: [ITHREAD]
hdac0: HDA Codec #2: Realtek ALC885
hdac1: <ATI RV770 High Definition Audio Controller> mem 0xe5010000-0xe5013fff ir
q 17 at device 0.1 on pci3
hdac1: HDA Driver Revision: 20090624_0136
hdac1: [ITHREAD]
hdac1: HDA Codec #0: ATI R6xx HDMI
pcm0: <HDA Realtek ALC885 PCM #0 Analog> at cad 2 nid 1 on hdac0
pcm1: <HDA Realtek ALC885 PCM #1 Analog> at cad 2 nid 1 on hdac0
pcm2: <HDA Realtek ALC885 PCM #2 Digital> at cad 2 nid 1 on hdac0
pcm3: <HDA ATI R6xx HDMI PCM #0 Digital> at cad 0 nid 1 on hdac1


# cat /dev/sndstat
FreeBSD Audio Driver (newpcm: 64bit 2009061500/amd64)
Installed devices:
pcm0: <HDA Realtek ALC885 PCM #0 Analog> at cad 2 nid 1 on hdac0 kld snd_hda [MP
SAFE] (1p:1v/1r:1v channels duplex default)
pcm1: <HDA Realtek ALC885 PCM #1 Analog> at cad 2 nid 1 on hdac0 kld snd_hda [MP
SAFE] (1p:1v/1r:1v channels duplex)
pcm2: <HDA Realtek ALC885 PCM #2 Digital> at cad 2 nid 1 on hdac0 kld snd_hda [M
PSAFE] (1p:1v/1r:1v channels duplex)
pcm3: <HDA ATI R6xx HDMI PCM #0 Digital> at cad 0 nid 1 on hdac1 kld snd_hda [MP
SAFE] (1p:1v/0r:0v channels simplex)



# mixer
Mixer vol is currently set to 75:75
Mixer pcm is currently set to 75:75
Mixer speaker is currently set to 75:75
Mixer line is currently set to 75:75
Mixer mic is currently set to 0:0
Mixer mix is currently set to 0:0
Mixer rec is currently set to 0:0
Recording source: mic

[Petz]

I wasn't able to hear a cd play using cdcontrol though. There is probably more config I need to do beside kldload? Either that or it defaulted to the wrong device?


Just read another forum post saying that cdcontrol works only for cd/dvd drives wired to the sound card with an analogue cable. That probably explains why its not working since it looks like I don't have one.

[jb_fvwm2]

You cannot plug an audio cable into the front of the
drive while the cd plays?

[Petz]

You cannot plug an audio cable into the front of the
drive while the cd plays?

I could but that kind of defeats the purpose of testing the sound card. Besdies why would you want to re cable your headphones each time you want to listen to a cd.

In that other forum post, I also read about mplayer(and an OpenBSD version of cdcontrol) that can playback music CDs digitally(copy data via the SATA/PATA connection from the DVD/CD drive to the motherboard then to the soundcard for output). This is what I would do.

[ariff@]

dd if=/dev/acd0t01 of=/dev/dspcd bs=2352

dd if=/dev/acd0 of=/dev/dspcd bs=2352


#!/bin/sh

for x in /dev/acd[0-9]t[0-9][0-9] ; do
dd if=$x of=/dev/dspcd bs=2352
done



There, your easter eggs :)

mplayer -cache 2352 cdda://1

[joel@]

I think we've received enough positive feedback for now. I'll make this thread non-sticky. :)