regarding the future of pulseaudio output

[Hynek Hanke]

Rui Batista napsal(a):
> Over the past month or so have been posted to or three patches 
> regarding pulseaudio output.

Hello Rui,

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 
ALSA, but
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 
Speech Dispatcher
stream visible to PA. So the user cannot easily set it's PA properties, 
can't control
its volume settings in pavucontrol etc.

The early versions of the old asynchronous PA code also behaved like 
this and
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 
lead to
the sound not being heard. It might and should try to reestablish the 
connection
several times, but eventually the synthesizer module needs to give up, 
so that
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 
minimize
the possibilities of total silence in case one of the components die and 
won't
come back.

> 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 
simpler
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).

With regards,
Hynek