Re: [Iaxclient-devel] Audio device lock problem - workaround

[Steve K. <st...@st...>]

Emil Stoyanov wrote:

>Hi,
>
> --- Steve Kann <st...@st...> schrieb: 
>  
>
>>I think that you might need more expansive changes
>>than you suggest.   
>>There's probably a lot of error-recovery that's
>>missing from in there..
>>
>>
>>Firstly, this part doesn't seem right at all:
>>
>>========
>>static PortAudioStream *iStream, *oStream, *aStream;
>>
>>+    /* try to close the stream first */
>>+    if (!iStream) {
>>+      err = Pa_CloseStream(iStream); 
>>+    }
>>+
>>
>>=========
>>
>>you're basically explicitly calling
>>Pa_CloseStream(NULL)..
>>
>>    
>>
>
>Right, my first dig into the code ;)
>
>
>  
>
>>It seems this isn't bad, but it's not productive
>>either, if you look at 
>>what Pa_CloseStream does:
>>
>>
>>PaError Pa_CloseStream( PortAudioStream* stream)
>>{
>>    PaError   result;
>>    internalPortAudioStream   *past;
>>
>>    DBUG(("Pa_CloseStream()\n"));
>>    if( stream == NULL ) return paBadStreamPtr;
>>
>>
>>Anyway, I think I figured out the right fix.  If
>>your fix worked, then 
>>this should also, and it won't cause crashes on
>>other people's machines :) :
>>
>>    
>>
>
>Thanks,that makes using the iaxclient a bit more
>relaxing, We can play music and wait for calls ;)
>
>Do you have idea if PortAudio can be used somehow with
>any of the available sound servers? Or we need a
>totally new driver, similar to audio_portaudio? As far
>as I understood, portaudio avoids access through sound
>middleware as that would give additionally latency.
>But is quite comfortable on the other side..
>
>  
>
You could write a new backend for portaudio which supports a sound server.

Or, you can run "esddsp"or artsdsp before iaxclient, and that seemed to 
work last time I used it.

I think that the next version of portaudio should support something 
called "jack"..



-SteveK