islamicnawer.blogg.se - Dante virtual soundcard ad hoc

I would very much prefer a specification for server that does not require that the sample clock functionality is duplicated on the client side. I would object to both these assumptions.

This will only work with servers on the client machine We need some information from the soundcard directly in sclang In an interprocess context, Julian's suggestion is really the only one that makes sense: server connects to audio driver, server gets timing from audio driver, language gets timing from the server. There's no way you can slave that and expect any accuracy. We're talking about interrupts happening 50x, 100x, 200x a second (with a 256 sample hardware buffer, 44100/256 = 172.265). You couldn't have a master timing process and slave both language and server to it, because (as far as I know) slaving a soundcard to another timing source just doesn't work. The soundcard's sample clock must be the master for sample accuracy. If it were me, I wouldn't go that direction. that's probably unrealistic.) It seems to me that it would be somewhat risky to couple the language to the internal server's DSP because you would need two versions of the language's main loop, right? One for internal and one for "normal" use. (Supporting sample accuracy across a network. In theory, we could do something like that for the internal server (which I already mentioned in passing) and then say sample-accuracy works only with the internal server. The separation is implicit in the server-client model, isn't it? The alternative is to integrate the language into the DSP cycles, as SC2 did and ChucK still does, but that would make it architecturally harder to support multiclient or network-distributed applications. Surely having one process in charge of exact scheduling is easier than two processes trying to schedule in tandem? You would still have the problem of drift, but that would open it up to systems where supernova isn't supported. If that's not practical, it would be easier to replicate supernova's -C flag in scsynth. Obviously it would be impossible for a remote server, so we would have to set appropriate expectations. I guess that would be easy for the internal server, and maybe possible for a local server through the shared memory interface.

The server would have to communicate precise information about samples vs time to the language.

So it's not quarkable.Ī true SampleClock is the best solution, but also hard to implement, so it's unlikely to happen unless somebody really, really needs it and that person also understands the internals of SC's schedulers. Clocks run "behind the scenes" - it would be impossible to have a SampleClock without C++ support. The trouble with a SampleClock is, it's a fairly invasive change. I'm pretty sure it never reached a point where it could be submitted as a pull request. I think was involved in some of those discussions (maybe?). I have a vague recollection that somebody forked the SC sources and worked on it, but I don't remember who.

FWIW I did a search yesterday for "SuperCollider SampleClock" but couldn't find it.