[Portaudio] pa_linux_alsa.c:3636 Assertion failed (with hack fix)
philburk at mobileer.com
Sun Nov 4 15:52:45 EST 2018
Thanks for working on this.
If all negative error codes are treated as xruns, then might important
errors be ignored?
What happens if a USB device is unplugged when running?
Maybe we should check for specific codes, eg. EPIPE.
On Sun, Nov 4, 2018 at 7:53 AM Alan Horstmann <gineera at aspect135.co.uk>
> Hi Ross & others,
> Thanks for casting an eye over this, and you are right the handling is not
> quite correct.
> Having looked over at it again, where lower level errors are considered to
> due to an Xrun, this is not treated as paUnanticipatedHostError at the
> level up, but rather as a recoverable situation. So I have amended the
> along these lines, not setting an error in the higher function, but still
> exiting early and triggering recovery.
> As for earlier discussion about return types, it is somewhat a matter of
> style, but the PaAlsaStreamComponent_BeginPolling() function is very short
> (probably inlined by the compiler) and PaError is not really appropriate.
> returning the actual Alsa error code there is the potential if needed to
> respond differently to different Alsa errors (although my understanding
> is that recovery action is the appropriate response for all).
> So, here is a version-3 patch - a retest would be appreciated!
> On Wednesday 17 October 2018 11:01, you wrote:
> > Hi Alan,
> > I am no fan of those PA_ENSURE et al macros, however the PA_ENSURE macro
> > usage that you removed sets the `result` local variable prior to jumping
> > to the error: label. I think you should do the same and set `result` to
> > something valid prior to `goto error`.
> > As a side note: it looks to me as though PaAlsaStream_WaitForFrames has
> > the potential to go into an infinite loop if the PA_ENSURE in the error:
> > section fails (since it will just `goto error;` again). But don't let me
> > distract you.
> > Ross.
> > On 16/10/2018 5:54 AM, Alan Horstmann wrote:
> > > On Monday 15 October 2018 04:40, Chameleon wrote:
> > >> I can confirm that it works (by deliberately causing an xrun by taking
> > >> too long in the audiocallback on my system) and from reading the code
> > >> looks correct. I can also confirm that I'm using alsa's dmix plugin.
> > >>
> > >> The only small thing is that PaAlsaStreamComponent_BeginPolling(..)
> > >> a return type of PaError, which may at some point be used with
> > >> Pa_GetErrorText(..) which would then return "Invalid error code" on
> > >> alsa/system error code. A (potential) cosmetic bug on a bug fix that
> > >> stops a library crash, so I offer it entirely as an observation and
> > >> as an issue that requires attention.
> > >
> > > Thanks for the confirmation. Indeed, 'dmix' was mentioned as one
> > > that would return EPIPE to indicate XRUN.
> > >
> > > As far as the return type is concerned, that was something I had also
> > > seen as slightly untidy, but left it in haste to minimise changes.
> > > since the return would not be checked by PA_ENSURE(.), it would really
> > > better to clean it up to an int, and remove 'result' as per this
> > > version-2 patch, attached. Could you check this one instead, please?
> > >
> > > Phil, Ross, are you happy with this change?
> > >
> > > Regards
> > >
> > > Alan
> > >
> > >
> > >
> > > _______________________________________________
> > > Portaudio mailing list
> > > Portaudio at lists.columbia.edu
> > > https://lists.columbia.edu/mailman/listinfo/portaudio
> Portaudio mailing list
> Portaudio at lists.columbia.edu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Portaudio