Hi Alex,
On Sun, 23 Dec 2001, Alexander R Angas wrote: > > I can't test reasonably from here either (no sound output, everything > > extremely slow). > > I have ALSA working now so will be able to test! Cool! > > > > I'm currently considering releasing with the sound server from two > > > > months ago (leaving the current state in CVS), but I'm not sure how > > > > negatively this would affect Win32. > > > > > > Performance under Win32 should be about the same. If it's polled, it > > > doesn't work too well on this platform. :) > > > > OK, but I don't see how the event server could be integrated cleanly... > > I'm not following, isn't it already? Yes, but going back two months would've destroyed that- still, the solution you suggested in your other mail sounds better. > The idea was to have the sound servers > abstracted far enough so that they could use common functions except in > exceptional cases. The problem under UNIX you mention below indicates that > this could be difficult or largely impossible. I assume you're referring to sending commands to yourself there? Will discuss this below. > But if it is possible, it > would mean that fixes and additions to soundserver.c which contains the > common ss functions would apply and work with both sound servers. That's > what I've been aiming for. It's unfortunate that this doesn't seem to be > working out. Well, not yet, but I'm certain it's doable (see the new prototypes snd_srv_play() and snd_srv_process() in soundserver.h; if snd_srv_play() was implemented with song iterators, it'd provide the separation we need). Those two functions should NEVER use non-standard functionality, then. They will ONLY use functions that are independant from the sound server implementation, or provided by it directly (i.e. no #ifdef'd parts, no 'if (server->is_event_based) foo() else bar();'). If this requirement cannot be followed, the sound server API should be changed. (These are rather absolute statements, and I'm aware of that. Time will tell whether it's possible to do things with these rules). > I managed to work out the threee song pointers when I converted the polled > ss over to use the sound server state struct. [...] Your interpretation of their usage and meaning seems to be correct, as far as I'm able to tell. > > As far as I understood your changes in this part of the code, you made > > the server send a command to itself there- this won't work with the UNIX > > sound server because it's using unidirectional pipes for this; the sound > > server process only has the reader end of those (maybe the specs should > > clarify that this does not have to be supported; I don't think that it'd > > be really helpful to require it). > > I will remember this - can it be changed or do the pipes have to stay > unidirectional? It's possible to implement this with a bidirectional pipe mechanism (socketpair(), which we're already using as a fallback in case pipe() is not implemented (never seen such a beast, but some proprietary OSses with a strapped-on BSD socket implementation might)). However, I don't think that sending piped commands to oneself will make sense, for the following reasons: a) Semantically, sending a command to yourself is the same as a function call, except with more indirection and... b) ...with the evaluation order being undefined (we allow for both immediate events and polled messages ATM, after all). (OK, if this only affects the polled server, we know we'll get delayed evaluation, but still...) (or is it called 'execution order' in imperative languages? Well, I hope you know what I mean...) c) It's harder to trace than a function call d) It's harder to understand than a function call > > You seem to have a function for this, maybe I should've used that > > instead... > > Only because it's helpful for tracing. It'd be cleaner, besides, it would help eliminate code duplication (after all, ending a song because it hit its end and ran out of loops, or because the script requested it to be ended should be treated pretty much the same, so we could avoid code duplication there). llap, Christoph
