Bugzilla – Bug 117989
aoss should not reset previous value of LD_PRELOAD
Last modified: 2007-02-16 18:15:52 UTC
If there is already any library in LD_PRELOAD, aoss ignores it. There is simplest way to keep original value. LD_PRELOAD="${LD_PRELOAD:+$LD_PRELOAD:}${exec_prefix}/\$LIB/libaoss.so" exec "$@" (needs #!/bin/bash Maybe LD_PRELOAD="$LD_PRELOAD:${exec_prefix}/\$LIB/libaoss.so" exec "$@" could be enough, too (it adds : to beginning of the string, if LD_PRELOAD was empty).
Nice catch. Feel free to fix alsa package on STABLE (I'm in Labs conference now :)
BTW, should the previous $LD_PRELOAD be before or after libaoss? If the previous LD_PRELOAD wraps the syscalls, aoss wouldn't work in the above change.
Yes, you are true. If previous preload wraps the same call, the last in the list wins. esddsp adds itself as first. I don't know, whether it is possible to create a different solution.
Ah, the last entry wins... Then the above should work indeed - aoss will win since its the last one. Please submit the package, or wait until the next week :) I think esddsp should be fixed in the same manner, too?
I think, that esddsp should win in "esddsp aoss something", because esddsp wraps only OSS, for ALSA it is actually a dummy. The only chance to use remote sound on thin clients is use of esddsp in session startup scripts and changing output of all programs to OSS. This is still far from optimal solution (optimal could be ALSA-over-network).
esd has also a loopback function, which ALSA doesn't support natively (yet). This may be another reason to start esd even on ALSA, too.
I'll close this as aoss is now rarely used in our recent versions.