On Tuesday 12 February 2008 00:45:29 [EMAIL PROTECTED] wrote:
[snip]
> 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..
I didn't ask for that. But there are some things that can be done to make life
easier for users.
[snip]
> 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".
ALSA works only on Linux. FreeBSD uses OSSv3 (there's disabled support for
OSSv4) and OpenSolaris will use OSSv4. If they want to be cross-platform (and
not 'Linux-only'), they should add support regardless of "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).
Is there a public bugtracker for this discussion?
> 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.
I've never had this problem. One thing I did notice is that if another program
connects to the same engine after a program disconnected, then it gets the
last volume, while if the previously disconnected program reconnects
afterwards, it get the maximum volume from the newly used engine. (In short,
the volume is saved per-engine, but not per-program, which seems less useful
to me)
I have a diff to ossxmix in the works, which lets it store specific volume for
programs. ossxmix reads an ini file into memory, when it detects a program
starting, it sets its vmix volume to the pre-set value. Making it work for
temporary settings is easy as well. These bugs can than be worked-around by
setting the respective program volume to maximum. Alternately, this will
allow to drop the "save last vmix volume" behaviour without losing
functionality.
> 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.
Maybe the plugin issues are browser related?
(FireFox is broken enough to crash when a plugin crashes. Opera just keeps
going, and I've never had a plugin crash with Konqueror).
> Well, I think, with time OSS4 will become properly integrated in linux
> again - at least I hope that.
>
> Regards
>
> apriori
Yours,
Yair K.
_______________________________________________
oss-devel mailing list
oss-devel@mailman.opensound.com
http://mailman.opensound.com/mailman/listinfo/oss-devel
