Massive sound changes in 8-CURRENT, testers wanted

I know is gone sound weird! But the Massive sound changes it is default or I got to install something.
 
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)
 
killasmurf86 said:
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.
 
killasmurf86 said:
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)

DutchDaemon said:
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.
 
The best thing was if the patches would go upstream.
 
lme@ said:
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.
 
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.
 
Bad exprience in here ... -BETA1

No sound and a LOR :(

log in (root)

# kldload snd_hda
# cat /dev/sndstat
Code:
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
Code:
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
Code:
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,c08a68db,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,c452ad40,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,c4887a80,...) 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,c4dba000,...) 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 said:
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 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
 
gnemmi said:
Then section 7.2.2 Testing the Sound Card 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.
 
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.
 
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

Code:
# 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

Code:
# 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)


Code:
# 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 said:
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 said:
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.
 
Code:
dd if=/dev/acd0t01 of=/dev/dspcd bs=2352

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

Code:
#!/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
 
I think we've received enough positive feedback for now. I'll make this thread non-sticky. :)
 
Back
Top