[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-multimedia
Subject:    Re: aRts in trunk
From:       mETz <mETz81 () web ! de>
Date:       2005-07-30 9:11:47
Message-ID: 200507301111.48006.mETz81 () web ! de
[Download RAW message or body]

On Freitag Juli 29 2005 23:32, Gary Cramblitt wrote:
> By way of feedback, let me tell you of the current state of sound support
> in the KDE Text-to-Speech System (KTTS).  KTTS currently supports 4 audio
> plugins.  aRts is the only one which is fully satisfactory.  Here are the
> problems with the other 3:
>
> 1.  ALSA.  Problems with device contention.  Some users are unable to open
> multiple PCMs.  It appears this is a configuration problem with dmix
> compounded by terrible documentation on the ALSA website (The dmix wiki

Indeed, I had a hard time setting dmix up on my stupid laptop 
onboard-soundcrap. That's really not convincing me that Linux now has got a 
_working_ kernel-level mixing :(

> 2.  aKode.  aKode does not offer a true pause() function.  The net result
> in KTTS is you must let the current sentence finish speaking when
> attempting to pause.  I realize aKode's primary purpose is decoding, not
> playback, but I mention this anyway.  See wish #107135.

That sounds like it could be fixed :)

> 3.  GStreamer.  As of GStreamer 0.8.10, it still can take up to a second
> for sound to stop playing when pausing or stopping.  Versions of GStreamer
> prior to 0.8.7 had major issues playing .wav files.  I still haven't

Exactly, that's why I told some people on irc already that I won't put more 
work into a gstreamer backend for Noatun3. Sure it can play stuff but seeking 
and pause/unpause sounds ugly right now. I'm still having hopes for gst 
1.0...

> GStreamer with the alsa sink also exhibits PCM contention problems;
> probably ALSA config problem again.

Didn't have problems after updating to a more recent gst version, it was buggy 
before though, the gst folks told me to use osssink :)

> I understand that aRts is unsupported, nobody wants to do the maintenance
> (I certainly don't have the expertise or time), and getting rid of it in
> KDE 4 is desirable.  My concern is that I'll be left with no good solution,
> when all is said and done.

The big problem with arts is:
- it's unmaintained, yes, that's a fact
- it has cool features that actually _do_ work already (compared to other 
systems)
- it does have bugs
- BUT these bugs don't affect all users

For me the last point is pretty important, getting artsd running is probably 
nothing for beginners but so far I did get things running on all machines 
that I have touched so it can be made working.
I have streamed artsd output to shoutcast servers for more than 24 hours so 
I'd say artsd can be quite stable.


Now back to the initial question, trunk or 3.5 branch:

I don't care as long as we have one working copy that can be fixed if needed.

What I'm more concerned about: What will happen to the classes in 
kdelibs/arts/? I'm still using them for Noatun3 and they are working pretty 
well except for one grave bug which I want to debug one day (KPlayObject 
crashes pretty often on non-available streams).

Bye, Stefan aka mETz
_______________________________________________
kde-multimedia mailing list
kde-multimedia@kde.org
https://mail.kde.org/mailman/listinfo/kde-multimedia

[prev in list] [next in list] [prev in thread] [next in thread]