Subject: Re: [linux-audio-dev] stats please.
From: Paul Davis (pbd_AT_Op.Net)
Date: Sat Oct 13 2001 - 20:36:33 EEST
>>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
This archive was generated by hypermail 2b28 : Sat Oct 13 2001 - 20:33:21 EEST