ok I retake it back hahahahahaha. I have found having read all this that my doubletalk and speakup don't cause this problem as much when I wanted to play an mp3 file. I only got the alsa modules because I wanted to be able to use my sound card with better functionality than was afforded me with the kernel drivers. and not only that, I wanted to use speak_freely too. <grin> but that's now turned into a port forwarding issue. damn. but any hoo, I apologise. On Wed, 7 Nov 2001, Frank Carmickle wrote: > On Wed, 7 Nov 2001, Shaun Oliver wrote: > > > ok I take that back it was barry that posted about the kernel timing > > issues. > > I was the one who sent the message of correction. And I will restate it > in different terms. Alsa does not live in user space. You insmod the > modules in to your kernel right? If you don't have a second cpu and the > one you have is busy your shit out of luck any way you slice it. It's all > a compromise. You need to hear chars from your synth and at 9600 bod you > get about one char per ms. So how long do you want to have silence in the > speech output while your waiting for the next load of chars? Probably > none. This is why the buffers are set the way they are. So in order to > not have breakups in your audio you have to send more bits to the audio > hardware at the times when speakup isn't hogging the cpu to get the chars > out the port. It's not very difficult to find the right balance. But do > a bunch more disk io and you'll be sitting there for a while. My machine > is very much not interactive when updatedb occurs. > > The reason why alsa is better then the open sound system is that alsa uses > much less cpu load. Thus getting more work done during those times when > speakup isn't hogging the cpu. > > -- Shaun Oliver. "We realize we have a problem with communication. However, we're not going to discuss it with our staff." email: shauno at goanna.net.au ICQ: 76958435
