Going from 1009 to 1011 kind of broke vmix

[Tomservo]

I'm saying kind of because it's really weird behaviour. Using two instances of MPlayer playing audio of some kind, things behave like this:

- Can't play two instances both on /dev/dsp (results in device busy)
- Can play two instances each using /dev/dsp(0) and /dev/dsp1, though both are symlinks to the same node (/dev/oss/sblive0/pcm0)
- Can't play two instances both using /dev/oss/sblive0/pcm0 (device busy, see where it's getting weird)

This came with version 1011. Did ossdevlinks -r already, didn't change anything.

In ossxmix, I had the vmix devices listed in the past, this time not.

Also, ossinfo presents me with this silly gem, which I suppose is probably the main problem:

Mixer devices
SB Audigy2 (STAC9721) (Mixer -1 of device object 1)

Thanks for any help.

[seawright]

I don't have any experience of Solaris but from the symptoms you describe I would say that vmix though loaded is not being used.

Delete the comment in:
/usr/lib/oss/conf/vmix.conf
and set "vmix1_masterdev=#"
where # is the index number for /dev/oss/sblive0/pcm0 obtained from ossinfo.
After that does reloading the drivers solve the problem?

[Tomservo]

Nope, didn't change anything. I think the case might even be that the mixer ID is set to 0xFFFFFFFF (aka -1 on signed int) for some reason.

--edit: Reverted to build 1006. Works fine for now. 1009 crashes my machine on boot half the time.

[seawright]

Ok,
Does your soundcard have hardware mixing?
If so remove vmix from,
/usr/lib/oss/etc/installed_drivers
and replace /dev/dsp with a symlink to,
/dev/oss/sblive0/pcm4
Reload driver and check if two instances of mplayer will play to /dev/dsp without returning device busy.

[Tomservo]

Yeah, EMU10Kx cards do have hardware mixing. Gonna try that.

--edit: That did it (using pcm0 though, which is main). Strangely enough, the vmix channels suddenly showed up in ossxmix.
--edit2: Durr, never mind, still using 1006
--edit3: Using the symlink with 1011, it appears to work, gonna reboot now.
--edit4: Reboot broke it again. Ah well, I'll wait for the next build. 1006 seems to work.

[rmf]

Exact same problem with hdaudio:

pci bus 0x0000 cardnum 0x1b function 0x00: vendor 0x8086 device 0x27d8
Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller

Also, does anyone else have the problem that audio samples played with audioplay leaves a pop at the end, while ossplay does not?

-r

[Tomservo]

Since we're at it, I have some severe timing problems, too. Using vmix, anything relying on A-V sync works fine and smooth. Making OSS go the hardware mixing route, i.e. disabling vmix, introduces huge jitter in every video application, unless you can make it assume/guess sync, like mplayer's autosync option.

[seawright]

You mean it works with build 1006 but not build 1011?
There is a build 1012 now. Have you tried that?

[Tomservo]

With 1012 it works again.

[rmf]

still broken for me. Seems like either oss or devaudio works, pending on who accessed it first. Odd thing is, when oss fails, then all oss opens fails with a device busy. When devaudio fails, the apps play, but no sound comes out (though the jds audio icons says no audio).

[dev]

still broken for me. Seems like either oss or devaudio works, pending on who accessed it first. Odd thing is, when oss fails, then all oss opens fails with a device busy. When devaudio fails, the apps play, but no sound comes out (though the jds audio icons says no audio).

You need to run drvconfig after each reboot and then the drivers attach correctly. We are trying to figure out why OSS will not attach after
a reboot


regards
Dev