On Friday 09 July 2004 12:00, William wrote: > Chris Cannam wrote: > > William wrote: > >> I wonder why there are so many refreshes whenever connections are > >> changed. > > > > The device manager is really just a view on the actual connection data > > which is stored in the sequencer process. So when you change > > something, it goes off and tells the sequencer process about the > > change, then gets a notification back again, then updates. That's > > why it's so slow. I imagine it could be done more efficiently even > > within that scheme, though. > > Given that Linux IPC is an extremely fast implementation, it seems odd that > the IPC between rosegarden and rosegardensequencer should be a cause of > significant latency and/or delay, for any plausible number of roundtrips. > I wonder what's going on.
I will try to explain what happens with this MIDI manager window, and why it does so many refresh cycles. You already know that RG has two executables, the sequencer and the GUI. The windows that you see, including the Studio window belong to the GUI process, and the ports, connections, ALSA queue and such things belong to 'rosegardensequencer' process. Both processes running at the same time, using DCOP as an IPC mechanism (like many other KDE applications). The sequencer has a timer triggering each 3 seconds a routine that checks if something in the ALSA environment has changed (clients, ports, connections...) and if true, sends a command to the GUI (via DCOP) asking to refresh its views. This refresh command allows you to see and use new ALSA clients in the GUI very soon as they are up. Of course this creates a refresh in the Studio window if it is opened when the command arrives. But the Studio window is not only a passive view for the sequencer's connection state, it also allows you to control several things: change connections to the output ports and subscribe record inputs. Each time you use some command changing a connection state, the command is forwarded via DCOP to the sequencer and it is (provisionally) reflected as if it succeeded in the view state (you see a first refresh here). The sequencer process tries to perform the command using the ALSA API and, if successful, ALSA will tell to the sequencer that something has changed (using system:announce), so the next 3 second cycle will trigger the refresh command to the GUI, and you see a second refresh. Sometimes it is more complex, as when some record device returns to the system, and it is remembered to be connected some time ago. In this case, the device manager will try to subscribe it as an input port, and this triggers more refreshes. I was tempted to use the announce broadcast as a direct trigger for the refresh command, avoiding the 3 seconds timer, but the problem is that when a new ALSA program is executed, it usually triggers several announces (new client, new port, client changes, port changes, and new connections) during a very short time period. Using a timer the number of refresh commands can be reduced. There is some room for improvements, however you must balance the complexity, development time and real benefit. Regards, Pedro ------------------------------------------------------- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com _______________________________________________ Rosegarden-devel mailing list [EMAIL PROTECTED] - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
