Hi all, well about linux users in general - the issue can't be solved by them properly. It's up to the respective distributors to solve the problems by recompiling the respective programs with OSS support again. If they're not willing to do that, it's unlikely that they ever wanted to support OSS again anyway. It's the distributors job to build something as much modular as possible and since they're usually not able to choose majoritiy fitting compile flags for all programs they simply add support for everything the respective application has to offer. Also with the problems you mentioned - you can't solve them for the linux users and shouldn't even attempt to, you will end up trying to build packages for all distros, which is the only sane way to properly solve the problems, because it will guarantee that all depencies are installed etc.. So you should just continue your path and instead make the users step up on their distributors to properly package OSS4.
I do see other problems with OSS4 on linux though. While most programs support it more or less properly, the two most important desktop environments aren't even able to properly control the volume (for devices using the new mixer API), and most developers I spoke with are even unwilling to add the support, because of the good old ALSA vs OSS "propaganda". Neither in KDE3 nor in KDE4 for example is KDE able to control the volume properly. While it's not that hard to solve the issue in KDE3, KDE4 entirely depends on information gathered by HAL - HAL does not support OSS4 either, so KDE4 doesn't detect OSS4 devices at all. I'm currently talking with the devs about possible solutions (though my proposals won't likely either bother or please them too much). For now it looks like it's again up to the distributors and their devs to solve this issue in linux. Another thing I experienced is the already known problem with vmix volume control. I think the vmix volume should be raised to maximum if an application disconnects from it. I sometimes experience cases in which output plugins apparently calculate the current mixer settings and take that as a reference for the maximum, therefore resulting in varying volume settings although nothing was changed by the respective program but by others that properly used the vmix volume control. Another more enerving issue happens with libflashsupport.so. Sometimes it just makes flash crash (I've no idea how to debug that) although it happens rather seldom. Also I _always_ experience some kind of very strange and loud initialisation sound when flash is loaded, comparable to a completely overdriven amplifier, just for half of a second. This problem only happens with flash. Well, I think, with time OSS4 will become properly integrated in linux again - at least I hope that. Regards apriori On Tuesday 12 February 2008 09:06:38 pm Hannu Savolainen wrote: > Yair K. wrote: > > Hi, > > > > In the forum, I've noticed that much of the problems users have with OSS, > > relate to making applications output via OSS, not making OSS work. For > > example see: > > > > http://cinnamonpirate.com/blog/480/ > > http://www.rawspinach.org/2008/01/15/sound-on-fedora-fc8-solved/ > > http://www.4front-tech.com/forum/viewtopic.php?t=2461&sid=e270103d1336fe8 > >77d7eee4c7b8e3c8d > > This is correct observation. The most common problems with OSS4 seem to be: > - Linux doesn't support precompiled binary drivers. This means that > gcc/binutils/make/kernel_headers/etc must be installed before OSS can be > installed. This is far too complicated for majority of Linux users. > - Applications included in Linux distributions have been compiled and > configured for ALSA. Recompiling them is too complicated. > - OSS plugins of many Linux applications are bogus. They may use > non-blocking I/O incorrectly. Some other use stupid usleep() hacks that > don't work reliably. > > > I think a few simple changes, can make for a much better experience: > > > > 1) Compile libflashsupport.so by default. If we comment out the #define > > OPENSSL line from flashsupport.c, than no new dependencies are > > introduced. Maybe even use the method currently used in soundon for > > libsalsa to install it. > > The problem is that precompiled libflashsupport.so may depend on > libraries/versions that are not installed. That prevents flash from > working at all (even without sound). So in practise the only safe way is > to compile it in the target system (if it works). > > > 2) What is the ossupdate program? Is it a reliable way of updating oss? > > It seems to be still closed source. > > ossupdate is a bonus program for the users who have licensed OSS. > > > 3) Inform the user he may need to install oss sound plugins for > > applications when installation is done. > > Users don't seem to read the messages printed during/after the > installation. > > Best regards, > > Hannu > _______________________________________________ > oss-devel mailing list > oss-devel@mailman.opensound.com > http://mailman.opensound.com/mailman/listinfo/oss-devel _______________________________________________ oss-devel mailing list oss-devel@mailman.opensound.com http://mailman.opensound.com/mailman/listinfo/oss-devel
