trouble with latest git, espeak, and PulseAudio

[Jacob Schmude]

No, I cannot use Dmix. Dmix does not avoid the hardware resampling, it
merely allows mixing. What Dmix will do on this card is attempt to
up-sample the speech to whatever audio is playing at the time, as it
does not allow for multiple sample rates simultaneously on different
channels. This causes anything from tinny-sounding speech (espeak) to
static (festival) and everything in between. It must all be done in
software and mixed *before* sending it to this hardware, or the results
are poor. There's a reason systems like Windows opted for an approach
like this, and even OSS4 adopted this. The OSS4 intel HDA driver has
other problems with this SIS-based chipset however, or I'd just use OSS4
and be done with the problem. It seems to me, rather than worrying about
ditching Pulseaudio, we should try and find out exactly why it is
changing the latency randomly. This is probably a bug in Pulseaudio.
Other than this, I can't say I've had any issues with it at all. It's
not crashed on me at any time. If the latency change is by design rather
than a bug then we need to work with it not against it. Anyone here
familiar enough with Pulseaudio to know which is the case?

On Mon, 2010-03-01 at 21:45 +0200, A wrote:
> If this is from your hardware then probably you can use dmix to avoid
> using the hardware mixing. I'm using alsa's dmix plug-in which is
> configured by default for my sound hardware and I haven't seen any
> problems with it. It's less troublesome than any other audio layer I
> have tried (artd and jackd).
> 
> The dmix plug-in does the mixing in software so hardware should not
> matter. I think plug is used over dmix to do resampling when needed.
> 
> Something like this in your .asoundrc should do the trick for you:
> pcm.!default{
>    type plug
>    slave.pcm dmix
> }
> 
> If not, http://alsa-project.org/main/index.php/Asoundrc#dmix has some
> good examples for configuring dmix. Also if your computer is slower,
> you may wish to increase buffers so you don't hear glitches.
> 
> I don't mind pulse audio or say it should be ditched. I just use
> whatever fits best the task at hand. For my kde I let KDE native apps
> use artsd but all other apps use the default ALSA device (just like
> artsd does) and for recording I'm using jackd on top of the external
> sound card I have.
> 
> btw. with the above suggested asoundrc you may experience some
> problems programs detecting your capture device (for example if you
> are using microphone). If dmix works for you I can try to give you a
> more comprehensive asoundrc that has your capture device detectable.
> 
> On Mon, Mar 1, 2010 at 9:15 PM, Jacob Schmude <j.schmude at gmail.com> wrote:
> > Hi
> > Unfortunately, on this system, I do not have a choice but to use
> > Pulseaudio. To use ALSA directly results in audio artifacts whenever
> > speech is used due to poor hardware resampling in the onboard card.
> > Really, we have to stop saying "just ditch Pulseaudio" and work with it
> > instead. It's not going away, and is sometimes the only thing allowing
> > certain poorly-implemented hardware to work properly in cases where ALSA
> > and OSS4 are not enough on their own. The blanket "ditch Pulseaudio"
> > attitude displayed by a lot of people is worrysome. Pulse is here to
> > stay, to think otherwise is wishful thinking and nowhere near close to
> > reality.
> > Too bad Opensolaris doesn't support enough of the hardware in this
> > system for me to switch over to that, since it is free of all these
> > ridiculous audio layers and conflicts.
> ...

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: 
<http://lists.freebsoft.org/pipermail/speechd/attachments/20100301/dceb4fae/attachment.pgp>