OSS v4.2 build 2004 - looking GOOD!

[rasta]

OSS 4.2 build 2004 installed perfectly on Solaris 10 u8 x64. However, adding "ossdetect" without quotes to the end of /etc/profile was necessary to get oss to attach properly. After doing that, oss works great, even after a reboot. I'll post again if I run into any problems.

Good job, Open Sound!

Thank you!

[rasta]

Using Solaris 10 u8 x64 on Intel hardware (using Host Driver: Windows DirectSound, Controller: ICH AC97 for VirtualBox 4.0.0 guest), build 2004 will still attach only intermittently. Workarounds are needed to get oss to function normally. DEFINITIVE step-by-step instructions are needed.

It seems that when boot archive is updated upon reboot, oss attaches normally. A reconfigure reboot (boot -r or reboot -- -r) often gets oss to attach properly. Without attachment, osstest will still work, but other sounds will not play, as has been the case for years. "ossdetect" placed at the end of /etc/profile does not solve the problem. If ossdetect is run as root, then oss will attach for subsequent logins by any user. How can I get ossdetect to be run automatically by the system after each reboot?

Other times, oss behaves perfectly after reboot.

[dev]

Using Solaris 10 u8 x64 on Intel hardware (using Host Driver: Windows DirectSound, Controller: ICH AC97 for VirtualBox 4.0.0 guest), build 2004 will still attach only intermittently. Workarounds are needed to get oss to function normally. DEFINITIVE step-by-step instructions are needed.

It seems that when boot archive is updated upon reboot, oss attaches normally. A reconfigure reboot (boot -r or reboot -- -r) often gets oss to attach properly. Without attachment, osstest will still work, but other sounds will not play, as has been the case for years. "ossdetect" placed at the end of /etc/profile does not solve the problem. If ossdetect is run as root, then oss will attach for subsequent logins by any user. How can I get ossdetect to be run automatically by the system after each reboot?

Other times, oss behaves perfectly after reboot.

Hi,


Try this: edit /etc/init.d/oss and add sleep 10 before the soundon command in the start) section. What happens after reboot is Solaris calls modunload -i 0 and this unloads all modules not currently in use. The problem with oss is that it's the framework (osscore/sadasupport/etc) that creates all the device nodes - not the driver - and if the framework gets loaded after the driver then no device nodes get reattached.



regards
Dev

[rasta]

Dev,

Thank you very much for the tip. I've implemented it, and I've had perfect attachment on 2 boots in a row. I'll keep you posted. I'm lovin' build 2004 so far!

Cheers!

[rasta]

Dev,

The behavior I'm getting now (with "sleep 10" added to /etc/init.d/oss) is that upon first boot, oss will not attach, but if I simply reboot, it will attach.

Below is the edited oss script. Did I edit it correctly?

> cat /etc/init.d/oss
#!/bin/sh
if test -f /etc/oss.conf
then
. /etc/oss.conf
else
OSSLIBDIR=/usr/lib/oss
fi

##########
#
# The first argument tells what to do.
##########

state=$1

if test -f /etc/oss.conf
then
. /etc/oss.conf
else
OSSLIBDIR=$OSSLIBDIR
fi

case $state in

'start')
soundoff
sleep 10
soundon
exit 0
;;
'stop')
/usr/sbin/savemixer > /dev/null 2>&1
exit 0
;;
esac

exit 1

[rasta]

Dev,

I posted this in this forum a while back:

*********************
Dev,

Here is some info about the unloading from the opensolaris opensound forum:

"One way to help reduce the chance of modunload -i 0 from auto-unloading
modules is to export a property -- "ddi-no-autodetach". This will not
prevent intentional unloads of modules by an end-user, but it will
prevent automatic unloads of modules that are not in use.

-- Garrett"

I hope this helps.

********************************

Did you try that? It appears that you and the oss team knows what the problem is with the modules unloading, but are either uninterested, incapable, or too busy to fix it. Please prove me wrong.

[dev]

Dev,

I posted this in this forum a while back:

*********************
Dev,

Here is some info about the unloading from the opensolaris opensound forum:

"One way to help reduce the chance of modunload -i 0 from auto-unloading
modules is to export a property -- "ddi-no-autodetach". This will not
prevent intentional unloads of modules by an end-user, but it will
prevent automatic unloads of modules that are not in use.

-- Garrett"

I hope this helps.

********************************

Did you try that? It appears that you and the oss team knows what the problem is with the modules unloading, but are either uninterested, incapable, or too busy to fix it. Please prove me wrong.

the problem is that osscore handles the device creation and it's a "framework" pseudo driver - hence ddi-no-autodetach will not work for osscore. - it only works for actual drivers - in OSS - drivers do not create the device nodes - they simply attach/detach the physical device.


The only real way is for solaris to implement nodetach to pseudo drivers.


(look at osscore.conf - it's parent is "pseudo". while any othe driver eg sblive.conf has the parent as pci.)


this problem has been solved by boomer in Solaris 11.

regards
Dev

[rasta]

Dev,

Thank you for the info. I guess it is just a basic incompatibility between Solaris 10 and oss 4.2. It is still more or less random if oss will attach properly to Solaris, but an ossdetect and a reboot or two usually gets oss working.

Is Solaris 11 the same as opensolaris? Is opensolaris independent from Oracle?

[rasta]

Cesium noticed that the oss source adds a 'ddi-no-autoattach' line under Solaris 9:

[code="setup/SunOS/confgen.c"]#ifdef SOL9
fprintf (conf, "ddi-no-autodetach=1 ddi-forceattach=1 \n");
#endif[/code]

Would removing the ifdef help so that the autodetach is run regardless of OS (meaning for Solaris 10, too)? Or maybe this property is exported elsewhere under Solaris 10?

Hope this helps. Please pass this info no to the oss developers, who may not read this forum.

[dev]

Cesium noticed that the oss source adds a 'ddi-no-autoattach' line under Solaris 9:

[code="setup/SunOS/confgen.c"]#ifdef SOL9
fprintf (conf, "ddi-no-autodetach=1 ddi-forceattach=1 \n");
#endif[/code]

Would removing the ifdef help so that the autodetech is run regardless of OS (meaning for Solaris 10, too)? Or maybe this property is exported elsewhere under Solaris 10?

Hope this helps. Please pass this info no to the oss developers, who may not read this forum.

Hi,


I've added the patch to the latest sources - I tested this on Solaris 10 sparc and it seemed to work.

[rasta]

GREAT!!!!!!!!!!!!!!!! Thank you very much for making the change.

[Egorio]

I've added the patch to the latest sources - I tested this on Solaris 10 sparc and it seemed to work.

where can i get it? i nned it for android development

[rasta]

So far, it looks like v4.2 build 2005 solves all problems related to attaching on Solaris 10 x86! Good job, 4front!!!

[vixcin]

From what I could understand, the main issue here that you are experiencing is nothing other than the fact that ossscores are handling the device creation apparently. And since it is a framework pseudo driver, only drivers which are actual can work. Audiodetach won’t work in this case, I’m afraid.

[ColoWin]

From what I could understand, the main issue here that you are experiencing is nothing other than the fact that ossscores are handling the device creation apparently. And since it is a framework pseudo driver, only drivers which are actual can work. Audiodetach won’t work in this case, I’m afraid.

Looks like you're right
____________________
mobile app development companies