Re: [Linuxsampler-devel] 24bit multi-io audio card compatibility, Was: CVS

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

Scrive Mark Knecht <mar...@co...>:

 > 
> Not only that, but I recorded the same drone using GSt and LS into Pro
> Tools and then looked visually at the two. With GSt set at full volume
> the two looked basically identical in Pro Tools down at the sample
> level.

Well, a sampler (when playing a sample at the root note) it's just copying
the data from the source (the sample stored in RAM/disk) to the output,
aka the soundcard. And since your audio paths are all digital it's
easy to get matching samples down to bit level (as long both samplers
only copy the data and do not screw it up by filters, interpolators etc).
As for interpolation, currently we use only linear interpolation,
cubic interpolation is implemented but commented out because it needs
 some tweaking for the stereo samples. We will make it configurable.

> > 
> > IIRC you played LS with --fragmentsize 256, lower this to 64
> > it should give you a latency of 2*64 = 128 frames = 3msec
> > 
> > Please redo the test and tell us if the latency is correct
> > (probably you need to add the 1.1msec of MIDI Note-on latency if you
> trigger
> > LS via external MIDI device).
> 
> I will revisit this tomorrow when I have more time. I think my tests
> need some corrections for sure. In LS I was using the 256 fragment size.
> In GSt I was using a buffer size of 128. That will certainly account (I
> think) for some of the reason that LS looked slower.

Be sure to pay attention what 128 stands for.
128 bytes or frames (samples, regardless if stereo or mono) or 
samples (128 samples played in stereo means 64 frames thus half of the
buffer time than if the 128 samples were played in mono).
I think the easiest ist to increase the buffer values in both samplers
to let's say 2048 or more and look at the delay time which will be easier
to analyze than the dimes you get when you use very short buffers.

> 
> As for how I measured it, I set up both GSt and LS to be triggered by my
> keyboard. The keyboard came into Linux on a MidiSport 2x2 input, and
> then using kaconnect was routed to a MidiSport output to go out to GSt,
> and routed directly to LS in software.

Well to be fair you must then subtract 1.1msec from the GSt latency
because in the above case GSt is treated unfairly (data gets into the
linux box and virtually immediately to LS but takes an additional
1.1msec (midi wire speed of a 3byte note-on/off message) to get out to GSt.

> 
> The LS output was then routed through playback_1/2 to the ADAT2-1/2
> outputs and was recorded by Pro Tools.
> 
> In the GSt box MIDI goes in through an AP2496 MIDI port and triggers
> GSt, which goes out over ADAT, into the HDSP 9652 where it is routed in
> hardware to ADAT2-3/4 outputs where it is recorded by Pro Tools at the
> same time as LS.

Just make sure that the tests are fair and that none of both apps
gets penalized by additional audio buffering (due to routing) etc.

> 
> All I was looking at was the relative positions of the two stereo
> signals in Pro Tools and seeing an offset with LS coming later.
> 
> I need to redo this with at least the same buffer size for the two
> samplers.

I'm very curious about the results .... :-)

> 
> 
> One other interesting thing I did was to just brutally overload LS with
> polyphony while using the drone library.Since you don't handle the
> sustain pedal yet I simply laid my arms down on the keyboard covering
> all the white notes for about 4 octaves and held them. All indications
> were that all the notes played. Since this library's note length is
> scaled by the keyboard position, the high notes cut out first, and then
> lower and lower notes cut out as they run their length. Since you don't
> loop yet, I can hear the notes drop out one by one. Everything seemed
> correct.

The only performance problems I could see is when one tries to play
a sample at let's say +4 octaves (48 semitones) up from the root note.
This means you play the sample 16 times faster ( 2^(48/12)=16 ) and
the initial RAM buffer time goes down from 1.5 to 0.1 sec which is too
short to compensate for disk latency. The associated 
streaming ringbuffer will run into problems too because the disk will
have hard time to keep up with ensuring that it is always filled.
But other streaming samplers have the same problem too and in practice
it will rarely happen because modern streaming sampling libraries are
heavily multisamples and the pitch shifting will be max a few semitones
so one has not to worry about that.

> 
> This was quite good.
> 
> One small negative I found was during just simple playing, upon release
> of a note I get definite little 'clicks' out of LS. I am guessing that
> this is probably because you implement no ADSR yet? I'm sure that GSt
> implements some standard release envelope to eliminate that problem. It
> probably continues to play the voice for a few more samples as it ramps
> the volume down to zero. If this is the case, then it's not a problem
> and you just need to work on providing something like that when you can.

Yes envelopes are not implemented yet thus when you release a key the
sample is cut off abruptly which leads to this high frequency click.
Full enveloping will come soon to but before implementing it we will
make sure that LS is able to handle sample accurate events so that
it can more easily be part of future integrated enviroments like
eg. Cubase and Halion. (where Halion can render sample accurate events
based of Cubase's sequencer events which are sent through the VSTi API).

> 
> For technical reasons I couldn't get the Bardstown piano over to the
> Linux box yet. It's compressed in an executable file. Is there some way
> to run that in Linux, maybe using a DOS window or something? I've never
> used dosemu or any form of DOS under Linux, so I don't know how to
> proceed. 
> 
> I can probably copy the library to a 1394 drive and then mount it under
> Linux. If there's no easier way to do it, then I will work on doing it
> that way tomorrow.

It's probably easier to decompress it on a Windows box and transfer it
to Linux.

> 
> I want to work on this as it will start to demonstrate LS's ability to
> work with multi-velocity libraries.

Some libraries already trigger the right samples associated to velocity-splits
some still show funny sample mapping but according to Christian after
his corrections all these problems will go away in one rush.

> 
> Overall I'm very happy and MOST impressed by the two signal outputs
> looking sample for sample identical in Pro Tools. That quite an
> accomplishment considering (I think) that no one has looked at this
> before me. Congrats to all of you!

Congrats to you for the in-depth tests, probably LS would (after getting
 to production quality state) not be the same without your feedback !
You are part of the of the team too, right ? So change that sentence
into "congrats to us all" :-)

I'm already drooling when we will be able to impress the northernsounds folks
 with a fully working version, screenshots and mp3 demos recorded using LS.
Having followed their passionate discussions I guess it will ignite a quite
 heavy discussion :-)
Meanwhile let's work hard to get to that point.

cheers,
Benno
http://www.linuxsampler.org
 


-------------------------------------------------
This mail sent through http://www.gardena.net