> >There is an ALSA tool called aoss. >What this does is hook any calls the application does to >fopen/fwrite/fread/fclose/open/close/read/write/ioctl etc. and detects >any calls to open /dev/dsp and /dev/mixer and diverts them to use >alsa-lib. This therefore manages to divert the applications use of >/dev/dsp before it even reaches the kernel. This therefore gives the >application full use of all the alsa-lib features. So, for example, >4-channel output would work in this mode. But, and this is the bit we >need help with, if the application uses dlopen to dynamically open a >plugin, the plugin's calls to open/close/read/write etc. are not hooked, >so the application fails. > >Is there any way to also hook the IO calls of dlopened plugins? > Well you could patch the affected plugin's .dynstr table so that it should at best try to call a function that has not yet been defined somewhere else (like open); IOW, you change the .dynstr entry from 'open' to say 'my_open', and regularly include libmy.so through e.g. LD_PRELOAD. Of course the MD5 won't match afterwards, but I think the plugin should execute as usual afterwards, since .dynstr is something no app should rely on. Jan Engelhardt -- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/alsa-devel
