#229
- Created on2015-01-19 20:03
- Reported by
- StatusFixed
- PriorityNormal (3)
- Assigned to
- Milestone
- Plan Level-
- Due Date-
PA/CoreAudio: assertion failure when requesting non-power-of-two channel count
This bug relates to Pa_ReadStream() and Pa_WriteStream().
-------- Forwarded Message --------
Subject: [Portaudio] Bug: Portaudio crashes for soundcards with non-power-of-two channels
Date: Mon, 19 Jan 2015 15:16:55 +0100
From: Bastian Bechtold
To: portaudio@music.columbia.edu
I am using a sound card Focusrite Scarlett 6i6, which has 6 inputs and 6
outputs.
Whenever I open a portaudio stream, it crashes with
Assertion failed: (!err), function initializeBlioRingBuffers, file
src/hostapi/coreaudio/pa_mac_core_blocking.c, line 191
That particular line is asserting that the return value of
PaUtil_InitializeRingBuffer(...,
ringBufferSize*blio->outputSampleSizePow2*outChan, ...)
should be zero. The documentation of `PaUtil_InitializeRingBuffer`
states that it will return zero if the `elementCount` (the shown
argument) is a power of 2.
But that obviously depends on the value of `outChan`! Thus, this
assertion will always fail if `outChan` is not a power of two. By
default, `outChan` will be the number of channels of your sound card.
I can prevent this by passing a power-of-two number of channels to
`Pa_OpenStream`'s `outputParameters.channelCount`.
This should be fixed, or at least be mentioned in the documentation for
`Pa_OpenStream`. Also, portaudio should return a meaningful error code
and not just an assertion failure.
Kind regards,
Bastian
_______________________________________________
Portaudio mailing list
Portaudio@music.columbia.edu
http://music.columbia.edu/mailman/listinfo/portaudio
-------- Forwarded Message --------
Subject: [Portaudio] Bug: Portaudio crashes for soundcards with non-power-of-two channels
Date: Mon, 19 Jan 2015 15:16:55 +0100
From: Bastian Bechtold
To: portaudio@music.columbia.edu
I am using a sound card Focusrite Scarlett 6i6, which has 6 inputs and 6
outputs.
Whenever I open a portaudio stream, it crashes with
Assertion failed: (!err), function initializeBlioRingBuffers, file
src/hostapi/coreaudio/pa_mac_core_blocking.c, line 191
That particular line is asserting that the return value of
PaUtil_InitializeRingBuffer(...,
ringBufferSize*blio->outputSampleSizePow2*outChan, ...)
should be zero. The documentation of `PaUtil_InitializeRingBuffer`
states that it will return zero if the `elementCount` (the shown
argument) is a power of 2.
But that obviously depends on the value of `outChan`! Thus, this
assertion will always fail if `outChan` is not a power of two. By
default, `outChan` will be the number of channels of your sound card.
I can prevent this by passing a power-of-two number of channels to
`Pa_OpenStream`'s `outputParameters.channelCount`.
This should be fixed, or at least be mentioned in the documentation for
`Pa_OpenStream`. Also, portaudio should return a meaningful error code
and not just an assertion failure.
Kind regards,
Bastian
_______________________________________________
Portaudio mailing list
Portaudio@music.columbia.edu
http://music.columbia.edu/mailman/listinfo/portaudio
Leave a comment
Brian Whitman posted a patch that looks pretty good, here:
https://gist.github.com/bwhitman/59d3761cfa7a8ab63e28
https://gist.github.com/bwhitman/59d3761cfa7a8ab63e28
Here is Bastian's original report:
http://music.columbia.edu/pipermail/portaudio/2015-January/thread.html#16536
Related Mailing list Discussion:
"[Portaudio] non-power-of-2 number of channels on multi-channel audio interface"
Starts here:
http://music.columbia.edu/pipermail/portaudio/2015-February/016604.html
Here's the February part of the thread:
http://music.columbia.edu/pipermail/portaudio/2015-February/thread.html#16604
Continues in March:
http://music.columbia.edu/pipermail/portaudio/2015-March/thread.html#16618
http://music.columbia.edu/pipermail/portaudio/2015-January/thread.html#16536
Related Mailing list Discussion:
"[Portaudio] non-power-of-2 number of channels on multi-channel audio interface"
Starts here:
http://music.columbia.edu/pipermail/portaudio/2015-February/016604.html
Here's the February part of the thread:
http://music.columbia.edu/pipermail/portaudio/2015-February/thread.html#16604
Continues in March:
http://music.columbia.edu/pipermail/portaudio/2015-March/thread.html#16618
on 2015-09-08 18:23 *
By bejayoharen
Is this only for blocking mode or for blocking and callbacks?
Brian Whitman's patch has two issues (If I'm reading the old emails correctly):
1. only works for output, not input
2. requires frame size argument to be a power of 2. (http://music.columbia.edu/pipermail/portaudio/2015-March/016620.html)
I see two possible solutions:
1. rewrite the ring buffer such that it no longer requires a power of two
2. pad the requested size of the ring buffer up to the next power of two
#2 doesn't seem too hard. I might be able to tackle it this weekend, if it's correct.
Brian Whitman's patch has two issues (If I'm reading the old emails correctly):
1. only works for output, not input
2. requires frame size argument to be a power of 2. (http://music.columbia.edu/pipermail/portaudio/2015-March/016620.html)
I see two possible solutions:
1. rewrite the ring buffer such that it no longer requires a power of two
2. pad the requested size of the ring buffer up to the next power of two
#2 doesn't seem too hard. I might be able to tackle it this weekend, if it's correct.
@bejayoharen The blocking case is the bug that was reported. Maybe the other case should be checked.
I think option 2 is reasonable. Option 1 sounds nice but seems like yak shaving.
The only thing with option 2 is that I'm not sure what that means for latency. I suggest that you look at pa_asio and see how it is handled there.
I think option 2 is reasonable. Option 1 sounds nice but seems like yak shaving.
The only thing with option 2 is that I'm not sure what that means for latency. I suggest that you look at pa_asio and see how it is handled there.
Normally the frame size for the ring buffer is required to be a power-of-2. The problem was that the size used to initialize the ring buffer was multiplied by the channel count, which was not a power-of-2. The patch from Brian just corrected that and does not add any new constraints.
A possible fix for both input and output is available for review here:
https://www.assembla.com/spaces/portaudio/git/merge_requests/3299213
https://www.assembla.com/spaces/portaudio/git/merge_requests/3299213
In portaudio:e111b3a269ae69c8c083ca4a2a3e3d66828d9ddc Merge branch 'ticket_229' into 'master'
Fix assert when reading or writing with non-power of 2 channels.
fixed #229
Merged-on: https://assembla.com/code/portaudio/git/merge_requests/3299213
