linuxsampler-devel

[Linuxsampler-devel] audio channels

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

Ok, regarding audio channels my idea is the following (remember some engines 
only know the amount of audio channels they need, when they have loaded an 
instrument): again, when you start LS there's nothing. You have to create a 
virtual audio output device (Alsa, Jack, CoreAudio, VSTi,...). You can also 
create more than one audio output device of course (means even an device for 
Alsa, one for Jack, one for VSTi,...).
You add a sampler channel, load an engine (Gig or DLS or Akai or ....) for 
that sampler channel, connect a (created) audio output device to that sampler 
channel and load an instrument. Now that the engine knows how much audio 
channels it needs, it sends a message to the connected audio output device to 
inform it how much audio channels the engine needs. It's the responsibilty of 
this virtual audio output device to create those output channels. For Jack 
this is easy: the Jack audio output device just increases or decreases the 
amount of Jack ports, but in case of Alsa for example it cannot just simply 
create new physical output ports, but it creates mix channels for the engine 
instead. So assuming the engine needs 4 channels (Alsa offers only 2), the 
Alsa audio output device will then create channel 3 and 4 which are actually 
only a copy of channel 1 and 2,  means the engines's output on channel 3 and 
4 will simply be mixed to the Alsa device's output channel 1 and 2.

Every audio output channel of audio output devices will have descriptions or 
something, so you can see in the frontend, if these channels are only mix 
channels or real channels. This means also the frontend must be capable to 
manage those audio output devices, create, destroy devices or for example in 
case of Alsa it would be nice when you can add further _real_ audio output 
channels, so you can really use more than 2 channels and they're not simply 
mixed to channel 1 and 2.

Of course we would have to extend LSCP for managing audio output devices.

Oh, and btw I will change the internal sample type (which is currently 
int16_t) to float. This is necessary for various DSP algorithms in future.

Comments? Doubts? Suggestions?

CU
Christian

Re: [Linuxsampler-devel] audio channels

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

Es geschah am Samstag, 10. April 2004 12:35 als Christian Schoenebeck schrieb:
> creates mix channels for the engine instead. So assuming the engine needs 4
> channels (Alsa offers only 2), the Alsa audio output device will then

Oh, and to avoid to get mail bombed by you: of course Alsa supports more than 
two channels (dependent on the actual hardware), this was just meant as a 
scenario. Excuse my inaccuracy!

CU
Christian

[Linuxsampler-devel] LS future, multiengine , audio channels

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

Hi,
what Christian said makes sense (both the multi engine stuff, audio channel
allocation etc).

The important thing is that the 
LS server provides all these functions to the client via LSCP
plus file management, eg the LS server export a dir (and all its subdirs)
and the client can browse and load samples from it using LSCP.
Only with that feature you can provide true remote client/server
operation.

Regarding the thoughts that Mark expressed.
I agree with him, we need to hide the complexity of LS behind
an easy to use GUI.
Assume we provide only GIG playback for now:
For the beginning a GUI like I proposed (load & play, sent the sources
to Rui sometime ago) is probably the best.
You see 16 midi channels and can assign a GIG sample to each channel.
You can tweak some parameters like volume,pan,reverb,chorus
(but LS should respond to midi CC too and the GUI should autoupdate 
the values/sliders via LSCP).

This makes LS easy to use.
About the audio routing: I agree with Mark some internal routing is
needed and for now jack port export for every sampler midi channel requiring
the user to do the routing by himself is simply too complex and probably
not that efficient.
(ok in a later release we can add it since there will be people wanting
to play a full performance but only record certain channels into ardour etc).

So what I propose is the following (to resemble a standard MIDI sampler
 or soundmodule):
all the voices of a sample on the same MIDI channel get downmixed
on a stereo bus which allows the following parameters:
volume, panorama, reverb, chorus 
For the reverb and chorus only a single instance of the FXes is needed since
we will have reverb and chorus send level for each midi channel.
For reberb and chorus I propose LADSPA which makes it easy to change
the type of FX , add more etc.
As default I'd load freeverb (or gverb?) for the Reverb and swh-chorus
for the chorus. (swh, something that does not tax the CPU too much but 
sounds good, what was that plugin again ? 4 voice chorus?).

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



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

Re: [Linuxsampler-devel] LS future, multiengine , audio channels

[Vladimir S. <ha...@so...>]

Hi,

One may agrue that in some configurations sample files will be loaded on the
same workstation where GUI is running, not on the dedicated sampler machine.
Sampler machine may not even have any means (CD, DVD, etc) to load files on
it's internal harddrive.
So, this may mean that LS should not just provide directory listing but in
fact a lot more functions making it yet another file server. All kinds of
issues will come up . . . security, efficiency, etc . . . People have spent
years writing file servers.
At this point one might argue that file management is above and beyond what
sampler should do.
I'm beginning to suspect that it might be easier to work with existing file
serverving methods. Meaning it's client responsibility to do his own
directory listing. If client (GUI) happens to be running on the same PC then
great, no problems. If it is running on a nother PC let's make them mount
the directory where sample files should go. Whatever method they choose
(samba, nfs, etc) is not up to us. Then we don't have to manage their
permissions. If several GUIs from several users from several workstations
are using one (or moce) LS, they'll not have to argue about who has
permissions to read/write/modify who's sample files. It will all be file
server's responsibility.

I am however not so sure about audio output "stuff".
I know that users on the GUI side would like to have a drop down list with
available audio to work with instead of having to type something like "alsa
card 123 channel 1". So, should LS provide a list of all possible outputs?
How will it handle stuff that changes underneath is (like jack's outputs
appearing and disappearing). I'm thinking GUI probably sends a request to
list current "stuff" and then if it feels like doing a refresh it does it
again. It may feel like it if certain errors happen or if user clicks a
button . . .

Regards,
Vladimir.

----- Original Message -----
From: <be...@ga...>
To: <lin...@li...>
Sent: Saturday, April 10, 2004 11:12 AM
Subject: [Linuxsampler-devel] LS future, multiengine , audio channels


> Hi,
> what Christian said makes sense (both the multi engine stuff, audio
channel
> allocation etc).
>
> The important thing is that the
> LS server provides all these functions to the client via LSCP
> plus file management, eg the LS server export a dir (and all its subdirs)
> and the client can browse and load samples from it using LSCP.
> Only with that feature you can provide true remote client/server
> operation.
>
> Regarding the thoughts that Mark expressed.
> I agree with him, we need to hide the complexity of LS behind
> an easy to use GUI.
> Assume we provide only GIG playback for now:
> For the beginning a GUI like I proposed (load & play, sent the sources
> to Rui sometime ago) is probably the best.
> You see 16 midi channels and can assign a GIG sample to each channel.
> You can tweak some parameters like volume,pan,reverb,chorus
> (but LS should respond to midi CC too and the GUI should autoupdate
> the values/sliders via LSCP).
>
> This makes LS easy to use.
> About the audio routing: I agree with Mark some internal routing is
> needed and for now jack port export for every sampler midi channel
requiring
> the user to do the routing by himself is simply too complex and probably
> not that efficient.
> (ok in a later release we can add it since there will be people wanting
> to play a full performance but only record certain channels into ardour
etc).
>
> So what I propose is the following (to resemble a standard MIDI sampler
>  or soundmodule):
> all the voices of a sample on the same MIDI channel get downmixed
> on a stereo bus which allows the following parameters:
> volume, panorama, reverb, chorus
> For the reverb and chorus only a single instance of the FXes is needed
since
> we will have reverb and chorus send level for each midi channel.
> For reberb and chorus I propose LADSPA which makes it easy to change
> the type of FX , add more etc.
> As default I'd load freeverb (or gverb?) for the Reverb and swh-chorus
> for the chorus. (swh, something that does not tax the CPU too much but
> sounds good, what was that plugin again ? 4 voice chorus?).
>
> cheers,
> Benno
> http://www.linuxsampler.org
>
>
>
> -------------------------------------------------
> This mail sent through http://www.gardena.net
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> Linuxsampler-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel
>

Re: [Linuxsampler-devel] LS future, multiengine , audio channels

[Mark K. <mar...@co...>]

On Sat, 2004-04-10 at 08:12, be...@ga... wrote:
<SNIP>
> You see 16 midi channels and can assign a GIG sample to each channel.
<SNIP>
> This makes LS easy to use.
> About the audio routing: I agree with Mark some internal routing is
> needed and for now jack port export for every sampler midi channel requiring
> the user to do the routing by himself is simply too complex and probably
> not that efficient.
> (ok in a later release we can add it since there will be people wanting
> to play a full performance but only record certain channels into ardour etc).
> 
<SNIP>

Benno and (by reference to another email) Vladimir,
   Thanks for the comments. I guess we agree in many ways. I'll point
out that I clearly understand that my comments are based pretty heavily
on using GSt for a few years now, and I come from both it's limitations
and its strengths. That said, I'll make a couple of points that I didn't
make before, but I think are topical about the comments above. The point
here is that if you have 16 gigs loaded, you'll need an audio mixer of
some type as most people won't have enough hardware to get all of that
audio to the hard disk recorder as separate channels.

1) I do not believe that the *full* realization of LS's capabilities, if
even limited to only 16 gigs, will ever be realized running LS on the
same machine as Ardour (or any other hard disk recording program) for
any standard hardware configuration. The use of the hard disk is too
different between Ardour doing essentially linear access and LS doing
random access. Add in conflicts on the PCI bus, etc., and I think LS
must be on it's own machine to really do 16 gigs and greater than 100
note polyphony. After all, 100 notes is only 6-7 notes per gig when
using 16 gigs. (Keep in mind that even GSt 2.5 handles up to 64 gigs
loaded at the same time.)

2) If we have a sampler that holds 16 gigs, and gigs are by default
stereo, then we are taking 32 individual audio channels. If LS is on a
separate machine, then we are talking about 4 ADAT cables to wire the
machines together if you wanted to record all of this audio in one pass.
That's a lot of money to do something that you can do effectively in
multiple passes later. What I do with GSt is to mix 16 or more gigs
together into (generally) 4 stereo pairs (percussion, strings, synths,
other) and run them into Pro Tools while I compose. I don't need all 32
audio channels separate while I write. When I'm done I then record up to
4 instruments at a time keeping all the audio as separate as I need to.
Sometimes I'll mix a bunch of strings together into a stereo group and
save tracks in Pro Tools.

   Hope this helps make a bit of sense out of my views.

Thanks,
Mark
   

Re: [Linuxsampler-devel] LS future, multiengine , audio channels

[Vladimir S. <ha...@so...>]

Mark,

While i agree that writing audio to the same drive as the gigs reside on 
is not a very good idea this does not mean that the only way out is 
several machines . . .
Sending data to the other machine is work too, and may even be more work 
. . . For example writing data to the sound or ethernet card may well be 
a lot more work comparing to writing the same data to the harddrive 
(depending on how good your hardware and drivers are. For instance if 
you have a hardware raid on 64bit wide PCI running at 133Mhz with 
several good SCSI drives hooked up to it in raid0 configuration we'll 
probably find that writing to that is a lot faster with a lot less 
overhead than any soundcard i know of).

Take a look at some good server motherboards. They have several PCI 
busses running at different speeds and width and you could have 
harddrive(s) on one disk/adapter/bus for random access and another (and 
perhaps even another CPU with audio output thread attached to it?! or 
maybe even irq affinity attaching certain irqs to certain CPUs).
In other words, there are multiple possibilities when it comes to 
performance, optimizations, etc. And sending data to another machine is 
not always the best solution.
When it really comes to optimizations, there are lots of things we will 
need to do and lots of tools to use. Profilers and analyzers of 
different types, etc, etc.
I've used Intel's SHG2 board in one project and it has been pretty good 
experience overall.
When it comes to PCI there are some pretty good PCI analyzers out there 
as well :)

Regards,
Vladimir.

Mark Knecht wrote:

>On Sat, 2004-04-10 at 08:12, be...@ga... wrote:
><SNIP>
>  
>
>>You see 16 midi channels and can assign a GIG sample to each channel.
>>    
>>
><SNIP>
>  
>
>>This makes LS easy to use.
>>About the audio routing: I agree with Mark some internal routing is
>>needed and for now jack port export for every sampler midi channel requiring
>>the user to do the routing by himself is simply too complex and probably
>>not that efficient.
>>(ok in a later release we can add it since there will be people wanting
>>to play a full performance but only record certain channels into ardour etc).
>>
>>    
>>
><SNIP>
>
>Benno and (by reference to another email) Vladimir,
>   Thanks for the comments. I guess we agree in many ways. I'll point
>out that I clearly understand that my comments are based pretty heavily
>on using GSt for a few years now, and I come from both it's limitations
>and its strengths. That said, I'll make a couple of points that I didn't
>make before, but I think are topical about the comments above. The point
>here is that if you have 16 gigs loaded, you'll need an audio mixer of
>some type as most people won't have enough hardware to get all of that
>audio to the hard disk recorder as separate channels.
>
>1) I do not believe that the *full* realization of LS's capabilities, if
>even limited to only 16 gigs, will ever be realized running LS on the
>same machine as Ardour (or any other hard disk recording program) for
>any standard hardware configuration. The use of the hard disk is too
>different between Ardour doing essentially linear access and LS doing
>random access. Add in conflicts on the PCI bus, etc., and I think LS
>must be on it's own machine to really do 16 gigs and greater than 100
>note polyphony. After all, 100 notes is only 6-7 notes per gig when
>using 16 gigs. (Keep in mind that even GSt 2.5 handles up to 64 gigs
>loaded at the same time.)
>
>2) If we have a sampler that holds 16 gigs, and gigs are by default
>stereo, then we are taking 32 individual audio channels. If LS is on a
>separate machine, then we are talking about 4 ADAT cables to wire the
>machines together if you wanted to record all of this audio in one pass.
>That's a lot of money to do something that you can do effectively in
>multiple passes later. What I do with GSt is to mix 16 or more gigs
>together into (generally) 4 stereo pairs (percussion, strings, synths,
>other) and run them into Pro Tools while I compose. I don't need all 32
>audio channels separate while I write. When I'm done I then record up to
>4 instruments at a time keeping all the audio as separate as I need to.
>Sometimes I'll mix a bunch of strings together into a stereo group and
>save tracks in Pro Tools.
>
>   Hope this helps make a bit of sense out of my views.
>
>Thanks,
>Mark
>   
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by: IBM Linux Tutorials
>Free Linux tutorial presented by Daniel Robbins, President and CEO of
>GenToo technologies. Learn everything from fundamentals to system
>administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
>_______________________________________________
>Linuxsampler-devel mailing list
>Lin...@li...
>https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel
>  
>

Re: [Linuxsampler-devel] LS future, multiengine , audio channels

[Mark K. <mar...@co...>]

On Sun, 2004-04-11 at 10:49, Vladimir Senkov wrote:
> Mark,
> 
> <SNIP>

> For instance if 
> you have a hardware raid on 64bit wide PCI running at 133Mhz with 
> several good SCSI drives 
<SNIP>
> 
> Regards,
> Vladimir.
> 
> Mark Knecht wrote:
> 
<SNIP>
> you'll need an audio mixer of
> >some type as most people won't have enough hardware to get all of that
> >audio to the hard disk recorder as separate channels.
<SNIP>

You can certainly buy hardware to meet whatever set of criteria you want
to shoot for.

My point was that most people won't have that available, nor do they
want to. I'll state straight out that I won't be using a Linux-based DAW
for the foreseeable future. I'm far more likely to dump $50K into a Pro
Tools HD-Accel system than attempt to run a Linux recorder and a sampler
on the same box. For this reason, since Pro Tools and LS by definition
do not even run on the same OS, to me the point is moot.

Really the question is whether you want the mixer in the app, or require
people to hook up 32 audio outputs using Jack and then do it all by hand
somehow. I think that's not a good use of my time, and I think that
almost no GSt user coming from Windows to try this out would think so
either, but I'm not arguing that LS should be some hard coded monster
GUI that wouldn't support that model. If others want it that way I hope
the code base supports it.

Anyway, I was fairly careful in my original response to use terms like
'How LS presents itself'. It's not of much interest to me as a user
what's under the hood. If it's easy to use, stable and does what I need,
then I'll us it. If not, then it's unlikely that I or many other Windows
users would invest huge amounts of time.

Looking for eggs in the back yard,
Mark

Re: [Linuxsampler-devel] LS future, multiengine , audio channels

[Vladimir S. <ha...@so...>]

Mark,

I'm not suggesting that everything MUST be done on the same PC all the 
time :)
Although i'd like to think that eventually linux will have enough apps 
so you could do it (by just adding another harddrive for "output").
So, the point is . . . it's a functional problem, not performance. I 
fully agree with your "functional" part of the argumentation but on 
performance i'm not so sure.

I personally would like to see LS as modular as possible and as easy to 
use with other tools as possible.
I was hoping that mixing could be put outside the sampler itself and 
something like jack could be used to interface into that. But maybe this 
is not efficient enough and there needs to be more "mixing points". I 
simply don't know.

BTW, if LS supported audio over Ethernet would that help (in terms of 
reducing the number of cables and interfaces)?

Careful with those eggs . . .
I've just seen on TV some kids were looking for eggs and found two 
loaded guns instead :)

Regards,
Vladimir.

Mark Knecht wrote:

>On Sun, 2004-04-11 at 10:49, Vladimir Senkov wrote:
>  
>
>>Mark,
>>
>><SNIP>
>>    
>>
>
>  
>
>>For instance if 
>>you have a hardware raid on 64bit wide PCI running at 133Mhz with 
>>several good SCSI drives 
>>    
>>
><SNIP>
>  
>
>>Regards,
>>Vladimir.
>>
>>Mark Knecht wrote:
>>
>>    
>>
><SNIP>
>  
>
>>you'll need an audio mixer of
>>    
>>
>>>some type as most people won't have enough hardware to get all of that
>>>audio to the hard disk recorder as separate channels.
>>>      
>>>
><SNIP>
>
>You can certainly buy hardware to meet whatever set of criteria you want
>to shoot for.
>
>My point was that most people won't have that available, nor do they
>want to. I'll state straight out that I won't be using a Linux-based DAW
>for the foreseeable future. I'm far more likely to dump $50K into a Pro
>Tools HD-Accel system than attempt to run a Linux recorder and a sampler
>on the same box. For this reason, since Pro Tools and LS by definition
>do not even run on the same OS, to me the point is moot.
>
>Really the question is whether you want the mixer in the app, or require
>people to hook up 32 audio outputs using Jack and then do it all by hand
>somehow. I think that's not a good use of my time, and I think that
>almost no GSt user coming from Windows to try this out would think so
>either, but I'm not arguing that LS should be some hard coded monster
>GUI that wouldn't support that model. If others want it that way I hope
>the code base supports it.
>
>Anyway, I was fairly careful in my original response to use terms like
>'How LS presents itself'. It's not of much interest to me as a user
>what's under the hood. If it's easy to use, stable and does what I need,
>then I'll us it. If not, then it's unlikely that I or many other Windows
>users would invest huge amounts of time.
>
>Looking for eggs in the back yard,
>Mark
>
>  
>