There has already been a lot of discussion on the fact that all apps
have to share the same Audio session properties, like audio buffer
lengths and the need to support other buffer sizes than the one you
think you're getting. Currently a lot of apps are running with 256
sample sized buffers for lower latency which is fine if you are the
only app running. I'm currently testing scenarios with 3-5 apps
running at the same time all sequenced from Genome and 256 samples is
too small to get all those apps running at the same time without
running into choppy sound issues. What needs to happen I think, is
greater control for users in setting audio buffer lengths. In a solo-
instrument setting, low latency is preferred, however in a multiple
app sequencing scenario, higher latency is preferred since it allows
more apps to run at the same time. My app can set the audio buffers
longer, but there's nothing to stop other apps from setting it lower
and breaking up the audio. It would be nice if every app had a setting
like "Audio Latency: low, medium, high" translating to 256, 512, and
1024 sample buffers. Apps maybe should also respect the current
latency when returning from background mode instead of forcing it
back. What do you guys think?
The next Sample Lab update includes setings as you describe. 1024 is really the only way to get most apps working together. Also the order apps are launched mattters which is awkward to have to explain to users IMO. On Oct 8, 2011 3:46 PM, "Dave [WhiteNoiseAudio]" <dwalli...@gmail.com> wrote:
> There has already been a lot of discussion on the fact that all apps > have to share the same Audio session properties, like audio buffer > lengths and the need to support other buffer sizes than the one you > think you're getting. Currently a lot of apps are running with 256 > sample sized buffers for lower latency which is fine if you are the > only app running. I'm currently testing scenarios with 3-5 apps > running at the same time all sequenced from Genome and 256 samples is > too small to get all those apps running at the same time without > running into choppy sound issues. What needs to happen I think, is > greater control for users in setting audio buffer lengths. In a solo- > instrument setting, low latency is preferred, however in a multiple > app sequencing scenario, higher latency is preferred since it allows > more apps to run at the same time. My app can set the audio buffers > longer, but there's nothing to stop other apps from setting it lower > and breaking up the audio. It would be nice if every app had a setting > like "Audio Latency: low, medium, high" translating to 256, 512, and > 1024 sample buffers. Apps maybe should also respect the current > latency when returning from background mode instead of forcing it > back. What do you guys think?
In my case,a 1024 sized buffer is totally unuseable (in a touch instrument), so there is no point in having a setting to allow it. If some background app cant go below 1024, then we are incompatible for that use. Filling our apps with esoteric options to support cases that wont work well anyway is not a good thing for usability.
It seems obvious that apps need to decide whether they generate midi, or sound; and we shutoff sound generation when acting as a background midi generator or controller. All the major cpu usage is coming from the sound generating app, and having more than one or two is unreasonable. Arpeggiators and controllers should not tax the cpu so hard.
> There has already been a lot of discussion on the fact that all apps > have to share the same Audio session properties, like audio buffer > lengths and the need to support other buffer sizes than the one you > think you're getting. Currently a lot of apps are running with 256 > sample sized buffers for lower latency which is fine if you are the > only app running. I'm currently testing scenarios with 3-5 apps > running at the same time all sequenced from Genome and 256 samples is > too small to get all those apps running at the same time without > running into choppy sound issues. What needs to happen I think, is > greater control for users in setting audio buffer lengths. In a solo- > instrument setting, low latency is preferred, however in a multiple > app sequencing scenario, higher latency is preferred since it allows > more apps to run at the same time. My app can set the audio buffers > longer, but there's nothing to stop other apps from setting it lower > and breaking up the audio. It would be nice if every app had a setting > like "Audio Latency: low, medium, high" translating to 256, 512, and > 1024 sample buffers. Apps maybe should also respect the current > latency when returning from background mode instead of forcing it > back. What do you guys think?
> The next Sample Lab update includes setings as you describe. 1024 is really
> the only way to get most apps working together. Also the order apps are
> launched mattters which is awkward to have to explain to users IMO.
> On Oct 8, 2011 3:46 PM, "Dave [WhiteNoiseAudio]" <dwalli...@gmail.com>
> wrote:
> > There has already been a lot of discussion on the fact that all apps
> > have to share the same Audio session properties, like audio buffer
> > lengths and the need to support other buffer sizes than the one you
> > think you're getting. Currently a lot of apps are running with 256
> > sample sized buffers for lower latency which is fine if you are the
> > only app running. I'm currently testing scenarios with 3-5 apps
> > running at the same time all sequenced from Genome and 256 samples is
> > too small to get all those apps running at the same time without
> > running into choppy sound issues. What needs to happen I think, is
> > greater control for users in setting audio buffer lengths. In a solo-
> > instrument setting, low latency is preferred, however in a multiple
> > app sequencing scenario, higher latency is preferred since it allows
> > more apps to run at the same time. My app can set the audio buffers
> > longer, but there's nothing to stop other apps from setting it lower
> > and breaking up the audio. It would be nice if every app had a setting
> > like "Audio Latency: low, medium, high" translating to 256, 512, and
> > 1024 sample buffers. Apps maybe should also respect the current
> > latency when returning from background mode instead of forcing it
> > back. What do you guys think?
Rob, while I agree that it might be unusable when your app is on the
foreground, it would be totally fine while your app is in the
background (if your app supports that).
On Oct 8, 5:03 pm, Rob Fielding <rob.field...@gmail.com> wrote:
> In my case,a 1024 sized buffer is totally unuseable (in a touch instrument), so there is no point in having a setting to allow it. If some background app cant go below 1024, then we are incompatible for that use. Filling our apps with esoteric options to support cases that wont work well anyway is not a good thing for usability.
> It seems obvious that apps need to decide whether they generate midi, or sound; and we shutoff sound generation when acting as a background midi generator or controller. All the major cpu usage is coming from the sound generating app, and having more than one or two is unreasonable. Arpeggiators and controllers should not tax the cpu so hard.
> On Oct 8, 2011, at 3:46 PM, "Dave [WhiteNoiseAudio]" <dwalli...@gmail.com> wrote:
> > There has already been a lot of discussion on the fact that all apps
> > have to share the same Audio session properties, like audio buffer
> > lengths and the need to support other buffer sizes than the one you
> > think you're getting. Currently a lot of apps are running with 256
> > sample sized buffers for lower latency which is fine if you are the
> > only app running. I'm currently testing scenarios with 3-5 apps
> > running at the same time all sequenced from Genome and 256 samples is
> > too small to get all those apps running at the same time without
> > running into choppy sound issues. What needs to happen I think, is
> > greater control for users in setting audio buffer lengths. In a solo-
> > instrument setting, low latency is preferred, however in a multiple
> > app sequencing scenario, higher latency is preferred since it allows
> > more apps to run at the same time. My app can set the audio buffers
> > longer, but there's nothing to stop other apps from setting it lower
> > and breaking up the audio. It would be nice if every app had a setting
> > like "Audio Latency: low, medium, high" translating to 256, 512, and
> > 1024 sample buffers. Apps maybe should also respect the current
> > latency when returning from background mode instead of forcing it
> > back. What do you guys think?
1024 is a latency of 20 MS (if the sample rate is 44100) -- There was
a core audio mailing list post a while back about the boundary of
perceptible latency, and I feel like that's pretty close to it.
Regardless, if it's a consistent latency (and does not jitter), the
musician adapts to it pretty quickly.
Still, might not be good for everyone -- just throwing that in there.
On Oct 9, 6:32 am, "Dave [WhiteNoiseAudio]" <dwalli...@gmail.com>
wrote:
> Rob, while I agree that it might be unusable when your app is on the
> foreground, it would be totally fine while your app is in the
> background (if your app supports that).
> On Oct 8, 5:03 pm, Rob Fielding <rob.field...@gmail.com> wrote:
> > In my case,a 1024 sized buffer is totally unuseable (in a touch instrument), so there is no point in having a setting to allow it. If some background app cant go below 1024, then we are incompatible for that use. Filling our apps with esoteric options to support cases that wont work well anyway is not a good thing for usability.
> > It seems obvious that apps need to decide whether they generate midi, or sound; and we shutoff sound generation when acting as a background midi generator or controller. All the major cpu usage is coming from the sound generating app, and having more than one or two is unreasonable. Arpeggiators and controllers should not tax the cpu so hard.
> > On Oct 8, 2011, at 3:46 PM, "Dave [WhiteNoiseAudio]" <dwalli...@gmail.com> wrote:
> > > There has already been a lot of discussion on the fact that all apps
> > > have to share the same Audio session properties, like audio buffer
> > > lengths and the need to support other buffer sizes than the one you
> > > think you're getting. Currently a lot of apps are running with 256
> > > sample sized buffers for lower latency which is fine if you are the
> > > only app running. I'm currently testing scenarios with 3-5 apps
> > > running at the same time all sequenced from Genome and 256 samples is
> > > too small to get all those apps running at the same time without
> > > running into choppy sound issues. What needs to happen I think, is
> > > greater control for users in setting audio buffer lengths. In a solo-
> > > instrument setting, low latency is preferred, however in a multiple
> > > app sequencing scenario, higher latency is preferred since it allows
> > > more apps to run at the same time. My app can set the audio buffers
> > > longer, but there's nothing to stop other apps from setting it lower
> > > and breaking up the audio. It would be nice if every app had a setting
> > > like "Audio Latency: low, medium, high" translating to 256, 512, and
> > > 1024 sample buffers. Apps maybe should also respect the current
> > > latency when returning from background mode instead of forcing it
> > > back. What do you guys think?
I can run sample lab + nlogsynth on ch2 (kudos for channel selection! Hope all instruments implement this), sunrizer on ch1. @ 512 on iPad2 but there are hiccups...1024 it is like butter. (Users can now choose 256/512/1024)
We knew the day would come when we would be fiddling with the buffer size in iOS like in a DAW... hoping most folks already understand the latency vs. more plug-ins trade-off. On Oct 17, 2011 2:39 PM, "Greg W (polychord)" <gregorywie...@gmail.com> wrote:
> 1024 is a latency of 20 MS (if the sample rate is 44100) -- There was > a core audio mailing list post a while back about the boundary of > perceptible latency, and I feel like that's pretty close to it. > Regardless, if it's a consistent latency (and does not jitter), the > musician adapts to it pretty quickly.
> Still, might not be good for everyone -- just throwing that in there.
> On Oct 9, 6:32 am, "Dave [WhiteNoiseAudio]" <dwalli...@gmail.com> > wrote: > > Rob, while I agree that it might be unusable when your app is on the > > foreground, it would be totally fine while your app is in the > > background (if your app supports that).
> > On Oct 8, 5:03 pm, Rob Fielding <rob.field...@gmail.com> wrote:
> > > In my case,a 1024 sized buffer is totally unuseable (in a touch > instrument), so there is no point in having a setting to allow it. If some > background app cant go below 1024, then we are incompatible for that use. > Filling our apps with esoteric options to support cases that wont work well > anyway is not a good thing for usability.
> > > It seems obvious that apps need to decide whether they generate midi, > or sound; and we shutoff sound generation when acting as a background midi > generator or controller. All the major cpu usage is coming from the sound > generating app, and having more than one or two is unreasonable. > Arpeggiators and controllers should not tax the cpu so hard.
> > > On Oct 8, 2011, at 3:46 PM, "Dave [WhiteNoiseAudio]" < > dwalli...@gmail.com> wrote:
> > > > There has already been a lot of discussion on the fact that all apps > > > > have to share the same Audio session properties, like audio buffer > > > > lengths and the need to support other buffer sizes than the one you > > > > think you're getting. Currently a lot of apps are running with 256 > > > > sample sized buffers for lower latency which is fine if you are the > > > > only app running. I'm currently testing scenarios with 3-5 apps > > > > running at the same time all sequenced from Genome and 256 samples is > > > > too small to get all those apps running at the same time without > > > > running into choppy sound issues. What needs to happen I think, is > > > > greater control for users in setting audio buffer lengths. In a solo- > > > > instrument setting, low latency is preferred, however in a multiple > > > > app sequencing scenario, higher latency is preferred since it allows > > > > more apps to run at the same time. My app can set the audio buffers > > > > longer, but there's nothing to stop other apps from setting it lower > > > > and breaking up the audio. It would be nice if every app had a > setting > > > > like "Audio Latency: low, medium, high" translating to 256, 512, and > > > > 1024 sample buffers. Apps maybe should also respect the current > > > > latency when returning from background mode instead of forcing it > > > > back. What do you guys think?
