Hi Brian, Thanks for explaining :) I agree without not to do anymore hacking until OSS dust is settled and with demand for performance improvement surfaces.
-Ghee Brian Cameron wrote: > > 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 >> >
