[Portaudio] Win64 Init crash when JACK is installed
evan at imitone.com
Wed Aug 2 13:59:18 EDT 2017
Sorry for the late reply, but to weigh in on this:
- Alberto has not experienced a crash with portaudio OR Jack; he's just
mentioning his experience with a related hazard.
- There is an open issue <https://github.com/jackaudio/jack2/issues/275>
on the Jack2 GitHub with an almost identical crash message, reported by a
user who built one of their example apps as 64-bit. PortAudio is not
involved in that user's case. This leads me to believe the defect is in
Jack2 for Windows, rather than in portaudio.
Basically, if the JackRouter ASIO interface is making API calls similar to
those in their example code, then it's triggering the problem (which
appears to involve assuming 32-bit pointers somewhere in the pipeline).
– Evan Balster
creator of imitone <http://imitone.com>
On Thu, Jul 27, 2017 at 8:16 PM, Ross Bencina <rossb-lists at audiomulch.com>
> Hi Phil,
> Alberto described some general problems with porting 32-bit C code to
> 64-bit. I agree that these are painful to deal with, but a quick search
> will show that they are fairly well understood by now. The usual fixes are
> to replace int/long by size_t, ssize_t and/or int32_t, int64_t depending on
> whether a "memory space size" value, or a specific value size is needed.
> Personally I find that size_t gets used far more often than int32_t or
> Alberto did not identify PortAudio as the culprit, and I don't think there
> is any major problem as it stands, although the use of size_t in some
> interfaces would certainly make sense.
> But I didn't really follow the logic of what you said below, could you
> clarify please?
> On 27/07/2017 11:47 AM, Phil Burk wrote:
>> I notice that portaudio.h is full of int and long structure members. I
>> imagine there could also be similar issues in the API implementations.
> I've thought about it before, and I don't think there's a problem.
> The data passed in int and long values in the PA API are never large
> enough for the 32/64 bit capacity to be relevant (e.g. channel counts,
> buffer sizes, etc.).
> If those structures get passed between 32 and 64-bit code then it
>> could definitely be a problem.
> Executables are either 32 or 64-bit. The only time you'd pass data between
> 32 and 64 bit code would be across process boundaries, which is outside the
> scope of PortAudio.
> The size of int and long on 64 bit platforms varies, but it is well known
> and clearly specified for each platform:
> Any time we pass a pointer to data, it is generally safer to use
>> explicitly sized fields, eg. int32_t or int64_t.
> More often we're passing data, not pointers to data. Can you give an
> example where we pass a pointer to data?
> Changing this could introduce a binary incompatibility so we should
>> only do it as part of a major version release.
> If we were to move away from int and long in the public API (I don't see a
> strong need), then the widespread convention would be to use types like
> size_t, not explicitly sized types.
> Portaudio mailing list
> Portaudio at lists.columbia.edu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Portaudio