Re: [linux-audio-dev] disk-based realtime sampler prototype released ! please try it.

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] disk-based realtime sampler prototype released ! please try it.
From: Benno Senoner (sbenno_AT_gardena.net)
Date: Thu Jul 13 2000 - 18:47:06 EEST


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.

>
> 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.


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Thu Jul 13 2000 - 18:26:52 EEST