like "play this wave file". The major remaining drawback >is latency; click on button in app, hear sound 2 seconds later when >scheduler
This is why we have sound servers like jack. Any delay is likely due to not having a fully callback based architecture in the app.
Maybe a better thing to do is rewrite arts/esd library >interfaces to omit the daemons altogether. That way the daemons can go >away, but the existing applications can be trivially migrated.
I've heard that arts is being phased out from kde use in the near future. I'm not sure what might replace it though.
Chris
On Wed, Apr 21, 2004 at 05:41:34PM -0400, chmorgan@charter.net wrote:
like "play this wave file". The major remaining drawback >is latency; click on button in app, hear sound 2 seconds later when >scheduler
This is why we have sound servers like jack. Any delay is likely due to not having a fully callback based architecture in the app.
JACK doesn't provide the full functionality of a high level sound server. There is a reason for that; the functionality does not belong in a streams multiplexer like JACK. Nor does streams multiplexing functionality belong in a high level app. Trying to combine the two is why the sound servers have been such a huge source of frustration for users of the two major free desktop environments.
Maybe a better thing to do is rewrite arts/esd library >interfaces to omit the daemons altogether. That way the daemons can go >away, but the existing applications can be trivially migrated.
I've heard that arts is being phased out from kde use in the near future. I'm not sure what might replace it though.
Do you have a reference for that? aRts is rather full featured compared to the competition. Its only achilles heel is the fact that it has no low latency capability and that it suffers from blocking /dev/dsp like every other high level sound server at the moment.
On Wednesday 21 April 2004 6:29 pm, Ryan Underwood wrote:
On Wed, Apr 21, 2004 at 05:41:34PM -0400, chmorgan@charter.net wrote:
like "play this wave file". The major remaining drawback >is latency; click on button in app, hear sound 2 seconds later when >scheduler
This is why we have sound servers like jack. Any delay is likely due to not having a fully callback based architecture in the app.
JACK doesn't provide the full functionality of a high level sound server. There is a reason for that; the functionality does not belong in a streams multiplexer like JACK. Nor does streams multiplexing functionality belong in a high level app. Trying to combine the two is why the sound servers have been such a huge source of frustration for users of the two major free desktop environments.
The issues with arts and esd are that by their very design they are unsuitable for professional audio use. Its easier to add things to the lower latency design of jack than it is to improve the latency of blocking io apps like arts and esd.
What high level functionality do you speak of besides automatic sample rate conversion? I'd imagine network transparency could even be bolted onto jack if necessary.
Maybe a better thing to do is rewrite arts/esd library >interfaces to omit the daemons altogether. That way the daemons can go >away, but the existing applications can be trivially migrated.
I've heard that arts is being phased out from kde use in the near future. I'm not sure what might replace it though.
Do you have a reference for that? aRts is rather full featured compared to the competition. Its only achilles heel is the fact that it has no low latency capability and that it suffers from blocking /dev/dsp like every other high level sound server at the moment.
I've no reference. Just chatting with some kde guys on freenode about it. Who knows if they were just pulling my leg. Considering that arts-project.org is unmaintained for years at a time its probably closer to truth than not.
Chris
The issues with arts and esd are that by their very design they are unsuitable for professional audio use. Its easier to add things to the lower latency design of jack than it is to improve the latency of blocking io apps like arts and esd.
to reinforce Chris' point: *no* significant linux musical application except Beast has any capability to use either arts, and only a few still use the OSS API, which theoretically would allow for esd (even if it doesn't work in practice).
if the freedesktop people have any intent of avoiding a split between the music world and the "desktop beep" world, JACK is the only viable sound server. if they don't care about such a split, then neither do most of us in the music/pro-audio world.
the ALSA API allows applications to be written so that they are neutral about the kind of device they talk to; its possible to move audio data to JACK, to a dmix device, a hw device and god knows what else via alsa-lib.
IMHO, the choices in front of sane audio developers are:
(1) if sample-synchronous and/or low latency behaviour and/or inter-app routing are important, use the JACK API. no other Linux API will provide these features and no other API is even close to offering them.
(2) otherwise use either (a) PortAudio if platform portability matters (b) alsa-lib if its really just a linux program.
The most important issue is designing applications around a callback model wherever possible. This is still an issue with alsa-lib, and remains an issue with MAS and some other network protocols. There are examples of bridging the unix-derived block-on-{read,write} model with the callback one, but although they work, they are really a band-aid that covers a deeper issue.
Some applications of audio i/o really not require sample-synchronous or low latency behaviour, and are much easier to write using the unix-derived block-on-{read,write} model.
It has been my intent to take these matters up with freedesktop.org, particular since two of its key members, Keith Packard and Jim Gettys, were on the panel that awarded JACK its Open Source Merit Award in January.
What high level functionality do you speak of besides automatic sample rate conversion? I'd imagine network transparency could even be bolted onto jack if necessary.
indeed. JACK is network protocol neutral. jackd itself does not (and will not) implement any network protocols (it doesn't even implement ALSA or OSS - thats handled by a special client), but it would be relatively easy to code an MAS client, or a low-level ethernet (Cobranet) client, or a client that uses 1394 as a transport protocol, or whatever. Just like JACK's other features, this kind of interconnectivity is *designed* to be provided by clients, seamlessly, not by the server.
--p (but you can call me JACK)
On Wed, 21 Apr 2004 21:06:22 -0400, Paul Davis wrote:
if the freedesktop people have any intent of avoiding a split between the music world and the "desktop beep" world, JACK is the only viable sound server. if they don't care about such a split, then neither do most of us in the music/pro-audio world.
Obviously if possible such a split could be avoided, but the ultimatum seems to be: use JACK or there will be compatibility. That's fine, but I thought that JACK was Linux only (as is alsa, for that matter), so we lose the sound-server-as-abstraction-layer properties of esd and arts.
The other issue is - what about X sync? Do you agree with Alan Cox that X has to handle audio as well to make it work? If so that raises some fundamental questions about our audio architecture.
(a) PortAudio if platform portability matters
It does, but I've yet to encounter anybody outside the pro-audio world who's even heard of PortAudio let alone programmed against it for games, desktops, windows emulators etc.
It has been my intent to take these matters up with freedesktop.org, particular since two of its key members, Keith Packard and Jim Gettys, were on the panel that awarded JACK its Open Source Merit Award in January.
indeed. JACK is network protocol neutral. jackd itself does not (and will not) implement any network protocols (it doesn't even implement ALSA or OSS - thats handled by a special client), but it would be relatively easy to code an MAS client, or a low-level ethernet (Cobranet) client, or a client that uses 1394 as a transport protocol, or whatever. Just like JACK's other features, this kind of interconnectivity is *designed* to be provided by clients, seamlessly, not by the server.
Random observation - that location of policy (in clients) sounds a lot like X. Would it be theoretically possible to merge jack with the X server, or am I smoking crazy weed?
thanks -mike
On Wed, 21 Apr 2004 21:06:22 -0400, Paul Davis wrote:
if the freedesktop people have any intent of avoiding a split between the music world and the "desktop beep" world, JACK is the only viable sound server. if they don't care about such a split, then neither do most of us in the music/pro-audio world.
Obviously if possible such a split could be avoided, but the ultimatum seems to be: use JACK or there will be compatibility. That's fine, but I thought that JACK was Linux only (as is alsa, for that matter), so we lose the sound-server-as-abstraction-layer properties of esd and arts.
JACK runs on OS X (and is proving very popular there). It is written in strict ANSI C and attempts to be strictly POSIX compatible. There is an OSS-API driver enabling it to be used on Solaris (at least).
JACK is a *much* higher level of abstraction that artsd or esd. There is no sample format negotiation, in particular. And this is the really hard part. Chris Morgan and I were talking about this privately last night.
The other issue is - what about X sync? Do you agree with Alan Cox that X has to handle audio as well to make it work? If so that raises some fundamental questions about our audio architecture.
Alan doesn't know enough about this :)
Any time you have 2 reference clocks, you have sync problems. It exists even when audio + video are done on the same system with or without X. The clocks have a different notion of what "1 second" is, and so the streams they control drift. Whether you have to correct over a network, or just within a single app, you still have to correct for this. Alternatively, you can choose 1 of the two clocks as the master, or you can allow a 3rd party to control them both.
Audio is not like video for sync+real-time-ness. The human visual system will not notice duplicate video frames, and most of the time it will fail to notice skipped video frames. The auditory system, however, will instantly hear any missed or duplicated audio as a click. This means that the requirements for real-time/callback driven audio are harder to meet and generally need to dominate over video. Unfortunately, video is considered the important item, and so audio ends up taking a back seat.
X could add new event type, "ProcessAudio" which would be driven by the audio clock on the host side. It would a similar model to JACK, but clouded by priority issues alluded to above. Audio has to flow independently of GUI/video stuff; thats why all "real" audio apps do audio in a dedicated thread, and why JACK enforces that design.
Random observation - that location of policy (in clients) sounds a lot like X. Would it be theoretically possible to merge jack with the X server, or am I smoking crazy weed?
Its not unimaginable, no.
--p
On Thu, 2004-04-22 at 14:38 -0400, Paul Davis wrote:
JACK runs on OS X (and is proving very popular there). It is written in strict ANSI C and attempts to be strictly POSIX compatible. There is an OSS-API driver enabling it to be used on Solaris (at least).
Bingo :) OK, so I originally thought that alsa dmix was the best way to get decent desktop mixing and such, maybe it still is (I'm a real newbie to this stuff), but it sounds like there are at least two good solutions in the pipeline.
Perhaps GNOME and KDE could be persuaded to move to JACK after all. The main problem is that I'm not sure what GStreamers support is like, and KDE can't/won't drop arts until kde 4 rolls around.
Random observation - that location of policy (in clients) sounds a lot like X. Would it be theoretically possible to merge jack with the X server, or am I smoking crazy weed?
Its not unimaginable, no.
Now it's actually possible to work with the X team easily, maybe it'd be worth raising this. I think the MAS team would object but oh well ...
thanks -mike
On Thu, 2004-04-22 at 20:12 +0100, Mike Hearn wrote:
On Thu, 2004-04-22 at 14:38 -0400, Paul Davis wrote:
JACK runs on OS X (and is proving very popular there). It is written in strict ANSI C and attempts to be strictly POSIX compatible. There is an OSS-API driver enabling it to be used on Solaris (at least).
Bingo :) OK, so I originally thought that alsa dmix was the best way to get decent desktop mixing and such, maybe it still is (I'm a real newbie to this stuff), but it sounds like there are at least two good solutions in the pipeline.
Perhaps GNOME and KDE could be persuaded to move to JACK after all. The main problem is that I'm not sure what GStreamers support is like, and KDE can't/won't drop arts until kde 4 rolls around.
Gstreamer talks to JACK ok. If you run gstreamer-properties you can tell GNOME that JACK should be the default audio output for gstreamer apps. The problem is that most GNOME apps aren't gstreamer aware atm. Jeff Waugh (GNOME release manager) has spoken about this stuff before. As I understand it (and correct me if I'm wrong here), a move away from esd would require an API change and that's not going to happen until GNOME 3.0 at the earliest.
Another option potentially worth considering is using SDL. I'm not too familiar with it, but it does provide an audio abstraction layer. Being written for games and so forth, it's likely they've designed it to be relatively low-latency. Alas that's all I know about it. Figured it was worth mentioning though.
I had a look at Wine's audio code a while ago with a view to prototyping this. Unfortunately I couldn't figure out enough about how it works to be able to do it. I'd be interested in having another attempt if someone could give me some pointers on getting started.
James.
-
chmorgan＠charter.net -
Chris Morgan -
James Gregory -
Mike Hearn -
Paul Davis -
Ryan Underwood