Bug #537
jcom.delay≈ crashes
| Status: | Closed | Start date: | 2010-06-09 | |
|---|---|---|---|---|
| Priority: | Urgent | Due date: | ||
| Assignee: |  Tim Place |
% Done: | 0% |
|
| Category: | - | Spent time: | - | |
| Target version: | - | |||
| Branch: | OS: |
Description
1. open jcom.delay≈.maxhelp.
2. turn on DSP
3. crash
here are two crash logs, one with linear interpoation, one with cubic inerpolation
Thread 9 Crashed:
0 EffectsLib.ttdylib 0x02eb0599 TTDelay::calculateCubicInterpolation(double const&, double&, TTDelayBuffer*) + 81 (TTDelay.cpp:271)
1 EffectsLib.ttdylib 0x02eb002e TTDelay::processAudioCubicInterpolation(TTAudioSignalArray*, TTAudioSignalArray*) + 142 (TTDelay.cpp:284)
2 org.jamoma.JamomaDSP 0x02ad03c0 TTAudioObject::process(TTAudioSignalArray*, TTAudioSignalArray*) + 64
3 org.jamoma.JamomaAudioGraph 0x02b574eb TTAudioGraphObject::process(TTAudioSignal*&, unsigned short) + 971
4 org.jamoma.JamomaAudioGraph 0x02b58e52 TTAudioGraphInlet::process() + 162
5 org.jamoma.JamomaAudioGraph 0x02b57348 TTAudioGraphObject::process(TTAudioSignal*&, unsigned short) + 552
6 org.jamoma.jcom.unpack≈ 0x1a2f68ae OutPerform(int*) + 104 (TTAudioGraphObject.h:130)
7 com.cycling74.MaxAudioAPI 0x02affb47 dspchain_tick + 90
8 com.cycling74.MaxAudioAPI 0x02afe577 ad_process + 470
9 com.cycling74.ad_coreaudio 0x031ce5f3 coreaudio_twodevice_ioproc + 537
10 ....audio_hijack_server.hermes 0x00d97b46 AudioDeviceIOCallback + 82
11 com.apple.audio.CoreAudio 0x997d75b4 HP_IOProc::Call(AudioTimeStamp const&, AudioTimeStamp const&, AudioBufferList const*, AudioTimeStamp const&, AudioBufferList*) + 374
12 com.apple.audio.CoreAudio 0x997d731a IOA_Device::CallIOProcs(AudioTimeStamp const&, AudioTimeStamp const&, AudioTimeStamp const&) + 370
13 com.apple.audio.CoreAudio 0x997d7116 HP_IOThread::PerformIO(AudioTimeStamp const&, double) + 620
14 com.apple.audio.CoreAudio 0x997d44fa HP_IOThread::WorkLoop() + 2506
15 com.apple.audio.CoreAudio 0x997d3b2b HP_IOThread::ThreadEntry(HP_IOThread*) + 17
16 com.apple.audio.CoreAudio 0x997d3a42 CAPThread::Entry(CAPThread*) + 140
17 libSystem.B.dylib 0x90cb8a19 _pthread_start + 345
18 libSystem.B.dylib 0x90cb889e thread_start + 34
Thread 8 Crashed:
0 EffectsLib.ttdylib 0x02eb052b TTDelay::calculateLinearInterpolation(double const&, double&, TTDelayBuffer*) + 113 (TTDelay.cpp:236)
1 EffectsLib.ttdylib 0x02eb00e2 TTDelay::processAudioLinearInterpolation(TTAudioSignalArray*, TTAudioSignalArray*) + 142 (TTDelay.cpp:245)
2 org.jamoma.JamomaDSP 0x02ad03c0 TTAudioObject::process(TTAudioSignalArray*, TTAudioSignalArray*) + 64
3 org.jamoma.JamomaAudioGraph 0x02b574eb TTAudioGraphObject::process(TTAudioSignal*&, unsigned short) + 971
4 org.jamoma.JamomaAudioGraph 0x02b58e52 TTAudioGraphInlet::process() + 162
5 org.jamoma.JamomaAudioGraph 0x02b57348 TTAudioGraphObject::process(TTAudioSignal*&, unsigned short) + 552
6 org.jamoma.jcom.unpack≈ 0x1a0cd8ae OutPerform(int*) + 104 (TTAudioGraphObject.h:130)
7 com.cycling74.MaxAudioAPI 0x02affb47 dspchain_tick + 90
8 com.cycling74.MaxAudioAPI 0x02afe577 ad_process + 470
9 com.cycling74.ad_coreaudio 0x031ce5f3 coreaudio_twodevice_ioproc + 537
10 ....audio_hijack_server.hermes 0x00d97b46 AudioDeviceIOCallback + 82
11 com.apple.audio.CoreAudio 0x997d75b4 HP_IOProc::Call(AudioTimeStamp const&, AudioTimeStamp const&, AudioBufferList const*, AudioTimeStamp const&, AudioBufferList*) + 374
12 com.apple.audio.CoreAudio 0x997d731a IOA_Device::CallIOProcs(AudioTimeStamp const&, AudioTimeStamp const&, AudioTimeStamp const&) + 370
13 com.apple.audio.CoreAudio 0x997d7116 HP_IOThread::PerformIO(AudioTimeStamp const&, double) + 620
14 com.apple.audio.CoreAudio 0x997d44fa HP_IOThread::WorkLoop() + 2506
15 com.apple.audio.CoreAudio 0x997d3b2b HP_IOThread::ThreadEntry(HP_IOThread*) + 17
16 com.apple.audio.CoreAudio 0x997d3a42 CAPThread::Entry(CAPThread*) + 140
17 libSystem.B.dylib 0x90cb8a19 _pthread_start + 345
18 libSystem.B.dylib 0x90cb889e thread_start + 34
Associated revisions
The AudioGraph now adapts the wrapped DSP object's MaxNumChannels attribute each vector when the process call is made. Fixes #537 and possibly a whole host of other issues.
History
Updated by Tim Place over 1 year ago
This turns out to be a more general problem rather than something specific to jcom.delay≈.
In an AudioGraph objects default to 1 channel at instantiation. Then, as the graph operates, objects adapt to the channel configurations on the fly. In quasi-stateless object (like op≈) this is no problem.
In objects which allocate memory buffers and such (like delay≈) the memory is generally only allocated when the MaxNumChannels attribute changes. Then, changes that happen on the fly are fine so long as they are confined to be with in the MaxNumChannels.
In AudioGraph, we never update the MaxNumChannels. So in the jcom.delay≈ help patcher, you turn on the audio and it tries to process 2 channels when we only allocated a memory buffer for one channel.
So...
I'm not sure what the right approach to this is. Any/all feedback is welcome. I'm not excited about having to check the channel configuration at each and every vector for efficiency reasons, but maybe that's what we need to do?
Updated by Tim Place over 1 year ago
- Priority changed from Normal to Urgent