PaUnixThread_Terminate: Joining thread ..still waiting

[Peter Lukac]

Hello all,

I have litte problem with portaudio library on my ARM linux device...

I need run more program which use different API at the some times (portaudio,
old OSS , and ALSA) therefore i set dmix plugin for mixing audio.
Every combination with portaudio program make problem

portaudio - OSS
portaudio - ALSA( aplay )
portaudio - portaudio

Sometimes when sound is playing (with "portaudio program") and my CPU is
overload on very little time ( when i run another application which playing
sound) sound stop playing and when i want quit application, application is
"lock" on joining thread. I'm not sure if CPU overload is reason why this
problem occured maybe it is when second application initialize audio or do
something else...

This problem occured on daily snapshot too..
created Tuesday, 04-May-2010 21:37:03 PDT

here is log with enabling debug output:

PA message: Stopping callback
PA message: PaUnixThread_Terminate: Joining thread 1026

I look at source and i found where problem occured.

file: portaudio/src/os/unix/pa_unix_util.c
method: PaError PaUnixThread_Terminate( PaUnixThread* self, int wait, PaError*
exitResult )
line: PA_ENSURE_SYSTEM( pthread_join( self->thread, &pret ), 0 );

btw: 9 line up is nice comment :)
/* TODO: Make join time out */

ok this is only consequence with problem which occured here:

file: portaudio/src/hostapi/alsa/pa_linux_alsa.c
method: static void *CallbackThreadFunc( void *userData )

I don't know how portaudio exactly works but in this method (thread) is call
method:

PA_ENSURE( PaAlsaStream_WaitForFrames( stream, &framesAvail, &xrun ) );

and sometimes never end because loop inside this method never end.

while( pollPlayback || pollCapture )
{
...
}
i suppose this is point where loop should be end

/* check the return status of our pfds */
if( pollCapture )
{
PA_ENSURE( PaAlsaStreamComponent_EndPolling( &self->capture, capturePfds,
&pollCapture, &xrun ) );
}
if( pollPlayback )
{
PA_ENSURE( PaAlsaStreamComponent_EndPolling( &self->playback,
playbackPfds, &pollPlayback, &xrun ) );
}
if( xrun )
{
break;
}

but when ? Can me somebody help what i should be check and found problem?


Some information on my system:

[root at device pjproject]# cat /proc/asound/version
Advanced Linux Sound Architecture Driver Version 1.0.17.

[root at device pjproject]# aplay --version
aplay: version 1.0.14 by Jaroslav Kysela <perex at suse.cz>


1.What implementation are you using? WMME, DirectSound, ASIO, etc.
ALSA
2.What OS are you using? Win98, Mac OS8, Linux, etc.
LINUX it's ARM device
3.What audio device are you using? SoundBlaster Live, MOTU408, etc.

4.Are there any error messages to report?
here is all portaudio log...

***INITIALIZATION***

PA message: before paHostApiInitializers[0].
PA message: BuildDeviceList: Ignoring ALSA plugin device cards of type unknown
PA message: BuildDeviceList: Found plugin front of type unknown
PA message: BuildDeviceList: Found plugin rear of type unknown
PA message: BuildDeviceList: Found plugin center_lfe of type unknown
PA message: BuildDeviceList: Found plugin side of type unknown
PA message: BuildDeviceList: Found plugin surround40 of type unknown
PA message: BuildDeviceList: Found plugin surround41 of type unknown
PA message: BuildDeviceList: Found plugin surround50 of type unknown
PA message: BuildDeviceList: Found plugin surround51 of type unknown
PA message: BuildDeviceList: Found plugin surround71 of type unknown
PA message: BuildDeviceList: Found plugin iec958 of type unknown
PA message: BuildDeviceList: Found plugin spdif of type unknown
PA message: BuildDeviceList: Found plugin dmix of type unknown
PA message: BuildDeviceList: Ignoring ALSA plugin device dsnoop of type
unknown
PA message: BuildDeviceList: Found plugin modem of type unknown
PA message: BuildDeviceList: Found plugin phoneline of type unknown
PA message: BuildDeviceList: Ignoring ALSA plugin device hw of type hw
PA message: BuildDeviceList: Ignoring ALSA plugin device plughw of type plug
PA message: BuildDeviceList: Ignoring ALSA plugin device plug of type plug
PA message: BuildDeviceList: Ignoring ALSA plugin device shm of type shm
PA message: BuildDeviceList: Ignoring ALSA plugin device tee of type file
PA message: BuildDeviceList: Ignoring ALSA plugin device file of type file
PA message: BuildDeviceList: Ignoring ALSA plugin device null of type null
PA message: BuildDeviceList: Found plugin default of type plug
PA message: BuildDeviceList: Found plugin vystup of type dmix
PA message: BuildDeviceList: Found plugin dsp0 of type plug
PA message: Default input device: UCB1400: (hw:0,0)
PA message: Default output device: UCB1400: (hw:0,0)
PA message: FillInDevInfo: Adding device UCB1400: (hw:0,0): 0
PA message: FillInDevInfo: Adding device vystup: 1
PA message: GropeDevice: Limiting number of plugin channels to 128
PA message: FillInDevInfo: Adding device dsp0: 2
PA message: FillInDevInfo: Adding device dmix: 3
PA message: GropeDevice: Limiting number of plugin channels to 128
PA message: Default output device: default
PA message: FillInDevInfo: Adding device default: 4
PA message: BuildDeviceList: Building device list took 0.410387 seconds
PA message: after paHostApiInitializers[0].

***PLAYING SOUND***
PA message: AlsaOpen: Opening device vystup
PA message: PaAlsaStreamComponent_DetermineFramesPerBuffer: The determined
period size (320) is less than minimum (1024)
PA message: PaAlsaStream_Configure: Playback period size: 1024, latency:
0.256000

..now sound is broken
...i want quit application...

PA message: Stopping callback
PA message: PaUnixThread_Terminate: Joining thread 1026

...and waiting..

Advice or hint is welcome :)

thanks







-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://music.columbia.edu/pipermail/portaudio/attachments/20100505/97085009/attachment.html>

[Peter Lukac]

hello again

i made next investigation and add this log

PA_DEBUG(( "result: %d revenrs: %d, count: %d fd: %d \n", rr,
revents,*shouldPoll,pfds->fd ));

to method:
PaAlsaStreamComponent_EndPolling

here is whole method:

static PaError PaAlsaStreamComponent_EndPolling( PaAlsaStreamComponent* self,
struct pollfd* pfds, int* shouldPoll, int* xrun )
{
PaError result = paNoError;
unsigned short revents;

int rr;
ENSURE_( rr = snd_pcm_poll_descriptors_revents( self->pcm, pfds,
self->nfds, &revents ), paUnanticipatedHostError );

PA_DEBUG(( "result: %d revenrs: %d, count: %d fd: %d \n", rr,
revents,*shouldPoll,pfds->fd ));
if( revents != 0 )
{
if( revents & POLLERR )
{
*xrun = 1;
}
else
self->ready = 1;

*shouldPoll = 0;
}

error:
return result;
}


and here are logs:


this is when all works fine:

PA message: result: 0 revenrs: 4, count: 1 fd: 4
PA message: result: 0 revenrs: 4, count: 1 fd: 4
PA message: result: 0 revenrs: 4, count: 1 fd: 4
PA message: result: 0 revenrs: 4, count: 1 fd: 4
PA message: result: 0 revenrs: 4, count: 1 fd: 4
PA message: result: 0 revenrs: 4, count: 1 fd: 4

and... when problem occured:

PA message: result: 0 revenrs: 4, count: 1 fd: 4
PA message: result: 0 revenrs: 4, count: 1 fd: 4
PA message: result: 0 revenrs: 4, count: 1 fd: 4
PA message: result: 0 revenrs: 8, count: 1 fd: 4
PA message: result: 0 revenrs: 4, count: 1 fd: 4
PA message: result: 0 revenrs: 0, count: 1 fd: 4
PA message: result: 0 revenrs: 0, count: 1 fd: 4
PA message: result: 0 revenrs: 0, count: 1 fd: 4
PA message: result: 0 revenrs: 0, count: 1 fd: 4


file destriptor 4 is file:

/dev/snd/timer

some advice?

thanks










-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://music.columbia.edu/pipermail/portaudio/attachments/20100506/a17ee48d/attachment.html>

[Dmitry Kostjuchenko]

Hi Peter!

Seems like poll() is returning POLLERR and then of course the connection to a device must be closed. And I
guess re-opened. I've never worked inside Alsa PA's implementation but poll() is a generic event collection
mechanisms so I can make some assumptions.

POLLERR 0x0008
POLLOUT 0x0004

POLLOUT I guess is returned when device is ready to be written. And according your log after some processing FD-
4 sends POLLERR notifier and disconnects then.

If XRUN variable is set PaAlsaStream_HandleXrun handler shall cope with problem. Could you put printf there as
well? Especially inside if( snd_pcm_status_get_state( st ) == SND_PCM_STATE_XRUN ) and outside of it. I
suspect PaAlsaStream_HandleXrun fails to recover, for example if SND_PCM_STATE_XRUN is not set.

Probably the best solution would be a reconnection to a device. The opened question still is why suddenly poll()
fails. This might be a root of the problem which shall be investigated.

Best regards,
Dmitry.

Post by Peter Lukac
hello again
i made next investigation and add this log
PA_DEBUG(( "result: %d revenrs: %d, count: %d fd: %d \n", rr,
revents,*shouldPoll,pfds->fd ));
PaAlsaStreamComponent_EndPolling
static PaError PaAlsaStreamComponent_EndPolling( PaAlsaStreamComponent* self, struct pollfd* pfds, int*

shouldPoll, int* xrun )

Post by Peter Lukac
{
PaError result = paNoError;
unsigned short revents;
int rr;
ENSURE_( rr = snd_pcm_poll_descriptors_revents( self->pcm, pfds,
self->nfds, &revents ), paUnanticipatedHostError );
PA_DEBUG(( "result: %d revenrs: %d, count: %d fd: %d \n", rr,
revents,*shouldPoll,pfds->fd ));
if( revents != 0 )
{
if( revents & POLLERR )
{
*xrun = 1;
}
else
self->ready = 1;
*shouldPoll = 0;
}
return result;
}
PA message: result: 0 revenrs: 4, count: 1 fd: 4
PA message: result: 0 revenrs: 4, count: 1 fd: 4
PA message: result: 0 revenrs: 4, count: 1 fd: 4
PA message: result: 0 revenrs: 4, count: 1 fd: 4
PA message: result: 0 revenrs: 4, count: 1 fd: 4
PA message: result: 0 revenrs: 4, count: 1 fd: 4
PA message: result: 0 revenrs: 4, count: 1 fd: 4
PA message: result: 0 revenrs: 4, count: 1 fd: 4
PA message: result: 0 revenrs: 4, count: 1 fd: 4
PA message: result: 0 revenrs: 8, count: 1 fd: 4
PA message: result: 0 revenrs: 4, count: 1 fd: 4
PA message: result: 0 revenrs: 0, count: 1 fd: 4
PA message: result: 0 revenrs: 0, count: 1 fd: 4
PA message: result: 0 revenrs: 0, count: 1 fd: 4
PA message: result: 0 revenrs: 0, count: 1 fd: 4
/dev/snd/timer
some advice?
thanks

iAuxSoft
------------------
[www.iauxsoft.com]

[Peter Lukac]

Hello Dmitry,
Thanks for reply. I think i found problem. As you write it's XRUN problem.
When CPU is overload and underflow occured then POLLERR is return from
method:
snd_pcm_poll_descriptors_revents()

Then PA try recover device in method:
PaAlsaStream_HandleXrun()

but without success because timer is not recover (is not running) and method
snd_pcm_poll_descriptors_revents()

still return 0 in parameter "revents".
My sollution is call method
snd_pcm_start()

after method:
snd_pcm_recover();

for playback and capture device because in capture device this problem occured
too.

here is my code for PaAlsaStream_HandleXrun() method:


static PaError PaAlsaStream_HandleXrun( PaAlsaStream *self )
{
PaError result = paNoError;
snd_pcm_status_t *st;
PaTime now = PaUtil_GetTime();
snd_timestamp_t t;
int errplayback = 0, errcapture = 0;

snd_pcm_status_alloca( &st );

if( self->playback.pcm )
{
snd_pcm_status( self->playback.pcm, st );
if( snd_pcm_status_get_state( st ) == SND_PCM_STATE_XRUN )
{
snd_pcm_status_get_trigger_tstamp( st, &t );
self->underrun = now * 1000 - ((PaTime) t.tv_sec * 1000 + (PaTime)
t.tv_usec / 1000);
errplayback = snd_pcm_recover( self->playback.pcm, -EPIPE, 0 );
//****************************************
//HERE IS CALL FOR START TIMER
//****************************************
ENSURE_( snd_pcm_start( self->playback.pcm ),
paUnanticipatedHostError );
}
}
if( self->capture.pcm )
{
snd_pcm_status( self->capture.pcm, st );
if( snd_pcm_status_get_state( st ) == SND_PCM_STATE_XRUN )
{
snd_pcm_status_get_trigger_tstamp( st, &t );
self->overrun = now * 1000 - ((PaTime) t.tv_sec * 1000 + (PaTime)
t.tv_usec / 1000);
errcapture = snd_pcm_recover( self->capture.pcm, -EPIPE, 0 );
//****************************************
//HERE IS CALL FOR START TIMER
//****************************************
ENSURE_( snd_pcm_start( self->capture.pcm ),
paUnanticipatedHostError );
}
}

if( errplayback || errcapture )
PA_ENSURE( AlsaRestart( self ) );

end:
return result;
error:
goto end;
}

I think this is not clean solution because this "fix" work only with DMIX
plugin (maybe with some other ). When this problem occured on pure device (not
on virtual dmix device) timer restart fail..
If somebody know how fix this problem, can do it?..I think it's only "timer
restart" problem and my knowledge about ALSA and PA library are poor.

This problem occured on PC too...simulation is easy: just overload CPU when
playing sound. But for more easy simulation just add usleep(50000) method.
before


/* check the return status of our pfds */
if( pollCapture )
{
PA_ENSURE( PaAlsaStreamComponent_EndPolling( &self->capture, capturePfds,
&pollCapture, &xrun ) );
}
if( pollPlayback )
{
PA_ENSURE( PaAlsaStreamComponent_EndPolling( &self->playback,
playbackPfds, &pollPlayback, &xrun ) );
}

in method:
PaAlsaStream_WaitForFrames()

Maybe this is not exactly what underflow do, but
"PaUnixThread_Terminate: Joining thread " occured.

regards

Post by Dmitry Kostjuchenko
Hi Peter!
Seems like poll() is returning POLLERR and then of course the connection
to a device must be closed. And I guess re-opened. I've never worked inside
Alsa PA's implementation but poll() is a generic event collection
mechanisms so I can make some assumptions.
POLLERR 0x0008
POLLOUT 0x0004
POLLOUT I guess is returned when device is ready to be written. And
according your log after some processing FD- 4 sends POLLERR notifier and
disconnects then.
If XRUN variable is set PaAlsaStream_HandleXrun handler shall cope with
problem. Could you put printf there as well? Especially inside if(
snd_pcm_status_get_state( st ) == SND_PCM_STATE_XRUN ) and outside of it. I
suspect PaAlsaStream_HandleXrun fails to recover, for example if
SND_PCM_STATE_XRUN is not set.
Probably the best solution would be a reconnection to a device. The opened
question still is why suddenly poll() fails. This might be a root of the
problem which shall be investigated.
Best regards,
Dmitry.

Post by Peter Lukac
hello again
i made next investigation and add this log
PA_DEBUG(( "result: %d revenrs: %d, count: %d fd: %d \n", rr,
revents,*shouldPoll,pfds->fd ));
PaAlsaStreamComponent_EndPolling
static PaError PaAlsaStreamComponent_EndPolling( PaAlsaStreamComponent*
self, struct pollfd* pfds, int*

shouldPoll, int* xrun )

Post by Peter Lukac
{
PaError result = paNoError;
unsigned short revents;
int rr;
ENSURE_( rr = snd_pcm_poll_descriptors_revents( self->pcm, pfds,
self->nfds, &revents ), paUnanticipatedHostError );
PA_DEBUG(( "result: %d revenrs: %d, count: %d fd: %d \n", rr,
revents,*shouldPoll,pfds->fd ));
if( revents != 0 )
{
if( revents & POLLERR )
{
*xrun = 1;
}
else
self->ready = 1;
*shouldPoll = 0;
}
return result;
}
PA message: result: 0 revenrs: 4, count: 1 fd: 4
PA message: result: 0 revenrs: 4, count: 1 fd: 4
PA message: result: 0 revenrs: 4, count: 1 fd: 4
PA message: result: 0 revenrs: 4, count: 1 fd: 4
PA message: result: 0 revenrs: 4, count: 1 fd: 4
PA message: result: 0 revenrs: 4, count: 1 fd: 4
PA message: result: 0 revenrs: 4, count: 1 fd: 4
PA message: result: 0 revenrs: 4, count: 1 fd: 4
PA message: result: 0 revenrs: 4, count: 1 fd: 4
PA message: result: 0 revenrs: 8, count: 1 fd: 4
PA message: result: 0 revenrs: 4, count: 1 fd: 4
PA message: result: 0 revenrs: 0, count: 1 fd: 4
PA message: result: 0 revenrs: 0, count: 1 fd: 4
PA message: result: 0 revenrs: 0, count: 1 fd: 4
PA message: result: 0 revenrs: 0, count: 1 fd: 4
/dev/snd/timer
some advice?
thanks

iAuxSoft
------------------
[www.iauxsoft.com]
_______________________________________________
Portaudio mailing list
Portaudio at music.columbia.edu
http://music.columbia.edu/mailman/listinfo/portaudio

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://music.columbia.edu/pipermail/portaudio/attachments/20100512/b0cbb70e/attachment.html>

[Peter Lukac]

and one more information:
when timer is restarting on "pure device" (not dmix device) sound stop
playing. But when application is quiting i get logs:

Stopping callback
PaUnixThread_Terminate: Joining thread 3076
Callback thread returned: -9999

and here is asound.conf with dmix plugin if somebody want:

pcm.!default {
type plug
slave.pcm "output"
}

pcm.output {
type dmix
ipc_key 1024
slave {
pcm "hw:0,0"
channels 2
rate 44100
format S16_LE
}
}

pcm.dsp0 {
type plug
slave.pcm "output"
}

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://music.columbia.edu/pipermail/portaudio/attachments/20100512/865b8bbe/attachment.html>

[Dmitry Kostjuchenko]

Hi Peter,

Good that the reason is found out and simulation of the behavior is possible! Although, I am confused about clean
resolving as well. There are several way how to react on such situation:

- Recover timer (as you kindly proposed and tested), if it suceeds, continue stream operation; If it fails:
[1] stop stream, and let application working with it to cope with restarting and etc,
[2] recover stream inside PA.

I am not Alsa specialist as well but suspect that hardware device gets fully disconnected unlike software mixer and
not sure that [2] can be cleanly done, although may be it worth a try.

I looked up quickly ALSA docs (http://www.suse.de/~mana/alsa090_howto.html) and found the following:
"
After the PCM playback is started, we have to make sure that our application sends enough data to the soundcard
buffer. Otherwise, a buffer underrun will occur. After such an underrun has occured, snd_pcm_prepare should be
called.
"
Could you please add a call to 'snd_pcm_prepare' near the place were you restore timer (or after it failed) and
check how all works?!

Best regards,
Dmitry.

Post by Peter Lukac
Hello Dmitry,
Thanks for reply. I think i found problem. As you write it's XRUN problem.
When CPU is overload and underflow occured then POLLERR is return from
snd_pcm_poll_descriptors_revents()
PaAlsaStream_HandleXrun()
but without success because timer is not recover (is not running) and method
snd_pcm_poll_descriptors_revents()
still return 0 in parameter "revents".
My sollution is call method
snd_pcm_start()
snd_pcm_recover();
for playback and capture device because in capture device this problem occured too.
static PaError PaAlsaStream_HandleXrun( PaAlsaStream *self )
{
PaError result = paNoError;
snd_pcm_status_t *st;
PaTime now = PaUtil_GetTime();
snd_timestamp_t t;
int errplayback = 0, errcapture = 0;
snd_pcm_status_alloca( &st );
if( self->playback.pcm )
{
snd_pcm_status( self->playback.pcm, st );
if( snd_pcm_status_get_state( st ) == SND_PCM_STATE_XRUN )
{
snd_pcm_status_get_trigger_tstamp( st, &t );
self->underrun = now * 1000 - ((PaTime) t.tv_sec * 1000 + (PaTime) t.tv_usec / 1000);
errplayback = snd_pcm_recover( self->playback.pcm, -EPIPE, 0 );
//****************************************
//HERE IS CALL FOR START TIMER
//****************************************
ENSURE_( snd_pcm_start( self->playback.pcm ), paUnanticipatedHostError );
}
}
if( self->capture.pcm )
{
snd_pcm_status( self->capture.pcm, st );
if( snd_pcm_status_get_state( st ) == SND_PCM_STATE_XRUN )
{
snd_pcm_status_get_trigger_tstamp( st, &t );
self->overrun = now * 1000 - ((PaTime) t.tv_sec * 1000 + (PaTime) t.tv_usec / 1000);
errcapture = snd_pcm_recover( self->capture.pcm, -EPIPE, 0 );
//****************************************
//HERE IS CALL FOR START TIMER
//****************************************
ENSURE_( snd_pcm_start( self->capture.pcm ), paUnanticipatedHostError );
}
}
if( errplayback || errcapture )
PA_ENSURE( AlsaRestart( self ) );
return result;
goto end;
}
I think this is not clean solution because this "fix" work only with DMIX plugin (maybe with some other ). When

this problem occured on pure device (not on virtual dmix device) timer restart fail..

Post by Peter Lukac
If somebody know how fix this problem, can do it?..I think it's only "timer restart" problem and my knowledge

about ALSA and PA library are poor.

Post by Peter Lukac
This problem occured on PC too...simulation is easy: just overload CPU when
playing sound. But for more easy simulation just add usleep(50000) method. before
/* check the return status of our pfds */
if( pollCapture )
{
PA_ENSURE( PaAlsaStreamComponent_EndPolling( &self->capture, capturePfds, &pollCapture, &xrun ) );
}
if( pollPlayback )
{
PA_ENSURE( PaAlsaStreamComponent_EndPolling( &self->playback, playbackPfds, &pollPlayback, &xrun ) );
}
PaAlsaStream_WaitForFrames()
Maybe this is not exactly what underflow do, but
"PaUnixThread_Terminate: Joining thread " occured.
regards

Post by Dmitry Kostjuchenko
Hi Peter!
Seems like poll() is returning POLLERR and then of course the connection
to a device must be closed. And I guess re-opened. I've never worked inside
Alsa PA's implementation but poll() is a generic event collection
mechanisms so I can make some assumptions.
POLLERR 0x0008
POLLOUT 0x0004
POLLOUT I guess is returned when device is ready to be written. And
according your log after some processing FD- 4 sends POLLERR notifier and
disconnects then.
If XRUN variable is set PaAlsaStream_HandleXrun handler shall cope with
problem. Could you put printf there as well? Especially inside if(
snd_pcm_status_get_state( st ) == SND_PCM_STATE_XRUN ) and outside of it. I
suspect PaAlsaStream_HandleXrun fails to recover, for example if
SND_PCM_STATE_XRUN is not set.
Probably the best solution would be a reconnection to a device. The opened
question still is why suddenly poll() fails. This might be a root of the
problem which shall be investigated.
Best regards,
Dmitry.

Post by Peter Lukac
hello again
i made next investigation and add this log
PA_DEBUG(( "result: %d revenrs: %d, count: %d fd: %d \n", rr,
revents,*shouldPoll,pfds->fd ));
PaAlsaStreamComponent_EndPolling
static PaError PaAlsaStreamComponent_EndPolling( PaAlsaStreamComponent*
self, struct pollfd* pfds, int*

shouldPoll, int* xrun )

Post by Peter Lukac
{
PaError result = paNoError;
unsigned short revents;
int rr;
ENSURE_( rr = snd_pcm_poll_descriptors_revents( self->pcm, pfds,
self->nfds, &revents ), paUnanticipatedHostError );
PA_DEBUG(( "result: %d revenrs: %d, count: %d fd: %d \n", rr,
revents,*shouldPoll,pfds->fd ));
if( revents != 0 )
{
if( revents & POLLERR )
{
*xrun = 1;
}
else
self->ready = 1;
*shouldPoll = 0;
}
return result;
}
PA message: result: 0 revenrs: 4, count: 1 fd: 4
PA message: result: 0 revenrs: 4, count: 1 fd: 4
PA message: result: 0 revenrs: 4, count: 1 fd: 4
PA message: result: 0 revenrs: 4, count: 1 fd: 4
PA message: result: 0 revenrs: 4, count: 1 fd: 4
PA message: result: 0 revenrs: 4, count: 1 fd: 4
PA message: result: 0 revenrs: 4, count: 1 fd: 4
PA message: result: 0 revenrs: 4, count: 1 fd: 4
PA message: result: 0 revenrs: 4, count: 1 fd: 4
PA message: result: 0 revenrs: 8, count: 1 fd: 4
PA message: result: 0 revenrs: 4, count: 1 fd: 4
PA message: result: 0 revenrs: 0, count: 1 fd: 4
PA message: result: 0 revenrs: 0, count: 1 fd: 4
PA message: result: 0 revenrs: 0, count: 1 fd: 4
PA message: result: 0 revenrs: 0, count: 1 fd: 4
/dev/snd/timer
some advice?
thanks

iAuxSoft
------------------
[www.iauxsoft.com]
_______________________________________________
Portaudio mailing list
Portaudio at music.columbia.edu
http://music.columbia.edu/mailman/listinfo/portaudio

iAuxSoft
------------------
[www.iauxsoft.com]

[Peter Lukac]

Hello Dmitry,

Bad news. Call "snd_pcm_prepare" not works and will not works because
in method "snd_pcm_recover" is calling method "snd_pcm_prepare"

int snd_pcm_recover(snd_pcm_t *pcm, int err, int silent)
{
if (err > 0)
err = -err;
if (err == -EINTR) /* nothing to do, continue */
return 0;
if (err == -EPIPE) {
const char *s;
if (snd_pcm_stream(pcm) == SND_PCM_STREAM_PLAYBACK)
s = "underrun";
else
s = "overrun";
if (!silent)
SNDERR("%s occured", s);
err = snd_pcm_prepare(pcm);
if (err < 0) {
SNDERR("cannot recovery from %s, prepare failed: %s",
s, snd_strerror(err));
return err;
}
return 0;
}
if (err == -ESTRPIPE) {
while ((err = snd_pcm_resume(pcm)) == -EAGAIN)
/* wait until suspend flag is released */
poll(NULL, 0, 1000);
if (err < 0) {
err = snd_pcm_prepare(pcm);
if (err < 0) {
SNDERR("cannot recovery from suspend, prepare
failed: %s", snd_strerror(err));
return err;
}
}
return 0;
}
return err;
}

When i'm try sample programs in alsalib...they works

http://www.alsa-project.org/alsa-doc/alsa-lib/_2test_2pcm__min_8c-
example.html#a3

http://www.alsa-project.org/alsa-doc/alsa-lib/_2test_2pcm_8c-example.html#a38

I think this is probem with wrong using alsalib in PA ..maybe somebody who
wrote this part of code should be know where problem is.

...thanks for you time

regards

Post by Dmitry Kostjuchenko
Hi Peter,
Good that the reason is found out and simulation of the behavior is
possible! Although, I am confused about clean resolving as well. There are
- Recover timer (as you kindly proposed and tested), if it suceeds,
continue stream operation; If it fails: [1] stop stream, and let
application working with it to cope with restarting and etc, [2] recover
stream inside PA.
I am not Alsa specialist as well but suspect that hardware device gets
fully disconnected unlike software mixer and not sure that [2] can be
cleanly done, although may be it worth a try.
I looked up quickly ALSA docs (http://www.suse.de/~mana/alsa090_howto.html)
and found the following: "
After the PCM playback is started, we have to make sure that our
application sends enough data to the soundcard buffer. Otherwise, a buffer
underrun will occur. After such an underrun has occured, snd_pcm_prepare
should be called.
"
Could you please add a call to 'snd_pcm_prepare' near the place were you
restore timer (or after it failed) and check how all works?!
Best regards,
Dmitry.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://music.columbia.edu/pipermail/portaudio/attachments/20100517/f5ee9e35/attachment-0001.html>

[Albert Santoni]

Hi Peter,

This problem has been affecting Mixxx on Linux with ALSA for quite
some time, and it looks like you're the first person to make some
headway on the problem. (We experience both the deadlock on xruns and
the thread join timeout at exit.)

The only helpful thing I can add to this discussion is that we've
found that the problem start in r1412. From the SVN log:

r1412 | aknudsen | 2009-05-24 09:54:22 -0700 (Sun, 24 May 2009) | 2 lines

Apply Kevin Kofler's non-mmap patch


If you look at the diff between r1411 and r1412, it might help you
figure out how to recover for pure devices. We never had any problems
recovering from xruns with direct ALSA devices (eg. hw:0,0) before
that patch...

Thanks,
Albert

Post by Peter Lukac
Hello Dmitry,
Bad news. Call "snd_pcm_prepare" not works and will not works because
in method "snd_pcm_recover" is calling method "snd_pcm_prepare"
int snd_pcm_recover(snd_pcm_t *pcm, int err, int silent)
{
if (err > 0)
err = -err;
if (err == -EINTR) /* nothing to do, continue */
return 0;
if (err == -EPIPE) {
const char *s;
if (snd_pcm_stream(pcm) == SND_PCM_STREAM_PLAYBACK)
s = "underrun";
else
s = "overrun";
if (!silent)
SNDERR("%s occured", s);
err = snd_pcm_prepare(pcm);
if (err < 0) {
SNDERR("cannot recovery from %s, prepare failed: %s",
s, snd_strerror(err));
return err;
}
return 0;
}
if (err == -ESTRPIPE) {
while ((err = snd_pcm_resume(pcm)) == -EAGAIN)
/* wait until suspend flag is released */
poll(NULL, 0, 1000);
if (err < 0) {
err = snd_pcm_prepare(pcm);
if (err < 0) {
SNDERR("cannot recovery from suspend, prepare
failed: %s", snd_strerror(err));
return err;
}
}
return 0;
}
return err;
}
When i'm try sample programs in alsalib...they works
http://www.alsa-project.org/alsa-doc/alsa-lib/_2test_2pcm__min_8c-
example.html#a3
http://www.alsa-project.org/alsa-doc/alsa-lib/_2test_2pcm_8c-example.html#a38
I think this is probem with wrong using alsalib in PA ..maybe somebody who
wrote this part of code should be know where problem is.
...thanks for you time
regards

Post by Dmitry Kostjuchenko
Hi Peter,
Good that the reason is found out and simulation of the behavior is
possible! Although, I am confused about clean resolving as well. There are
- Recover timer (as you kindly proposed and tested), if it suceeds,
continue stream operation; If it fails: [1] stop stream, and let
application working with it to cope with restarting and etc, [2] recover
stream inside PA.
I am not Alsa specialist as well but suspect that hardware device gets
fully disconnected unlike software mixer and not sure that [2] can be
cleanly done, although may be it worth a try.
I looked up quickly ALSA docs
(http://www.suse.de/~mana/alsa090_howto.html)
and found the following: "
After the PCM playback is started, we have to make sure that our
application sends enough data to the soundcard buffer. Otherwise, a buffer
underrun will occur. After such an underrun has occured, snd_pcm_prepare
should be called.
"
Could you please add a call to 'snd_pcm_prepare' near the place were you
restore timer (or after it failed) and check how all works?!
Best regards,
Dmitry.

_______________________________________________
Portaudio mailing list
Portaudio at music.columbia.edu
http://music.columbia.edu/mailman/listinfo/portaudio

[Dmitry Kostjuchenko]

Hi Albert,

Your pick to a revision # is very useful of course, at least we know where the bug was born. I analysed the revision,
it allows to use non-MMAPed device. I made several changes to PA's ALSA implementation but have no ability to
test it under Linux now and if you have ability to simulate xrun it would be great if you could compile and test.

As this is a raw try I do not commit a patch to PA SVN but would like to give a separate file for a trial first:
http://rapidshare.com/files/392042661/pa_linux_alsa.zip.html

I will also e-mail it to your e-mail directly.

Best regards,
Dmitry.
?

Post by Dmitry Kostjuchenko
Hi Peter,
This problem has been affecting Mixxx on Linux with ALSA for quite
some time, and it looks like you're the first person to make some
headway on the problem. (We experience both the deadlock on xruns and
the thread join timeout at exit.)
The only helpful thing I can add to this discussion is that we've
r1412 | aknudsen | 2009-05-24 09:54:22 -0700 (Sun, 24 May 2009) | 2 lines
Apply Kevin Kofler's non-mmap patch
If you look at the diff between r1411 and r1412, it might help you
figure out how to recover for pure devices. We never had any problems
recovering from xruns with direct ALSA devices (eg. hw:0,0) before
that patch...
Thanks,
Albert

Post by Peter Lukac
Hello Dmitry,
Bad news. Call "snd_pcm_prepare" not works and will not works because
in method "snd_pcm_recover" is calling method "snd_pcm_prepare"
int snd_pcm_recover(snd_pcm_t *pcm, int err, int silent)
{
if (err > 0)
err = -err;
if (err == -EINTR) /* nothing to do, continue */
return 0;
if (err == -EPIPE) {
const char *s;
if (snd_pcm_stream(pcm) == SND_PCM_STREAM_PLAYBACK)
s = "underrun";
else
s = "overrun";
if (!silent)
SNDERR("%s occured", s);
err = snd_pcm_prepare(pcm);
if (err < 0) {
SNDERR("cannot recovery from %s, prepare failed: %s",
s, snd_strerror(err));
return err;
}
return 0;
}
if (err == -ESTRPIPE) {
while ((err = snd_pcm_resume(pcm)) == -EAGAIN)
/* wait until suspend flag is released */
poll(NULL, 0, 1000);
if (err < 0) {
err = snd_pcm_prepare(pcm);
if (err < 0) {
SNDERR("cannot recovery from suspend, prepare
failed: %s", snd_strerror(err));
return err;
}
}
return 0;
}
return err;
}
When i'm try sample programs in alsalib...they works
http://www.alsa-project.org/alsa-doc/alsa-lib/_2test_2pcm__min_8c-
example.html#a3
http://www.alsa-project.org/alsa-doc/alsa-lib/_2test_2pcm_8c-example.html#a38
I think this is probem with wrong using alsalib in PA ..maybe somebody who
wrote this part of code should be know where problem is.
...thanks for you time
regards

Post by Dmitry Kostjuchenko
Hi Peter,
Good that the reason is found out and simulation of the behavior is
possible! Although, I am confused about clean resolving as well. There are
- Recover timer (as you kindly proposed and tested), if it suceeds,
continue stream operation; If it fails: [1] stop stream, and let
application working with it to cope with restarting and etc, [2] recover
stream inside PA.
I am not Alsa specialist as well but suspect that hardware device gets
fully disconnected unlike software mixer and not sure that [2] can be
cleanly done, although may be it worth a try.
I looked up quickly ALSA docs
(http://www.suse.de/~mana/alsa090_howto.html)
and found the following: "
After the PCM playback is started, we have to make sure that our
application sends enough data to the soundcard buffer. Otherwise, a buffer
underrun will occur. After such an underrun has occured, snd_pcm_prepare
should be called.
"
Could you please add a call to 'snd_pcm_prepare' near the place were you
restore timer (or after it failed) and check how all works?!
Best regards,
Dmitry.

_______________________________________________
Portaudio mailing list
Portaudio at music.columbia.edu
http://music.columbia.edu/mailman/listinfo/portaudio

_______________________________________________
Portaudio mailing list
Portaudio at music.columbia.edu

http://music.columbia.edu/mailman/listinfo/portaudio


iAuxSoft
------------------
[www.iauxsoft.com]

[RJ Ryan]

Hi Dimitry,

I have tried your patch and it does not resolve the problem for me, though
as you'll see I am not exactly experiencing the same hang as you. In my
case, I can easily reproduce the hang on joining threads by running the
patest_sine program in conjunction with pasuspender. I am on Ubuntu Lucid
10.04 using portaudio trunk. I run patest_sine as:

$ pasuspender bin/patest_sine

The 'default' ALSA device is chosen, which is a pulse device (according to
the PA debug output). The hang is likely because the default device is a
pulse device, which has been suspended via pasuspender. I have threaded many
PA_DEBUG's throughout the code, similar to yours.

In my case, PaAlsaStream_HandleXrun handler is never run. Correspondingly,
the revents flag never takes on a value of 8 (POLLERR). It is 4 (POLLOUT)
once, and then 0 for the rest of time.

Here is some debug output I have collected:
...
BuildDeviceList: Found plugin default of type pulse
BuildDeviceList: Found plugin pulse of type pulse
...
Play for 5 seconds.
PaAlsaStream_WaitForFrames Begin
About to poll()
poll() wokeup >=0 result: 1
snd_pcm_state is 2
result: 1 revenrs: 4, count: 1 fd: 3
PaAlsaStream_WaitForFrames ended

PaAlsaStreamComponent_EndProcessing numFrames 2048
begin writei
end writei, res: 2048
PaAlsaStreamComponent_EndProcessing numFrames 2048
begin writei
end writei, res: 2048
PaAlsaStreamComponent_EndProcessing numFrames 2048
begin writei
end writei, res: 2048
PaAlsaStream_WaitForFrames
About to poll()
poll() wokeup >=0 result: 0
snd_pcm_state is 3
result: 0 revenrs: 0, count: 1 fd: 3
About to poll()
poll() wokeup >=0 result: 0
snd_pcm_state is 3
... repeat forever

As you can see, PA gets the POLLOUT revent, and writes 3x2048 to the device.

From then on poll() just times out repeatedly. As I said, this is probably

because I have run pasuspender to suspend the pulse device, and patest_sine
picks the 'default' device which is a pulse device. Regardless, portaudio
should not fail to exit in this case because this results in nasty hangs. Is
this a situation that calls for a timeout in joining the thread? Is there
another saner way to determine that the device is hung and not responding?

Best regards,
RJ Ryan

Message: 1
Date: Thu, 27 May 2010 12:07:10 +0300
From: Dmitry Kostjuchenko <dmitrykos at inbox.lv>
To: Portaudio Mailing List <portaudio at music.columbia.edu>
Subject: Re: [Portaudio] PaUnixThread_Terminate: Joining thread
..still waiting
Message-ID: <1274951230.4bfe363ed3ced at mail.inbox.lv>
Content-Type: text/plain; charset=UTF-8
Hi Albert,
Your pick to a revision # is very useful of course, at least we know where
the bug was born. I analysed the revision,
it allows to use non-MMAPed device. I made several changes to PA's ALSA
implementation but have no ability to
test it under Linux now and if you have ability to simulate xrun it would
be great if you could compile and test.
As this is a raw try I do not commit a patch to PA SVN but would like to
http://rapidshare.com/files/392042661/pa_linux_alsa.zip.html
I will also e-mail it to your e-mail directly.
Best regards,
Dmitry.
?

Post by Dmitry Kostjuchenko
Hi Peter,
This problem has been affecting Mixxx on Linux with ALSA for quite
some time, and it looks like you're the first person to make some
headway on the problem. (We experience both the deadlock on xruns and
the thread join timeout at exit.)
The only helpful thing I can add to this discussion is that we've
r1412 | aknudsen | 2009-05-24 09:54:22 -0700 (Sun, 24 May 2009) | 2 lines
Apply Kevin Kofler's non-mmap patch
If you look at the diff between r1411 and r1412, it might help you
figure out how to recover for pure devices. We never had any problems
recovering from xruns with direct ALSA devices (eg. hw:0,0) before
that patch...
Thanks,
Albert

Post by Peter Lukac
Hello Dmitry,
Bad news. Call "snd_pcm_prepare" not works and will not works because
in method "snd_pcm_recover" is calling method "snd_pcm_prepare"
int snd_pcm_recover(snd_pcm_t *pcm, int err, int silent)
{
if (err > 0)
err = -err;
if (err == -EINTR) /* nothing to do, continue */
return 0;
if (err == -EPIPE) {
const char *s;
if (snd_pcm_stream(pcm) == SND_PCM_STREAM_PLAYBACK)
s = "underrun";
else
s = "overrun";
if (!silent)
SNDERR("%s occured", s);
err = snd_pcm_prepare(pcm);
if (err < 0) {
SNDERR("cannot recovery from %s, prepare failed: %s",
s, snd_strerror(err));
return err;
}
return 0;
}
if (err == -ESTRPIPE) {
while ((err = snd_pcm_resume(pcm)) == -EAGAIN)
/* wait until suspend flag is released */
poll(NULL, 0, 1000);
if (err < 0) {
err = snd_pcm_prepare(pcm);
if (err < 0) {
SNDERR("cannot recovery from suspend, prepare
failed: %s", snd_strerror(err));
return err;
}
}
return 0;
}
return err;
}
When i'm try sample programs in alsalib...they works
http://www.alsa-project.org/alsa-doc/alsa-lib/_2test_2pcm__min_8c-
example.html#a3

http://www.alsa-project.org/alsa-doc/alsa-lib/_2test_2pcm_8c-example.html#a38

Post by Dmitry Kostjuchenko

Post by Peter Lukac
I think this is probem with wrong using alsalib in PA ..maybe somebody

who

Post by Dmitry Kostjuchenko

Post by Peter Lukac
wrote this part of code should be know where problem is.
...thanks for you time
regards

Post by Dmitry Kostjuchenko
Hi Peter,
Good that the reason is found out and simulation of the behavior is
possible! Although, I am confused about clean resolving as well. There

are

Post by Dmitry Kostjuchenko

Post by Peter Lukac

Post by Dmitry Kostjuchenko
- Recover timer (as you kindly proposed and tested), if it suceeds,
continue stream operation; If it fails: [1] stop stream, and let
application working with it to cope with restarting and etc, [2]

recover

Post by Dmitry Kostjuchenko

Post by Peter Lukac

Post by Dmitry Kostjuchenko
stream inside PA.
I am not Alsa specialist as well but suspect that hardware device gets
fully disconnected unlike software mixer and not sure that [2] can be
cleanly done, although may be it worth a try.
I looked up quickly ALSA docs
(http://www.suse.de/~mana/alsa090_howto.html)
and found the following: "
After the PCM playback is started, we have to make sure that our
application sends enough data to the soundcard buffer. Otherwise, a

buffer

Post by Dmitry Kostjuchenko

Post by Peter Lukac

Post by Dmitry Kostjuchenko
underrun will occur. After such an underrun has occured,

snd_pcm_prepare

Post by Dmitry Kostjuchenko

Post by Peter Lukac

Post by Dmitry Kostjuchenko
should be called.
"
Could you please add a call to 'snd_pcm_prepare' near the place were

you

Post by Dmitry Kostjuchenko

Post by Peter Lukac

Post by Dmitry Kostjuchenko
restore timer (or after it failed) and check how all works?!
Best regards,
Dmitry.

_______________________________________________
Portaudio mailing list
Portaudio at music.columbia.edu
http://music.columbia.edu/mailman/listinfo/portaudio

_______________________________________________
Portaudio mailing list
Portaudio at music.columbia.edu

http://music.columbia.edu/mailman/listinfo/portaudio
iAuxSoft
------------------
[www.iauxsoft.com]
------------------------------

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://music.columbia.edu/pipermail/portaudio/attachments/20100529/01a886b7/attachment-0001.html>

[RJ Ryan]

Hi Dimitry,

I subscribe to the list on digest mode so I haven't received your reply yet,
but I saw it on the archives. I tried your patch and adding the timeouts for
poll() returning 0 worked :). `pasuspender bin/patest_sine' now returns
after the timeout expires. The timeout makes patest_sine take about 5 more
seconds to exit, so maybe it should be a smaller timeout?

Thanks,
RJ

Post by RJ Ryan
Hi Dimitry,
I have tried your patch and it does not resolve the problem for me, though
as you'll see I am not exactly experiencing the same hang as you. In my
case, I can easily reproduce the hang on joining threads by running the
patest_sine program in conjunction with pasuspender. I am on Ubuntu Lucid
$ pasuspender bin/patest_sine
The 'default' ALSA device is chosen, which is a pulse device (according to
the PA debug output). The hang is likely because the default device is a
pulse device, which has been suspended via pasuspender. I have threaded many
PA_DEBUG's throughout the code, similar to yours.
In my case, PaAlsaStream_HandleXrun handler is never run. Correspondingly,
the revents flag never takes on a value of 8 (POLLERR). It is 4 (POLLOUT)
once, and then 0 for the rest of time.
...
BuildDeviceList: Found plugin default of type pulse
BuildDeviceList: Found plugin pulse of type pulse
...
Play for 5 seconds.
PaAlsaStream_WaitForFrames Begin
About to poll()
poll() wokeup >=0 result: 1
snd_pcm_state is 2
result: 1 revenrs: 4, count: 1 fd: 3
PaAlsaStream_WaitForFrames ended
PaAlsaStreamComponent_EndProcessing numFrames 2048
begin writei
end writei, res: 2048
PaAlsaStreamComponent_EndProcessing numFrames 2048
begin writei
end writei, res: 2048
PaAlsaStreamComponent_EndProcessing numFrames 2048
begin writei
end writei, res: 2048
PaAlsaStream_WaitForFrames
About to poll()
poll() wokeup >=0 result: 0
snd_pcm_state is 3
result: 0 revenrs: 0, count: 1 fd: 3
About to poll()
poll() wokeup >=0 result: 0
snd_pcm_state is 3
... repeat forever
As you can see, PA gets the POLLOUT revent, and writes 3x2048 to the
device. From then on poll() just times out repeatedly. As I said, this is
probably because I have run pasuspender to suspend the pulse device, and
patest_sine picks the 'default' device which is a pulse device. Regardless,
portaudio should not fail to exit in this case because this results in nasty
hangs. Is this a situation that calls for a timeout in joining the thread?
Is there another saner way to determine that the device is hung and not
responding?
Best regards,
RJ Ryan

Message: 1
Date: Thu, 27 May 2010 12:07:10 +0300
From: Dmitry Kostjuchenko <dmitrykos at inbox.lv>
To: Portaudio Mailing List <portaudio at music.columbia.edu>
Subject: Re: [Portaudio] PaUnixThread_Terminate: Joining thread
..still waiting
Message-ID: <1274951230.4bfe363ed3ced at mail.inbox.lv>
Content-Type: text/plain; charset=UTF-8
Hi Albert,
Your pick to a revision # is very useful of course, at least we know where
the bug was born. I analysed the revision,
it allows to use non-MMAPed device. I made several changes to PA's ALSA
implementation but have no ability to
test it under Linux now and if you have ability to simulate xrun it would
be great if you could compile and test.
As this is a raw try I do not commit a patch to PA SVN but would like to
http://rapidshare.com/files/392042661/pa_linux_alsa.zip.html
I will also e-mail it to your e-mail directly.
Best regards,
Dmitry.
?

Post by Dmitry Kostjuchenko
Hi Peter,
This problem has been affecting Mixxx on Linux with ALSA for quite
some time, and it looks like you're the first person to make some
headway on the problem. (We experience both the deadlock on xruns and
the thread join timeout at exit.)
The only helpful thing I can add to this discussion is that we've
r1412 | aknudsen | 2009-05-24 09:54:22 -0700 (Sun, 24 May 2009) | 2

lines

Post by Dmitry Kostjuchenko
Apply Kevin Kofler's non-mmap patch
If you look at the diff between r1411 and r1412, it might help you
figure out how to recover for pure devices. We never had any problems
recovering from xruns with direct ALSA devices (eg. hw:0,0) before
that patch...
Thanks,
Albert

Post by Peter Lukac
Hello Dmitry,
Bad news. Call "snd_pcm_prepare" not works and will not works because
in method "snd_pcm_recover" is calling method "snd_pcm_prepare"
int snd_pcm_recover(snd_pcm_t *pcm, int err, int silent)
{
if (err > 0)
err = -err;
if (err == -EINTR) /* nothing to do, continue */
return 0;
if (err == -EPIPE) {
const char *s;
if (snd_pcm_stream(pcm) == SND_PCM_STREAM_PLAYBACK)
s = "underrun";
else
s = "overrun";
if (!silent)
SNDERR("%s occured", s);
err = snd_pcm_prepare(pcm);
if (err < 0) {
SNDERR("cannot recovery from %s, prepare failed: %s",
s, snd_strerror(err));
return err;
}
return 0;
}
if (err == -ESTRPIPE) {
while ((err = snd_pcm_resume(pcm)) == -EAGAIN)
/* wait until suspend flag is released */
poll(NULL, 0, 1000);
if (err < 0) {
err = snd_pcm_prepare(pcm);
if (err < 0) {
SNDERR("cannot recovery from suspend, prepare
failed: %s", snd_strerror(err));
return err;
}
}
return 0;
}
return err;
}
When i'm try sample programs in alsalib...they works
http://www.alsa-project.org/alsa-doc/alsa-lib/_2test_2pcm__min_8c-
example.html#a3

http://www.alsa-project.org/alsa-doc/alsa-lib/_2test_2pcm_8c-example.html#a38

Post by Dmitry Kostjuchenko

Post by Peter Lukac
I think this is probem with wrong using alsalib in PA ..maybe somebody

who

Post by Dmitry Kostjuchenko

Post by Peter Lukac
wrote this part of code should be know where problem is.
...thanks for you time
regards

Post by Dmitry Kostjuchenko
Hi Peter,
Good that the reason is found out and simulation of the behavior is
possible! Although, I am confused about clean resolving as well.

There are

Post by Dmitry Kostjuchenko

Post by Peter Lukac

Post by Dmitry Kostjuchenko
- Recover timer (as you kindly proposed and tested), if it suceeds,
continue stream operation; If it fails: [1] stop stream, and let
application working with it to cope with restarting and etc, [2]

recover

Post by Dmitry Kostjuchenko

Post by Peter Lukac

Post by Dmitry Kostjuchenko
stream inside PA.
I am not Alsa specialist as well but suspect that hardware device

gets

Post by Dmitry Kostjuchenko

Post by Peter Lukac

Post by Dmitry Kostjuchenko
fully disconnected unlike software mixer and not sure that [2] can be
cleanly done, although may be it worth a try.
I looked up quickly ALSA docs
(http://www.suse.de/~mana/alsa090_howto.html)
and found the following: "
After the PCM playback is started, we have to make sure that our
application sends enough data to the soundcard buffer. Otherwise, a

buffer

Post by Dmitry Kostjuchenko

Post by Peter Lukac

Post by Dmitry Kostjuchenko
underrun will occur. After such an underrun has occured,

snd_pcm_prepare

Post by Dmitry Kostjuchenko

Post by Peter Lukac

Post by Dmitry Kostjuchenko
should be called.
"
Could you please add a call to 'snd_pcm_prepare' near the place were

you

Post by Dmitry Kostjuchenko

Post by Peter Lukac

Post by Dmitry Kostjuchenko
restore timer (or after it failed) and check how all works?!
Best regards,
Dmitry.

_______________________________________________
Portaudio mailing list
Portaudio at music.columbia.edu
http://music.columbia.edu/mailman/listinfo/portaudio

_______________________________________________
Portaudio mailing list
Portaudio at music.columbia.edu

http://music.columbia.edu/mailman/listinfo/portaudio
iAuxSoft
------------------
[www.iauxsoft.com]
------------------------------

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://music.columbia.edu/pipermail/portaudio/attachments/20100529/5055d86f/attachment-0001.html>

[Dmitry Kostjuchenko]

Hi RJ!

Ok, let's decrease by 2 times to 64-times of timout, it is around 4 secs. In application, it will be almost not
noticable as happens in PA's Alsa polling thread. 128 probably was too high value. 64 to my view is ok, it is large
anough to be safe in order not to abort normal device on overloaded system.

Dmitry.

Post by RJ Ryan
Hi Dimitry,
I subscribe to the list on digest mode so I haven't received your reply yet,
but I saw it on the archives. I tried your patch and adding the timeouts for
poll() returning 0 worked :). `pasuspender bin/patest_sine' now returns
after the timeout expires. The timeout makes patest_sine take about 5 more
seconds to exit, so maybe it should be a smaller timeout?
Thanks,
RJ

Post by RJ Ryan
Hi Dimitry,
I have tried your patch and it does not resolve the problem for me, though
as you'll see I am not exactly experiencing the same hang as you. In my
case, I can easily reproduce the hang on joining threads by running the
patest_sine program in conjunction with pasuspender. I am on Ubuntu Lucid
$ pasuspender bin/patest_sine
The 'default' ALSA device is chosen, which is a pulse device (according to
the PA debug output). The hang is likely because the default device is a
pulse device, which has been suspended via pasuspender. I have threaded many
PA_DEBUG's throughout the code, similar to yours.
In my case, PaAlsaStream_HandleXrun handler is never run. Correspondingly,
the revents flag never takes on a value of 8 (POLLERR). It is 4 (POLLOUT)
once, and then 0 for the rest of time.
...
BuildDeviceList: Found plugin default of type pulse
BuildDeviceList: Found plugin pulse of type pulse
...
Play for 5 seconds.
PaAlsaStream_WaitForFrames Begin
About to poll()
poll() wokeup >=0 result: 1
snd_pcm_state is 2
result: 1 revenrs: 4, count: 1 fd: 3
PaAlsaStream_WaitForFrames ended
PaAlsaStreamComponent_EndProcessing numFrames 2048
begin writei
end writei, res: 2048
PaAlsaStreamComponent_EndProcessing numFrames 2048
begin writei
end writei, res: 2048
PaAlsaStreamComponent_EndProcessing numFrames 2048
begin writei
end writei, res: 2048
PaAlsaStream_WaitForFrames
About to poll()
poll() wokeup >=0 result: 0
snd_pcm_state is 3
result: 0 revenrs: 0, count: 1 fd: 3
About to poll()
poll() wokeup >=0 result: 0
snd_pcm_state is 3
... repeat forever
As you can see, PA gets the POLLOUT revent, and writes 3x2048 to the
device. From then on poll() just times out repeatedly. As I said, this is
probably because I have run pasuspender to suspend the pulse device, and
patest_sine picks the 'default' device which is a pulse device. Regardless,
portaudio should not fail to exit in this case because this results in nasty
hangs. Is this a situation that calls for a timeout in joining the thread?
Is there another saner way to determine that the device is hung and not
responding?
Best regards,
RJ Ryan

Message: 1
Date: Thu, 27 May 2010 12:07:10 +0300
From: Dmitry Kostjuchenko <dmitrykos at inbox.lv>
To: Portaudio Mailing List <portaudio at music.columbia.edu>
Subject: Re: [Portaudio] PaUnixThread_Terminate: Joining thread
..still waiting
Message-ID: <1274951230.4bfe363ed3ced at mail.inbox.lv>
Content-Type: text/plain; charset=UTF-8
Hi Albert,
Your pick to a revision # is very useful of course, at least we know where
the bug was born. I analysed the revision,
it allows to use non-MMAPed device. I made several changes to PA's ALSA
implementation but have no ability to
test it under Linux now and if you have ability to simulate xrun it would
be great if you could compile and test.
As this is a raw try I do not commit a patch to PA SVN but would like to
http://rapidshare.com/files/392042661/pa_linux_alsa.zip.html
I will also e-mail it to your e-mail directly.
Best regards,
Dmitry.
?

Post by Dmitry Kostjuchenko
Hi Peter,
This problem has been affecting Mixxx on Linux with ALSA for quite
some time, and it looks like you're the first person to make some
headway on the problem. (We experience both the deadlock on xruns and
the thread join timeout at exit.)
The only helpful thing I can add to this discussion is that we've
r1412 | aknudsen | 2009-05-24 09:54:22 -0700 (Sun, 24 May 2009) | 2

lines

Post by Dmitry Kostjuchenko
Apply Kevin Kofler's non-mmap patch
If you look at the diff between r1411 and r1412, it might help you
figure out how to recover for pure devices. We never had any problems
recovering from xruns with direct ALSA devices (eg. hw:0,0) before
that patch...
Thanks,
Albert

Post by Peter Lukac
Hello Dmitry,
Bad news. Call "snd_pcm_prepare" not works and will not works because
in method "snd_pcm_recover" is calling method "snd_pcm_prepare"
int snd_pcm_recover(snd_pcm_t *pcm, int err, int silent)
{
if (err > 0)
err = -err;
if (err == -EINTR) /* nothing to do, continue */
return 0;
if (err == -EPIPE) {
const char *s;
if (snd_pcm_stream(pcm) == SND_PCM_STREAM_PLAYBACK)
s = "underrun";
else
s = "overrun";
if (!silent)
SNDERR("%s occured", s);
err = snd_pcm_prepare(pcm);
if (err < 0) {
SNDERR("cannot recovery from %s, prepare failed: %s",
s, snd_strerror(err));
return err;
}
return 0;
}
if (err == -ESTRPIPE) {
while ((err = snd_pcm_resume(pcm)) == -EAGAIN)
/* wait until suspend flag is released */
poll(NULL, 0, 1000);
if (err < 0) {
err = snd_pcm_prepare(pcm);
if (err < 0) {
SNDERR("cannot recovery from suspend, prepare
failed: %s", snd_strerror(err));
return err;
}
}
return 0;
}
return err;
}
When i'm try sample programs in alsalib...they works
http://www.alsa-project.org/alsa-doc/alsa-lib/_2test_2pcm__min_8c-
example.html#a3

http://www.alsa-project.org/alsa-doc/alsa-lib/_2test_2pcm_8c-example.html#a38

Post by Dmitry Kostjuchenko

Post by Peter Lukac
I think this is probem with wrong using alsalib in PA ..maybe somebody

who

Post by Dmitry Kostjuchenko

Post by Peter Lukac
wrote this part of code should be know where problem is.
...thanks for you time
regards

Post by Dmitry Kostjuchenko
Hi Peter,
Good that the reason is found out and simulation of the behavior is
possible! Although, I am confused about clean resolving as well.

There are

Post by Dmitry Kostjuchenko

Post by Peter Lukac

Post by Dmitry Kostjuchenko
- Recover timer (as you kindly proposed and tested), if it suceeds,
continue stream operation; If it fails: [1] stop stream, and let
application working with it to cope with restarting and etc, [2]

recover

Post by Dmitry Kostjuchenko

Post by Peter Lukac

Post by Dmitry Kostjuchenko
stream inside PA.
I am not Alsa specialist as well but suspect that hardware device

gets

Post by Dmitry Kostjuchenko

Post by Peter Lukac

Post by Dmitry Kostjuchenko
fully disconnected unlike software mixer and not sure that [2] can be
cleanly done, although may be it worth a try.
I looked up quickly ALSA docs
(http://www.suse.de/~mana/alsa090_howto.html)
and found the following: "
After the PCM playback is started, we have to make sure that our
application sends enough data to the soundcard buffer. Otherwise, a

buffer

Post by Dmitry Kostjuchenko

Post by Peter Lukac

Post by Dmitry Kostjuchenko
underrun will occur. After such an underrun has occured,

snd_pcm_prepare

Post by Dmitry Kostjuchenko

Post by Peter Lukac

Post by Dmitry Kostjuchenko
should be called.
"
Could you please add a call to 'snd_pcm_prepare' near the place were

you

Post by Dmitry Kostjuchenko

Post by Peter Lukac

Post by Dmitry Kostjuchenko
restore timer (or after it failed) and check how all works?!
Best regards,
Dmitry.

_______________________________________________
Portaudio mailing list
Portaudio at music.columbia.edu
http://music.columbia.edu/mailman/listinfo/portaudio

_______________________________________________
Portaudio mailing list
Portaudio at music.columbia.edu

http://music.columbia.edu/mailman/listinfo/portaudio
iAuxSoft
------------------
[www.iauxsoft.com]
------------------------------

-------------------------
iAuxSoft: Middleware SDK
[http://www.iauxsoft.com]

[Damian Minkov]

Hi,

we are using portaudio in sip-communicator wrapped in JNI and with
blocking api. I was very happy to see latest changes comments as we
also have some problems on linux systems. The problems we face seems
the same as those described in current mail thread. I was eager to
test those changes, but they seems to broke something, cause I have a
crash when running with them.
I tried investigating the problem and as we are using blocking api I
tried running test patest_read_write_wire with revision 1501 which
works and with revision 1502 which crashes.

Any suggestions?
Thanks
damencho

Here is the output when crashing :

$ bin/patest_read_write_wire
patest_read_write_wire.c
before paHostApiInitializers[0].
BuildDeviceList: Ignoring ALSA plugin device cards of type unknown
BuildDeviceList: Found plugin front of type unknown
BuildDeviceList: Found plugin rear of type unknown
BuildDeviceList: Found plugin center_lfe of type unknown
BuildDeviceList: Found plugin side of type unknown
BuildDeviceList: Found plugin surround40 of type unknown
BuildDeviceList: Found plugin surround41 of type unknown
BuildDeviceList: Found plugin surround50 of type unknown
BuildDeviceList: Found plugin surround51 of type unknown
BuildDeviceList: Found plugin surround71 of type unknown
BuildDeviceList: Found plugin iec958 of type unknown
BuildDeviceList: Found plugin spdif of type unknown
BuildDeviceList: Found plugin hdmi of type unknown
BuildDeviceList: Found plugin dmix of type unknown
BuildDeviceList: Ignoring ALSA plugin device dsnoop of type unknown
BuildDeviceList: Found plugin modem of type unknown
BuildDeviceList: Found plugin phoneline of type unknown
BuildDeviceList: Ignoring ALSA plugin device hw of type hw
BuildDeviceList: Ignoring ALSA plugin device plughw of type plug
BuildDeviceList: Ignoring ALSA plugin device plug of type plug
BuildDeviceList: Ignoring ALSA plugin device shm of type shm
BuildDeviceList: Ignoring ALSA plugin device tee of type file
BuildDeviceList: Ignoring ALSA plugin device file of type file
BuildDeviceList: Ignoring ALSA plugin device null of type null
BuildDeviceList: Found plugin rawbluetooth of type bluetooth
BuildDeviceList: Found plugin bluetooth of type plug
BuildDeviceList: Found plugin default of type pulse
BuildDeviceList: Found plugin pulse of type pulse
Default input device: HDA Intel: ALC889A Analog (hw:0,0)
Default output device: HDA Intel: ALC889A Analog (hw:0,0)
FillInDevInfo: Adding device HDA Intel: ALC889A Analog (hw:0,0): 0
FillInDevInfo: Adding device HDA Intel: ALC889A Digital (hw:0,1): 1
FillInDevInfo: Adding device HDA Intel: ALC889A Analog (hw:0,2): 2
FillInDevInfo: Adding device front: 3
FillInDevInfo: Adding device surround40: 4
FillInDevInfo: Failed groping surround41 for playback
FillInDevInfo: Failed groping surround50 for playback
FillInDevInfo: Adding device surround51: 5
FillInDevInfo: Adding device surround71: 6
FillInDevInfo: Adding device iec958: 7
FillInDevInfo: Adding device spdif: 8
FillInDevInfo: Adding device pulse: 9
FillInDevInfo: Adding device dmix: 10
Default input device: default
Default output device: default
FillInDevInfo: Adding device default: 11
BuildDeviceList: Building device list took 0.103085 seconds
after paHostApiInitializers[0].
before paHostApiInitializers[1].
PaOSS BuildDeviceList: Total number of devices found: 1
after paHostApiInitializers[1].
Input device # 11.
Input LL: 0.01161 s
Input HL: 0.0464399 s
Output device # 11.
Output LL: 0.01161 s
Output HL: 0.0464399 s
AlsaOpen: Opening device default
AlsaOpen: Opening device default
PaAlsaStreamComponent_InitialConfigure: device MMAP
SND_PCM_ACCESS_MMAP_INTERLEAVED: NO
PaAlsaStreamComponent_InitialConfigure: device MMAP
SND_PCM_ACCESS_MMAP_NONINTERLEAVED: NO
PaAlsaStreamComponent_InitialConfigure: device can MMAP: NO
PaAlsaStreamComponent_InitialConfigure: device MMAP
SND_PCM_ACCESS_MMAP_INTERLEAVED: NO
PaAlsaStreamComponent_InitialConfigure: device MMAP
SND_PCM_ACCESS_MMAP_NONINTERLEAVED: NO
PaAlsaStreamComponent_InitialConfigure: device can MMAP: NO
PaAlsaStream_Configure: Capture period size: 512, latency: 0.046440
PaAlsaStream_Configure: Playback period size: 512, latency: 0.046440
Wire on. Will run one minute.
*** glibc detected *** bin/patest_read_write_wire: double free or
corruption (out): 0x0000000000920060 ***
======= Backtrace: =========
/lib/libc.so.6(+0x775b6)[0x7f8d9d4125b6]
/lib/libc.so.6(cfree+0x73)[0x7f8d9d418e53]
bin/patest_read_write_wire[0x4092c5]
bin/patest_read_write_wire[0x409900]
bin/patest_read_write_wire[0x40e5e4]
bin/patest_read_write_wire[0x40486a]
/lib/libc.so.6(__libc_start_main+0xfd)[0x7f8d9d3b9c4d]
bin/patest_read_write_wire[0x404499]
======= Memory map: ========
00400000-00425000 r-xp 00000000 08:03 1966467
/home/damencho/dev/portaudio/portaudio/bin/patest_read_write_wire
00624000-00625000 r--p 00024000 08:03 1966467
/home/damencho/dev/portaudio/portaudio/bin/patest_read_write_wire
00625000-00626000 rw-p 00025000 08:03 1966467
/home/damencho/dev/portaudio/portaudio/bin/patest_read_write_wire
008d0000-0092f000 rw-p 00000000 00:00 0 [heap]
7f8d84000000-7f8d84021000 rw-p 00000000 00:00 0
7f8d84021000-7f8d88000000 ---p 00000000 00:00 0
7f8d89a2f000-7f8d8da30000 r--s 00000000 00:10 8725
/dev/shm/pulse-shm-186025029
7f8d8da30000-7f8d91a31000 rw-s 00000000 00:10 331262
/dev/shm/pulse-shm-1317317186
7f8d91a31000-7f8d95a32000 rw-s 00000000 00:10 331255
/dev/shm/pulse-shm-1825499815
7f8d95a32000-7f8d95a33000 ---p 00000000 00:00 0
7f8d95a33000-7f8d96233000 rw-p 00000000 00:00 0
7f8d991fb000-7f8d99211000 r-xp 00000000 08:03 859
/lib/libgcc_s.so.1
7f8d99211000-7f8d99410000 ---p 00016000 08:03 859
/lib/libgcc_s.so.1
7f8d99410000-7f8d99411000 r--p 00015000 08:03 859
/lib/libgcc_s.so.1
7f8d99411000-7f8d99412000 rw-p 00016000 08:03 859
/lib/libgcc_s.so.1
7f8d99412000-7f8d99413000 ---p 00000000 00:00 0
7f8d99413000-7f8d99c13000 rw-p 00000000 00:00 0
7f8d99c13000-7f8d99c1f000 r-xp 00000000 08:03 4295
/lib/libnss_files-2.11.1.so
7f8d99c1f000-7f8d99e1e000 ---p 0000c000 08:03 4295
/lib/libnss_files-2.11.1.so
7f8d99e1e000-7f8d99e1f000 r--p 0000b000 08:03 4295
/lib/libnss_files-2.11.1.so
7f8d99e1f000-7f8d99e20000 rw-p 0000c000 08:03 4295
/lib/libnss_files-2.11.1.so
7f8d99e20000-7f8d99e2a000 r-xp 00000000 08:03 16612
/lib/libnss_nis-2.11.1.so
7f8d99e2a000-7f8d9a029000 ---p 0000a000 08:03 16612
/lib/libnss_nis-2.11.1.so
7f8d9a029000-7f8d9a02a000 r--p 00009000 08:03 16612
/lib/libnss_nis-2.11.1.so
7f8d9a02a000-7f8d9a02b000 rw-p 0000a000 08:03 16612
/lib/libnss_nis-2.11.1.so
7f8d9a02b000-7f8d9a033000 r-xp 00000000 08:03 4293
/lib/libnss_compat-2.11.1.so
7f8d9a033000-7f8d9a232000 ---p 00008000 08:03 4293
/lib/libnss_compat-2.11.1.so
7f8d9a232000-7f8d9a233000 r--p 00007000 08:03 4293
/lib/libnss_compat-2.11.1.so
7f8d9a233000-7f8d9a234000 rw-p 00008000 08:03 4293
/lib/libnss_compat-2.11.1.so
7f8d9a234000-7f8d9a239000 r-xp 00000000 08:03 197781
/usr/lib/alsa-lib/libasound_module_pcm_pulse.so
7f8d9a239000-7f8d9a438000 ---p 00005000 08:03 197781
/usr/lib/alsa-lib/libasound_module_pcm_pulse.so
7f8d9a438000-7f8d9a439000 r--p 00004000 08:03 197781
/usr/lib/alsa-lib/libasound_module_pcm_pulse.so
7f8d9a439000-7f8d9a43a000 rw-p 00005000 08:03 197781
/usr/lib/alsa-lib/libasound_module_pcm_pulse.so
7f8d9a43a000-7f8d9a440000 r-xp 00000000 08:03 7533
/usr/lib/libogg.so.0.6.0
7f8d9a440000-7f8d9a63f000 ---p 00006000 08:03 7533
/usr/lib/libogg.so.0.6.0
7f8d9a63f000-7f8d9a640000 r--p 00005000 08:03 7533
/usr/lib/libogg.so.0.6.0
7f8d9a640000-7f8d9a641000 rw-p 00006000 08:03 7533
/usr/lib/libogg.so.0.6.0
7f8d9a641000-7f8d9a66d000 r-xp 00000000 08:03 3062
/usr/lib/libvorbis.so.0.4.3
7f8d9a66d000-7f8d9a86c000 ---p 0002c000 08:03 3062
/usr/lib/libvorbis.so.0.4.3
7f8d9a86c000-7f8d9a86d000 r--p 0002b000 08:03 3062
/usr/lib/libvorbis.so.0.4.3
7f8d9a86d000-7f8d9a86e000 rw-p 0002c000 08:03 3062
/usr/lib/libvorbis.so.0.4.3
7f8d9a86e000-7f8d9aa31000 r-xp 00000000 08:03 3659
/usr/lib/libvorbisenc.so.2.0.6
7f8d9aa31000-7f8d9ac31000 ---p 001c3000 08:03 3659
/usr/lib/libvorbisenc.so.2.0.6
7f8d9ac31000-7f8d9ac48000 r--p 001c3000 08:03 3659
/usr/lib/libvorbisenc.so.2.0.6
7f8d9ac48000-7f8d9ac49000 rw-p 001da000 08:03 3659
/usr/lib/libvorbisenc.so.2.0.6
7f8d9ac49000-7f8d9ac92000 r-xp 00000000 08:03 2298
/usr/lib/libFLAC.so.8.2.0
7f8d9ac92000-7f8d9ae92000 ---p 00049000 08:03 2298
/usr/lib/libFLAC.so.8.2.0
7f8d9ae92000-7f8d9ae93000 r--p 00049000 08:03 2298
/usr/lib/libFLAC.so.8.2.0
7f8d9ae93000-7f8d9ae94000 rw-p 0004a000 08:03 2298
/usr/lib/libFLAC.so.8.2.0
7f8d9ae94000-7f8d9aeab000 r-xp 00000000 08:03 4292
/lib/libnsl-2.11.1.so
7f8d9aeab000-7f8d9b0aa000 ---p 00017000 08:03 4292
/lib/libnsl-2.11.1.so
7f8d9b0aa000-7f8d9b0ab000 r--p 00016000 08:03 4292
/lib/libnsl-2.11.1.so
7f8d9b0ab000-7f8d9b0ac000 rw-p 00017000 08:03 4292
/lib/libnsl-2.11.1.so
7f8d9b0ac000-7f8d9b0ae000 rw-p 00000000 00:00 0
7f8d9b0ae000-7f8d9b0b3000 r-xp 00000000 08:03 3741
/usr/lib/libXdmcp.so.6.0.0
7f8d9b0b3000-7f8d9b2b2000 ---p 00005000 08:03 3741
/usr/lib/libXdmcp.so.6.0.0
7f8d9b2b2000-7f8d9b2b3000 r--p 00004000 08:03 3741
/usr/lib/libXdmcp.so.6.0.0
7f8d9b2b3000-7f8d9b2b4000 rw-p 00005000 08:03 3741
/usr/lib/libXdmcp.so.6.0.0
7f8d9b2b4000-7f8d9b2b6000 r-xp 00000000 08:03 2433
/usr/lib/libXau.so.6.0.0
7f8d9b2b6000-7f8d9b4b6000 ---p 00002000 08:03 2433
/usr/lib/libXau.so.6.0.0
7f8d9b4b6000-7f8d9b4b7000 r--p 00002000 08:03 2433
/usr/lib/libXau.so.6.0.0
7f8d9b4b7000-7f8d9b4b8000 rw-p 00003000 08:03 2433
/usr/lib/libXau.so.6.0.0
7f8d9b4b8000-7f8d9b4f5000 r-xp 00000000 08:03 562
/lib/libdbus-1.so.3.4.0Aborted



On Sat, May 29, 2010 at 11:35 PM, Dmitry Kostjuchenko

Post by Dmitry Kostjuchenko
Hi RJ!
Ok, let's decrease by 2 times to 64-times of timout, it is around 4 secs. In application, it will be almost not
noticable as happens in PA's Alsa polling thread. 128 probably was too high value. 64 to my view is ok, it is large
anough to be safe in order not to abort normal device on overloaded system.
Dmitry.

Post by RJ Ryan
Hi Dimitry,
I subscribe to the list on digest mode so I haven't received your reply yet,
but I saw it on the archives. I tried your patch and adding the timeouts for
poll() returning 0 worked :). `pasuspender bin/patest_sine' now returns
after the timeout expires. The timeout makes patest_sine take about 5 more
seconds to exit, so maybe it should be a smaller timeout?
Thanks,
RJ

Post by RJ Ryan
Hi Dimitry,
I have tried your patch and it does not resolve the problem for me, though
as you'll see I am not exactly experiencing the same hang as you. In my
case, I can easily reproduce the hang on joining threads by running the
patest_sine program in conjunction with pasuspender. I am on Ubuntu Lucid
$ pasuspender bin/patest_sine
The 'default' ALSA device is chosen, which is a pulse device (according to
the PA debug output). The hang is likely because the default device is a
pulse device, which has been suspended via pasuspender. I have threaded many
PA_DEBUG's throughout the code, similar to yours.
In my case, PaAlsaStream_HandleXrun handler is never run. Correspondingly,
the revents flag never takes on a value of 8 (POLLERR). It is 4 (POLLOUT)
once, and then 0 for the rest of time.
...
BuildDeviceList: Found plugin default of type pulse
BuildDeviceList: Found plugin pulse of type pulse
...
Play for 5 seconds.
PaAlsaStream_WaitForFrames Begin
About to poll()
poll() wokeup >=0 result: 1
snd_pcm_state is 2
result: 1 revenrs: 4, count: 1 fd: 3
PaAlsaStream_WaitForFrames ended
PaAlsaStreamComponent_EndProcessing numFrames 2048
begin writei
end writei, res: 2048
PaAlsaStreamComponent_EndProcessing numFrames 2048
begin writei
end writei, res: 2048
PaAlsaStreamComponent_EndProcessing numFrames 2048
begin writei
end writei, res: 2048
PaAlsaStream_WaitForFrames
About to poll()
poll() wokeup >=0 result: 0
snd_pcm_state is 3
result: 0 revenrs: 0, count: 1 fd: 3
About to poll()
poll() wokeup >=0 result: 0
snd_pcm_state is 3
... repeat forever
As you can see, PA gets the POLLOUT revent, and writes 3x2048 to the
device. From then on poll() just times out repeatedly. As I said, this is
probably because I have run pasuspender to suspend the pulse device, and
patest_sine picks the 'default' device which is a pulse device. Regardless,
portaudio should not fail to exit in this case because this results in nasty
hangs. Is this a situation that calls for a timeout in joining the thread?
Is there another saner way to determine that the device is hung and not
responding?
Best regards,
RJ Ryan

Message: 1
Date: Thu, 27 May 2010 12:07:10 +0300
From: Dmitry Kostjuchenko <dmitrykos at inbox.lv>
To: Portaudio Mailing List <portaudio at music.columbia.edu>
Subject: Re: [Portaudio] PaUnixThread_Terminate: Joining thread
..still waiting
Message-ID: <1274951230.4bfe363ed3ced at mail.inbox.lv>
Content-Type: text/plain; charset=UTF-8
Hi Albert,
Your pick to a revision # is very useful of course, at least we know where
the bug was born. I analysed the revision,
it allows to use non-MMAPed device. I made several changes to PA's ALSA
implementation but have no ability to
test it under Linux now and if you have ability to simulate xrun it would
be great if you could compile and test.
As this is a raw try I do not commit a patch to PA SVN but would like to
http://rapidshare.com/files/392042661/pa_linux_alsa.zip.html
I will also e-mail it to your e-mail directly.
Best regards,
Dmitry.
?

Post by Dmitry Kostjuchenko
Hi Peter,
This problem has been affecting Mixxx on Linux with ALSA for quite
some time, and it looks like you're the first person to make some
headway on the problem. (We experience both the deadlock on xruns and
the thread join timeout at exit.)
The only helpful thing I can add to this discussion is that we've
r1412 | aknudsen | 2009-05-24 09:54:22 -0700 (Sun, 24 May 2009) | 2

lines

Post by Dmitry Kostjuchenko
Apply Kevin Kofler's non-mmap patch
If you look at the diff between r1411 and r1412, it might help you
figure out how to recover for pure devices. We never had any problems
recovering from xruns with direct ALSA devices (eg. hw:0,0) before
that patch...
Thanks,
Albert

Post by Peter Lukac
Hello Dmitry,
Bad news. Call "snd_pcm_prepare" not works and will not works because
in method "snd_pcm_recover" is calling method "snd_pcm_prepare"
int snd_pcm_recover(snd_pcm_t *pcm, int err, int silent)
{
if (err > 0)
err = -err;
if (err == -EINTR) /* nothing to do, continue */
return 0;
if (err == -EPIPE) {
const char *s;
if (snd_pcm_stream(pcm) == SND_PCM_STREAM_PLAYBACK)
s = "underrun";
else
s = "overrun";
if (!silent)
SNDERR("%s occured", s);
err = snd_pcm_prepare(pcm);
if (err < 0) {
SNDERR("cannot recovery from %s, prepare failed: %s",
s, snd_strerror(err));
return err;
}
return 0;
}
if (err == -ESTRPIPE) {
while ((err = snd_pcm_resume(pcm)) == -EAGAIN)
/* wait until suspend flag is released */
poll(NULL, 0, 1000);
if (err < 0) {
err = snd_pcm_prepare(pcm);
if (err < 0) {
SNDERR("cannot recovery from suspend, prepare
failed: %s", snd_strerror(err));
return err;
}
}
return 0;
}
return err;
}
When i'm try sample programs in alsalib...they works
http://www.alsa-project.org/alsa-doc/alsa-lib/_2test_2pcm__min_8c-
example.html#a3

http://www.alsa-project.org/alsa-doc/alsa-lib/_2test_2pcm_8c-example.html#a38

Post by Dmitry Kostjuchenko

Post by Peter Lukac
I think this is probem with wrong using alsalib in PA ..maybe somebody

who

Post by Dmitry Kostjuchenko

Post by Peter Lukac
wrote this part of code should be know where problem is.
...thanks for you time
regards

Post by Dmitry Kostjuchenko
Hi Peter,
Good that the reason is found out and simulation of the behavior is
possible! Although, I am confused about clean resolving as well.

There are

Post by Dmitry Kostjuchenko

Post by Peter Lukac

Post by Dmitry Kostjuchenko
- Recover timer (as you kindly proposed and tested), if it suceeds,
continue stream operation; If it fails: [1] stop stream, and let
application working with it to cope with restarting and etc, [2]

recover

Post by Dmitry Kostjuchenko

Post by Peter Lukac

Post by Dmitry Kostjuchenko
stream inside PA.
I am not Alsa specialist as well but suspect that hardware device

gets

Post by Dmitry Kostjuchenko

Post by Peter Lukac

Post by Dmitry Kostjuchenko
fully disconnected unlike software mixer and not sure that [2] can be
cleanly done, although may be it worth a try.
I looked up quickly ALSA docs
(http://www.suse.de/~mana/alsa090_howto.html)
and found the following: "
After the PCM playback is started, we have to make sure that our
application sends enough data to the soundcard buffer. Otherwise, a

buffer

Post by Dmitry Kostjuchenko

Post by Peter Lukac

Post by Dmitry Kostjuchenko
underrun will occur. After such an underrun has occured,

snd_pcm_prepare

Post by Dmitry Kostjuchenko

Post by Peter Lukac

Post by Dmitry Kostjuchenko
should be called.
"
Could you please add a call to 'snd_pcm_prepare' near the place were

you

Post by Dmitry Kostjuchenko

Post by Peter Lukac

Post by Dmitry Kostjuchenko
restore timer (or after it failed) and check how all works?!
Best regards,
Dmitry.

_______________________________________________
Portaudio mailing list
Portaudio at music.columbia.edu
http://music.columbia.edu/mailman/listinfo/portaudio

_______________________________________________
Portaudio mailing list
Portaudio at music.columbia.edu

http://music.columbia.edu/mailman/listinfo/portaudio
iAuxSoft
------------------
[www.iauxsoft.com]
------------------------------

-------------------------
iAuxSoft: Middleware SDK
[http://www.iauxsoft.com]
_______________________________________________
Portaudio mailing list
Portaudio at music.columbia.edu
http://music.columbia.edu/mailman/listinfo/portaudio

[Peter Lukac]

Hello all

I check last daily snapshot:
pa_snapshot.tgz created Monday, 31-May-2010 21:37:05 PDT

and i'm very glad the problem is in progress...
This version is more better like before but i have still some problems.

I tested PA with pjlib.. http://www.pjsip.org
pjlib is SIP voip stack with utilites for VOIP and audio

i used:
1) pjsua (pjsip-apps/bin)
2) auddemo (pjsip-apps/bin/samples/arm-unknown-linux-gnu)


AUDDEMO
====================================

1) DEVICE - with DMIX
-------------------------------------------------------------
When i open device "alsa DMIX device" and CPU is little overload all works
fine. PA recover from XRUN and sound still playing:

PaAlsaStream_HandleXrun: restarting Alsa to recover from XRUN
AlsaStop: Dropped frames
AlsaRestart: Restarted audio
PaAlsaStream_HandleXrun: restarting Alsa to recover from XRUN
AlsaStop: Dropped frames
AlsaRestart: Restarted audio
PaAlsaStream_HandleXrun: restarting Alsa to recover from XRUN
AlsaStop: Dropped frames
AlsaRestart: Restarted audio
PaAlsaStream_HandleXrun: restarting Alsa to recover from XRUN

..but when CPU is more overload sound stop playing and i get tons of these

Post by Dmitry Kostjuchenko

Post by Damian Minkov

PaAlsaStream_WaitForFrames: poll timed out, returning error

Expression 'paTimedOut' failed in
'src/../../../portaudio/src/hostapi/alsa/pa_linux_alsa.c', line: 2991
Expression 'self->capture.ready || self->playback.ready' failed in
'src/../../../portaudio/src/hostapi/alsa/pa_linux_alsa.c', line: 3074
Expression 'self->capture.ready || self->playback.ready' failed in
'src/../../../portaudio/src/hostapi/alsa/pa_linux_alsa.c', line: 3074
Expression 'self->capture.ready || self->playback.ready' failed in
'src/../../../portaudio/src/hostapi/alsa/pa_linux_alsa.c', line: 3074
Expression 'self->capture.ready || self->playback.ready' failed in
'src/../../../portaudio/src/hostapi/alsa/pa_linux_alsa.c', line: 3074
Expression 'self->capture.ready || self->playback.ready' failed in
'src/../../../portaudio/src/hostapi/alsa/pa_linux_alsa.c', line: 3074

from this state i can't correctly quit application...


2) DEVICE - without DMIX (pure device)
-------------------------------------------------------------
when XRUN occured PA try recover from XRUN and sound still playing:

PaAlsaStream_HandleXrun: restarting Alsa to recover from XRUN
AlsaStop: Dropped frames
AlsaRestart: Restarted audio
PaAlsaStream_HandleXrun: restarting Alsa to recover from XRUN
AlsaStop: Dropped frames
AlsaRestart: Restarted audio
PaAlsaStream_HandleXrun: restarting Alsa to recover from XRUN
AlsaStop: Dropped frames
AlsaRestart: Restarted audio
PaAlsaStream_HandleXrun: restarting Alsa to recover from XRUN
AlsaStop: Dropped frames
AlsaRestart: Restarted audio

..all works fine.


PJSUA
====================================
this application behaves somewhat differently..

1) DEVICE - with DMIX
-------------------------------------------------------------
with this device application behave same like AUDDEMO.
when XRUN occured and CPU is little overload these logs are print:

PaAlsaStream_HandleXrun: restarting Alsa to recover from XRUN
AlsaStop: Dropped frames
AlsaRestart: Restarted audio
PaAlsaStream_HandleXrun: restarting Alsa to recover from XRUN
AlsaStop: Dropped frames
AlsaRestart: Restarted audio

and when CPU is more overload :

PaAlsaStream_WaitForFrames: poll timed out, returning error
Expression 'paTimedOut' failed in
'src/../../../portaudio/src/hostapi/alsa/pa_linux_alsa.c', line: 2991
Expression 'self->capture.ready || self->playback.ready' failed in

..sound stop playing and application is broken..can't leave from application.

2) DEVICE - without DMIX (pure device)
-------------------------------------------------------------
this behave is different like in AUDDEMO.

when XRUN occured sound stop playing and lot of logs are print:

PaAlsaStream_HandleXrun: restarting Alsa to recover from XRUN
AlsaStop: Dropped frames
AlsaRestart: Restarted audio
PaAlsaStream_HandleXrun: restarting Alsa to recover from XRUN
AlsaStop: Dropped frames
AlsaRestart: Restarted audio
PaAlsaStream_HandleXrun: restarting Alsa to recover from XRUN
AlsaStop: Dropped frames
AlsaRestart: Restarted audio
PaAlsaStream_HandleXrun: restarting Alsa to recover from XRUN
AlsaStop: Dropped frames
AlsaRestart: Restarted audio

from this state i can't correctly quit application.


it seems the problem is almost solved. Only one thing. When these
logs occured and application is broken:

PaAlsaStream_WaitForFrames: poll timed out, returning error
Expression 'paTimedOut' failed in
'src/../../../portaudio/src/hostapi/alsa/pa_linux_alsa.c', line: 2991


I think the problem with "pure device" - PJSUA is in PJSUA application.
(or maybe not :) )

If i can some help with testing new patches or new logs for understanding what
happens just send me patch and i try it.


thanks

Post by Dmitry Kostjuchenko
Hello Damian,
Thanks for reporting the crash. I reverted changes from previous patch (non-
MMAPed buffer size hardcoding) and
now it works as before, although non-MMAPed buffer size needs rework for
optimal latency.
The patch is commited.
Best regards,
Dmitry.

Post by Damian Minkov
Hi,
we are using portaudio in sip-communicator wrapped in JNI and with
blocking api. I was very happy to see latest changes comments as we
also have some problems on linux systems. The problems we face seems
the same as those described in current mail thread. I was eager to
test those changes, but they seems to broke something, cause I have a
crash when running with them.
I tried investigating the problem and as we are using blocking api I
tried running test patest_read_write_wire with revision 1501 which
works and with revision 1502 which crashes.

[Peter Lukac]

hello everyone

i have another problem with version:
pa_snapshot.tgz created Monday, 31-May-2010 21:37:05 PDT

when i only open sound device and nothing is playing and CPU is not overload i
get these logs:

ContinuePoll: Trying to poll again for playback frames, pollTimeout: 19
ContinuePoll: Trying to poll again for playback frames, pollTimeout: 8
ContinuePoll: Stopping poll for playback
PaAlsaStream_HandleXrun: restarting Alsa to recover from XRUN
AlsaStop: Dropped frames
AlsaRestart: Restarted audio
PaAlsaStream_HandleXrun: restarting Alsa to recover from XRUN
AlsaStop: Dropped frames
AlsaRestart: Restarted audio
PaAlsaStream_HandleXrun: restarting Alsa to recover from XRUN
AlsaStop: Dropped frames
AlsaRestart: Restarted audio
....
....
few logs later:

PaAlsaStream_HandleXrun: restarting Alsa to recover from XRUN
AlsaStop: Dropped frames
AlsaRestart: Restarted audio
ContinuePoll: Stopping poll for playback
PaAlsaStream_HandleXrun: restarting Alsa to recover from XRUN
AlsaStop: Dropped frames
AlsaRestart: Restarted audio


I can quit application but i can't play sound...

some advice?

thanks

[Dmitry Kostjuchenko]

Hello Peter,

Do you run PA in full-duplex mode? The logs you showed indicate dead loop happening in some specific situation.
Would be better if you could have some small example to simulate behavior then it would be easier to try fixing an issue.

What is the system are you trying to run your app on?

Dmitry.

Post by Peter Lukac
hello everyone
pa_snapshot.tgz created Monday, 31-May-2010 21:37:05 PDT
when i only open sound device and nothing is playing and CPU is not overload i
ContinuePoll: Trying to poll again for playback frames, pollTimeout: 19
ContinuePoll: Trying to poll again for playback frames, pollTimeout: 8
ContinuePoll: Stopping poll for playback
PaAlsaStream_HandleXrun: restarting Alsa to recover from XRUN
AlsaStop: Dropped frames
AlsaRestart: Restarted audio
PaAlsaStream_HandleXrun: restarting Alsa to recover from XRUN
AlsaStop: Dropped frames
AlsaRestart: Restarted audio
PaAlsaStream_HandleXrun: restarting Alsa to recover from XRUN
AlsaStop: Dropped frames
AlsaRestart: Restarted audio
....
....
PaAlsaStream_HandleXrun: restarting Alsa to recover from XRUN
AlsaStop: Dropped frames
AlsaRestart: Restarted audio
ContinuePoll: Stopping poll for playback
PaAlsaStream_HandleXrun: restarting Alsa to recover from XRUN
AlsaStop: Dropped frames
AlsaRestart: Restarted audio
I can quit application but i can't play sound...
some advice?
thanks
_______________________________________________
Portaudio mailing list
Portaudio at music.columbia.edu
http://music.columbia.edu/mailman/listinfo/portaudio

-------------------------
iAuxSoft: Middleware SDK
[http://www.iauxsoft.com]

[Peter Lukac]

Hi Dmitry,

What do you mean with full-duplex? If you mean open playback and capture
device at the same time then yes.. I don't have time now for make test
aplication but as soon as posible i make application and try simulate problem.
I don't use PA directly i use application that uses PA.


regards

Post by Dmitry Kostjuchenko
Hello Peter,
Do you run PA in full-duplex mode? The logs you showed indicate dead loop
happening in some specific situation. Would be better if you could have
some small example to simulate behavior then it would be easier to try
fixing an issue.
What is the system are you trying to run your app on?
Dmitry.

[Dmitry Kostjuchenko]

Hi RJ!

Seems that the behavior you describe is one more bug in PA Alsa. I examined poll() region in PA implementation
and apparently poll() == 0 situation was not processed, thus is poll() is returning only 0 results all the time we get
deadlock. To circumvalent situation I added processing of timeouts which is simple counter which counts up to 128
(around 8 sec) and if reached function returns timeout error. Thus patest_sine example works now and does not
deadlock anymore with $ pasuspender bin/patest_sine.

I am not sure that thread join timout somehow connected to such situation, but definitely not processing poll() 0
results led to 100% deadlock.

I havn't commited patch to PA SVN, but tested it my self. I would like to provide it to you for test as well. If it
behaives ok for you as well I will put changes to PA SVN then.

Link: http://rapidshare.com/files/393004598/pa_linux_alsa.zip.html

Best regards,
Dmitry.
?

Post by RJ Ryan
Hi Dimitry,
?
I have tried your patch and it does not resolve the problem for me, though as you'll see I am not exactly

experiencing the same hang as you. In my case, I can easily reproduce the hang on joining threads by running the
patest_sine program in conjunction with pasuspender. I am on Ubuntu Lucid 10.04 using portaudio trunk. I run

Post by RJ Ryan
?
$ pasuspender bin/patest_sine?
?
The 'default' ALSA device is chosen, which is a pulse device (according to the PA debug output). The hang is

likely because the default device is a pulse device, which has been suspended via pasuspender.?I have threaded
many PA_DEBUG's throughout the code, similar to yours.

Post by RJ Ryan
?
In my case, PaAlsaStream_HandleXrun handler is never run. Correspondingly, the revents flag never takes on a

value of 8 (POLLERR). It is 4 (POLLOUT) once, and then 0 for the rest of time.?

Post by RJ Ryan
?
Here is some debug output I have collected:?
...
BuildDeviceList: Found plugin default of type pulse
BuildDeviceList: Found plugin pulse of type pulse
...
Play for 5 seconds.
PaAlsaStream_WaitForFrames Begin
About to poll()
poll() wokeup >=0 result: 1
snd_pcm_state is 2
result: 1 revenrs: 4, count: 1 fd: 3?
PaAlsaStream_WaitForFrames ended
?
PaAlsaStreamComponent_EndProcessing numFrames 2048
begin writei
end writei, res: 2048
PaAlsaStreamComponent_EndProcessing numFrames 2048
begin writei
end writei, res: 2048
PaAlsaStreamComponent_EndProcessing numFrames 2048
begin writei
end writei, res: 2048
PaAlsaStream_WaitForFrames
About to poll()
poll() wokeup >=0 result: 0
snd_pcm_state is 3
result: 0 revenrs: 0, count: 1 fd: 3?
About to poll()
poll() wokeup >=0 result: 0
snd_pcm_state is 3
... repeat forever
?
As you can see, PA gets the POLLOUT revent, and writes 3x2048 to the device. From then on poll() just times

out repeatedly. As I said, this is probably because I have run pasuspender to suspend the pulse device, and
patest_sine picks the 'default' device which is a pulse device. Regardless, portaudio should not fail to exit in this
case because this results in nasty hangs. Is this a situation that calls for a timeout in joining the thread? Is there
another saner way to determine that the device is hung and not responding??

Post by RJ Ryan
?
Best regards,
RJ Ryan
?

-------------------------
iAuxSoft: Middleware SDK
[http://www.iauxsoft.com]

[Albert Santoni]

Hi Dmitry,

Thanks for the updated patch, I'll test this out over the next day and
see if it resolves our problems. (I just tested the previous patch and
it didn't fix it for me.)

In the meantime, because of how important this is to Mixxx and our
users, we'd like to offer bounty on this problem as extra
encouragement. :) I've created a Pledgie page for the bounty, which
currently sits at $125 USD:
http://pledgie.com/campaigns/10964

Thanks,
Albert




On Sat, May 29, 2010 at 11:49 AM, Dmitry Kostjuchenko

Post by Dmitry Kostjuchenko
Hi RJ!
Seems that the behavior you describe is one more bug in PA Alsa. I examined poll() region in PA implementation
and apparently poll() == 0 situation was not processed, thus is poll() is returning only 0 results all the time we get
deadlock. To circumvalent situation I added processing of timeouts which is simple counter which counts up to 128
(around 8 sec) and if reached function returns timeout error. Thus patest_sine example works now and does not
deadlock anymore with $ pasuspender bin/patest_sine.
I am not sure that thread join timout somehow connected to such situation, but definitely not processing poll() 0
results led to 100% deadlock.
I havn't commited patch to PA SVN, but tested it my self. I would like to provide it to you for test as well. If it
behaives ok for you as well I will put changes to PA SVN then.
Link: http://rapidshare.com/files/393004598/pa_linux_alsa.zip.html
Best regards,
Dmitry.

Post by RJ Ryan
Hi Dimitry,
I have tried your patch and it does not resolve the problem for me, though as you'll see I am not exactly

experiencing the same hang as you. In my case, I can easily reproduce the hang on joining threads by running the
patest_sine program in conjunction with pasuspender. I am on Ubuntu Lucid 10.04 using portaudio trunk. I run

Post by RJ Ryan
$ pasuspender bin/patest_sine
The 'default' ALSA device is chosen, which is a pulse device (according to the PA debug output). The hang is

likely because the default device is a pulse device, which has been suspended via pasuspender.?I have threaded
many PA_DEBUG's throughout the code, similar to yours.

Post by RJ Ryan
In my case, PaAlsaStream_HandleXrun handler is never run. Correspondingly, the revents flag never takes on a

value of 8 (POLLERR). It is 4 (POLLOUT) once, and then 0 for the rest of time.

Post by RJ Ryan
...
BuildDeviceList: Found plugin default of type pulse
BuildDeviceList: Found plugin pulse of type pulse
...
Play for 5 seconds.
PaAlsaStream_WaitForFrames Begin
About to poll()
poll() wokeup >=0 result: 1
snd_pcm_state is 2
result: 1 revenrs: 4, count: 1 fd: 3
PaAlsaStream_WaitForFrames ended
PaAlsaStreamComponent_EndProcessing numFrames 2048
begin writei
end writei, res: 2048
PaAlsaStreamComponent_EndProcessing numFrames 2048
begin writei
end writei, res: 2048
PaAlsaStreamComponent_EndProcessing numFrames 2048
begin writei
end writei, res: 2048
PaAlsaStream_WaitForFrames
About to poll()
poll() wokeup >=0 result: 0
snd_pcm_state is 3
result: 0 revenrs: 0, count: 1 fd: 3
About to poll()
poll() wokeup >=0 result: 0
snd_pcm_state is 3
... repeat forever
As you can see, PA gets the POLLOUT revent, and writes 3x2048 to the device. From then on poll() just times

out repeatedly. As I said, this is probably because I have run pasuspender to suspend the pulse device, and
patest_sine picks the 'default' device which is a pulse device. Regardless, portaudio should not fail to exit in this
case because this results in nasty hangs. Is this a situation that calls for a timeout in joining the thread? Is there
another saner way to determine that the device is hung and not responding?

Post by RJ Ryan
Best regards,
RJ Ryan

-------------------------
iAuxSoft: Middleware SDK
[http://www.iauxsoft.com]
_______________________________________________
Portaudio mailing list
Portaudio at music.columbia.edu
http://music.columbia.edu/mailman/listinfo/portaudio

[Dmitry Kostjuchenko]

Hello Damian,

Thanks for reporting the crash. I reverted changes from previous patch (non-MMAPed buffer size?hardcoding) and
now it works as before, although non-MMAPed buffer size needs rework for optimal latency.?

The patch is commited.

Best regards,
Dmitry.
?

Post by Damian Minkov
Hi,
we are using portaudio in sip-communicator wrapped in JNI and with
blocking api. I was very happy to see latest changes comments as we
also have some problems on linux systems. The problems we face seems
the same as those described in current mail thread. I was eager to
test those changes, but they seems to broke something, cause I have a
crash when running with them.
I tried investigating the problem and as we are using blocking api I
tried running test patest_read_write_wire with revision 1501 which
works and with revision 1502 which crashes.
Any suggestions?
Thanks
damencho

[Reid Bishop]

All,

My C# SDR application is written to work with non-interleaved buffers. All
works fine with MME, DirectSound, and ASIO- but I crash miserably when using
WASAPI. Note that I have no way yet to test ASIO on Windows 7, but it
worked fine on XP when that computer was alive.

I can also verify that WASAPI works fine with the typical test programs such
as patest_sine.c, pa_minlat.c, etc.

I have a test program that I found on the net some time ago, that tests
nonInterleaved buffers- although this test program uses blocking I/O, rather
than callbacks. This at least allowed me to directly use the Visual Studio
debugger to track this crash down a bit more. This test program works fine
with MME, doesn't do a thing with DirectSound (it just feeds all the data in
a loop, never blocks, and exits immediately), and also crashes miserably
with WASAPI.

Here's where PA crashes using WASAPI with the nonInterleaved blocking test
program:

msvcr90d.dll!memcpy(unsigned char * dst=0x00570800, unsigned char *
src=0x001936b4, unsigned long count=0x00001e00) Line 188 Asm

portaudio_devtest.exe!WriteStream(void * s=0x005af8f8, const void *
_buffer=0x0018fab4, unsigned long _frames=0x00002000) pa_win_wasapi.c, Line
2896 + 0x14 bytes
(the function being called is "memcpy(data, buffer, buffer_size);"

portaudio_devtest.exe!Pa_WriteStream(void * stream=0x005af8f8, const
void * buffer=0x0018fab4, unsigned long frames=0x00002000) pa_front.c, Line
1656 + 0x19 bytes
(the function being called is "result = PA_STREAM_INTERFACE(stream)->Write(
stream, buffer, frames );"

portaudio_devtest.exe!writeLoop(void * stream=0x005af8f8, PaTestData
* data=0x0018fbc4) Line 83 + 0x12 bytes

portaudio_devtest.exe!main() Line 130 + 0x10 bytes

portaudio_devtest.exe!__tmainCRTStartup() Line 586 + 0x19 bytes

portaudio_devtest.exe!mainCRTStartup() Line 403
kernel32.dll!76ec3677()
[Frames below may be incorrect and/or missing, no symbols loaded for
kernel32.dll]
ntdll.dll!773e9d72()
ntdll.dll!773e9d45()

I would have tried to run a simple C program that utilizes nonInterleaved
buffers and the callback methodology, but couldn't find one. I may try to
write one depending on what the lowdown is with WASAPI.

-Reid-
W0CNN
CNNSDR Development

[Dmitry Kostjuchenko]

Hi Reid,
Non-interlieved buffers are not supported with WASAPI and blocking
interface. I missed its implementation and will do so soon.
Best regards,
Dmitry.

Post by Reid Bishop
All,
My C# SDR application is written to work with non-interleaved
buffers. All
works fine with MME, DirectSound, and ASIO- but I crash miserably when using
WASAPI. Note that I have no way yet to test ASIO on Windows 7, but
it
worked fine on XP when that computer was alive.
I can also verify that WASAPI works fine with the typical test
programs such
as patest_sine.c, pa_minlat.c, etc.
I have a test program that I found on the net some time ago, that tests
nonInterleaved buffers- although this test program uses blocking I/O, rather
than callbacks. This at least allowed me to directly use the Visual
Studio
debugger to track this crash down a bit more. This test program
works fine
with MME, doesn't do a thing with DirectSound (it just feeds all the data in
a loop, never blocks, and exits immediately), and also crashes
miserably
with WASAPI.
Here's where PA crashes using WASAPI with the nonInterleaved
blocking test
msvcr90d.dll!memcpy(unsigned char * dst=0x00570800, unsigned char *
src=0x001936b4, unsigned long count=0x00001e00) Line 188 Asm
portaudio_devtest.exe!WriteStream(void * s=0x005af8f8, const void *
_buffer=0x0018fab4, unsigned long _frames=0x00002000)
pa_win_wasapi.c, Line
2896 + 0x14 bytes
(the function being called is "memcpy(data, buffer, buffer_size);"
portaudio_devtest.exe!Pa_WriteStream(void * stream=0x005af8f8, const
void * buffer=0x0018fab4, unsigned long frames=0x00002000)
pa_front.c, Line
1656 + 0x19 bytes
(the function being called is "result =
PA_STREAM_INTERFACE(stream)->Write(
stream, buffer, frames );"
portaudio_devtest.exe!writeLoop(void * stream=0x005af8f8, PaTestData
* data=0x0018fbc4) Line 83 + 0x12 bytes
portaudio_devtest.exe!main() Line 130 + 0x10 bytes
portaudio_devtest.exe!__tmainCRTStartup() Line 586 + 0x19 bytes
portaudio_devtest.exe!mainCRTStartup() Line 403
kernel32.dll!76ec3677()
[Frames below may be incorrect and/or missing, no symbols loaded for
kernel32.dll]
ntdll.dll!773e9d72()
ntdll.dll!773e9d45()
I would have tried to run a simple C program that utilizes
nonInterleaved
buffers and the callback methodology, but couldn't find one. I may
try to
write one depending on what the lowdown is with WASAPI.
-Reid-
W0CNN
CNNSDR Development
_______________________________________________
Portaudio mailing list
Portaudio at music.columbia.edu
http://music.columbia.edu/mailman/listinfo/portaudio

-------------------------
iAuxSoft: Middleware SDK
[http://www.iauxsoft.com]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://music.columbia.edu/pipermail/portaudio/attachments/20100531/f7a1cd1d/attachment-0001.html>

[Dmitry Kostjuchenko]

Furthermore to this issue: I just implemented non-Interlieved buffers
for WASAPI so that you can test them in your app.

Post by Dmitry Kostjuchenko
Hi Reid,
Non-interlieved buffers are not supported with WASAPI and blocking
interface. I missed its implementation and will do so soon.
Best regards,
Dmitry.

Post by Reid Bishop
All,
My C# SDR application is written to work with non-interleaved
buffers. All
works fine with MME, DirectSound, and ASIO- but I crash miserably when using
WASAPI. Note that I have no way yet to test ASIO on Windows 7, but
it
worked fine on XP when that computer was alive.
I can also verify that WASAPI works fine with the typical test programs such
as patest_sine.c, pa_minlat.c, etc.
I have a test program that I found on the net some time ago, that tests
nonInterleaved buffers- although this test program uses blocking I/O, rather
than callbacks. This at least allowed me to directly use the Visual
Studio
debugger to track this crash down a bit more. This test program
works fine
with MME, doesn't do a thing with DirectSound (it just feeds all the data in
a loop, never blocks, and exits immediately), and also crashes miserably
with WASAPI.
Here's where PA crashes using WASAPI with the nonInterleaved
blocking test
msvcr90d.dll!memcpy(unsigned char * dst=0x00570800, unsigned char *
src=0x001936b4, unsigned long count=0x00001e00) Line 188 Asm
portaudio_devtest.exe!WriteStream(void * s=0x005af8f8, const void *
_buffer=0x0018fab4, unsigned long _frames=0x00002000)
pa_win_wasapi.c, Line
2896 + 0x14 bytes
(the function being called is "memcpy(data, buffer, buffer_size);"
portaudio_devtest.exe!Pa_WriteStream(void * stream=0x005af8f8, const
void * buffer=0x0018fab4, unsigned long frames=0x00002000)
pa_front.c, Line
1656 + 0x19 bytes
(the function being called is "result =
PA_STREAM_INTERFACE(stream)->Write(
stream, buffer, frames );"
portaudio_devtest.exe!writeLoop(void * stream=0x005af8f8,
PaTestData
* data=0x0018fbc4) Line 83 + 0x12 bytes
portaudio_devtest.exe!main() Line 130 + 0x10 bytes
portaudio_devtest.exe!__tmainCRTStartup() Line 586 + 0x19 bytes
portaudio_devtest.exe!mainCRTStartup() Line 403
kernel32.dll!76ec3677()
[Frames below may be incorrect and/or missing, no symbols loaded for
kernel32.dll]
ntdll.dll!773e9d72()
ntdll.dll!773e9d45()
I would have tried to run a simple C program that utilizes
nonInterleaved
buffers and the callback methodology, but couldn't find one. I may
try to
write one depending on what the lowdown is with WASAPI.
-Reid-
W0CNN
CNNSDR Development
_______________________________________________
Portaudio mailing list
Portaudio at music.columbia.edu
http://music.columbia.edu/mailman/listinfo/portaudio

-------------------------
iAuxSoft: Middleware SDK
[http://www.iauxsoft.com]

-------------------------
iAuxSoft: Middleware SDK
[http://www.iauxsoft.com]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://music.columbia.edu/pipermail/portaudio/attachments/20100531/6a0a06bc/attachment.html>

[Reid Bishop]

Dmitri- wow, you are fast! I'll try it a bit later today.



Are non-interleaved buffers supported by WASAPI using callback interface?
That's where I first had the crash in my C# application- which uses the
callback interface.



-Reid-

W0CNN

CNNSDR Development



_____

From: portaudio-bounces at music.columbia.edu
[mailto:portaudio-bounces at music.columbia.edu] On Behalf Of Dmitry
Kostjuchenko
Sent: Monday, May 31, 2010 3:52 AM
To: Portaudio Mailing List
Subject: Re: [Portaudio] WASAPI supports paNonInterleaved?



Furthermore to this issue: I just implemented non-Interlieved buffers for
WASAPI so that you can test them in your app.

Quoting Dmitry Kostjuchenko <dmitrykos at inbox.lv>:

Hi Reid,

Non-interlieved buffers are not supported with WASAPI and blocking
interface. I missed its implementation and will do so soon.

Best regards,
Dmitry.

Quoting Reid Bishop < <mailto:rbish at attglobal.net> rbish at attglobal.net>:

All,

My C# SDR application is written to work with non-interleaved buffers. All
works fine with MME, DirectSound, and ASIO- but I crash miserably when using
WASAPI

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://music.columbia.edu/pipermail/portaudio/attachments/20100531/e269cc28/attachment.html>

[Dmitry Kostjuchenko]

Hi Reid!

Callback interface supports non-Interlieving buffer from inside of PA top-level layer thus implementation layer does
not really bother about it. I checke modified example with sine using non-Interlieving buffer - all is ok, sine is
playing correctly.

It is strange why you got crash with callback, may be you mixed things up?, because the log output you attached
showed that your app was using blocking interface (Pa_GetStreamWriteAvailable/Pa_WriteStream).

Regards,
Dmitry.

Dmitri- wow, you are fast!? I?ll try it a bit later today.
?
Are non-interleaved buffers supported by WASAPI using callback interface?? That?s where I first had the crash in

my C# application- which uses the callback interface.

?
-Reid-
W0CNN
CNNSDR Development
?
From:portaudio-bounces at music.columbia.edu [mailto:portaudio-bounces at music.columbia.edu] On Behalf Of

Dmitry Kostjuchenko

Sent: Monday, May 31, 2010 3:52 AM
To: Portaudio Mailing List
Subject: Re: [Portaudio] WASAPI supports paNonInterleaved?
?
Furthermore to this issue: I just implemented non-Interlieved buffers for WASAPI so that you can test them in

your app.

Post by Dmitry Kostjuchenko
Hi Reid,
Non-interlieved buffers are not supported with WASAPI and blocking interface. I missed its implementation and

will do so soon.

Post by Dmitry Kostjuchenko
Best regards,
Dmitry.

Post by Reid Bishop
All,
My C# SDR application is written to work with non-interleaved buffers. All
works fine with MME, DirectSound, and ASIO- but I crash miserably when using
WASAPI

-------------------------
iAuxSoft: Middleware SDK
[http://www.iauxsoft.com]

[Reid Bishop]

Dmitry,

Yes- the debug output I showed you was using a C test program that uses
blocking interface. I have no way to debug PA within a C# program, so I had
to revert to a C test program. Unfortunately, I only have a test program
that uses a blocking interface!

It looks like I will have to find a better way to debug PA within my C#
program. Right now, I get a hard crash when I call Pa_StartStream with
WASAPI. I have no idea how to determine what is causing the problem. All
my code is rock-solid with MME and DirectSound.

PA_OpenStream is fine... all parameters look good.
My Callback routine never gets called- the crash occurs immediately after
Pa_StartStream is called.

Any thoughts?

-Reid-
W0CNN
CNNSDR Development

-----Original Message-----
From: portaudio-bounces at music.columbia.edu
[mailto:portaudio-bounces at music.columbia.edu] On Behalf Of Dmitry
Kostjuchenko
Sent: Monday, May 31, 2010 11:48 AM
To: Portaudio Mailing List
Subject: Re: [Portaudio] WASAPI supports paNonInterleaved?

Hi Reid!

Callback interface supports non-Interlieving buffer from inside of PA
top-level layer thus implementation layer does
not really bother about it. I checke modified example with sine using
non-Interlieving buffer - all is ok, sine is
playing correctly.

It is strange why you got crash with callback, may be you mixed things up?,
because the log output you attached
showed that your app was using blocking interface
(Pa_GetStreamWriteAvailable/Pa_WriteStream).

Regards,
Dmitry.

Dmitri- wow, you are fast!? I?ll try it a bit later today.
?
Are non-interleaved buffers supported by WASAPI using callback interface??

That?s where I first had the crash in
my C# application- which uses the callback interface.

?
-Reid-
W0CNN
CNNSDR Development
?
From:portaudio-bounces at music.columbia.edu

[mailto:portaudio-bounces at music.columbia.edu] On Behalf Of
Dmitry Kostjuchenko

Sent: Monday, May 31, 2010 3:52 AM
To: Portaudio Mailing List
Subject: Re: [Portaudio] WASAPI supports paNonInterleaved?
?
Furthermore to this issue: I just implemented non-Interlieved buffers for

WASAPI so that you can test them in
your app.

Post by Dmitry Kostjuchenko
Hi Reid,
Non-interlieved buffers are not supported with WASAPI and blocking

interface. I missed its implementation and
will do so soon.

Post by Dmitry Kostjuchenko
Best regards,
Dmitry.

Post by Reid Bishop
All,
My C# SDR application is written to work with non-interleaved buffers. All
works fine with MME, DirectSound, and ASIO- but I crash miserably when using
WASAPI

-------------------------
iAuxSoft: Middleware SDK
[http://www.iauxsoft.com]

[Reid Bishop]

Dmitry,

Does your test program utilize both Input and Output parameters? Mine does-
so perhaps that is the difference.

Could you attach your test program for non-interleaved, callback based
routine? I could then test it to make sure it isn't a problem with my
WASAPI driver.

-Reid-
W0CNN
CNNSDR Development

-----Original Message-----
From: portaudio-bounces at music.columbia.edu
[mailto:portaudio-bounces at music.columbia.edu] On Behalf Of Reid Bishop
Sent: Monday, May 31, 2010 12:08 PM
To: 'Portaudio Mailing List'
Subject: Re: [Portaudio] WASAPI supports paNonInterleaved?

Dmitry,

Yes- the debug output I showed you was using a C test program that uses
blocking interface. I have no way to debug PA within a C# program, so I had
to revert to a C test program. Unfortunately, I only have a test program
that uses a blocking interface!

It looks like I will have to find a better way to debug PA within my C#
program. Right now, I get a hard crash when I call Pa_StartStream with
WASAPI. I have no idea how to determine what is causing the problem. All
my code is rock-solid with MME and DirectSound.

PA_OpenStream is fine... all parameters look good.
My Callback routine never gets called- the crash occurs immediately after
Pa_StartStream is called.

Any thoughts?

-Reid-
W0CNN
CNNSDR Development

-----Original Message-----
From: portaudio-bounces at music.columbia.edu
[mailto:portaudio-bounces at music.columbia.edu] On Behalf Of Dmitry
Kostjuchenko
Sent: Monday, May 31, 2010 11:48 AM
To: Portaudio Mailing List
Subject: Re: [Portaudio] WASAPI supports paNonInterleaved?

Hi Reid!

Callback interface supports non-Interlieving buffer from inside of PA
top-level layer thus implementation layer does
not really bother about it. I checke modified example with sine using
non-Interlieving buffer - all is ok, sine is
playing correctly.

It is strange why you got crash with callback, may be you mixed things up?,
because the log output you attached
showed that your app was using blocking interface
(Pa_GetStreamWriteAvailable/Pa_WriteStream).

Regards,
Dmitry.

Dmitri- wow, you are fast!? I?ll try it a bit later today.
?
Are non-interleaved buffers supported by WASAPI using callback interface??

That?s where I first had the crash in
my C# application- which uses the callback interface.

?
-Reid-
W0CNN
CNNSDR Development
?
From:portaudio-bounces at music.columbia.edu

[mailto:portaudio-bounces at music.columbia.edu] On Behalf Of
Dmitry Kostjuchenko

Sent: Monday, May 31, 2010 3:52 AM
To: Portaudio Mailing List
Subject: Re: [Portaudio] WASAPI supports paNonInterleaved?
?
Furthermore to this issue: I just implemented non-Interlieved buffers for

WASAPI so that you can test them in
your app.

Post by Dmitry Kostjuchenko
Hi Reid,
Non-interlieved buffers are not supported with WASAPI and blocking

interface. I missed its implementation and
will do so soon.

Post by Dmitry Kostjuchenko
Best regards,
Dmitry.

Post by Reid Bishop
All,
My C# SDR application is written to work with non-interleaved buffers. All
works fine with MME, DirectSound, and ASIO- but I crash miserably when using
WASAPI

-------------------------
iAuxSoft: Middleware SDK
[http://www.iauxsoft.com]

_______________________________________________
Portaudio mailing list
Portaudio at music.columbia.edu
http://music.columbia.edu/mailman/listinfo/portaudio

[Dmitry Kostjuchenko]

Reid,

I attached an example which utilizes non-interlieved 2-ch buffer to play sine. Please test it. Although could it be a
problem due to full-duplex operation may be?

You can enable debugging of unmanaged code in C# by the way, to do so you need (if Visual Studio used):
1) in C# project settings: go to Debug tab and?set?check box - Enable unmanaged code debugging;
2) Compile PA DLL in Debug mode and make sure PDB file which was created for portaudio_x86.dll is located in
the same directory where PA DLL is;
3) In Visual Studio, in top Menu Debug->Exceptions and make sure all check boxes marked;
4) Run your app and wait for an exception to be thrown, the debugger shall guide you to the source file of PA lib
where exception happened.

If you manage to get callstack and findout where exception happened it would definitely help. Meanwhile I will test
full-duplex with non-interlieved buffers as well.

Best regards,
Dmitry.

Post by Peter Lukac
Dmitry,
Does your test program utilize both Input and Output parameters? Mine does-
so perhaps that is the difference.
Could you attach your test program for non-interleaved, callback based
routine? I could then test it to make sure it isn't a problem with my
WASAPI driver.
-Reid-
W0CNN
CNNSDR Development
-----Original Message-----
From: portaudio-bounces at music.columbia.edu
[mailto:portaudio-bounces at music.columbia.edu] On Behalf Of Reid Bishop
Sent: Monday, May 31, 2010 12:08 PM
To: 'Portaudio Mailing List'
Subject: Re: [Portaudio] WASAPI supports paNonInterleaved?
Dmitry,
Yes- the debug output I showed you was using a C test program that uses
blocking interface. I have no way to debug PA within a C# program, so I had
to revert to a C test program. Unfortunately, I only have a test program
that uses a blocking interface!
It looks like I will have to find a better way to debug PA within my C#
program. Right now, I get a hard crash when I call Pa_StartStream with
WASAPI. I have no idea how to determine what is causing the problem. All
my code is rock-solid with MME and DirectSound.
PA_OpenStream is fine... all parameters look good.
My Callback routine never gets called- the crash occurs immediately after
Pa_StartStream is called.
Any thoughts?
-Reid-
W0CNN
CNNSDR Development
-----Original Message-----
From: portaudio-bounces at music.columbia.edu
[mailto:portaudio-bounces at music.columbia.edu] On Behalf Of Dmitry
Kostjuchenko
Sent: Monday, May 31, 2010 11:48 AM
To: Portaudio Mailing List
Subject: Re: [Portaudio] WASAPI supports paNonInterleaved?
Hi Reid!
Callback interface supports non-Interlieving buffer from inside of PA
top-level layer thus implementation layer does
not really bother about it. I checke modified example with sine using
non-Interlieving buffer - all is ok, sine is
playing correctly.
It is strange why you got crash with callback, may be you mixed things up?,
because the log output you attached
showed that your app was using blocking interface
(Pa_GetStreamWriteAvailable/Pa_WriteStream).
Regards,
Dmitry.

Dmitri- wow, you are fast!? I?ll try it a bit later today.
?
Are non-interleaved buffers supported by WASAPI using callback interface??

That?s where I first had the crash in
my C# application- which uses the callback interface.

?
-Reid-
W0CNN
CNNSDR Development
?
From:portaudio-bounces at music.columbia.edu

[mailto:portaudio-bounces at music.columbia.edu] On Behalf Of
Dmitry Kostjuchenko

Sent: Monday, May 31, 2010 3:52 AM
To: Portaudio Mailing List
Subject: Re: [Portaudio] WASAPI supports paNonInterleaved?
?
Furthermore to this issue: I just implemented non-Interlieved buffers for

WASAPI so that you can test them in
your app.

Post by Dmitry Kostjuchenko
Hi Reid,
Non-interlieved buffers are not supported with WASAPI and blocking

interface. I missed its implementation and
will do so soon.

Post by Dmitry Kostjuchenko
Best regards,
Dmitry.

Post by Reid Bishop
All,
My C# SDR application is written to work with non-interleaved buffers.

All

Post by Dmitry Kostjuchenko

Post by Reid Bishop
works fine with MME, DirectSound, and ASIO- but I crash miserably when

using

Post by Dmitry Kostjuchenko

Post by Reid Bishop
WASAPI

-------------------------
iAuxSoft: Middleware SDK
[http://www.iauxsoft.com]
_______________________________________________
Portaudio mailing list
Portaudio at music.columbia.edu
http://music.columbia.edu/mailman/listinfo/portaudio
_______________________________________________
Portaudio mailing list
Portaudio at music.columbia.edu
http://music.columbia.edu/mailman/listinfo/portaudio
_______________________________________________
Portaudio mailing list
Portaudio at music.columbia.edu

http://music.columbia.edu/mailman/listinfo/portaudio


-------------------------
iAuxSoft: Middleware SDK
[http://www.iauxsoft.com]
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pa_test_sine_wasapi_ni.zip
Type: application/x-zip-compressed
Size: 2914 bytes
Desc: not available
URL: <http://music.columbia.edu/pipermail/portaudio/attachments/20100531/62c97228/attachment.bin>

[Reid Bishop]

Dmitry,

Post by Dmitry Kostjuchenko
I attached an example which utilizes non-interlieved 2-ch buffer to play
sine. Please test it. Although could it be a problem due to full-duplex
operation may be?

Thanks- your example program works fine on my hardware. I noticed your
sampleformat was set to paInt16, so I changed the program to use paFloat32.
It still worked just fine. We are now at the point where the test program
is using the exact same sampleformat, channelcount, etc- so I believe the
problem might be due to using full duplex operation. I'll keep digging here
as best as I can.

Post by Dmitry Kostjuchenko
You can enable debugging of unmanaged code in C# by the way, to do so you
need (if Visual Studio used): ....

I forgot to mention I am using VisualStudio Express- hence I am not given
the option to enable debugging of unmanaged code. As such, I cannot
retrieve the callstack to help find the problem. I am seriously considering
purchasing the non-express version of Visual Studio as it seems I am running
into more and more limitations in the Express edition.

Thanks for the test program- at least I now know my WASAPI driver is
behaving, as is my build of PortAudio.

-Reid-
W0CNN
CNNSDR Development

[Reid Bishop]

Dmitry,

The problem definitely appears to have something to do with operating full
duplex. I have attached a modified version of your test program- you will
see where it crashes when you enable the inputParameters in Pa_OpenStream.

This version of your test program uses paFloat32 sampleformat, and 96000
samplerate- to more closely mimic what my program does.

-Reid-
W0CNN
CNNSDR Development

-----Original Message-----
From: portaudio-bounces at music.columbia.edu
[mailto:portaudio-bounces at music.columbia.edu] On Behalf Of Reid Bishop
Sent: Monday, May 31, 2010 3:08 PM
To: 'Portaudio Mailing List'
Subject: Re: [Portaudio] WASAPI supports paNonInterleaved?

Dmitry,

Post by Dmitry Kostjuchenko
I attached an example which utilizes non-interlieved 2-ch buffer to play
sine. Please test it. Although could it be a problem due to full-duplex
operation may be?

Thanks- your example program works fine on my hardware. I noticed your
sampleformat was set to paInt16, so I changed the program to use paFloat32.
It still worked just fine. We are now at the point where the test program
is using the exact same sampleformat, channelcount, etc- so I believe the
problem might be due to using full duplex operation. I'll keep digging here
as best as I can.

Post by Dmitry Kostjuchenko
You can enable debugging of unmanaged code in C# by the way, to do so you
need (if Visual Studio used): ....

I forgot to mention I am using VisualStudio Express- hence I am not given
the option to enable debugging of unmanaged code. As such, I cannot
retrieve the callstack to help find the problem. I am seriously considering
purchasing the non-express version of Visual Studio as it seems I am running
into more and more limitations in the Express edition.

Thanks for the test program- at least I now know my WASAPI driver is
behaving, as is my build of PortAudio.

-Reid-
W0CNN
CNNSDR Development


_______________________________________________
Portaudio mailing list
Portaudio at music.columbia.edu
http://music.columbia.edu/mailman/listinfo/portaudio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pa_test_sine_wasapi_ni.zip
Type: application/octet-stream
Size: 3084 bytes
Desc: not available
URL: <http://music.columbia.edu/pipermail/portaudio/attachments/20100531/97d9ae1d/attachment.obj>

[Dmitry Kostjuchenko]

Hi Reid,
Ok, WASAPI did not have full-duplex implemented, now it is done and
commited to PA SVN. Your full-duplex example works ok with any WASAPI
supported parameters. Please check how your app works.
Regards,
Dmitry.
&#160;

Post by Peter Lukac
Dmitry,
The problem definitely appears to have something to do with
operating full
duplex. I have attached a modified version of your test program- you
will
see where it crashes when you enable the inputParameters in
Pa_OpenStream.
This version of your test program uses paFloat32 sampleformat, and 96000
samplerate- to more closely mimic what my program does.
-Reid-
W0CNN
CNNSDR Development
-----Original Message-----
From: portaudio-bounces at music.columbia.edu
[mailto:portaudio-bounces at music.columbia.edu] On Behalf Of Reid Bishop
Sent: Monday, May 31, 2010 3:08 PM
To: 'Portaudio Mailing List'
Subject: Re: [Portaudio] WASAPI supports paNonInterleaved?
Dmitry,

Post by Dmitry Kostjuchenko
I attached an example which utilizes non-interlieved 2-ch

buffer to play

Post by Dmitry Kostjuchenko
sine. Please test it. Although could it be a problem due to

full-duplex

Post by Dmitry Kostjuchenko
operation may be?

Thanks- your example program works fine on my hardware. I noticed
your
sampleformat was set to paInt16, so I changed the program to use paFloat32.
It still worked just fine. We are now at the point where the test
program
is using the exact same sampleformat, channelcount, etc- so I
believe the
problem might be due to using full duplex operation. I'll keep
digging here
as best as I can.

Post by Dmitry Kostjuchenko
You can enable debugging of unmanaged code in C# by the way, to

do so you

Post by Dmitry Kostjuchenko
need (if Visual Studio used): ....

I forgot to mention I am using VisualStudio Express- hence I am not given
the option to enable debugging of unmanaged code. As such, I cannot
retrieve the callstack to help find the problem. I am seriously
considering
purchasing the non-express version of Visual Studio as it seems I am running
into more and more limitations in the Express edition.
Thanks for the test program- at least I now know my WASAPI driver is
behaving, as is my build of PortAudio.
-Reid-
W0CNN
CNNSDR Development
_______________________________________________
Portaudio mailing list
Portaudio at music.columbia.edu
http://music.columbia.edu/mailman/listinfo/portaudio

-------------------------
iAuxSoft: Middleware SDK
[http://www.iauxsoft.com]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://music.columbia.edu/pipermail/portaudio/attachments/20100601/705a56cd/attachment.html>

[Reid Bishop]

Dmitry,



Amazing. your new additions to the WASAPI code work wonderfully. I have my
application up and running without any known issues yet using WASAPI in full
duplex. I also have this all running in a 64bit compile, which is an extra
bonus. I am absolutely amazed at the low CPU utilization and the very low
latency of the WASAPI interface. I am still experimenting with how to set
the latency settings (I get an occasional Pop/Click here and there), as how
the latency settings work is entirely different with WASAPI. My application
has dropped to zero CPU utilization using WASAPI on a Dell i580 (two core, 4
hyperthread Intel running 3.2GHZ). Before my application was running 3-4%
CPU using MME or DirectSound. I also use DirectX for all my spectrum graph
drawing, and LOTS of math doing DSP and FFT on the data.



I still have more work to do (I actually need 2 channels in, 2 channels out,
and another stream dedicated to 2 channels for audio listening), so I will
be in a mode where I use WASAPI for 2 in, 2 out, and ASIO for the other 2
channels of listening. I had this setup working with ASIO/MME before on XP,
so I don't anticipate any issues when switching to WASAPI/ASIO.



I thank you SO MUCH for the effort you are pouring into the WASAPI and the
other interfaces. It is really now starting to pay off Dmitry!



-Reid-

W0CNN

CNNSDR Development





_____

From: portaudio-bounces at music.columbia.edu
[mailto:portaudio-bounces at music.columbia.edu] On Behalf Of Dmitry
Kostjuchenko
Sent: Tuesday, June 01, 2010 11:30 AM
To: Portaudio Mailing List
Subject: Re: [Portaudio] WASAPI supports paNonInterleaved?



Hi Reid,

Ok, WASAPI did not have full-duplex implemented, now it is done and commited
to PA SVN. Your full-duplex example works ok with any WASAPI supported
parameters. Please check how your app works.




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://music.columbia.edu/pipermail/portaudio/attachments/20100601/c67dd813/attachment.html>

[Dmitry Kostjuchenko]

Hello Reid,

Thank you very much for a warm words!

I also noticed that WASAPI gives no overhead under Vista/7 in comparison to WMME/DS and that is why took it over to
make it working same as other interfaces in PA. Additionally I added possibility to get WASAPI host buffer pointers
directly to your application by redirecting calls from PA processor to application by using
PaWasapiHostProcessorCallback prototype. This is valuable for example for my app. where exposure of host buffer
gives ability to avoid copying, software rendering core writes directly to it. Although using
PaWasapiHostProcessorCallback skips sample type conversions and etc. so higher-level operations which PA
processing-level layer does are skipped, and it is less flexible and convenient.

Please also note, unlike DS/WMME WASAPI supports 24-bit samples natively without conversions.

As to latency settings, WASAPI interface behaives similar to other PA interfaces, no differences. You have parameter
PaStreamParameters::suggestedLatency set in seconds, for example to set latency as 65 miliseconds you set 0.065
value. User buffer size does not affect latency.

Best regards,
Dmitry.

Post by Peter Lukac
Dmitry,
Amazing. your new additions to the WASAPI code work wonderfully. I have my
application up and running without any known issues yet using WASAPI in full
duplex. I also have this all running in a 64bit compile, which is an extra
bonus. I am absolutely amazed at the low CPU utilization and the very low
latency of the WASAPI interface. I am still experimenting with how to set
the latency settings (I get an occasional Pop/Click here and there), as how
the latency settings work is entirely different with WASAPI. My application
has dropped to zero CPU utilization using WASAPI on a Dell i580 (two core, 4
hyperthread Intel running 3.2GHZ). Before my application was running 3-4%
CPU using MME or DirectSound. I also use DirectX for all my spectrum graph
drawing, and LOTS of math doing DSP and FFT on the data.
I still have more work to do (I actually need 2 channels in, 2 channels out,
and another stream dedicated to 2 channels for audio listening), so I will
be in a mode where I use WASAPI for 2 in, 2 out, and ASIO for the other 2
channels of listening. I had this setup working with ASIO/MME before on XP,
so I don't anticipate any issues when switching to WASAPI/ASIO.
I thank you SO MUCH for the effort you are pouring into the WASAPI and the
other interfaces. It is really now starting to pay off Dmitry!
-Reid-
W0CNN
CNNSDR Development
_____
From: portaudio-bounces at music.columbia.edu
[mailto:portaudio-bounces at music.columbia.edu] On Behalf Of Dmitry
Kostjuchenko
Sent: Tuesday, June 01, 2010 11:30 AM
To: Portaudio Mailing List
Subject: Re: [Portaudio] WASAPI supports paNonInterleaved?
Hi Reid,
Ok, WASAPI did not have full-duplex implemented, now it is done and commited
to PA SVN. Your full-duplex example works ok with any WASAPI supported
parameters. Please check how your app works.

-------------------------
iAuxSoft: Middleware SDK
[http://www.iauxsoft.com]