regarding the future of pulseaudio output
hanke at brailcom.org
Wed Jan 6 14:07:27 CET 2010
Rui Batista napsal(a):
> Over the past month or so have been posted to or three patches
> regarding pulseaudio output.
I didn't have a chance to follow your patchers closely (which is luckily
soon going to change), but I'm very happy that a good work is being
done. I totally agree that the old PA code in SpeechD was experimental,
for some reasons didn't work well and needed a rewrite.
Let me post some general comments.
> The pulse-simple (I called it for simplicity) patch works good but, as
> the libao one does, it has some drawbacks I'd like to point out.
> Neither libao or pulse-simple api provide ways to implement the
> set_volume function directly (we can change the samples amplitude but
> that's not so clever)
You are right. We should not change sample amplitude. This is OK in
in a soundserver like PA, this would create a whole set of new problems.
PA would not be receiving what it expects and the whole volume control
mechanism inside PA will become kind of broken.
Is there a reason why the simple API does not have this basic function?
Maybe we should ask Lennart if its not possible to include it, which is
I think the proper solution.
> for each pulse_speak the driver must connect to the server, open a
> stream and play it (libao pulse driver uses the pa_simple routines so
> the limitations are similar I think).
This is an issue for two reasons. It may make things slower (maybe not
much, but still unnecessary).
The more important fact is that this means that there is no persistent
stream visible to PA. So the user cannot easily set it's PA properties,
its volume settings in pavucontrol etc.
The early versions of the old asynchronous PA code also behaved like
we quickly found out it's a major drawback and against PA design.
> On other note the pulse_open function doesn't do any verification to
> see if the server is running...
I think it's important that the audio output reports any errors which
the sound not being heard. It might and should try to reestablish the
several times, but eventually the synthesizer module needs to give up,
Speech Dispatcher knows it's not working and can engage other synthesizer
(or eventually the Dummy audio module, which tries several audio methods
to replay a pre-recorded error message). This is all done so that we
the possibilities of total silence in case one of the components die and
> I'm ready to try to rewrite the assynchrnous code if needed, or doing
> anything I can to improove pulseaudio support.
Sounds great, please do!
I also believe that even with the asynchronous API, the code can be made
and better. However, what you write do not seem to be any principal
problems and it
sound to me like we should still try to see, if we can't achieve what we
need with just
the simple API. We don't really need any asynchronicity in the audio
code (as it's already
running in a dedicated thread anyway).
More information about the Speechd