Menu
▾
▴
linuxsampler-devel
|
From: Mark K. <mar...@co...> - 2003-10-28 13:06:49
|
Hi, I downloaded (I think) the CVS code. How do I build it? No INSTALL instruction file, so I tried: make -f Makefile.am which produced a executable configure file, but then attempting to run that configure file failed: bash-2.05b$ ./configure creating cache ./config.cache ./configure: line 541: syntax error near unexpected token `LinuxSampler,0.0.1' ./configure: line 541: `AM_INIT_AUTOMAKE(LinuxSampler,0.0.1)' bash-2.05b$ This is on Gentoo. The system is very up to date. - Mark |
|
From: Robert J. <rob...@da...> - 2003-10-28 13:19:30
|
Hi Mark, it sounds as if you got the version from sourceforge.net (as I did) the real version is at: cvs -z3 -d:pserver:ano...@cv...:/home/schropp/linuxsampler co linuxsampler just typeing make after it downloaded worked for me. /Robert Tuesday 28 October 2003 14.03 skrev Mark Knecht: > Hi, > I downloaded (I think) the CVS code. How do I build it? No INSTALL > instruction file, so I tried: > > make -f Makefile.am > > which produced a executable configure file, but then attempting to run > that configure file failed: > > bash-2.05b$ ./configure > creating cache ./config.cache > ./configure: line 541: syntax error near unexpected token > `LinuxSampler,0.0.1' > ./configure: line 541: `AM_INIT_AUTOMAKE(LinuxSampler,0.0.1)' > bash-2.05b$ > > > This is on Gentoo. The system is very up to date. > > - Mark > > > > ------------------------------------------------------- > This SF.net email is sponsored by: The SF.net Donation Program. > Do you like what SourceForge.net is doing for the Open > Source Community? Make a contribution, and help us add new > features and functionality. Click here: http://sourceforge.net/donate/ > _______________________________________________ > Linuxsampler-devel mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel |
|
From: Mark K. <mar...@co...> - 2003-10-28 13:47:10
|
On Tue, 2003-10-28 at 05:07, Robert Jonsson wrote: > Hi Mark, > > it sounds as if you got the version from sourceforge.net (as I did) > > the real version is at: > > cvs -z3 -d:pserver:ano...@cv...:/home/schropp/linuxsampler > co linuxsampler > > just typeing make after it downloaded worked for me. > > /Robert > Robert, Thanks. That downloaded and built fine, but it's not running: bash-2.05b$ cd LSt/linuxsampler/ bash-2.05b$ ./linuxsampler --gig ../Gigs/Mellotron\ 8Voice.gig Initializing audio output...Error snd_pcm_hw_params_set_access: Invalid argument. bash-2.05b$ This machine is using the infamous HDSP 9652. I can try it on my GSt machine later this afternoon. That machine uses a Hammerfall Light and has lots of gig files. - Mark |
|
From: <be...@ga...> - 2003-10-28 14:41:26
|
Scrive Mark Knecht <mar...@co...>:
>
> Robert,
> Thanks. That downloaded and built fine, but it's not running:
>
>
> bash-2.05b$ cd LSt/linuxsampler/
>
> bash-2.05b$ ./linuxsampler --gig ../Gigs/Mellotron\ 8Voice.gig
> Initializing audio output...Error snd_pcm_hw_params_set_access: Invalid
> argument.
> bash-2.05b$
>
> This machine is using the infamous HDSP 9652. I can try it on my GSt
> machine later this afternoon. That machine uses a Hammerfall Light and
> has lots of gig files.
This is because we currently use direct ALSA hw audio out and I've added
only code for 16bit/44.1kHz stereo to the AudioIO class.
Anyway as a quick solution you could try to
use the plughw: ALSA mode (where ALSA does the conversion between
audio fromat requested by the app and audio format supported by the card):
edit the file audioio.cpp
and at line 59
replace:
pcm_name = strdup("hw:0,0");
with:
pcm_name = strdup("plughw:0,0");
make clean; make
and try again.
Please let us know if it works.
If not then we will have to add code that supports the Hammerfall audio
settings.
You could either try to do this by yourself (if you have the necessary skills)
or I could do this by myself. I have a Hammerfall 9656 here and I assume
that the audio wordsizes are the same so I guess code that runs on that box
runs on on the HDSP too.
Anyway I just hope plughw: works so it saves us additional work.
Well this is a classic case why jackd is so beneficial: you are freed from
the burden of supporting several kinds of audio interfaces, multichannel stuff,
word sizes, sampling rates etc.
As said jackd support will come next but for now we need direct ALSA out
support for latency profiling reasons. This is fundamental for the initial
development and tuning phase.
Mark if we don't get plughw: working I'll make sure to add
HDSP support to the AudioIO class because you are very valuable and important
for ironing out playback problems, compatibility with large GIG libs etc.
Let us know about plughw please.
(the conversion in ALSA is pretty efficient so
the added overhead is quite low and the performance is almost as same
as when doing the conversion in the app itself).
Benno
>
> - Mark
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: The SF.net Donation Program.
> Do you like what SourceForge.net is doing for the Open
> Source Community? Make a contribution, and help us add new
> features and functionality. Click here: http://sourceforge.net/donate/
> _______________________________________________
> Linuxsampler-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel
>
-------------------------------------------------
This mail sent through http://www.gardena.net
|
|
From: Mark K. <mar...@co...> - 2003-10-28 15:29:38
|
On Tue, 2003-10-28 at 06:35, be...@ga... wrote:
> edit the file audioio.cpp
> and at line 59
> replace:
> pcm_name = strdup("hw:0,0");
> with:
> pcm_name = strdup("plughw:0,0");
>
> make clean; make
>
Benno,
One step closer:
mark@Wizard linuxsampler $ ./linuxsampler --gig ../Gigs/Mellotron\
8Voice.gig
Initializing audio output...Error setting number of periods. : Invalid
argument
mark@Wizard linuxsampler $
I think the Hammerfall stuff only handles period sizes of 2? Is that
what's going on here? Or something else?
Mark
|
|
From: <be...@ga...> - 2003-10-28 15:58:32
|
> Benno, > One step closer: > > mark@Wizard linuxsampler $ ./linuxsampler --gig ../Gigs/Mellotron\ > 8Voice.gig > Initializing audio output...Error setting number of periods. : Invalid > argument > mark@Wizard linuxsampler $ > > I think the Hammerfall stuff only handles period sizes of 2? Is that > what's going on here? Or something else? you are correct, the hammerfall can deal only with number of fragments (period size) of 2. you can specify them on the commandline: --numfragments 2 and set the frames per audio buffer too: --fragmentsize 256 (means each audio fragment uses 256 frames). can you try again with the --numfragments 2 and see if it works ? as for using hw:1 just change the source and replace plughw:0 with plughw:1 and recompile (always do a make clean). let us know. Benno > > Mark > > > > ------------------------------------------------------- > This SF.net email is sponsored by: SF.net Giveback Program. > Does SourceForge.net help you be more productive? Does it > help you create better code? SHARE THE LOVE, and help us help > YOU! Click Here: http://sourceforge.net/donate/ > _______________________________________________ > Linuxsampler-devel mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel > ------------------------------------------------- This mail sent through http://www.gardena.net |
|
From: Mark K. <mar...@co...> - 2003-10-28 17:09:48
|
On Tue, 2003-10-28 at 07:58, be...@ga... wrote: > > you are correct, the hammerfall can deal only with > number of fragments (period size) of 2. > you can specify them on the commandline: > --numfragments 2 > and set the frames per audio buffer too: > --fragmentsize 256 (means each audio fragment uses 256 frames). > > can you try again with the --numfragments 2 and see if it works ? > Benno, Again a step closer. Probably LSt working (I'm ssh'ed in, so I cannot actually listen right now) but still some messages I'd rather not see: mark@Wizard linuxsampler $ ./linuxsampler --numfragments 2 --fragmentsize 256 -- gig ../Gigs/Mellotron\ 8Voice.gig Initializing audio output...OK Loading gig file...OK Caching initial samples...OK Starting disk thread...OK Starting MIDI in thread...WARNING, can't mlockall() memory!: Operation not permitted Disk thread running OK WARNING, can't mlockall() memory!: Operation not permitted sched_setscheduler: Operation not permitted Starting audio thread...OK LinuxSampler initialization completed. WARNING, can't mlockall() memory!: Operation not permitted sched_setscheduler: Operation not permitted Audio thread running LinuxSampler stopped due to SIGINT Segmentation fault mark@Wizard linuxsampler $ This is on the standard Gentoo kernel. Possibly it doesn't have some sort of kernel option or patch compiled in? Let me know what you think. Do I need to run as root? I will do some audio testing tonight. Good work! Mark |
|
From: Mark K. <mar...@co...> - 2003-10-28 17:11:20
|
Yes, works better as root: root@Wizard linuxsampler # ./linuxsampler --numfragments 2 --fragmentsize 256 --gig ../Gigs/Mellotron\ 8Voice.gig Initializing audio output...OK Loading gig file...OK Caching initial samples...OK Starting disk thread...OK Starting MIDI in thread...OK Disk thread running Starting audio thread...OK LinuxSampler initialization completed. Audio thread running On Tue, 2003-10-28 at 09:09, Mark Knecht wrote: > On Tue, 2003-10-28 at 07:58, be...@ga... wrote: > > > > > you are correct, the hammerfall can deal only with > > number of fragments (period size) of 2. > > you can specify them on the commandline: > > --numfragments 2 > > and set the frames per audio buffer too: > > --fragmentsize 256 (means each audio fragment uses 256 frames). > > > > can you try again with the --numfragments 2 and see if it works ? > > > Benno, > Again a step closer. Probably LSt working (I'm ssh'ed in, so I cannot > actually listen right now) but still some messages I'd rather not see: > > mark@Wizard linuxsampler $ ./linuxsampler --numfragments 2 > --fragmentsize 256 -- > gig ../Gigs/Mellotron\ 8Voice.gig > Initializing audio output...OK > Loading gig file...OK > Caching initial samples...OK > Starting disk thread...OK > Starting MIDI in thread...WARNING, can't mlockall() memory!: Operation > not permitted > Disk thread running > OK > WARNING, can't mlockall() memory!: Operation not permitted > sched_setscheduler: Operation not permitted > Starting audio thread...OK > LinuxSampler initialization completed. > WARNING, can't mlockall() memory!: Operation not permitted > sched_setscheduler: Operation not permitted > Audio thread running > > > LinuxSampler stopped due to SIGINT > Segmentation fault > mark@Wizard linuxsampler $ > > > This is on the standard Gentoo kernel. Possibly it doesn't have some > sort of kernel option or patch compiled in? Let me know what you think. > > Do I need to run as root? > > I will do some audio testing tonight. > > Good work! > > Mark |
|
From: <be...@ga...> - 2003-10-28 17:32:37
|
Scrive Mark Knecht <mar...@co...>: > Yes, works better as root: > > root@Wizard linuxsampler # ./linuxsampler --numfragments 2 > --fragmentsize 256 --gig ../Gigs/Mellotron\ 8Voice.gig > Initializing audio output...OK > Loading gig file...OK > Caching initial samples...OK > Starting disk thread...OK > Starting MIDI in thread...OK > Disk thread running > Starting audio thread...OK > LinuxSampler initialization completed. > Audio thread running > excellent ! the mlock and sched_setscheduler warnings are becaue a regular user cannot call these functions. It might occur you get mlock errors as root too, but this means that the preloaded RAM size (preloadsize * number of samples in a GIG file) exceeds the available physical memory. See my response to Robert. Keep in mind that here is no concept of midi channel yet, so you can just send midi data (note on/off) to any channel of the ALSA port linuxsampler creates. Let us know if when getting back home you are able to get out sound of LS. PS: Mark, be careful to not scare off neighbours with strange noises while remotely operating LS via ssh :-) cheers, Benno ------------------------------------------------- This mail sent through http://www.gardena.net |
|
From: Mark K. <mar...@co...> - 2003-10-28 17:54:27
|
On Tue, 2003-10-28 at 09:31, be...@ga... wrote: > PS: Mark, be careful to not scare off neighbours with strange noises while > remotely operating LS via ssh :-) > > cheers, > Benno I have made this mistake before. (Actually wife and son sent running to the movies.) Now the studio monitors are off and the only sounds would be in headphones at my mix desk. ;-) |
|
From: Mark K. <mar...@co...> - 2003-10-29 00:12:45
|
Reposting due to the attachment holding the information you might all want to read back. Sorry about that. Can we work out a standard place to put audio clips? I don't run a web server or ftp server here. Thanks, Mark On Tue, 2003-10-28 at 12:39, Mark Knecht wrote: > On Tue, 2003-10-28 at 09:31, be...@ga... wrote: > > > > > Keep in mind that here is no concept of midi channel yet, so you can > > just send midi data (note on/off) to any channel of the ALSA port > > linuxsampler creates. > > > > Let us know if when getting back home you are able to get out sound > > of LS. > > > > Benno, > OK, I came home for lunch since I was curious about trying this out. > I am getting sound from LinuxSampler, so congrats. That's great! > > I only have one GSt library on this machine right now, which is the > 'String Boxes' library from Sonic Implants. I have loaded the 8 voice > Mellotron Choir gig file. I am listening to both GSt and LSt them side > by side. I am able to get both single notes and polyphony from LSt. > That's good. Some data: > > 1) The first issue is that the Mellotron voice I'm playing is 10 seconds > long on GSt, at which point I hear it loop and start over. (Hit one key > and hold it for 30 seconds and you hear 3 passes.) However, LSt is only > playing the voice for 2 seconds and then quitting. It doesn't loop the > voice after 10 seconds, it just stops. > > 2) The pitch of the LSt voice doesn't sound quite right. It seems too > high and brittle. Twice as high, possibly? This is most likely that > we're not picking up the intended middle C correctly I think. (C3 or C4 > - it changes from file to file I think.) > > 3) Zooming way in while in Pro Tools shows the latency of LSt to be > slower than GSt. It doesn't look horrible, and I didn't try to measure > the difference as I don't have much time right now. We can focus on that > later. > > I set up a quick Pro Tools session and recorded them both at the same > time from the same key hit. The 24-bit zipped file with both sounds > separate is about 2MB. That is probably too large for me to send to the > reflector. Shall I send you a copy directly? I'm attaching the shorter, > 16-bit version here, but at 350K your reflector may bounce it. Do you > have an ftp site somewhere where I could drop audio like this? Maybe > even in CVS somewhere? > > Mark > > |
|
From: <be...@ga...> - 2003-10-29 00:54:14
|
crive Mark Knecht <mar...@co...>: > > Benno, > OK, I came home for lunch since I was curious about trying this out. > I am getting sound from LinuxSampler, so congrats. That's great! > > I only have one GSt library on this machine right now, which is the > 'String Boxes' library from Sonic Implants. I have loaded the 8 voice > Mellotron Choir gig file. I am listening to both GSt and LSt them side > by side. I am able to get both single notes and polyphony from LSt. > That's good. Some data: > > 1) The first issue is that the Mellotron voice I'm playing is 10 seconds > long on GSt, at which point I hear it loop and start over. (Hit one key > and hold it for 30 seconds and you hear 3 passes.) However, LSt is only > playing the voice for 2 seconds and then quitting. It doesn't loop the > voice after 10 seconds, it just stops. Keep in mind that looping is not implemented yes. If LS is playing only for 2secs then it is playing a sample that is only. 2secs long. The wrong pitch is because LS is not honoring all the articulation parameters yet. Christian will at that soon. This will correct all errors you encountered. (wrong sample triggered, thus often it sounds out of tune or the note scale is completely screwed up). For example if you try the 100MB church organ from G-Town: http://62.13.11.115/gtown/ it sounds bad too because the note scale does not sound correctly. > > 2) The pitch of the LSt voice doesn't sound quite right. It seems too > high and brittle. Twice as high, possibly? This is most likely that > we're not picking up the intended middle C correctly I think. (C3 or C4 > - it changes from file to file I think.) This is normal for the reason stated above. Christian hurry up ! :-) > > 3) Zooming way in while in Pro Tools shows the latency of LSt to be > slower than GSt. It doesn't look horrible, and I didn't try to measure > the difference as I don't have much time right now. We can focus on that > later. Hmm this is interesting. How do you measure the latency ? Can you record both the time a midi event gets in and put that on the same time scale as the audio in PT ? 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 set up a quick Pro Tools session and recorded them both at the same > time from the same key hit. The 24-bit zipped file with both sounds > separate is about 2MB. That is probably too large for me to send to the > reflector. Shall I send you a copy directly? I'm attaching the shorter, > 16-bit version here, but at 350K your reflector may bounce it. Do you > have an ftp site somewhere where I could drop audio like this? Maybe > even in CVS somewhere? I could open you an account on the LS. But I'd like to wait for Christian's comments if it is too early for such tests. (because he must add articulation otherwise all but the simple GIGs will play incorrectly). > Certainly. I didn't take it the least bit personally. Please don't take > offense in the future when 100's of people coming from years of GSt > background ask the same questions. Take some time and write a position > statement on it today, put it on the web site and let's just point > people towards it. The only thing I can promise you is that I'm not > going to be the last to ask it!! ;-) You are completely right. As long as users are doing us an excellent service like you are doing they are allowed to pose this question :-) PS: your message with attachment probably did not make it through the mailing list (I'll forward the file to Christian). In future please keep the test files on your box and we will agree off-list where to put them. PS: the current version of LS simply sums up voices and divides the result by 4: in audiothread.cpp: sample_point = this->pAudioSumBuffer[u] / 4; // FIXME division by 4 just for testing purposes (to give a bit of head room when mixing multiple voices together) this means your headroom is about 12db (1/4) so don't be surprised if you hear clipping when lots of voices are playing. We will make this configurable or some good soul will add a limiter/compressor. But I think the best solution would (when jackd support will be in) to simply output the audio in 32bit float and then run it through external compressor/limiter/amp plugins. cheers, Benno http://www.linuxsampler.org ------------------------------------------------- This mail sent through http://www.gardena.net |
|
From: Mark K. <mar...@co...> - 2003-10-29 03:45:03
|
On Tue, 2003-10-28 at 16:52, be...@ga... wrote: > > 1) The first issue is that the Mellotron voice I'm playing is 10 seconds > > long on GSt, at which point I hear it loop and start over. (Hit one key > > and hold it for 30 seconds and you hear 3 passes.) However, LSt is only > > playing the voice for 2 seconds and then quitting. It doesn't loop the > > voice after 10 seconds, it just stops. > > Keep in mind that looping is not implemented yes. Yep, this turned out to be an aspect of that specific library. I loaded up some really long gig files from a library called 'Drone Archeology'. They can run over a minute long and they played correctly in LS. 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. > If LS is playing only for 2secs then it is playing a sample that is only. > 2secs long. The wrong pitch is because LS is not honoring all the articulation > parameters yet. Christian will at that soon. Great. > > > > 3) Zooming way in while in Pro Tools shows the latency of LSt to be > > slower than GSt. It doesn't look horrible, and I didn't try to measure > > the difference as I don't have much time right now. We can focus on that > > later. > > Hmm this is interesting. How do you measure the latency ? > Can you record both the time a midi event gets in and put that on the > same time scale as the audio in PT ? > > 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. 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. 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. 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. 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. 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. 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. I want to work on this as it will start to demonstrate LS's ability to work with multi-velocity libraries. 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! Cheers, Mark |
|
From: <be...@ga...> - 2003-10-29 10:25:44
|
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 |
|
From: Robert J. <rob...@da...> - 2003-10-28 17:37:29
|
tisdagen den 28 oktober 2003 18.11 skrev Mark Knecht: > Yes, works better as root: ahh, ofcourse! That was my problem also, no mlockall or sched messages. Actually worked quite well without it, probably due to the relatively little load I managed to provoke. /Robert > > root@Wizard linuxsampler # ./linuxsampler --numfragments 2 > --fragmentsize 256 --gig ../Gigs/Mellotron\ 8Voice.gig > Initializing audio output...OK > Loading gig file...OK > Caching initial samples...OK > Starting disk thread...OK > Starting MIDI in thread...OK > Disk thread running > Starting audio thread...OK > LinuxSampler initialization completed. > Audio thread running > > On Tue, 2003-10-28 at 09:09, Mark Knecht wrote: > > On Tue, 2003-10-28 at 07:58, be...@ga... wrote: > > > you are correct, the hammerfall can deal only with > > > number of fragments (period size) of 2. > > > you can specify them on the commandline: > > > --numfragments 2 > > > and set the frames per audio buffer too: > > > --fragmentsize 256 (means each audio fragment uses 256 frames). > > > > > > can you try again with the --numfragments 2 and see if it works ? > > > > Benno, > > Again a step closer. Probably LSt working (I'm ssh'ed in, so I cannot > > actually listen right now) but still some messages I'd rather not see: > > > > mark@Wizard linuxsampler $ ./linuxsampler --numfragments 2 > > --fragmentsize 256 -- > > gig ../Gigs/Mellotron\ 8Voice.gig > > Initializing audio output...OK > > Loading gig file...OK > > Caching initial samples...OK > > Starting disk thread...OK > > Starting MIDI in thread...WARNING, can't mlockall() memory!: Operation > > not permitted > > Disk thread running > > OK > > WARNING, can't mlockall() memory!: Operation not permitted > > sched_setscheduler: Operation not permitted > > Starting audio thread...OK > > LinuxSampler initialization completed. > > WARNING, can't mlockall() memory!: Operation not permitted > > sched_setscheduler: Operation not permitted > > Audio thread running > > > > > > LinuxSampler stopped due to SIGINT > > Segmentation fault > > mark@Wizard linuxsampler $ > > > > > > This is on the standard Gentoo kernel. Possibly it doesn't have some > > sort of kernel option or patch compiled in? Let me know what you think. > > > > Do I need to run as root? > > > > I will do some audio testing tonight. > > > > Good work! > > > > Mark > > ------------------------------------------------------- > This SF.net email is sponsored by: SF.net Giveback Program. > Does SourceForge.net help you be more productive? Does it > help you create better code? SHARE THE LOVE, and help us help > YOU! Click Here: http://sourceforge.net/donate/ > _______________________________________________ > Linuxsampler-devel mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel |
|
From: Robert J. <rob...@da...> - 2003-10-28 13:58:57
|
Yeah, benno mentioned that it only works for cards capable of 16-bit data... yet. /Robert Tuesday 28 October 2003 14.41 skrev Mark Knecht: > On Tue, 2003-10-28 at 05:07, Robert Jonsson wrote: > > Hi Mark, > > > > it sounds as if you got the version from sourceforge.net (as I did) > > > > the real version is at: > > > > cvs -z3 > > -d:pserver:ano...@cv...:/home/schropp/linuxsampler co > > linuxsampler > > > > just typeing make after it downloaded worked for me. > > > > /Robert > > Robert, > Thanks. That downloaded and built fine, but it's not running: > > > bash-2.05b$ cd LSt/linuxsampler/ > > bash-2.05b$ ./linuxsampler --gig ../Gigs/Mellotron\ 8Voice.gig > Initializing audio output...Error snd_pcm_hw_params_set_access: Invalid > argument. > bash-2.05b$ > > This machine is using the infamous HDSP 9652. I can try it on my GSt > machine later this afternoon. That machine uses a Hammerfall Light and > has lots of gig files. > > - Mark > > > > ------------------------------------------------------- > This SF.net email is sponsored by: The SF.net Donation Program. > Do you like what SourceForge.net is doing for the Open > Source Community? Make a contribution, and help us add new > features and functionality. Click here: http://sourceforge.net/donate/ > _______________________________________________ > Linuxsampler-devel mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel |
|
From: Mark K. <mar...@co...> - 2003-10-28 14:49:43
|
On Tue, 2003-10-28 at 05:49, Robert Jonsson wrote: > Yeah, benno mentioned that it only works for cards capable of 16-bit data... > yet. > > /Robert > Benno, Is that true? If so, then can I use my on-board Via sound chip somehow to run this? I could hook its analog output into an A/D and get it back into my routing matrix if you think it will work. If so, how would I tell LSt to use the second sound card? I don't see any options at the command line when I add a --help modifier. Do you support anything like -hw:1? Let me know. Mark |
|
From: Mark K. <mar...@co...> - 2003-10-28 18:00:19
|
On Tue, 2003-10-28 at 09:31, be...@ga... wrote: > excellent ! > the mlock and sched_setscheduler warnings are becaue a regular user > cannot call these functions. > It might occur you get mlock errors as root too, but this means > that the preloaded RAM size (preloadsize * number of samples in a GIG file) > exceeds the available physical memory. > See my response to Robert. > Sorry that I haven't gone back through the archives yet, but educate me. Is this revision streaming from disk? I understand the architecture where the first portion of the loaded gig files are in memory and then GSt has to do a seek and start getting the rest of all notes being played. Is this what you are doing in this revision? And what's the current legal state of the 'stream from disk' patent? Has anyone determined if this is a problem for this tool? I typically load 16 libraries in GSt as a starting point. (Good Sounds.gsp) They encompass about 6GB of disk space - obviously too much for memory... (And I do understand that you are only handling a single gig file and not a performance file at this time.) Thanks, Mark |
|
From: <be...@ga...> - 2003-10-28 19:36:39
|
Scrive Mark Knecht <mar...@co...>: > On Tue, 2003-10-28 at 09:31, be...@ga... wrote: > > > excellent ! > > the mlock and sched_setscheduler warnings are becaue a regular user > > cannot call these functions. > > It might occur you get mlock errors as root too, but this means > > that the preloaded RAM size (preloadsize * number of samples in a GIG > file) > > exceeds the available physical memory. > > See my response to Robert. > > > > Sorry that I haven't gone back through the archives yet, but educate me. > Is this revision streaming from disk? I understand the architecture > where the first portion of the loaded gig files are in memory and then > GSt has to do a seek and start getting the rest of all notes being > played. > > Is this what you are doing in this revision? Yes any disk based sample must use that method (Kontakt, Halion etc) because the disk is too slow to provide low latency sample triggering. > > And what's the current legal state of the 'stream from disk' patent? Has > anyone determined if this is a problem for this tool? In 1991-1992 I worked for a small italian multimedia company Digimail S.r.l that wrote games and CDROM multimedia for the Amiga and CD32 (A set top box based on the Amiga). They produced the italian version of the "Grolier Encyclopedia" multimedia CDROM. At that time I wrote low level routines needed for the audio part of the encyclopedia. One of them was exactly a set of routines that permitted to preload a small initial part of samples in RAM (in 8bit 8SVX format) and then when the high level encyclopedia software requested it, it could to trigger and start them them with low latency. while streaming the samples from a mass storage device (either HD or CDROM). at that time PCs were only able to produce annoying BEEEEPs :-) precaching initial parts in RAM is basically done by any kind of application that streams data from an external source (be it from mass storage, network etc). This is "technology" is as old as the mass storage device. So then people talk about the RAM caching patent I'm amazed that people take it seriously and have concerns if linuxsampler uses ram caching. Should I sue the world because I have prior art in that field ? (the whole streaming routines were only a couple of dozen lines of MC68000 assembly). You know pure software patents are illegal in EU anyway and most of our developers (me, Christian, Steve H.) are living there so we are not doing anything unlawful here. (plus keep in mind I have prior art so even if I resided in the US I would be 100% ok). The disk streaming part was entirely developed by me (see old evo sampler versions about 3 years ago), I take the full resposibilities for that, so other developers do not need to fear anything related to this topic. If you feel you are breaking a patent just don't use linuxsampler or if you want we firewall the server in a way that only EU people can download the code. Do you want this ? (of course the previous sencence was meant to put between <SARCASM></SARCASM> tags :-) ) Plus try to think logically: if this patent was really non bogus then why were not Steinberg (Halion) and NI (Kontakt) sued out of the market. NI appeared very late on the audio scene but seems that most of disk based sampling users are switching to Kontakt. A potential killer for Giga. (think about LS .... a bunch of poor open source developers, no money to extract) BTW: did you know Invision patented the playback of samples from RAM on a PC ? This would probably make all softsynths/samplers in existence (probably hundreds) illegal. OTOH there is certainly lots of prior art here too and this is why Invision did not go against competitors ? Seriously, I don't care. I think the US is risking to be leaved behind the rest of the world in terms of IT because the current bogus US software patent system is killing innovation. Can we get back to linuxsampler technicals ? > I typically load > 16 libraries in GSt as a starting point. (Good Sounds.gsp) They > encompass about 6GB of disk space - obviously too much for memory... > > (And I do understand that you are only handling a single gig file and > not a performance file at this time.) We will use our own performance file format (perhaps XML). LS is not a GSt copy it only loads GIG files just like many other softsamplers. PS: Mark do not take my rant personally it is just that I hear the same questions popping up again and again and I'm amazed that people do not realize how weak a patent about "loading a piece of file in RAM" is. I'd be curious where the world would be if Euler, Newton, Leibnitz etc all patented their stuff :-) cheers, Benno ------------------------------------------------- This mail sent through http://www.gardena.net |
|
From: Mark K. <mar...@co...> - 2003-10-28 20:09:07
|
On Tue, 2003-10-28 at 11:32, be...@ga... wrote: > > > > And what's the current legal state of the 'stream from disk' patent? Has > > anyone determined if this is a problem for this tool? > > > In 1991-1992 I worked for a small italian multimedia company > Digimail S.r.l ... <SNIP> > ...I resided in the US I would be 100% ok). <hehe!!> Sore spot, 'eh?! ;-) (Just joking! I get it's important AND that it's a pain...) > The disk streaming part was entirely developed by me (see old evo sampler > versions about 3 years ago), I take the full resposibilities for that, > so other developers do not need to fear anything related to this topic. Great. > > If you feel you are breaking a patent just don't use linuxsampler or if you > want we firewall the server in a way that only EU people can download the code. > Do you want this ? > (of course the previous sencence was meant to put between <SARCASM></SARCASM> > tags :-) ) Benno, This is completely a non-issue for me. It was nothing other than a question. I have no personal position on patents, other than I hate writing them. I hold some number (4, 5?) of U.S. patent, all hardware related. They are just something I do for the companies I work for as a condition of employment. Left to my own devices I'm far too lazy to bother! ;-) > > Plus try to think logically: if this patent was really non bogus then > why were not Steinberg (Halion) and NI (Kontakt) sued out of the market. > NI appeared very late on the audio scene but seems that most of > disk based sampling users are switching to Kontakt. My understanding was that Kontakt still does not really stream from disk, but I may be wrong about this. That was from Northern Sounds recently, but it's just talk, not a legal statement by anyone who knows. > Can we get back to linuxsampler technicals ? :-) YES!! :-) > We will use our own performance file format (perhaps XML). > LS is not a GSt copy it only loads GIG files just like many other > softsamplers. Perfectly OK. gsp files are easy to build and are completely dependent on the Sampler. > > PS: Mark do not take my rant personally it is just that I hear the same > questions popping up again and again and I'm amazed that people do not > realize how weak a patent about "loading a piece of file in RAM" is. Certainly. I didn't take it the least bit personally. Please don't take offense in the future when 100's of people coming from years of GSt background ask the same questions. Take some time and write a position statement on it today, put it on the web site and let's just point people towards it. The only thing I can promise you is that I'm not going to be the last to ask it!! ;-) |
|
From: Robert J. <rob...@da...> - 2003-10-29 11:14:25
|
Hi, > > Can we get back to linuxsampler technicals ? > I'm happy that you (as I) live in Europe where software patents are illegal. Though this will probably change...which is quite a failure. I'm also happy that you have solid prior art for the sample loading technique. But I think also think (as Mark mentioned) that you will just have to get used to people asking about how LS is affected by the patent. By now it's common knowledge that there exist patents in this area, so I would be surprised if people didn't ask. Putting a FAQ on the site with some info might help. As to the merits of the patent in question, I too agree that the patent is absurd and should never have been granted...but this happens all the time I'm afraid... About the enforcability of the patent... I've heard numerous stories about the way the system works (both here in EU and in the US) and the truth is that it doesn't really matter whether you are right, unless you have _lots_ of cash to back up your claim. Luckily we have the FSF that are willing to help in this situation, hopefully that would be enough. --- Just look at the recent circus of SCO vs the World for a glimpse at how incredibly F***ed the world of lawyers and suits is. There was a recent thread on music-dsp about patents in the audio arena that was very interesting. --- Okay, enough ranting... Keep up the coding, lets not worry about things that are beyond the comprehension of the average man :) /Robert |
Thanks for helping keep SourceForge clean.
X