All, Do not overestimate the importance of latency. While for voice-over work and punch-in/out work this is important, and while a lot of musicians cannot play with latencies less than 0 ms, this is not necessary true for performing musicians. The performers get their feedback through the stage monitors. Ronan indicqated that those will not be put through the pc so latency here is negligable. The main monitors are often much suppressed on stage (feedback!) (by directing the sound where it is wanted: in the audience). So the audience hears almost only the main PA. Maybe the first row(s) will hear something of the musicians themselves, but as long as the delay stay below the Haas limit, there should be no problem. And if you have PA for more than thousand listeners, the direct sound is peanuts since those will likely be even closer to the PA. People seem to forget that in a symphonic orchestra the distance between performers is more than a few meters. So delays of several tens of milliseconds are no problem for a trained musician. Regards, Johan On Wednesday 24 January 2007 23:49, Bill Unruh wrote: > On Wed, 24 Jan 2007, ronan mcallister wrote: > > > Hello Bill, All, > > > > Very sorry for the incomplete description of what I want to end up doing. > > By the way, my time frame is a couple months. > > > > This is eventually for control and management of "live" music as in running > > PA sound for a live concert (eg musicians playing back through our PA system > > and monitors to a "live" audience -- well at least I hope the audience is > > "live"!).. I am concerned that Linux tools aren't ready for prime time to > > replace analog equipment when it comes to hundreds or thousands of hollering > > concert goers. > > I may not be up to date, but I would be very doubtful that Linux could > handle that (or any computer processing). The problem is the latency. Ie, > sound is read in in chunks, processed and then sent out in chunks. Thus > there is a time lag between the time the music comes in and goes out. It is > hard to imagine this as being less than 10 time slices ( eg 1/4000 sec for > a 44100 rate system) That time lag would mean that the music went out that > much later, and mixing with the direct sound could produce some interesting > effects. Now if the speakers were say sufficiently far from the performers, > then that time lag might be OK. (sound travel time). It would be a tricky > juggling act however. > You would also have to make suree that you get a real time kernel, since > you could not tolerate the system suddenly running off for a millisecond > checking up on the disk drive or something. > > The hundreds or thousands of concert goers is less of a problem. In fact > the more the better since they are then further from the stage, giving you > more time to electronically do stuff-- ie the latency becomes less > important. If you can keep the audience 20 meters from the stage, you get > almost 1/10 of a second which is more than enough time to account for the > latency. In fact if the speakers are say 10 meters in front of the > performers, you want to delay their output by at least 1/30 second anyway, > since you want the direct sound from the performers to get to the audience > before the sound from the speakers anyway. > > On the other hand if you are in a living room or nightclub which is only a few meters > across anyway you have no time to do anything before the sound has to be > out there. > > > Ie, huge venues are probably far better for replacing analog with digital > processing. > > > > > We are not digitizing the music currently rather this is for eventual > > playback to the audience through a PA system (upwards of 10KW) through our > > house and monitor speakers. we currently do this all in analog (analog > > mixers, eq's, compression, limiters, crossovers etc). I'm investigating if > > linux components can be dependable and robust enough (eventually as I gain > > experience with it) to be considered a replacement for any of our analog > > equipment. > > I would make sure to use a real time kernel, so that the kernel does not > wander off doing something else while the sound is forced to wait. > > > > >> From what I've seen thus far, the Linux distros focused on sound are > > powerful and flexible but are "bleeding edge" and are more geared toward > > postprocessing and studio mixing/remixing tasks, digital audio mastering etc > > than to replace analog mixer boards and other analog equipment in live > > concert situations. > > > > Out of the several music-focused linux distros, I've only found Suse 10.1/2 > > to recognize my SATA drives upon installation. I've got a HP pavillion > > Well, most modern distros running recent (2.6.1x) kernels recognize SATA. > > > > 7170n PC with a Pentium D chip. As a Linux user with knowledge circa 15 > > years ago and at that time it was early slackware, my hope in this latest > > endeavor was to find an audio-focused distro that would upon installation > > and as I upgrade it recognize most of my peripherals (my PC is nearly > > 1.5years old). I also need to use a RT kernel. > > > > My first task is to get a simple WAV file to playback through a Jack-aware > > WAV file player (jack enabled audacity, or ardour2 etc) -- to become > > familiar with routing signals through jack and to know more about the > > stability of the software. Then as I become more confident in myself and in > > the software, substitute pieces of our analog equipment (eg start with a > > mixer) with Jack compatible Linux apps/tools (maybe Jamin, BruteFIR, etc). > > > > Yes I have a long ways to go. that's why I'm starting with my inbuilt sound > > card prior to purchasing an expensive RME card -- I figure I should be able > > to make the onboard Intel HDA audio card work for basic tasks. > > Unfortunately the Intel HDA card is one that the alsa people have had a lot > of trouble with. Intel is supposed to be linux friendly, but it is not > clear if they really are, or why the hda driven soundsystems seem to have > had the greatest trouble. I would probably suggest some other better > supported sound card first. > > > > > > Today after having installed OpenSuse 10.2 and following all of the > > instructions in "3 steps to JAD for beginners" ( > > http://wiki.jacklab.net/index.php/3_Steps_to_JAD_for_Beginners) -- this > > seemed to be a good starting point for someone as new to the recent Linuxes > > and digital audio as myself; I found I could run jack server and even jamin > > - and with the jack connection panel I could route a WAV file using > > "alsaplayer -o jack" as source through jamin and eventually to the external > > loudspeakers; and it appears there is audio going throuh jamin, however, no > > audio output to my ears. > > > > I'll keep struggling with this. I realize I need to know alot more about > > digital audio and Linux before even approaching an evaluation of Linux > > distros, but if you have any thoughts on my current plan (to continue to use > > OpenSuse 10.2 + JAD and experiment) -- I'd appreciate it. Until I figure > > out what kernel driver I need to add to the other audio kernels (like > > Gentoo, PlanetCRMA, Studio64 so upon install it recognizes my SATA drives, > > I'll continue with Suse and JAD. > > > > Thanks again > > Ronan > > > > PS if all of my visions for pro-sound / live audio / concert management > > fails, I hope to at least use Linux to put my LP's on CD and to do some > > remixing.... > > No problem with that. > > > > > > > > > > > > > > > > On 1/24/07, Bill Unruh <unruh@xxxxxxxxxxxxxx> wrote: > >> > >> On Wed, 24 Jan 2007, Johan De Groote wrote: > >> > >> > > > >> > > Are any of these distros any better with managing and processing > >> > > "live" > >> > > sound (not a Live CD -- but an Installed Linux) ? EG, I want to > >> > > signal-process live audio as in live concerts as well as use something > >> like > >> > > bruteFIR for home-hifi and home theater (eg to implement digital > >> crossovers, > >> > > filters, acoustic analysis, etc). Most of the folks I've discussed > >> this > >> > > with use Linux audio tools for creating/modifying/mastering studio > >> music not > >> > > "live" sound. > >> > > >> > Never tried to do live sound with it. I'm one of the recording/messing > >> around > >> > types :) > >> > >> No idea what you mean by "live" vs studio. Both are the same -- and input > >> of music. It is obviously best to simply record the "live sound" and later > >> process it, since errors can be corrected. If you switch of the recorder > >> in > >> the midst of a "live" because you pushed the wrong button, y ou cannot > >> correct that mistake. But perhaps if you told us what you see as the > >> difference between "live" and studio, someone could better halp you. > >> > >> > >> > >> ------------------------------------------------------------------------- > >> Take Surveys. Earn Cash. Influence the Future of IT > >> Join SourceForge.net's Techsay panel and you'll get the chance to share > >> your > >> opinions on IT & business topics through brief surveys - and earn cash > >> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > >> _______________________________________________ > >> Alsa-user mailing list > >> Alsa-user@xxxxxxxxxxxxxxxxxxxxx > >> https://lists.sourceforge.net/lists/listinfo/alsa-user > >> > > > > -- > William G. Unruh | Canadian Institute for| Tel: +1(604)822-3273 > Physics&Astronomy | Advanced Research | Fax: +1(604)822-5324 > UBC, Vancouver,BC | Program in Cosmology | unruh@xxxxxxxxxxxxxx > Canada V6T 1Z1 | and Gravity | www.theory.physics.ubc.ca/ > -- You're never alone when you hear voices inside your head. ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Alsa-user mailing list Alsa-user@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/alsa-user
