[pulseaudio-discuss] Anyone heard of RoarAudio?

[Colin Guthrie]

'Twas brillig, and Tanu Kaskinen at 06/08/10 08:10 did gyre and gimble:
> On Thu, 2010-08-05 at 12:45 +0100, Colin Guthrie wrote:
>> 'Twas brillig, and Colin Guthrie at 05/08/10 12:16 did gyre and gimble:
>>> It's not really clear to me what it is or what it is trying to do over
>>> and above PulseAudio's capabilities:
>>>
>>> http://roaraudio.keep-cool.org/
>>
>> Having looked a little beyond the marketing fluff, it seems to me to be
>> totally lacking in almost all regard!
> 
> Totally lacking in almost all regard? Using what criteria? To me it
> looks like RoarAudio provides a respectable amount of features.

Well that was perhaps a little harsh in retrospect! In the context I had
in my head it's not too bad but the surface feature set does indeed
sound good. I'll try and rationalise the context in which I was thinking
when I made that remark (which was very much from a technical
implementation perspective rather than features)

 1. The alsa backend is very trivial (some may argue this is a good
thing - personally I don't think it is but hey ho). There is not code to
deal with any kind of independent scheduling, it simply runs as any
other standard alsa client (there are only about 20 or so calls to
snd_*() APIs). Obviously a huge part of PA is it's timer-based
scheduling to leverage the power savings this approach allows.

 2. Related to the above, there is obviously not specific code to deal
with kcontrol abstraction and rationalisation. Users are still stuck
with ALSA level madness and bizarre controls to puzzle out to make the
sound work.

 3. There does not appear to be any kind of enumeration support to
listing available alsa devices. I don't see anything that parses hints
and such like. Perhaps I missed this.

 4. In terms of client-server communications I do not see any mechanism
to share memory meaning that data must be copied across the socket (I've
not looked at this closely so could be wrong), which is obviously not ideal.

 5. There does not appear to be support for bluetooth devices (except
probably via alsa which in turn requires users to edit asound.conf etc.
etc.)



The places where, on the surface - I've not played with the code itself
- it seems to do better than PA is with the integration with streaming
services etc. i.e. pushing out to shoutcast and the like.

Now all of that can be done with PA and some external tools (e.g.
gstreamer) very easily (just record from the monitor source and you're
good) but it it's really not user friendly. There could certainly be
some GUI tools developed for PA+GStreamer that would make this process
much nicer (it's been on my general todo list for a while. Maybe I'll
eventually get around to it).


So that was really what I meant by "totally lacking". The above features
of PA are really some of the key parts of the audio system and one of
the reasons I like PA and the project. It was overly harsh of me to
criticise it in such a way, but I just wanted to target my reply at a
PA-centric audience because without looking more closely at the code
itself, it would be easily to miss some of the fundamental stuff that
the features table as currently presented glosses over.

Col




-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mandriva Linux Contributor [http://www.mandriva.com/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]