fixed buffer sizes?
fixed buffer sizes?
- Subject: fixed buffer sizes?
- From: Paul Davis <email@hidden>
- Date: Tue, 16 Feb 2010 11:40:50 -0500
We (ardour/mixbus development team) have been grappling with an issue
with a family of plugins that for now I'm going to leave
unnamed. Using google, its clear that several other AU hosts,
including Reaper, Fruity Loops and Digital Performer have all had
issues with these plugins over the years. At one point, even Logic had
some issues with them as well.
Distilling what we've observed down to its essence, our question is
this: should a host be able to call AudioUnitRender() with any number
of frames as long it is below the last-set maximum-frames-per-slice value?
Or is there some unstated model that has allowed some plugin
developers to have an expectation that the host will use the same
frame cnt for every render call for every plugin, until the next
time maximum-frames-per-slice is set?
It is very clear that other host developers have grappled with these
issues (just read various Reaper release notes and search for "fixed
size buffers"; or look on various DP or FL forums from a couple of
years ago), we are wondering if:
1) the expected behaviour of the host is to always run the entire "graph"
(not necessarily an AUGraph) with a fixed buffer size (in between
any resets, naturally) ?
2) if not, is there any interest in extending auval to detect
some specific cases that we've found where plugins break (badly)
when the buffer size (ie. the frame count passed to AudioUnitRender)
is varied (but remains below the maximum-frames-per-slice property)?
The behaviour we've seen will never be revealed by testing single
plugin, even with multiple instances of the plugin. This makes the
use of auval to detect the problem rather difficult ...
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden