Pedro Lopez-Cabanillas wrote: > I will try to explain what happens with this MIDI manager window, and why it > does so many refresh cycles.
Thank you for your very clear explanation. > 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). I'm not familiar with the internals of KDE. How efficient is KDE's DCOP IPC compared to Linux IPC? I know it's not relevant to the refresh problem, given what you say below. > 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. Is there any reason why the timer frequency could not be changed dynamically depending on whether or not the Studio window is actually open, such that when the Studio window is open, the timer frequency is increased to, say, five times per second, but when the Studio window is closed, the timer frequency is restored to once every 3 seconds? This should help reduce at least one component of the refresh latency. > 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. Why would subscribing it as an input port trigger more than one refresh? > 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. Is there an upper limit on the length of the "very short time period" during which the different announce messages from executing a single new ALSA program are all delivered? Could that uppper limit plus a small safety-margin be used as the timer frequency? Would a group of related announce messages following a single new ALSA program execution ever come close to having a 3 seconds gap between any of the messages? Is that why the timer has a period of 3 seconds? Does ALSA have an option for synchronous delivery of announce messages from a single new ALSA program execution? If so, would you still need the timer for some other reason? > There is some room for improvements, however you must balance the complexity, > development time and real benefit. William ------------------------------------------------------- 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
