Subject: FW: [linux-audio-dev] disk-based realtime sampler prototype relea sed ! please try it.
From: Garth Brantley (garth_AT_fullduplex.com)
Date: Thu Jul 13 2000 - 19:05:26 EEST
-----Original Message-----
From: Garth Brantley
Sent: Thursday, July 13, 2000 11:51 AM
To: 'Benno Senoner'
Subject: RE: [linux-audio-dev] disk-based realtime sampler prototype
released ! please try it.
> -----Original Message-----
> From: Benno Senoner [mailto:sbenno_AT_gardena.net]
> Sent: Thursday, July 13, 2000 11:47 AM
> To: Juhana Sadeharju
> Cc: LAD Mail; david_AT_gardena.net
> Subject: Re: [linux-audio-dev] disk-based realtime sampler prototype
> released ! please try it.
>
>
> On Thu, 13 Jul 2000, Juhana Sadeharju wrote:
> >
> > I'm not sure am I able to test the sampler. I will port it
> to my system
> > with my unfinished utility library, and then I will write
> GTK+ interface
> > because I don't have MIDI, and then I look at that sequence playing
> > stuff (extension of a simple looping).
>
> what we can do is to add ALSA sequencer support so that you can use
> it from apps which use the ALSA sequencer API.
> I never used the ALSA sequencer API but this should not be quite easy
> to do.
> I can even make a keyboard input module to my disksampler, so that
> you can play it from a computer keyboard (but that is not very useful
> for usable live performances :-) )
>
> >
> > Some quick suggestions:
> >
> > The resampling should be done always to downward so that
> disk reading
> > speed never increase. I will check simple resampling filter from
> > Dattorro's Effect Design paper but you could test different playing
> > speeds without interpolation or with linear interpolation.
> If we would
> > resample upward, a simple linear interpolation between
> nearby samples
> > would not work, I see.
>
> But what if a sample is sampled only at a certain frequency
> and we want
> to play it at higher speed ?
> We have to either play faster or precompute a 2nd upsampled
> copy on the
> disk and then play it slower.
> But even playing samples at 2x speed is not a problem as long as
> you do not exceed the total disk bandwidth.
>
Musically speaking you almost always want to speed up samples & not slow
them down! It makes sense if you think about. If you speed up a note to
make a higher pitched note you are not losing any quality. Do it the other
way round and it sounds bad.
> >
> > The beginnings of loop segments could be kept in memory
> too. Alternative
> > would be to preload them just before the end of the loop segment (if
> > key is still hold down) but that might be more difficult to
> implement.
>
> I will opt for the 2nd alternative, because the disk streamer
> has to seek within
> the file anyway at every refilling step, thus it does not
> know if the sample is
> contiguous or not.
> Just change the offset when you reach at loop end and automagically
> it will preload from a different location.
> The audiothread streams from the ringbuffer in a linear fashion,
> and outputs the data that the diskthread feeds him.
> The advantage of this is that you can put the looping logic
> etc in the disk
> thread which has not so sharp time constraints, thus even
> with heavy looping
> you do not stress the audio task in any way. (or at least very little)
>
> >
> > Regards,
> >
> > Juhana
>
>
> Benno.
>
-Garth
This archive was generated by hypermail 2b28 : Thu Jul 13 2000 - 19:32:51 EEST