>>That's not what i've heard when i've talked to steinberg. but perhaps >>it would be different for "smaller" companies. Heh. Yesterday, I was >>looking at a 1986 issue of Keyboard magazine. It had a small ad for >>"Steinberg Music Software", run by a US importer. > >Again, I have extrapolated my conclusions based on my conversaton with >Sibelius devel team (although I do understand that this is not an audio app >in its true sense), who expressed absolutely no interest in developing >Sibelius for Linux [at the time, at least], as well as base my thoughts on >what I heard from other sources (i.e. discussion boards, such as this one). >If you have heard something different in respect to Steinberg, please do >share the good news with the community :-).
There's no good news to share. My point was that Steinberg's problem with linux is not that there is no single point of information about multimedia issues, as you suggested. They have other, more significant reasons for not actively developing for Linux at this time. >There is, however, one relatively recent development, the so-called E-WDM >drivers released by www.egosys.net company (hw vendor), which supposedly >unify all architectures (ASIO, WDM, Sonar, Giga etc.) into one with >incredible latencies (advertised as neing 1.5 ms for Sonar). I am not sure I don't know any audio h/w that would support such a thing. Should we advertise Linux as supporting 0.75msec latencies when its impossible to demonstrate in use with any existing hardware? Note that these ads *never* specify what they mean by latency. There are at least two definitions, and arguably more. >Absolutely :-). Speaking of which, is JACK currently capable of replacing >arts and esd daemons in its current state? Is this even a part of the >long-term plan? It seems until we get a sound daemon which will be not only >extremely efficient, but also backwards compatible, Linux will suffer of >lack of user-friendliness in that department. JACK doesn't aim to do what esd or artsd do. Its goal is to enable audio interchange *in a low latency environment with perfect sample accurate sync*. artsd is already extremely capable of enabling data sharing between clients, and there would be very little point in writing JACK if it simply stood in for artsd - stefan has done a lot of work already so why duplicate it? the problem is that artsd won't work if you want, say, sub-5msec latencies between clients. To this end, JACK requires that applications that use it must use a different programming model than the existing audio APIs that esd and artsd support. Its theoretically possible to use alsa-lib as a wrapper to communicate with JACK, and I would anticipate that as the main way of connecting "JACK-ignorant" applications into a JACK system, but doing so will lose the low latency and sample accurate sync properties that JACK offers (for that client). This is unavoidable, since the applications do not use the callback-driven model that JACK (and CoreAudio and many others) uses. Its possible that a similar approach might work for clients that can talk to artsd. An LD_PRELOAD hack could be done for OSS API based applications. But frankly, I would view such things as a little pointless. They wouldn't run in sync, so why do it? --p
