Hi!
Erik Jarvi notified me that on gnome-hackers was a discussion about the
future sound-system of gnome. I am the developer of asd, an advanced
sound daemon. the program is designed to be a compatible esound-drop-in
replacement with better flexibility and lower latency. At the momemnt
the daemon works quite well and has most of the features esd had but no
compatibilty to it.
I read a bunch of messages in gnome-hackers and want to advocate for
asd's inclusion in gnome now.
I think I have not to tell you the disadvantages of esound. And in my
eyes artsd is also bad. (it is resource-intensive, it's more a
synthesizer than a simple sound server and it's c++ (isn't that a very
serious problem? i thought Gnome as whole was intended to be GNU
software - the G in gnome means GNU, isn't it? - but GNU software has to
be written in C?)
So i want to describe the advantages of asd and its design:
I started the project first to be able to use two separate sound cards
for simultaneous playback. this is quite complicated task because most
sound cards have slightly different playback speeds. This results in
some strange effects when playback is done without proper
resampling. First i thought of adding these features to esd, but this
wasnt practical because esd has a single-threaded design. playback on
more than one device ist just not possible with that. so i decided to
implement my own sound server with a multi-threaded design and some
other features which i missed in esd. (Up to now asd can't do the
synchronisation of two soundcards yet because resampling is not yet
implemented as I am waiting for some fast resampling routines which
Brian Craft wanted to contribute) the project started a few month ago
and now i have a mostly stable daemon.
the other design goal of asd is low latency. this is a complicated
problem and i have not yet got that working well with asd. asd operates
with audio blocks of fixed size (the size is tunable on runtime) and
block queues for each of the input sources and each of the output
sinks. a client program has full control of its attached queue (it may
be paused, cleared, shortened or whatever), but no control on the output
queues. a multiplexer sits between the two queues and mixes blocks from
several input queues and writes them to several output queues. the
length of the queues can be tuned. Ideally the fragment size of the
underlying device driver should be the same or a multiple of the asd
block size.
so the playback latency (within asd) is the product of the sink queue
length and the block size. i experimented with some very small values
here but i could not get the latency below 100ms (what someone wrote was
the acceptable minimum) without some ugly ticks and pops in playback. i
do not know what generates these but i think they result from crappy
sound drivers as they go away after some time of playback but return on
high cpu usage peaks. currently i am using a block-size of 16k and a
sink queue length of 2 at 44khz/16b/stereo resulting in a latency
between 200 and 300ms but no pops, cracks and ticks. to this value you
have to add the latency of the sounddrivers (configured to use 2
fragments and 4k frag size. i did not check if these got accepted).
for better results i'd need the support of other programmers with more
experience in low-latency sound programming as i do not know much about
it. i only played around with the tunable options of asd and the oss-dsp
and looked how the latency reacts.
i am also thinking of implementing a simple pass-through mode would would
just copy all incoming blocks directly to a sink which would stop
simultaneous audio playback but could be used for some ultra-low-latency
needing application. the resulting latency would just the latency of the
tcp (or unix-) socket and the sound device itself. this mode could be
used by applications like midi synthesizers, games or dvd players which
need to synchronize sound to certain other events. when the users uses
one of these application he certainly does not want to hear the sound
effects of a window manager concurrently. Speech recognition progams
could enable this for having best latency in recording only.
i think ms directsound implements something like that. why not copy a
good idea?
differences to artsd:
o asd does only audio playback and capture. no filtering or synthesizing
o it is written in c (dpendencies are pthreads and glib)
o it is designed for low latency
o it will be able to synchronize playback on several sound cards
o it is relatively small and fast
o maybe more (i do not know arts so well)
differences to esd:
o asd isn't junk
o more flexible design
o not fixed to certain data format
o too many others to listen.
someone on the list argued that asd's design would be to complicated for
the avaerage user with its multiple sinks, sources and multiplexers. i
do not think that this is the fact. asd has some predefined multiplexers
"play0" and "capt0" which will be used as a default when playing back
audio or capturing audio respectively is requested by a
client-program. by default these multiplexers will be created and linked
to /dev/dsp0 via a source and a sink. So without further configuration
asd will behave exactly as esd did. only the power users will exploit
its more complicated features. and the best is: old programs linked to
libesd0 will continue to work as asd will have a compatibly interface.
another nice feature i wan't to implement is a udp-broadcast sink and
source which will broadcast all audio data to the lan. this would make
it possible to link all local machines together and use only one big
pair of boxes.
the code base is not stable yet. i will introduce some big changes soon
as i want to introduce more than 2 channel playback and real
esd compatibility. And many more will come. asd is in heavy development.
personally i would welcome the inclusion of asd in gnome. i did at first
not have this as goal but it would certainly please my ego.
asd is not yet ready for prime time. and i think it won't be soon enough
for gnome2.
i'll implement a sink and a source for artsd eventually, so that asd
uses artsd for playback/capturing. this will increase the compatbility
between kde and gnome but won't be an optimal solution because this
won't have positive influence on the latency.
the idea of having an abstracting library which will just capsule the
calls to esd, asd, artsd, oss or alsa seems to be a very good solution
to me. every user (or every distribution maker) would be able to use
it's own sound server wit no latency drawbacks.
I hope I could make asd tasty to you...
Lennart
BTW: Everyone who wants to join the development of asd is welcome!
(a funny thing is that i'm studying at the same university as stefan
westerfeld does...)
--
name { Lennart Poettering } mail { lennart poettering de }
icq { 11060553 } www { http://www.poettering.de/lennart/ }
loc { hamburg, germany } pgp { 0x1A015CC4 } hack { .phi. }
Attachment:
pgphJ5ysr755E.pgp
Description: PGP signature