Ghee: >> I disagree. When you change the volume, you do want to see the mixer >> applet refresh. I notice that if I set the delay to more than 1.5 >> seconds that it starts to make me wonder, "why isn't the applet >> updating, what's broken?". We could perhaps up the delay to 2 or 2.5 >> seconds, but the delay starts to get much more noticeable at these >> higher timeouts. > > This seems to be broken to me in the refresh mechanism. It the user > changes > the volume, it should refresh immediately. Why can't it directly refresh > it? > Is it because the value is stored out of process? Can some standard IPC > mechanism such as pipe can use to rectify this?
In short, yes, the value is stored out-of-process, in the kernel. It is accessed and controlled via ioctls. If you change the value in one program, other programs cannot find out about this unless they reread the /dev/audioctl device or register for SIGPOLL notification via the mixer interfaces. So, your suggestion of using some standard IPC wouldn't really work to well. I guess we could hack gnome-volume-control, sdtaudiocontrol and any other programs that might change system volume to notify the applet via some IPC mechanism, but if the user changed the volume in a program that wasn't hacked to use this IPC mechanism, then the mixer applet wouldn't update. The nice thing about using the GStreamer plugin is it hides the details of how to control the volume for a given interface (SunAudio or OSS). For example, gnome-volume-control and the mixer applet use this plugin for controlling volume. The volume can also be changed by any other program that calls the ioctls directly (such as sdtaudiocontrol) or which uses the GStreamer mixer plugins. The not so nice thing about using this plugin mechanism with SunAudio is that SunAudio only provides volume change notification via a SIGPOLL signal. As Jan has already pointed out, it is not possible to safely listen for signals in a library plugin, so the plugin itself can't be fixed to automatically notice changes in volume, mute settings, etc. Assuming applets can register to listen for signals, then we could hack the mixer applet to listen to SIGPOLL notification and avoid doing the poll. However, we'd need to be careful to only do this when using the SunAudio interfaces, and not when using OSS or something else. Also, I'm not sure that Sun Ray's SunAudio shim supports this SIGPOLL notification interface. I know that they don't support 100% of the SunAudio mixer interfaces. If they don't support this, then using this interface wouldn't help Sun Ray's at all. Or perhaps we could work with the kernel people to provide some other notification mechanism other than the SIGPOLL so the GStreamer plugin could be notified directly and update its internal volume/mute state without needing to actually reread the device. I'm not sure that this is worth the bother, though. Since we are moving towards using OSS anyway, we probably should make sure that things work as we want with OSS and not worry so much about the problems with the SunAudio interface. Brian >> When you actually change the volume (e.g. in gnome-volume-control or >> sdtaudiocontrol), most users don't twiddle the knobs for over 5 seconds. >> A delay of that long wouldn't be good because you don't want it to wait >> until the user is done making changes to start updating. >> >>> From the case it has noticed a change, I think your suggestion is >>> great! >>> But I don't know/understand enough how the changes is being trigger off, >>> can't make better suggestion. >> >> As Jan points out, we could use SIGPOLL, but this is ugly since it would >> require that the mixer applet become aware of the SunAudio device. This >> breaks the model that the GStreamer plugin should be the only place >> aware of the actual device specifics. >> >> Also, this approach would be tricky to get right since we are moving >> towards using OSS sometime early next year. So the mixer applet would >> need to know when SunAudio is being used and only listen to SIGPOLL in >> that case. We wouldn't want to listen to SIGPOLL if OSS is being used. >> >> In my opinion, this patch does improve things and reduces the amount of >> time the mixer hits the CPU by a factor of 10. This improves things in >> the meantime while we wait for OSS to integrate. >> >> Unless someone has a great suggestion on how to further improve things, >> I think we should hold off on doing anything further until OSS >> integrates. At that time, we should focus on making sure the >> performance is reasonable with OSS since SunAudio will eventually be >> going away. >> >> Brian >
