rasta wrote: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.
I posted this in this forum a while back:
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.
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.
rasta wrote:Cesium noticed that the oss source adds a 'ddi-no-autoattach' line under Solaris 9:
fprintf (conf, "ddi-no-autodetach=1 ddi-forceattach=1 \n");
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.
dev wrote:I've added the patch to the latest sources - I tested this on Solaris 10 sparc and it seemed to work.
vixcin wrote: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.
Users browsing this forum: No registered users and 5 guests