Re: [linux-audio-dev] Linux Audio Hardware Selection
> > >(btw, why jackd doesn't read /etc/jackrc or ~/.jackrc ?) > > > On Fri, Jan 24, 2003 at 11:27:12 -0500, Paul Davis wrote: > > because that means we have a config file, which means we need a config > > file parser, which means we need to replicate a bunch of code or link > > against another library. if jackd was a commonly executed command for > > users, i could justify that. as it is, i can't. Steve Harris <[EMAIL PROTECTED]> writes: > What about having a simple config file that is just a set of default > options, eg. /root/.jackrc: > -R -d alsa -d Hammerfall -r 44100 -p 256 > > Then this can be chopped up and prepended to argv[] before being thrown at > the argv parser. > > It doesn't work as well as it might because of the -d thing (so you cant > override the driver easily), but you can still override the rate, number > of periods etc. Why not just distribute an /etc/init.d/jackd script? It would be useful, and such a script can easily read config files with no extra library dependencies in JACK. -- Jack O'Quin Austin, Texas, USA BTW, like everyone else, I like Takashi and Paul's idea of running the JACK engine in-process if libjack finds that no daemon is running.
Re: [linux-audio-dev] Linux Audio Hardware Selection
On Friday 24 January 2003 19.29, Paul Winkler wrote: > On Fri, Jan 24, 2003 at 11:27:12AM -0500, Paul Davis wrote: > > i've had the same idea. my approach would basically be to have > > libjack try to contact the server. if it fails, then it just > > starts up a thread to run the audio loop, and then instantiate > > the client as an in-process client. > > i must be missing the point. Where does the audio go? isn't jackd > responsible for connecting to alsa? Well, yes - but if the lib fails to find jackd, it can do pretty much anything, instead of just failing. Like trying try to set up some direct audio I/O instead and "fake" jackd. :-) //David Olofson - Programmer, Composer, Open Source Advocate .- 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 -' --- http://olofson.net --- http://www.reologica.se ---
Re: [linux-audio-dev] Linux Audio Hardware Selection
On Fri, Jan 24, 2003 at 11:27:12AM -0500, Paul Davis wrote: > i've had the same idea. my approach would basically be to have libjack > try to contact the server. if it fails, then it just starts up a > thread to run the audio loop, and then instantiate the client as an > in-process client. i must be missing the point. Where does the audio go? isn't jackd responsible for connecting to alsa? -- Paul Winkler http://www.slinkp.com Look! Up in the sky! It's X-PERVERT WHO LIVES NEXT DOOR! (random hero from isometric.spaceninja.com)
Re: [linux-audio-dev] Linux Audio Hardware Selection
> >(btw, why jackd doesn't read /etc/jackrc or ~/.jackrc ?) > > because that means we have a config file, which means we need a config > file parser, which means we need to replicate a bunch of code or link > against another library. if jackd was a commonly executed command for > users, i could justify that. as it is, i can't. I would support adding another library. I think both system and user configuration files add a lot to the usability department. BTW, the standalone non-jackd libjack sounds like a very good idea! -- Fernando
Re: [linux-audio-dev] Linux Audio Hardware Selection
On Fri, Jan 24, 2003 at 11:27:12 -0500, Paul Davis wrote: > not at all. it would allow programs to be run with no context switch > overhead if they are started alone without jackd, which would be > rather nice. we need to get in-process clients done first, though. Agreed and agreed. > >(btw, why jackd doesn't read /etc/jackrc or ~/.jackrc ?) > > because that means we have a config file, which means we need a config > file parser, which means we need to replicate a bunch of code or link > against another library. if jackd was a commonly executed command for > users, i could justify that. as it is, i can't. What about having a simple config file that is just a set of default options, eg. /root/.jackrc: -R -d alsa -d Hammerfall -r 44100 -p 256 Then this can be chopped up and prepended to argv[] before being thrown at the argv parser. It doesn't work as well as it might because of the -d thing (so you cant override the driver easily), but you can still override the rate, number of periods etc. - Steve
Re: [linux-audio-dev] Linux Audio Hardware Selection
On Friday 24 January 2003 18.22, Paul Davis wrote: > >> >(btw, why jackd doesn't read /etc/jackrc or ~/.jackrc ?) > >> > >> because that means we have a config file, which means we need a > >> config file parser, which means we need to replicate a bunch of > >> code or link against another library. if jackd was a commonly > >> executed command for users, i could justify that. as it is, i > >> can't. > > > >Seems like it would be useful for the "no jackd" case, though. (Or > >you'd have to force code changes upon applications anyway.) > > > >For Kobo Deluxe, I just hacked a simple integrated command line > > and config file parser. Inherit the parser class, add your > > argument > > there are plenty of decent config file parsers floating around. > the goal is to avoid JACK requiring other libraries, as much as > possible. Yeah. The point is that it's just two files you throw into your project. Not incredibly sexy, but it works for tiny things that evolve very slowly or not at all. //David Olofson - Programmer, Composer, Open Source Advocate .- 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 -' --- http://olofson.net --- http://www.reologica.se ---
Re: [linux-audio-dev] Linux Audio Hardware Selection
>> >(btw, why jackd doesn't read /etc/jackrc or ~/.jackrc ?) >> >> because that means we have a config file, which means we need a >> config file parser, which means we need to replicate a bunch of >> code or link against another library. if jackd was a commonly >> executed command for users, i could justify that. as it is, i >> can't. > >Seems like it would be useful for the "no jackd" case, though. (Or >you'd have to force code changes upon applications anyway.) > >For Kobo Deluxe, I just hacked a simple integrated command line and >config file parser. Inherit the parser class, add your argument there are plenty of decent config file parsers floating around. the goal is to avoid JACK requiring other libraries, as much as possible. --p
Re: [linux-audio-dev] Linux Audio Hardware Selection
On Friday 24 January 2003 17.27, Paul Davis wrote: [...] > >(btw, why jackd doesn't read /etc/jackrc or ~/.jackrc ?) > > because that means we have a config file, which means we need a > config file parser, which means we need to replicate a bunch of > code or link against another library. if jackd was a commonly > executed command for users, i could justify that. as it is, i > can't. Seems like it would be useful for the "no jackd" case, though. (Or you'd have to force code changes upon applications anyway.) For Kobo Deluxe, I just hacked a simple integrated command line and config file parser. Inherit the parser class, add your argument variables and implement a function that registers the variables. Then tell it to read your config file and/or hand it argc + argv. You can have default values and check whether default values were overidden, and there's support for integers, floats, switches and strings. Unfortunately, it's in C++, though the actual code is mostly C style, and shouldn't be too hard to port. (The key registering won't look as sexy, but that's no major issue.) Licence is LGPL, like most of my engine/lib sort of stuff. I don't have it as a separate package, but that can be arranged if there's interest. //David Olofson - Programmer, Composer, Open Source Advocate .- 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 -' --- http://olofson.net --- http://www.reologica.se ---
Re: [linux-audio-dev] Linux Audio Hardware Selection
>At Fri, 24 Jan 2003 08:09:44 -0500, >Paul Davis wrote: >> >> the other alternative that many of us here like rather a lot is JACK >> (http://jackit.sf.net/), which provides a different model: data >> sharing between applications, shared access to hardware, >> sample-synchronous execution of all applications, and no hardware >> parameters to be configured. it sits on top of ALSA (and potentially >> other similar hardware abstractions). > >what i've thought of is to make libjack runnable as standalone without >jack server. i know it sounds useless for serious purpose. not at all. it would allow programs to be run with no context switch overhead if they are started alone without jackd, which would be rather nice. we need to get in-process clients done first, though. imagine: your program can run in either mode - networked to other applications and sharing the audio interface, or running with high efficiency all by itself. all this with no code changes to your application! >but, at least, people can write the application using a simple API, >and have possiblity to debug in different environment. i've had the same idea. my approach would basically be to have libjack try to contact the server. if it fails, then it just starts up a thread to run the audio loop, and then instantiate the client as an in-process client. >for example, in the standalone mode, libjack will initialize the >necessary hardware setup silenty according to the config file, so that >in the application you don't need to set up the nasty things. >(btw, why jackd doesn't read /etc/jackrc or ~/.jackrc ?) because that means we have a config file, which means we need a config file parser, which means we need to replicate a bunch of code or link against another library. if jackd was a commonly executed command for users, i could justify that. as it is, i can't. --p
Re: [linux-audio-dev] Linux Audio Hardware Selection
At Fri, 24 Jan 2003 08:09:44 -0500, Paul Davis wrote: > > the other alternative that many of us here like rather a lot is JACK > (http://jackit.sf.net/), which provides a different model: data > sharing between applications, shared access to hardware, > sample-synchronous execution of all applications, and no hardware > parameters to be configured. it sits on top of ALSA (and potentially > other similar hardware abstractions). what i've thought of is to make libjack runnable as standalone without jack server. i know it sounds useless for serious purpose. but, at least, people can write the application using a simple API, and have possiblity to debug in different environment. for example, in the standalone mode, libjack will initialize the necessary hardware setup silenty according to the config file, so that in the application you don't need to set up the nasty things. (btw, why jackd doesn't read /etc/jackrc or ~/.jackrc ?) Takashi
Re: [linux-audio-dev] Linux Audio Hardware Selection
>I was looking for a good, up-to-date documentation pointer upon software featu >res provided by alsa. But I'm new to this architecture and I might be "intoxic >ated" by some kernel streaming architectures : is there a kind of hardware ab >straction with ALSA, e.g. features that are managed by the software at usr or >kernel level, in a +/-transparent way, when the HW does not provide them ? yes, its called alsa-lib. its big, its bold, and to some people its beautiful. >My understanding is that Alsa does not provide multiple device open (a second >open can be blocking, or return with an error, but won't succeed, as no sw mix >ing is available). that's correct right at this very moment in time. however, the mythical "mix" ALSA PCM "plugin" provides multi-open-without-h/w-support by streaming data to a server called "aserver". at this time, the mix plugin is not part of the ALSA source base. its far from clear that anyone is doing any work on it. >is there anything that can be emulated by alsa on user request, when the hw ca >nnot ? (for instance frequency change, frame conversion (n channels to m chan >nels) etc...). all of it. the other alternative that many of us here like rather a lot is JACK (http://jackit.sf.net/), which provides a different model: data sharing between applications, shared access to hardware, sample-synchronous execution of all applications, and no hardware parameters to be configured. it sits on top of ALSA (and potentially other similar hardware abstractions). --p
RE: [linux-audio-dev] Linux Audio Hardware Selection
Hi all, I was looking for a good, up-to-date documentation pointer upon software features provided by alsa. But I'm new to this architecture and I might be "intoxicated" by some kernel streaming architectures : is there a kind of hardware abstraction with ALSA, e.g. features that are managed by the software at usr or kernel level, in a +/-transparent way, when the HW does not provide them ? My understanding is that Alsa does not provide multiple device open (a second open can be blocking, or return with an error, but won't succeed, as no sw mixing is available). is there anything that can be emulated by alsa on user request, when the hw cannot ? (for instance frequency change, frame conversion (n channels to m channels) etc...). How would you implement such thing ? With a kind of abstraction layer daemon, that exports the same api but perform missing hw features ? Could the LADSPA plugin architecture be a solution to implement multiple device open ? tx Marc.
Re: [linux-audio-dev] Linux Audio Hardware Selection
On Thu, Jan 23, 2003 at 11:13:28AM -0600, Matt Gerassimoff wrote: > Hello, > > I've been watching the mail on this list for some time. I've looked at as > much documentation on the web as I can find. From alsa's web site to the > linux audio developers web site. What I would like to know (or see in a > FAQ or HOWTO) is how to setup a linux pro audio system. With different > levels of price/performance issues. Things like: (snip) > What do you guys suggest? I suggest taking it to [EMAIL PROTECTED] :) -- Paul Winkler http://www.slinkp.com Look! Up in the sky! It's VEGETARIAN ATTENDANT! (random hero from isometric.spaceninja.com)
[linux-audio-dev] Linux Audio Hardware Selection
Hello, I've been watching the mail on this list for some time. I've looked at as much documentation on the web as I can find. From alsa's web site to the linux audio developers web site. What I would like to know (or see in a FAQ or HOWTO) is how to setup a linux pro audio system. With different levels of price/performance issues. Things like: sound cards necessary external equipment (amplifiers/interfaces) speaker systems cpu cases with low sound midi interfaces usb interfaces dat interfaces I'm pretty savvy when it comes to computer hardware but the audio hardware is where I'm lacking knowledge. Currently I have a Korg Triton keyboard and a SoundBlaster Live! card. I'm looking at upgrading to a more professional quality setup to handle: multi-track recording/mastering realtime synthesis audio sound/music development/programming possibly portable (19" rack mounted stuff) for live performance I've seen discussions on Digital Audio cards like the RMU Hammerfall and Digi series and the MidiMan Delta series. Some have S/PDIF interfaces and other digital interfaces. What and how do connect to these? What equipment is necessary/recommended? How do you choose one card from the other? Is there a good web page to find this information? Should there be one? A nice page describing various setups for different levels of pro to semi-pro audio systems would be handy. What do you guys suggest? Thanks, Matt Gerassimoff
