linuxsampler-devel — This list is for discussing LinuxSampler development issues and ideas

Re: [Linuxsampler-devel] Anything going on?

[Josh G. <jg...@us...>]

On Thu, 2002-12-12 at 03:21, Antti Boman wrote:
> Josh Green wrote:
> > Well, I'm still ploding along on Swami development. New devel branch
> > is.. well developing :) libInstPatch has some more testing under its
> > belt and a Python interface is beginning to form. I'm starting to
> > re-work the GUI side of things to make it more pluggable in anticipation
> > of new formats being added to libInstPatch (DLS2, Akai, GUS and perhaps
> > SF1). Much of this has still not been committed to CVS, although I would
> > be quick to commit it if I knew someone was interested (hint hint).
> 
> No-one is. No, seriously, I'm interested :) And ready to test and help.
> 
> -a

Cool :) There is quite a lot of things to do with Swami, so if you
really are interested, join the swami-devel mailing list (nothing
happening there at the moment, except for my status reports from time to
time). The development branch of Swami/libInstPatch has not quite
reached the stage where testing is really useful (still some things to
implement). If you are good with GUIs, I could use some ideas and brain
storming of how the user interface could be re-designed. The underlying
architecture is very object oriented (in a good way) but the GUI still
looks like the old Smurf SoundFont Editor (which is a mock up of a
screen shot I had of Vienna).

I want the new GUI to have a flexible layout (using the Gtk(H/V)Paned
widgets for now until a more flexible one is written) where the type of
UI element can be set (patch tree, patch properties, effect controls,
sample waveform loop control, GUI envelopes, etc) and these elements can
be docked or undocked from different windows. There could then be layout
presets (such as a "Classic" one that would resemble the current
interface). I'm just now re-writing the object state save/restore system
which is going to be XML based using libxml2 which will help a lot with
making the user interface more object oriented (and being able to
actually store this for later use).

Also much needs to be done in the area of adding API to the different UI
objects that plugins can take advantage of. A plugin may for instance
want to add its own operations to the right-click menu on the patch tree
object, add its own configuration UI to the preferences dialog, etc.

Anyways, additional discussion should probably occur on the swami-devel
list. One need not be an expert to help out and there is a lot of other
things besides GUI work that could use some help :) Cheers.
	Josh Green

Swami website: http://swami.sourceforge.net
Swami mailing lists: http://sourceforge.net/mail/?group_id=47510

Re: [Linuxsampler-devel] Anything going on?

[David O. <da...@ol...>]

On Thursday 12 December 2002 14.17, Benno Senoner wrote:
> Antii, no problem regarding your skills in a good product, the GUI
> is as important as the engine thus your help will be very precious.
>
> PS: I'm CCing David Olofson which has revived Audiality (a
> sampler/synth engine that ranges from games to building high
> quality soft synths/samplers ... see his posts on LAD.
>
> I hope David joins our mailing list since he is very knowledgable
> when it comes to efficient real time code, time stamping of events
> etc. At time David and I have had really cool (private) discussions
> about event systems, sample accurate time stamps for plugins /
> engines etc, David, I see you have now a bit more time to dedicate
> to linux audio things.

Well, yes - I've put Kobo Deluxe, glSDL and that on hold for now, and=20
most of the time has been spent on Audiality lately. (Except for the=20
last few days, which I've spent mostly discussing and working on XAP;=20
our new instrument plugin API.)

Oh, Audiality and XAP both have (rudimentary, but still) pages on my=20
site:
=09http://olofson.net=09(try the naigation bar :-)


> Do you intend to join our quest to provide
> this highly universal sampler engine that could be used for many
> apps ranging from games to high quality midi software sound modules
> ?
> I mean, from your web page it seems that both audiatily and
> linuxsampler  want to achieve similar goals. You mentioned the
> willing of implement disk streaming too, so why not unite the two
> things ? In my opinion it would make sense.

I don't know yet. It would obviously seem like we have *lots* of=20
common goals, and also more than a few design choices in common.

There are basically three things we need to agree on:

=09* Language
=09=09I strongly prefer C, mostly for portability reasons,
=09=09but also since I don't think the complexity of the
=09=09engine motivates the use of C++. (And mind you; I
=09=09have a scripting engine in there! ;-)

=09* Scalability
=09=09Audiality runs rather well on very low end PCs. Due
=09=09to the extremely space efficient script based sounds,
=09=09it's possibly to fit rather high quality music in
=09=09a few kB - on par with IXS. These are things I would
=09=09like to maintain and explore further. (Although they
=09=09may not be my top priorities right now.)

=09* License
=09=09LGPL is the only license that makes sense for
=09=09Audiality. (Which means that I'll have to "clean"
=09=09the code if I can't get in touch with Masanao Izumo.)
=09=09The GPL is too restrictive, since it does not allow
=09=09the use of Audiality as the audio/music engine in
=09=09proprietary games and multimedia productions.


> I think is is a good thing if you people come up with
> solutions/proposals for implementing a sampler engine, but in the
> long run it would be wise to join our forces and work on highly
> reusable modular components like samplelibrary reading libs, sample
> rendering engines, patch editors etc.

Yes indeed. If XAP turns out right, there's a good chance of=20
Audiality being split up into a "plugin kit", since it's already=20
working in similar ways to a XAP plugin net internally. (In fact, the=20
event system in my XAP proposal is just a slightly generalized=20
version of the Audiality event system - which in turn, was derived=20
from the MAIA code.)

I think we might have a rather nice pilot project for XAP here. This=20
design needs serious review and testing before finalizing, and using=20
it to modularize Audiality as well as a framework for Linuxsampler=20
should probably force most issues to surface. These two projects=20
include off-line rendering, direct-from-disk playback, advanced real=20
time control (soon scripting in Audiality) and real time processing.=20
Add a sequencer with some editing operations, we have a "test suite"=20
the covers most plugin API features we can think of - as well as a=20
pretty cool toolkit! :-)


//David Olofson - Programmer, Composer, Open Source Advocate

=2E- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`---------------------------> http://olofson.net/audiality -'
=2E- M A I A -------------------------------------------------.
|    The Multimedia Application Integration Architecture    |
`----------------------------> http://www.linuxdj.com/maia -'
   --- http://olofson.net --- http://www.reologica.se ---

Re: [Linuxsampler-devel] Anything going on?

[Antti B. <ant...@mi...>]

Benno Senoner wrote:
> Antii, no problem regarding your skills in a good product, the GUI is
> as important as the engine thus your help will be very precious. 

Thanks. I'll follow the discussion on the list and try to gather the 
information what's needed and how it should be done. UI-wise, at the moment.

-a

Re: [Linuxsampler-devel] Anything going on?

[Phil K. <phi...@el...>]

Thanks Steve,

It compiles and runs fine.

I'll have a better play and dig through the code later.

Cheers

Phil

On Thu, 2002-12-12 at 12:11, Steve Harris wrote:
> OK, its on
> http://www.ecs.soton.ac.uk/~swh/linuxsampler-2002-12-12.tar.gz
> 
> I added some patches to make it compile unser gcc3, but it should be OK on
> older compilers still.
> 
> - Steve
> 
> On Thu, Dec 12, 2002 at 10:56:43 +0000, Phil Kerr wrote:
> > Can someone pop it on a server somewhere so I can have a play, or if
> > it's not too big, < 500k, email me a copy.
> > 
> > On Thu, 2002-12-12 at 10:57, Steve Harris wrote:
> > > On Wed, Dec 11, 2002 at 11:36:35 -0300, Juan Linietsky wrote:
> > > > The cvs is quite outdated..
> > > > I cant commit it seems (either i dont underst very well how sourceforge works,
> > > > or my account is wrong, or i forgot my password :), so i've sent
> > > > the latest tarball to benno and steve...
> > > > Benno seems to be quite busy this week, but i hope
> > > > he gets to review/upoaded the latest tarball...
> > > 
> > > I built it OK, but I had some alsa seq realted problems and so couldn't
> > > try it. I'l give it another go when I have a chance.
> > > 
> > > - Steve 
> > > 
> > > 
> > > -------------------------------------------------------
> > > This sf.net email is sponsored by:
> > > With Great Power, Comes Great Responsibility 
> > > Learn to use your power at OSDN's High Performance Computing Channel
> > > http://hpc.devchannel.org/
> > > _______________________________________________
> > > Linuxsampler-devel mailing list
> > > Lin...@li...
> > > https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel
> > 
> 
> -- 
> Stephen Harris                    07970 557047
> AKT, IAM Research Group          023 8059 2831
> University of Southampton, UK
> sw...@ec...     http://www.aktors.org/           
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:
> With Great Power, Comes Great Responsibility 
> Learn to use your power at OSDN's High Performance Computing Channel
> http://hpc.devchannel.org/
> _______________________________________________
> Linuxsampler-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel

Re: [Linuxsampler-devel] Anything going on?

[Benno S. <be...@ga...>]

Antii, no problem regarding your skills in a good product, the GUI is
as important as the engine thus your help will be very precious. 

PS: I'm CCing David Olofson which has revived Audiality (a sampler/synth
engine that ranges from games to building high quality soft
synths/samplers ... see his posts on LAD.

I hope David joins our mailing list since he is very knowledgable when
it comes to efficient real time code, time stamping of events etc.
At time David and I have had really cool (private) discussions about
event systems, sample accurate time stamps for plugins / engines etc, 
David, I see you have now a bit more time to dedicate to linux audio
things. Do you intend to join our quest to provide this highly universal
 sampler engine that could be used for many apps ranging from games to
 high quality midi software sound modules ?
I mean, from your web page it seems that both audiatily and
linuxsampler  want to achieve similar goals. You mentioned the willing
of implement disk streaming too, so why not unite the two things ?
In my opinion it would make sense.

I think is is a good thing if you people come up with
solutions/proposals for implementing a sampler engine, but in the long
run it would be wise to join our forces and work on highly reusable
modular components like samplelibrary reading libs, sample rendering
engines, patch editors etc.

cheers,
Benno


Il gio, 2002-12-12 alle 12:18, Antti Boman ha scritto:
> Thanks for the responses. Nice to see things are still developing. I'm 
> always a bit too worried about the possibility of good projects being 
> abandoned.
> 
> Benno Senoner wrote:
> > Hi,
> > sorry for my absence, I have to migrate the servers of an ISP (need to
> > finish for christmas)  thus I will not be that much present for the next
> > two weeks. (I promise no high-load situations again for the whole 2003
> > :-) )
> 
> No need to be sorry, I'm in no position to force people do these things :)
> 
> I'm still willing to hop in when GUIs or similar are needed. 
> Unfortunately, my skills in the low level area are still rather... low.
> 
> -a

-- 
http://linuxsampler.sourceforge.net
Building a professional grade software sampler for Linux.
Please help us designing and developing it.
 

Re: [Linuxsampler-devel] Anything going on?

[Steve H. <S.W...@ec...>]

OK, its on
http://www.ecs.soton.ac.uk/~swh/linuxsampler-2002-12-12.tar.gz

I added some patches to make it compile unser gcc3, but it should be OK on
older compilers still.

- Steve

On Thu, Dec 12, 2002 at 10:56:43 +0000, Phil Kerr wrote:
> Can someone pop it on a server somewhere so I can have a play, or if
> it's not too big, < 500k, email me a copy.
> 
> On Thu, 2002-12-12 at 10:57, Steve Harris wrote:
> > On Wed, Dec 11, 2002 at 11:36:35 -0300, Juan Linietsky wrote:
> > > The cvs is quite outdated..
> > > I cant commit it seems (either i dont underst very well how sourceforge works,
> > > or my account is wrong, or i forgot my password :), so i've sent
> > > the latest tarball to benno and steve...
> > > Benno seems to be quite busy this week, but i hope
> > > he gets to review/upoaded the latest tarball...
> > 
> > I built it OK, but I had some alsa seq realted problems and so couldn't
> > try it. I'l give it another go when I have a chance.
> > 
> > - Steve 
> > 
> > 
> > -------------------------------------------------------
> > This sf.net email is sponsored by:
> > With Great Power, Comes Great Responsibility 
> > Learn to use your power at OSDN's High Performance Computing Channel
> > http://hpc.devchannel.org/
> > _______________________________________________
> > Linuxsampler-devel mailing list
> > Lin...@li...
> > https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel
> 

-- 
Stephen Harris                    07970 557047
AKT, IAM Research Group          023 8059 2831
University of Southampton, UK
sw...@ec...     http://www.aktors.org/           

Re: [Linuxsampler-devel] Anything going on?

[Antti B. <ant...@mi...>]

Josh Green wrote:
> Well, I'm still ploding along on Swami development. New devel branch
> is.. well developing :) libInstPatch has some more testing under its
> belt and a Python interface is beginning to form. I'm starting to
> re-work the GUI side of things to make it more pluggable in anticipation
> of new formats being added to libInstPatch (DLS2, Akai, GUS and perhaps
> SF1). Much of this has still not been committed to CVS, although I would
> be quick to commit it if I knew someone was interested (hint hint).

No-one is. No, seriously, I'm interested :) And ready to test and help.

-a

Re: [Linuxsampler-devel] Anything going on?

[Antti B. <ant...@mi...>]

Thanks for the responses. Nice to see things are still developing. I'm 
always a bit too worried about the possibility of good projects being 
abandoned.

Benno Senoner wrote:
> Hi,
> sorry for my absence, I have to migrate the servers of an ISP (need to
> finish for christmas)  thus I will not be that much present for the next
> two weeks. (I promise no high-load situations again for the whole 2003
> :-) )

No need to be sorry, I'm in no position to force people do these things :)

I'm still willing to hop in when GUIs or similar are needed. 
Unfortunately, my skills in the low level area are still rather... low.

-a

Re: [Linuxsampler-devel] Anything going on?

[Steve H. <S.W...@ec...>]

On Wed, Dec 11, 2002 at 11:36:35 -0300, Juan Linietsky wrote:
> The cvs is quite outdated..
> I cant commit it seems (either i dont underst very well how sourceforge works,
> or my account is wrong, or i forgot my password :), so i've sent
> the latest tarball to benno and steve...
> Benno seems to be quite busy this week, but i hope
> he gets to review/upoaded the latest tarball...

I built it OK, but I had some alsa seq realted problems and so couldn't
try it. I'l give it another go when I have a chance.

- Steve 

Re: [Linuxsampler-devel] Anything going on?

[Juan L. <co...@re...>]

On Wed, 11 Dec 2002 15:40:19 +0200
Antti Boman <ant...@mi...> wrote:

> Hi,
> 
> Is anything going on with linuxsampler? I checked out CVS and it showed 
> updates haven't happened fro five weeks. Are you people working on 
> something else or just... hiding? ;)
> 
> -a
> 

The cvs is quite outdated..
I cant commit it seems (either i dont underst very well how sourceforge works,
or my account is wrong, or i forgot my password :), so i've sent
the latest tarball to benno and steve...
Benno seems to be quite busy this week, but i hope
he gets to review/upoaded the latest tarball...

I'd send it to the list, but it doesnt like big posts, so if
anyone else wants it let me know and i'll private-email it!

Juan Linietsky

Re: [Linuxsampler-devel] evo code

[Benno S. <be...@ga...>]

Il mar, 2002-11-26 alle 00:23, Christian Schoenebeck ha scritto:
> >
> > What does mean expected buffers similar to ASIO etc ? Can you elaborate
> > ?
> 
> AFAIK ASIO uses two buffers which are isolated. One buffer is only accessed 
> for wether reading or writing, never both at the same time. So buffer A gets 
> filled by the disk stream while buffer B is read by the audio thread. After 
> that buffer B gets filled while buffer A is read and so on...
> The time for one period is fixed by the buffer size, sampling rate and audio 
> channels.
> 
> Somebody already posted an article about that, but I haven't found it anymore.
> 
> The advantage of those simple buffers is that you can always expect a fixed 
> buffer size for reading/writing at any time. Whereas with you approach, you 
> always have to check how many bytes are left to read/write and if you have to 
> continue from the beginning of the buffer after accessing some pieces at the 
> end. That's why your way is a bit more CPU hungry but circumvents those 
> latency problems ASIO and Gigasampler has (latency fixed to the buffer size 
> and latency jitter or even higher latency to correct that jitter).

Keep in mind that with variable sample pitch (which is always the case
in a sampler) you will never be able to read an integral number of
samples from the source (the sample on disk or ram) resample them and
write it to as you call it to the "asio buffer". 
In my code I use OSS or ALSA writing data in chunks too (fragments),
thus it is excactly the stuff you described.
Thanks to the wraparound concept, the overhead is really small since the
buffer ptr updates are very infrequent and occur in a low priority
thread.(the disk thread).

> 
> > If you you have a more efficient scheme in mind please tell us.
> > The final latency does not depend on the ringbuffer size since this
> > buffer is only for compensating disk latency.
> 
> Of course not, I meant those ASIO/Giga Buffers.
but this is user selectable , no problem here, ... As said before, I
successfully ran tests
with 3 x 32 sample audio buffers which leads to 2.1 msec latency. :)
> 
> > On the audio side we simply use regular fragment-based audio output.
> > This means usually only 2-3 fized sized buffers so no ring buffers are
> > involved.
> 
> I guess you mean these audio_sum, audio_buf arrays [audiothread.cpp] to 
> calculate the mix and send it to the audio device, right?

yes.

> >
> > The check_wrap is suboptimal since it checks for when it is about time
> > to replicate some data past the buffer end so that the interpolator can
> > fetch samples past the "official ring buffer end boundary".
> 
> Why is this inefficient? Do you mean because of the memcpy() in check_wrap() 
> that copies a portion within the buffer?

Not the function itself is inefficient, only the fact that it is called
relatively often from within the audiothread. The check_wrap can be
moved to the audio thread where it will be called less frequently thus
saving some cpu cycles (but not that much since it is inlined).

> 
> > This check can be moved within the disk thread which accesses the buffer
> > with a much lower frequency and where it is easy to figure out when the
> > last read reached the ring buffer end position.
> 
> I'm not sure what you're getting at. Do you mean that it's more likely that 
> read/write access to the buffer won't interfere/overlap, because the audio 
> thread reads faster than the disk buffer can fill up the space, due to the 
> higher priority of the audio thread?

no, the disk thread "always writes faster than the audio thread reads",
or in short: there will be always some data in the ring buffer as long
as the disk is not overloaded (if that happens we must lower the max #
of voices or user more powerful hardware ... it is not our fault).
Anyway since in regular conditions there will always some data in the
buffer, resampling will work perfectly even at buffer boundaries thanks
to the check_wrap func that mirrors the data that is stored at the
buffer beginning to the position that resides past the buffer end.

cheers,
Benno


-- 
http://linuxsampler.sourceforge.net
Building a professional grade software sampler for Linux.
Please help us designing and developing it.
 

Re: [Linuxsampler-devel] Anything going on?

[Josh G. <jg...@us...>]

On Wed, 2002-12-11 at 05:40, Antti Boman wrote:
> Hi,
> 
> Is anything going on with linuxsampler? I checked out CVS and it showed 
> updates haven't happened fro five weeks. Are you people working on 
> something else or just... hiding? ;)
> 
> -a
> 
> 

Well, I'm still ploding along on Swami development. New devel branch
is.. well developing :) libInstPatch has some more testing under its
belt and a Python interface is beginning to form. I'm starting to
re-work the GUI side of things to make it more pluggable in anticipation
of new formats being added to libInstPatch (DLS2, Akai, GUS and perhaps
SF1). Much of this has still not been committed to CVS, although I would
be quick to commit it if I knew someone was interested (hint hint).
Cheers.
	Josh Green

[Linuxsampler-devel] Anything going on?

[Antti B. <ant...@mi...>]

Hi,

Is anything going on with linuxsampler? I checked out CVS and it showed 
updates haven't happened fro five weeks. Are you people working on 
something else or just... hiding? ;)

-a

Re: [Linuxsampler-devel] evo code

[Christian S. <chr...@ep...>]

Es geschah am Sonntag, 24. November 2002 22:25 als Benno Senoner schrieb:
> Not sure if ints are faster than bools, but OTOH I agree with you that
> bools are more elegant. (somethimes I write inelegant code, sorry).

I wasn't able to determine any performance benefit of it, nevertheless at 
least a typef won't hurt. 

> > Is there any benefit of using this double_to_int() function
> > [audiovoice.cpp] and the asm code in it, instead of a normal type cast?
>
> See Steve's reply, this hack is needed only on x86, PPCs and most of the
> other archs can use simple casts.

I compared both and got exactly the same results wether asm or normal type 
cast and wether integral or rational number (Athlon). But the performance is 
in fact a point.

> > I was a bit surprised about the ring buffer. I expected a buffer similar
> > to the ones which are used in ASIO or Gigasampler. These consume less CPU
> > time but on the other hand of course, latency values are dependent on the
> > buffer size. How about giving the user the choice which kind of buffer to
> > use?
>
> What does mean expected buffers similar to ASIO etc ? Can you elaborate
> ?

AFAIK ASIO uses two buffers which are isolated. One buffer is only accessed 
for wether reading or writing, never both at the same time. So buffer A gets 
filled by the disk stream while buffer B is read by the audio thread. After 
that buffer B gets filled while buffer A is read and so on...
The time for one period is fixed by the buffer size, sampling rate and audio 
channels.

Somebody already posted an article about that, but I haven't found it anymore.

The advantage of those simple buffers is that you can always expect a fixed 
buffer size for reading/writing at any time. Whereas with you approach, you 
always have to check how many bytes are left to read/write and if you have to 
continue from the beginning of the buffer after accessing some pieces at the 
end. That's why your way is a bit more CPU hungry but circumvents those 
latency problems ASIO and Gigasampler has (latency fixed to the buffer size 
and latency jitter or even higher latency to correct that jitter).

> The ringbuffer is very very efficient, basically the audio thread can
> access the ringbuffer as it were a linear sample, at the end of the
> processing of a fragment you simply do read_ptr = (read_ptr +
> fragment_size) & (ringbuf_size-1);  (ringbuf_size is a power of two to
> avoid relatively slow % (modulus) ops).

Yes I found the latter a very clever and efficient trick to keep the pointer 
within the boundaries.

> If you you have a more efficient scheme in mind please tell us.
> The final latency does not depend on the ringbuffer size since this
> buffer is only for compensating disk latency.

Of course not, I meant those ASIO/Giga Buffers.

> On the audio side we simply use regular fragment-based audio output.
> This means usually only 2-3 fized sized buffers so no ring buffers are
> involved.

I guess you mean these audio_sum, audio_buf arrays [audiothread.cpp] to 
calculate the mix and send it to the audio device, right?

> > And finally I was a little bit unsure about the purpose of the
> > check_wrap() method in the RingBuffer template. It ensures a sequential
> > reading of 2*WRAP_ELEMTS = 2048 elements, right???
> > If so, shouldn't there a be a check if there are enough elements
> > available for reading?
>
> The check_wrap is suboptimal since it checks for when it is about time
> to replicate some data past the buffer end so that the interpolator can
> fetch samples past the "official ring buffer end boundary".

Why is this inefficient? Do you mean because of the memcpy() in check_wrap() 
that copies a portion within the buffer?

> This check can be moved within the disk thread which accesses the buffer
> with a much lower frequency and where it is easy to figure out when the
> last read reached the ring buffer end position.

I'm not sure what you're getting at. Do you mean that it's more likely that 
read/write access to the buffer won't interfere/overlap, because the audio 
thread reads faster than the disk buffer can fill up the space, due to the 
higher priority of the audio thread?

Regards,
Christian

Re: [Linuxsampler-devel] evo code

[Benno S. <be...@ga...>]

On Sat, 2002-11-23 at 22:00, Christian Schoenebeck wrote:
> 
> Is there a reason that int types were always used for actually bool types or 
> is it just some kind of habit?

Not sure if ints are faster than bools, but OTOH I agree with you that
bools are more elegant. (somethimes I write inelegant code, sorry).

> 
> Is there any benefit of using this double_to_int() function [audiovoice.cpp] 
> and the asm code in it, instead of a normal type cast?

See Steve's reply, this hack is needed only on x86, PPCs and most of the
other archs can use simple casts.

> 
> I was a bit surprised about the ring buffer. I expected a buffer similar to 
> the ones which are used in ASIO or Gigasampler. These consume less CPU time 
> but on the other hand of course, latency values are dependent on the buffer 
> size. How about giving the user the choice which kind of buffer to use?

What does mean expected buffers similar to ASIO etc ? Can you elaborate
?
The ringbuffer is very very efficient, basically the audio thread can
access the ringbuffer as it were a linear sample, at the end of the
processing of a fragment you simply do read_ptr = (read_ptr +
fragment_size) & (ringbuf_size-1);  (ringbuf_size is a power of two to
avoid relatively slow % (modulus) ops).
If you you have a more efficient scheme in mind please tell us.
The final latency does not depend on the ringbuffer size since this
buffer is only for compensating disk latency.
The bigger this ringbuffer the smaller the risk of ending up in an
"empty disk voice buffer" situation.
The disk buffer size can be smaller for low-msec disk access times.
On the audio side we simply use regular fragment-based audio output.
This means usually only 2-3 fized sized buffers so no ring buffers are
involved.

> 
> And finally I was a little bit unsure about the purpose of the check_wrap() 
> method in the RingBuffer template. It ensures a sequential reading of 
> 2*WRAP_ELEMTS = 2048 elements, right???
> If so, shouldn't there a be a check if there are enough elements available 
> for reading?

The check_wrap is suboptimal since it checks for when it is about time
to replicate some data past the buffer end so that the interpolator can
fetch samples past the "official ring buffer end boundary".
This check can be moved within the disk thread which accesses the buffer
with a much lower frequency and where it is easy to figure out when the
last read reached the ring buffer end position. (in that case read the
data from disk and write it at ring buffer start and replicate some
samples past the ring buffer end).

If you have more question or if some of the issues are not clear please
let us know on the mailing list.

cheers,
Benno

-- 
http://linuxsampler.sourceforge.net
Building a professional grade software sampler for Linux.
Please help us designing and developing it.
 

Re: [Linuxsampler-devel] evo code

[Steve H. <S.W...@ec...>]

On Sat, Nov 23, 2002 at 10:00:21 +0100, Christian Schoenebeck wrote:
> Is there a reason that int types were always used for actually bool types or 
> is it just some kind of habit?

Ints are generally the fastest types to access, so using them for bools
makes sense.
 
> Is there any benefit of using this double_to_int() function [audiovoice.cpp] 
> and the asm code in it, instead of a normal type cast?

Casting to int rounds down to the nearest int (which isn't always what you
want) and is very slow on x86. It reuires flushing the register stack
reseting the fpunit's parameters, doing the conversion, flushing the stack...

The other questions are specific to evo, so I cant help you there.

- Steve

[Linuxsampler-devel] evo code

[Christian S. <chr...@ep...>]

I read the evo-0.0.6 code to become acquainted with the basics involved in 
this project and audio applications in general (as I've never written an 
audio app before). I appreciate that the code isn't that complex, so you can 
easily get an overview of the most relevant parts.

It left me with some minor questions however, that I hope somebody can 
explain to me (I guess that's most likely Benno but if anybody else can tell 
me too... :)

Is there a reason that int types were always used for actually bool types or 
is it just some kind of habit?

Is there any benefit of using this double_to_int() function [audiovoice.cpp] 
and the asm code in it, instead of a normal type cast?

I was a bit surprised about the ring buffer. I expected a buffer similar to 
the ones which are used in ASIO or Gigasampler. These consume less CPU time 
but on the other hand of course, latency values are dependent on the buffer 
size. How about giving the user the choice which kind of buffer to use?

And finally I was a little bit unsure about the purpose of the check_wrap() 
method in the RingBuffer template. It ensures a sequential reading of 
2*WRAP_ELEMTS = 2048 elements, right???
If so, shouldn't there a be a check if there are enough elements available 
for reading?

Regards,
Christian

Re: [Linuxsampler-devel] Re: Envelopes , filtering and zipper noise

[Steve H. <S.W...@ec...>]

On Thu, Nov 21, 2002 at 03:06:26AM -0300, Juan Linietsky wrote:
> I think i dont understand the concept of zippernoise, isnt it the one that occurs
> when setting the resonance too high? In that case I dont see why should that be avoided,
> since it's common in any synth i've tried..

I think youre thinking of self resonance (the oscilator like tune you get
from high resonance and non zero input).

zipper noise is an anoying buzzing sound you get when the recalcuation or
interpolation steps are too far apart, caused by discontinuities in the
amplitude curve, or sometimes first derivative of the amplitude.

- Steve 

Re: [Linuxsampler-devel] Re: Envelopes , filtering and zipper noise

[Juan L. <co...@re...>]

On Sat, 16 Nov 2002 10:43:36 -0000
"Paul Kellett" <pau...@ma...> wrote:

> I'm replying to things in the digest - sorry I'm out of sync with everyone 
> else...!
> 
> 
> Benno Senoner <be...@ga...> wrote:
> >
> > Regarding adding a let's say resonant LP filter to the sample output:
> > I guess the coefficients need to be smoothed out in some way too,
> > otherwise zipper noise will probably show up again.
> 
> Filter cutoff is much less sensitive to zipper nose than amplitude, and
> for typical sampler patches, updating the filter coefficients every 32
> or 64 samples is ok, with no interpolation.  The only time this is a 
> problem is for fast, high-resonance filter "chirps", but it still sounds
> acceptable, just not as good as an analog or virtual analog synth.
> 
> 

I think for a sampler, this isnt something much to worry about, I'd
just put focus on speed and quality instead of features :)


> > What would a good tradeoff for achieving low-CPU usage zippernoise-free
> > filter modulation would be ? (some kind of interpolation of precomputed
> > coefficients ?)
> 
> Use a state variable filter.  Almost every other hardware and software
> synth does, and you can adjust cutoff and resonance directly without 
> worrying about stability, or any heavy calculations.
> 
> 
I think i dont understand the concept of zippernoise, isnt it the one that occurs
when setting the resonance too high? In that case I dont see why should that be avoided,
since it's common in any synth i've tried..


> 
> Steve Harris <S.W...@ec...> wrote:
> > 
> > BTW do we know for sure than samplers use exponential envelopes? I guess 
> > we need linear ones too, but they are easy to implement. 
> 
> Decay and release should be exponential.  It's nice to offer a choice of
> linear or other curves (mostly useful for drum sounds) but for most 
> instruments, linear decay/release sounds bad - the fade out is too sudden.
> But the ear is quite tolerant if the curves are only approximately
> exponential.
> 
> 

The problem with exponential release envelopes is that they take too much to fade, 
and that can leaves voices hanging and consuming CPU for large periods where
they are not or almost not being heard. For this I think the out-of-voices-removing
algorithm should be given good voice priority values to work with.
And yes, exponential attack envelopes make it sound like the voices take 
some time to start, i noticed this in synths like the DX7.

> 
> > get some recordings from samples of high freq sinewaves with envelopes.
> > I think Frank N. has done this allready for the S2000, Frank are you on
> > the list?
> 
> It's better to use square waves, then the shape of the envelope (for 
> example if there are sharp corners between each stage) is not hidden by
> the shape of the waveform.
> 
Squares are so cool :) I use them to check the filter response and variation a lot.
 
> 
> Benno Senoner <be...@ga...> wrote:
> > 
> > It is probably the easiest to keep track of the previous pitch value
> > and then simply interpolate linearly to the new value within a let's say
> > 0.5 - 1 msec time frame. I think this would smooth out things nicely,
> > right ?
> > 
> > (Steve, others, do you agree ?)
> 
> Agree.  But a lot of the time, where the envelopes and any LFOs are
> changing slowly, you may not even need to interpolate pitch and filter
> cutoff, just step every 1ms.

unless the LFO is timed _very_ fast (which usually beats 
the purpose of the L in it :) There is not any need to
interpolate the pitch between resampling fragments, because
you will definitively not notice it, just think that it never
does any crazy jumps in the sample, simply speedsup/slowdown
so there isnt really a way that artifacts can pop up.


BTW! I've been covered with work lately, i need to find some time to finish up and
upload a working skeleton program!


Cheers

Juan Linietsky

Re: [Linuxsampler-devel] GUI thoughts

[Matthias W. <mat...@in...>]

On Fri, Nov 15, 2002 at 07:22:35PM -0800, Josh Green wrote:
> > AFAIK there are no r/w locks in the current linuxthread implementation.
> > I read about plans to include those in connection with the NPT (native
> > posix threads).
> > 
> > matthias
> > 
> 
> What about pthread_rwlock_t (you can see this in
> /usr/include/pthread.h). I notice that the function prototypes are
> surrounded by an "#ifdef __USE_UNIX98" which I'm unfamiliar with. I can
> do a "p sizeof (pthread_rwlock_t)" in gdb with a pthread linked program,
> so it seems to be available (32 bytes a mutex, not bad I guess). Cheers.
> 	Josh Green

I played around with this when I needed 'pthread_mutexattr_settype' and 
found out that I had to define

#define _XOPEN_SOURCE 600

before the first system include in my code; this will set some other defines
in /usr/include/features.h . I have to note that lots of basic types (I
guess one of it was size_t) got screwed up so I had to drop it again.

Besides, I'd try to use atomic types and atomic read/writes to avoid
locking wherever possible.

matthias

[Linuxsampler-devel] Re: Envelopes , filtering and zipper noise

[Paul K. <pau...@ma...>]

I'm replying to things in the digest - sorry I'm out of sync with everyone 
else...!


Benno Senoner <be...@ga...> wrote:
>
> Regarding adding a let's say resonant LP filter to the sample output:
> I guess the coefficients need to be smoothed out in some way too,
> otherwise zipper noise will probably show up again.

Filter cutoff is much less sensitive to zipper nose than amplitude, and
for typical sampler patches, updating the filter coefficients every 32
or 64 samples is ok, with no interpolation.  The only time this is a 
problem is for fast, high-resonance filter "chirps", but it still sounds
acceptable, just not as good as an analog or virtual analog synth.


> What would a good tradeoff for achieving low-CPU usage zippernoise-free
> filter modulation would be ? (some kind of interpolation of precomputed
> coefficients ?)

Use a state variable filter.  Almost every other hardware and software
synth does, and you can adjust cutoff and resonance directly without 
worrying about stability, or any heavy calculations.



Steve Harris <S.W...@ec...> wrote:
> 
> BTW do we know for sure than samplers use exponential envelopes? I guess 
> we need linear ones too, but they are easy to implement. 

Decay and release should be exponential.  It's nice to offer a choice of
linear or other curves (mostly useful for drum sounds) but for most 
instruments, linear decay/release sounds bad - the fade out is too sudden.
But the ear is quite tolerant if the curves are only approximately
exponential.



> get some recordings from samples of high freq sinewaves with envelopes.
> I think Frank N. has done this allready for the S2000, Frank are you on
> the list?

It's better to use square waves, then the shape of the envelope (for 
example if there are sharp corners between each stage) is not hidden by
the shape of the waveform.




Benno Senoner <be...@ga...> wrote:
> 
> It is probably the easiest to keep track of the previous pitch value
> and then simply interpolate linearly to the new value within a let's say
> 0.5 - 1 msec time frame. I think this would smooth out things nicely,
> right ?
> 
> (Steve, others, do you agree ?)

Agree.  But a lot of the time, where the envelopes and any LFOs are
changing slowly, you may not even need to interpolate pitch and filter
cutoff, just step every 1ms.

  
> Ok but assume these nice LP filter  wah-wah effects.
> The LFO frequency in this case is up to a few Hz, but the modulation
> frequency (filter coefficient change rate) ? How low can it go so that
> zipper noise can be avoided ?

There is no simple answer to this - you will hear zipper noise on a low/mid
frequency sine wave that you won't hear on any other sound, so maybe it
is better to have a user-adjustable "quality" setting for what gets 
interpolated.  If someone is going to be playing big piano and orchestral
samples with no processing, they can switch to the lowest setting (so best
if it's not actually labelled "quality"!) or offer an unprocessed playback
option like HALion does.




Paul.

_____________________________

  m a x i m | digital audio

    http://mda-vst.com
_____________________________

Re: [Linuxsampler-devel] Envelopes , filtering and zipper noise

[Steve H. <S.W...@ec...>]

On Sat, Nov 16, 2002 at 12:48:20 +0100, Frank Neumann wrote:
> Please find the following files for analysis:
> http://lakai.sf.net/sinetest.wav.gz (the sample, 440 KByte packed)
> http://lakai.sf.net/sine1_attack.png (a screenshot of a close look at the
> attack phase)
> http://lakai.sf.net/sine2_release.png (the same for the release phase)

Thanks, thats great.
 
> If you need more analysis, let me know; however, I'll be on a company trip
> (to Bristol - yeah, UK, unfortunately not So'ton :-}) from Sunday - 
> Thursday, so don't expect answer before Friday.

Shame up in that part of the cournty quite often, but not this week.

Cheers,
   Steve

Re: [Linuxsampler-devel] GUI thoughts

[Josh G. <jg...@us...>]

On Fri, 2002-11-15 at 13:18, Matthias Weiss wrote:
> On Wed, Nov 13, 2002 at 10:35:51PM -0800, Josh Green wrote:
> > 
> > consist of samples, instruments, presets, zones etc, there are quite a
> > lot of them. Thats a lot of wasted space just for a lock. I guess I'll
> > have to look into some other threading libraries, perhaps just go
> > pthread or something. The ideal would be a recursive R/W lock. I've seen
> > these in the pthread library, but I'm not sure if they are recursive. 
> 
> AFAIK there are no r/w locks in the current linuxthread implementation.
> I read about plans to include those in connection with the NPT (native
> posix threads).
> 
> matthias
> 

What about pthread_rwlock_t (you can see this in
/usr/include/pthread.h). I notice that the function prototypes are
surrounded by an "#ifdef __USE_UNIX98" which I'm unfamiliar with. I can
do a "p sizeof (pthread_rwlock_t)" in gdb with a pthread linked program,
so it seems to be available (32 bytes a mutex, not bad I guess). Cheers.
	Josh Green

Re: [Linuxsampler-devel] Envelopes , filtering and zipper noise

[Josh G. <jg...@us...>]

I was just having a few thoughts concerning different implementations of
synth primitives (envelopes, LFOs, wavetable interpolation, filters,
etc). It seems like if LinuxSampler is going to be modular (or JIT
based) there could be several ways to do things for different
CPU/quality trade offs. It might even be nice to have very expensive
algorithms created (6+ point interpolation or something :) This could be
useful as one could create a MIDI sequence of a song, compose it with
less CPU hungry synth primitives and then have the option of rendering
the final piece in non-realtime using all the highest quality primitives
:) So it seems building the modular framework is probably the most
important stage, no? Or is the current focus to create something that
just works? Anyways, just some thoughts. Cheers.
	Josh Green

Re: [Linuxsampler-devel] Envelopes , filtering and zipper noise

[Frank N. <bea...@we...>]

Hi,
Steve wrote:

> BTW do we know for sure than samplers use exponential envelopes? I guess we
> need linear ones too, but they are easy to implement. We should probably
> get some recordings from samples of high freq sinewaves with envelopes.
> I think Frank N. has done this allready for the S2000, Frank are you on
> the list?

Yes, I'm here :-). I just made a short example of this for you; I hope this
is what you were asking for, I have a hard time trying to catch up with all
the mailing lists :-).

I loaded a sine wave into the sampler, set the program's attack and release
times to 0 and played a couple of high-pitched notes, sampled this into the
PC (44.1 kHz) and had a closer look at the attack and release phase of the
sample (for analysis, Conrad Parker's "sweep" is highly recommended; I just 
learnt recently that you can even vertically zoom into a sample by using
Shift+Cursor up/down, which helps a lot in finding the exact starting point
of a sample :-)

Please find the following files for analysis:
http://lakai.sf.net/sinetest.wav.gz (the sample, 440 KByte packed)
http://lakai.sf.net/sine1_attack.png (a screenshot of a close look at the
attack phase)
http://lakai.sf.net/sine2_release.png (the same for the release phase)

It was interesting for me to discover that the release phase is always
faded out somewhat exponentially (and "rather slowly", taking about 2.2ms),
while the attack phase is very short; looking _very_ close at it, I'd say
it's about 28 samples long, ~0.6 ms. But both are _not zero_ (so really 
"hard clicks" can never occur). That's the same behaviour I'd expect from
any software instrument, too.

If you need more analysis, let me know; however, I'll be on a company trip
(to Bristol - yeah, UK, unfortunately not So'ton :-}) from Sunday - 
Thursday, so don't expect answer before Friday.

Greetings,
Frank