discuss the need for linking directly to alsa and the --alsa-volume switch

[williamh]

I would like to discuss pull request #19.
If we are going to do that , shouldn't we link to pcaudiolib instead of
alsa directly since espeak supports pulse, oss and alsa?

[sthibaul]

it doesn't seem that pcaudiolib supports setting the volume level?
(which is the whole point of using alsa in #19)

[williamh]

My concern is that #19 pulls in alsa-specific code on all systems and I'm not sure how that will work if espeak is configured to use oss or pulseaudio.

I'm thinking about doing the volume adjustment through the espeak api (pr incoming).

[sthibaul]

alsa-specific code on all systems and I'm not sure how that will work if espeak is configured to use oss or pulseaudio.

linking-in an additional library is usually not a problem at all. Libraries usually don't do magic things just because they are linked-in.

I'm thinking about doing the volume adjustment through the espeak api (pr incoming).

Does it set the alsa level when espeak is using alsa? That is what we need to be sure that we are able to raise volume to the maximum that the system can achieve.

[sthibaul]

Does it set the alsa level when espeak is using alsa?

It doesn't seem to be so. So that won't achieve what we need.

[williamh]

My thought is --default-volume and --default-rate switches for espeakup that would set the values for espeak to start from and fall back on the hard coded defaults we have now if they aren't set.
The goal is to get espeak to start louder correct?

[sthibaul]

The goal is to get espeak to start louder correct?

The goal is to make espeakup able to speak as loud as the hardware can achieve.

If for whatever reason (bios, driver, whatever) the alsa volume level is e.g. at 50% level at system bootup, and espeakup cannot raise it by itself, the user is screwed, not being able to hear anything with some hardware combinaisons.

[alex19EP]

I can also name at least two problems with pcaudiolib.

sometimes it seems to me that using espeak to communicate with the sound system was a mistake.

[williamh]

It is possible to make espeakup handle all of the sound processing, but I don't see the need to do that since espeak itself can handle more sound backends than we would. It feels like it would be extra work to do something that his already done.

[alex19EP]

It is possible to make espeakup handle all of the sound processing, but I don't see the need to do that since espeak itself can handle more sound backends than we would.

yeah it can, but it does it very badly.

[sthibaul]

yeah it can, but it does it very badly.

Possibly better fix espeak, then?

[alex19EP]

of course this is the best option. Unfortunately my C programming skills are not good enough for that yet.

[sthibaul]

That's an opportunity to work on it ;)

[alex19EP]

exactly. and I do it. but i still prefer c ++.

[williamh]

@alex19EP I tend to agree with @sthibaul , it is better to fix the issues where they exist to make things better for everyone. Fixing sound issues by processing sound ourselves in espeakup wouldn't benefit other espeak users.
If there are issues in espeak's sound processing, it is better to open issues there and work with that team to get them fixed.