AU validation fails on Mac OS X 10.5


#1

I compiled an AU plugin with Mac OS X 10.4.10 and tried to validate it in Mac OS X 10.5.1, usind the auval version 1.2.1b3 that comes with it.

This is the last part of the given report:

RENDER TESTS:
Input Format: AudioStreamBasicDescription:  2 ch,  44100 Hz, 'lpcm' (0x00000029) 32-bit little-endian float, deinterleaved
Output Format: AudioStreamBasicDescription:  2 ch,  44100 Hz, 'lpcm' (0x00000029) 32-bit little-endian float, deinterleaved
Render Test at 512 frames
Slicing Render Test at 64 frames
  PASS

Render Test at 64 frames, sample rate: 22050 Hz
Render Test at 137 frames, sample rate: 96000 Hz
Render Test at 4096 frames, sample rate: 44100 Hz
Render Test at 4096 frames, sample rate: 192000 Hz
Render Test at 4096 frames, sample rate: 11025 Hz
Render Test at 512 frames, sample rate: 48000 Hz
  PASS

1 Channel Test:
In and Out Format: AudioStreamBasicDescription:  1 ch,  48000 Hz, 'lpcm' (0x00000029) 32-bit little-endian float, deinterleaved
Render Test at 512 frames
  PASS

1 to 2 Channel Render Test at 256 frames
ERROR: Output Buffer Size does not match requested num frames

* * FAIL
--------------------------------------------------
AU VALIDATION FAILED: CORRECT THE ERRORS ABOVE.
--------------------------------------------------

Then I tried validating it back in Mac OS X 10.4.10, with auval 1.2.0a11, and this is the same terminating part of the report:

RENDER TESTS:
Input Format: AudioStreamBasicDescription:  2 ch,  44100 Hz, 'lpcm' (0x00000029) 32-bit little-endian float, deinterleaved
Output Format: AudioStreamBasicDescription:  2 ch,  44100 Hz, 'lpcm' (0x00000029) 32-bit little-endian float, deinterleaved
Render Test at 512 frames
Slicing Render Test at 64 frames
  PASS

Render Test at 64 frames, sample rate: 22050 Hz
Render Test at 137 frames, sample rate: 96000 Hz
Render Test at 4096 frames, sample rate: 44100 Hz
Render Test at 4096 frames, sample rate: 192000 Hz
Render Test at 4096 frames, sample rate: 11025 Hz
Render Test at 512 frames, sample rate: 48000 Hz
  PASS

1 Channel Test:
In and Out Format: AudioStreamBasicDescription:  1 ch,  48000 Hz, 'lpcm' (0x00000029) 32-bit little-endian float, deinterleaved
Render Test at 512 frames
  PASS

Checking connection semantics:
Connection format:
AudioStreamBasicDescription:  2 ch,  48000 Hz, 'lpcm' (0x00000029) 32-bit little-endian float, deinterleaved
  PASS
kAudioUnitErr_TooManyFramesToProcess

Checking parameter setting
Using AudioUnitSetParameter
Using AudioUnitScheduleParameter
  PASS

* * PASS
--------------------------------------------------
AU VALIDATION SUCCEEDED.
--------------------------------------------------

Notice that the name of the constant kAudioUnitErr_TooManyFramesToProcess reporting the error gets printed only when I validate the DEBUG version of the plugin.

Looks like it is intended as a “warning” or something in 10.4, but becomes an invalidating error in 10.5 (both Debug and Release binaries result in the same error upon validation in 10.5)

I’ve searched a bit and found that responsable for printing that line in 10.4 is the following code, found in AUBase.cpp at line 1273

    if (inFramesToProcess > mMaxFramesPerSlice)
        COMPONENT_THROW(kAudioUnitErr_TooManyFramesToProcess);

with inFramesToProces being 8192 and mMaxFramesPerSlice = 512.

How do I solve this issue?


#2

Are you using the juce code from the trunk of SVN? There was an AU channel number problem I fixed recently…


#3

Yeah, I noticed that bug too and anyway yes, I’m up to date to the latest AU wrapper code, but the error still remains.


#4

It’s peculiar, I can’t see why they’re doing that. I guess the fix is just for the wrapper to call SetMaxFramesPerSlice with a really high value to indicate that it’s ok for the plugin to handle large frame sizes…

Something like this:

[code] ComponentResult Initialize()
{
SetMaxFramesPerSlice (16384);

[/code]

The default maximum size seems to be 1156, so I guess auval is using bigger buffers than that for reasons best known to itself.


#5

I noticed you checked it this last modification in your AU wrapper code. I’m testing with it now, but the problem has not be solve since it behaves exactly the same under 10.5, while the message i get when validating (both debug and release) under 10.4 is now:

RENDER TESTS:
Input Format: AudioStreamBasicDescription:  2 ch,  44100 Hz, 'lpcm' (0x00000029) 32-bit little-endian float, deinterleaved
Output Format: AudioStreamBasicDescription:  2 ch,  44100 Hz, 'lpcm' (0x00000029) 32-bit little-endian float, deinterleaved
Render Test at 512 frames
Slicing Render Test at 64 frames
  PASS

Render Test at 64 frames, sample rate: 22050 Hz
Render Test at 137 frames, sample rate: 96000 Hz
Render Test at 4096 frames, sample rate: 44100 Hz
Render Test at 4096 frames, sample rate: 192000 Hz
Render Test at 4096 frames, sample rate: 11025 Hz
Render Test at 512 frames, sample rate: 48000 Hz
  PASS

1 Channel Test:
In and Out Format: AudioStreamBasicDescription:  1 ch,  48000 Hz, 'lpcm' (0x00000029) 32-bit little-endian float, deinterleaved
Render Test at 512 frames
  PASS

1 to 2 Channel Render Test at 256 frames
  PASS

Checking connection semantics:
Connection format:
AudioStreamBasicDescription:  2 ch,  48000 Hz, 'lpcm' (0x00000029) 32-bit little-endian float, deinterleaved
  PASS
ERROR:   AU is not passing time stamp correctly. Was given: 16329, but input received: 16841

Checking parameter setting
Using AudioUnitSetParameter
Using AudioUnitScheduleParameter
  PASS

* * PASS
--------------------------------------------------
AU VALIDATION SUCCEEDED.
--------------------------------------------------

The numbers in the error message don’t change if I change the argument of SetMaxFramesPerSlice, neither if I move the statement at the end of the Initialize() method.

Commenting that single line obviously brings back the same kAudioUnitErr_TooManyFramesToProcess warning.


#6

ah, well I’m stumped then. No idea what it means by that. I’ll have to do some more digging, maybe I’m misunderstanding the way that parameter is supposed to be used…


#7

This is the reply I got, posting the same problem to the coreaudio-api mailing list.

Is that useful to you? I’m not really into the internals of AU programming… that’s why I found your wrapper so useful!


#8

thanks, that does sound useful…


#9

After some digging on my own, I found what the problem is.

First of all, it has nothing to do with the reported kAudioUnitErr_TooManyFramesToProcess.

The problem is due to the fact that auval in Leopard 10.5 performs the mono to stereo render test with the bypassed plugin as well, thus the following code in AUEffectBase.cpp is executed (line 333):

		if (ShouldBypassEffect())
		{
			// leave silence bit alone
			
			if(!ProcessesInPlace() )
			{
				theInput->CopyBufferContentsTo (theOutput->GetBufferList());
			}
		}

Since the AUEffectBase.cpp is geared toward dealing with the same number of input and output channels, the raw copy performed by CopyBufferContentsTo when there is one input channel and two output channels fills the second output with random informations, both in the content and in the reported length of the buffer.
Since this is likely to be completely different from the number of frames that auval expects to receive, this causes the error reported in my first post.

My workaround is to use my own copy of AUEffectBase.cpp, patched this way:

		if (ShouldBypassEffect())
		{
			// leave silence bit alone
			
			if(!ProcessesInPlace() )
			{
			    // yyy !!!
				AudioBufferList& inputABL(theInput->GetBufferList());
				AudioBufferList& outputABL(theOutput->GetBufferList());
				
				if(inputABL.mNumberBuffers != outputABL.mNumberBuffers) {	// if number of buffers differs from input to output
					const AudioBuffer *srcbuf = inputABL.mBuffers;
					AudioBuffer *destbuf = outputABL.mBuffers;
					for (int outputBufferIndex = outputABL.mNumberBuffers-1; outputBufferIndex >= 0; outputBufferIndex--) {
					    int inputBufferIndex = (outputBufferIndex >= (int)inputABL.mNumberBuffers) ? (inputABL.mNumberBuffers-1) : outputBufferIndex; 
						if (destbuf[outputBufferIndex].mData != srcbuf[inputBufferIndex].mData)
							memmove(destbuf[outputBufferIndex].mData, srcbuf[inputBufferIndex].mData, srcbuf[inputBufferIndex].mDataByteSize);
						destbuf[outputBufferIndex].mDataByteSize = srcbuf[inputBufferIndex].mDataByteSize;
					}
				} else {
					theInput->CopyBufferContentsTo(outputABL);
				}
				
				// yyy !!!
				
				// theInput->CopyBufferContentsTo (theOutput->GetBufferList());
			}
		}

My code is the one within the two yyy !!! lines, and its serves for copying every input channel to the output, filling additional channels with replicas of the last valid input channel. That is, in a mono to stereo context, copying the input channel to both output channels.

This is the fastest way I could solve the issue. Sure it is not an elegant one.

According to the reply given on the coreaudio-api mailing list, the correct approach should be replacing the inheritance of the AU wrapper from AUEffectBase with one from another class, subclass of AUBase, more capable of dealing with n-to-m channel configurations.

Maybe this is the direction that should be taken in JUCE: checking in such a class, with the starting codebase taken from AUEffectBase.cpp, where to add modifications and patches if and when similar issues will appear in the future.

One more consideration:
the statement added to juce_AudioUnitWrapper.cpp at line 464

SetMaximumFramesPerSlice(16384);

does not have any positive effect and corrupts the validation of Audio Units both on Mac OS X 10.4 and 10.5 with errors relative to timestamps, the same way I reported with one of my previous posts. I think it should be removed in the current repository.


#10

Wow - thanks for digging that up! Yes, it does sound like doing a proper derived class is the way to go, though it’s a bit pathetic for apple’s own code to fail in such a confusing way. I’ll get onto this as soon as I can!


#11

yes, SetMaximumFramesPerSlice(16384) should be removed.
In Ableton Live i have no input signal when its there, don’t now why, but without this line it works.

[/quote]


#12

Can I ask whether there has been any update to this from JUCE's code and AU wrapper etc ? 

 

I am having the exact same issue myself with what I believe should be latest version of JUCE via Git. 

 

A little beyond my abilities to work out the necessary modifications to the AUEffectBase file and I have been unsuccesful with yfede's code fix above. 

 

Cheers 


#13

This thread is 6 years old - the code is probably entirely different now! I don't even remember the original problem..


#14

Hi Jules, 

 

Apologies I realise the thread is very old. 

 

I was suprised to find that I was having the exact same issue with the latest versions etc. 

 

Have searched through various threads and found nothing recent in regards to the error. 

 

Is there anywhere I can be pointed to this issue being adressed in a more recent thread ? 


#15

I've really no idea, but I'm sure I would have addressed this back in 2008 when it was raised, and I've not heard anyone else mention it since, so maybe what you're seeing is something else instead?


#16

Hi Jules, 

 

Would it be better for me to start up a new and clean thread ? 

 

Essentially I am recieving the exact same issue with my AU plug. 

 

Bad Max Frames - Render should fail

/Applications/Xcode.app/Contents/Developer/Extras/CoreAudio/AudioUnits/AUPublic/AUBase/AUBase.cpp:1439 inFramesToProcess=8192, mMaxFramesPerSlice=512; TooManyFrames

  from AU (0x810001): 'aumu' 'RudP' 'RudE', render err: -10874

  PASS

 

 

I have selected the Is A Synth build option through introjucer and left the channel configuration as {1, 1}, {2, 2} for the moment. 

The juce demo plugin runs fine but the project I am currently runing gives the error above on AU validation checks in Logic and Also fails to open in the JUCE Audio Plugin Host app. 

 

Everything builds fine otherwise and no errors out of xcode. The odd thing is that I have had this issue previously and Logic would load the plugin maybe 1 out of every 10 attempts. 

 

Any help would be massivley appreciated. 

Thanks

 


#17

AFAIK the AU base classes themselves check the number of frames, so there shouldn't be anything that we need to do to handle it. And why would your plugin fail when the demo (and presumably everyone else's juce plugins) pass auval?


#18