Re: [linux-audio-dev] Echo Darla/Gina/Layla/... on Linux
On Monday 24 March 2003 08:35, David Olofson wrote: > On Friday 21 March 2003 21.47, Paul Davis wrote: > > agreed. its a rather tricky design however, because on a lot of > > hardware, you have to defer most of the driver initialization until > > the firmware load is complete. the h/w won't even talk to you > Just to make things more fun, it seems that Echo put some programmable > logic in the external part of Layla. (Only the DSP is on the PCI > card.) Problem is that the external box has it's own power supply, > and a switch on the front panel, and may well be powered off when you > start up the computer. If that happens, the driver must delay the > initialization until the external box is powered on. It's an FPGA, IIRC. All the codecs and such are in the external box, and the FPGA does all the signal routing and may do some DSP work (for output monitor matrix and volume). The Layla's output monitoring capabilities are quite powerful, with any input available for monitoring to any output, with multiple inputs to multiple outputs allowed. So the FPGA must do some mixing for all 12 possible outputs, where each output may have anywhere from zero to eight inputs assigned. Since the S/PDIF I/O is included in the matrix possibilities (both as an input and an output), but has no level control on either inputs or outputs, I would hazard a guess that the input and output level controls are implemented as digitally controlled volume control chips, and the FPGA probably only does minimal mixing in the S/PDIF domain. I can open my Layla to make sure; just not today. The few times I've tried the 'switch the external box off with PC up' routine have all caused problems at some point. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Re: [linux-audio-dev] Echo Darla/Gina/Layla/... on Linux
On Monday 17 March 2003 19:00, Ranjit Singh wrote: > Lamar, since you're on Internet Radio and that, maybe you'd like to do the > testing from an engineer's perspective? (ie with stability and throughput > as your main goals.) Do you have any coding experience? I am a broadcast engineer by profession, but a hacker by hobby. I maintain the PostgreSQL RPMset, the nspostgres AOLserver database driver, and do a little bit of coding. I wouldn't consider myself fluent in C++, however. But I enjoy learning new things I _have_ had some issues with the TRS 1/4 inch jacks on the Layla 20, though. Odd things like the top jack of a two-jack stack becoming inoperative after plugging in the bottom plug (in balanced mode). If using unbalanced connections, I don't have this problem. I've been considering some 'surgery' on the box, and replacing the 1/4's with a DB25 or something, that I could then breakout to XLR's. Of course, I've also been considering an upgrade to something like a Motu 1394 solution. But I'm not sure yet. We do real-time live multitrack recording here with Layla. It works quite well; using Ardour with the box would be cool. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Re: [linux-audio-dev] Echo Darla/Gina/Layla/... on Linux
On Saturday 15 March 2003 08:23, Brad Arant wrote: > If anyone can forward some specs to these cards I would be glad to see what > I can do. > If also have a Darla 24 (No-SPDIF) that I can test with. If anybody has > other cards in this family that would like to test and have been waiting > for drivers then please forward your name to me or this group and I add you > to the beta testing list when I get there. The C++ driver source code from echo is available on echo's web site. www.echoaudio.com I downloaded it (have a 20-bit original 'Event' Layla), but haven't even had time to look at it. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Re: [linux-audio-dev] multiport midi interfaces
On Saturday 01 March 2003 03:50, pawL wrote: > Are there any multiport midi interfaces that work in Linux?? Roland/Edirol UA-100 USB Audio Canvas has two IN's and two OUT's. It's ALSA-supported for MIDI; there's a custom driver that supports the audio. The custom driver doesn't work very well on Red Hat 8. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Re: [Alsa-devel] Re: [linux-audio-dev] Re: why is no-one responding are you all just a bunch of &*^%&^%^& wits???
On Thursday 13 February 2003 04:44, Takashi Iwai wrote: > Paul Davis wrote: > > when ardour is in a state where i believe (rightly or wrongly) that a > > reasonably typical target user can sit down and just use it without > > encountering bugs when recording a typical 12-32 track piece, there > > will be binaries. > don't forget that the binary distribution may cause different kind of > problems, too. I have some experience with distributing binaries of a large package. I have maintained the PostgreSQL RPM's for over three years. While I continue to do it, there are definitely pitfalls. They are avoidable, however. You try to make the source RPM rebuild easily on the target distributions, and only distribute binaries for which distributions you have. If they build it from source RPM (which has advantages over the traditional configure/make/make install) then it's their baby. The advantages of RPM's are mostly apparent when you upgrade or uninstall. See the Cinelerra RPM for an example of the wild things one can do with an RPM. With a tool such as apt-get, and an apt repository of RPM's, installation of even the most complicated set of package dependencies can be a breeze. Reference Planet CCRMA. Download apt-rpm, make some config changes, apt-get update, and then apt-get install packages of your choice. Dependencies are automatically calculated, packages downloaded, and everything installed in the right order. There are significant advantages to this structure. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Re: [linux-audio-dev] [ann] preamp.so
On Tuesday 12 November 2002 09:49, Tim Goetze wrote: > more interesting is that if you feed it a sine wave, the > circuit *never* clips the lower lobe, it rather seems to > compress so the lower lobe never hits the end of the curve. > it does clip the lower lobe of a triangle however. This is interesting. > > if you'd like to run spice yourself, it's fairly easy: fetch > spice3f5sfix.tar.gz (google for it, i think it's on sunsite) > and run the spice binary on the netlist linked from the preamp > page. So the SPICE sims have helped. Great! I know that SPICE is the cat's meow for electronic/electrical design problems, which is where I've used it in the past. It's just not quite fast enough to do real-time effects processing, even on current hardware. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Re: [linux-audio-dev] spiced 12AX7, plots, clipper.so
On Saturday 09 November 2002 10:29, Tim Goetze wrote: > i'd appreciate it a lot if those of you who are more apt at > EE and/or DSP take a look at the page and correct my deductions > in public or private. Two observations. The asymetrical clipping may be partly responsible for the 'warm' sound associated with tube distortion. Likewise, if you look closely, you'll see the clipping has relatively rounded edges -- another point for tubes, which by nature clip 'soft' like that. The compression rate close to the clip level isn't linear, but appears exponential. Solid state devices typically don't clip in that fashion, but do so in a much harder way. Good research, here. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Re: [linux-audio-dev] spiced 12AX7, plots, clipper.so
On Thursday 07 November 2002 19:24, Tim Goetze wrote: > after taking some plots from a simple 12AX7 preamp spice > model, i've decided to try naive asymmetric hard-clipping, > without any antialiasing measures. > http://quitte.de/12AX7-clipping.html > it may not be a true amp model, but to me ... it rocks. This looks very good. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Re: Insturmenting the amplifier for sampling (Was:Re: [linux-audio-dev] Re: Cheby amp code?)
On Wednesday 06 November 2002 14:47, Mark Rages wrote: > On Wed, Nov 06, 2002 at 02:09:50PM -0500, Lamar Owen wrote: > > cap already, in which case you have real problems, because the effective > > capacitance or two series caps is equal to the reciprocal of the sums of > > the reciprocals of the individual caps (the same as parallel resistors). > Ahh, but like parallel resistors, if one is "big" the other resistance will > set the value. So choose a "big" balue for the external cap and you'll be > fine. Which means the soundcard's cap would be the upper asymptote. Which is where I was driving towards -- unless you have a good soundcard, that is. Typical soundcards don't have really good input coupling caps, and that would 'color' the waveform seen by the A/D. > > Photflash electrolytics would be the next best thing, configured in a > > nonpolar back-to-back arrangement, as they have extremely low ESR and > > inductance, meaning they should be pretty linear. > But you don't need nonpolar caps... Just get the polarity right. Assuming > your soundcard is going to be grounded with the amp (grounding in tube amps > is itself... interesting), you will, in almost every circumstance, want the > + side to go to the amp. Ah, but did you see the schematic of the amp in question? 'Ground' could be the 120VAC LINE if you have the grounding switch set wrong. Best be safe, since the amp's ground and the soundcard's ground could have 120VAC differential. Besides, a nonpolar coupling cap would be more useful in the generic case, so that you could trace through both a negative and positive supply voltage situation. > I've seen schematics for the Bassman on the web. . Yeah, I'll google around for it. I just have to see which flavor of Bassman this one is (twin 12's with separate head). It is very old, that much I know. > > And I'm still wondering whether a SPICE model of the amplifier in > > question would tell us anything about the waveforms :-) > Probably not much more than careful thought and intuitive mathematical > modeling... besides, SPICE probably doesn't consider things like capacitor > soakage and transformer hysteresis, which can give an amp some 'flavor'. You can model those things easily enough with the port parameters SPICE allows. And that's why I suggested such. SPICE is incredibly powerful -- I have seen the pspice commercial flavor used for modeling HID lamp ballasts, which operate on magnetic circuit principles. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Insturmenting the amplifier for sampling (Was:Re: [linux-audio-dev] Re: Cheby amp code?)
On Wednesday 06 November 2002 12:50, Steve Harris wrote: > On Wed, Nov 06, 2002 at 12:07:24PM -0500, Lamar Owen wrote: > > As it also works as a transient recorder and spectrum analyzer (to > The trick really is get get a sample off of it, 8bit might be enough, but > I suspect 16 will be easier to deal with. A series 1 microfarad capacitor in the 1kV breakdown range in series with your line input should work, but you might want to use an old soundcard and machine to do it... :-) Paper 1 mic caps in that voltage range are available -- in a pinch 0.47 or even 0.2 would work, but the lower you go on capacitance the more the probe will pollute the signal. Assuming the soundcard's line input doesn't already have a low-voltage series coupling cap already, in which case you have real problems, because the effective capacitance or two series caps is equal to the reciprocal of the sums of the reciprocals of the individual caps (the same as parallel resistors). I have a couple of 50 microfarad oil-filled caps in the 12kV range, but you don't want me to ship them (all 100 plus pounds) to you The capacitors that are used in mag-reg HID arc ballasts are high value and high voltage, but I'm not sure what their frequency response will be like. ESR for those big oil-filled paper caps at 1kHz is probably going to be quite high due to the inductance of the paper/foil rolls. It just depends upon how precise you need it to be. A high voltage nonpolarized electrolytic would be close to ideal -- tweeter caps, for instance, for high-power speakers would be good, as at the typical input impedance for a sound card they would pass the lower frequencies just fine (they ordinarily work with a low impedance driver, thus decreasing the time constant and increasing the cutoff frequency). Their ESR shouldn't be a problem, as they're designed for low impedances. Photflash electrolytics would be the next best thing, configured in a nonpolar back-to-back arrangement, as they have extremely low ESR and inductance, meaning they should be pretty linear. I have a mostly working Fender Bassman available for testing. Does anyone here have a schematic for that beast? I can get the particulars. It has a nasty hum, and the bias on the 6L6's is quite bad (they run bright orange instead of just barely red). There are probably many resistors that have changed values in it, along with several dried out electolytics. I also have a Dynaco three-tube kit special (A450 output with twin 8417's) available for testing. And I'm still wondering whether a SPICE model of the amplifier in question would tell us anything about the waveforms :-) -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Re: [linux-audio-dev] Re: Cheby amp code
On Tuesday 05 November 2002 17:57, Steve Harris wrote: > On Tue, Nov 05, 2002 at 08:26:40 +0100, Tim Goetze wrote: > > Steve Harris wrote: > > >The bad news is that it means going inside someones amp with a probe, I > > >would have a go myself, but I've allready killed my last amp, and my > > >electronics skills are bad enough that I would probably fry myself ;) > > looking at a fender tube amp schematic shows +140 V after the first > > 12AY7 -- i don't have any equipment that would make this signal > > digestable by a computer. > Yeah, ggjjjzap. I dont have anything that can handle that either. How do > those attenuating osciloscope probes work? Maybe you can build something > equivalent in an audio lead, though I wouldnt be happy putting anything > like that through a homemade attenuator into my desk. I have one of these: http://www.velleman.be/Product.asp?lan=1&id=338488 (Velleman PCS64i digital oscilliscope adapter for PC). It's good to 600V, I think. It attaches to your parallel port. RadioShack carries them in the US. They run about $300. As it also works as a transient recorder and spectrum analyzer (to 32MHz), it is a great buy. Even though it is an 8-bit device, it is useful in showing what the signal looks like, as your eye can't distinguish the difference on a 75dpi screen between 16 bit and 8 bit samples. If you were close enough, I'd let you borrow my Tektronix 475 analog oscope With a 10x attenuator probe it's good for signal amplitudes of a couple hundred volts with a DC offset of 600V. If I had the amp in question here, I would be happy to do the trace for you; I routinely work on hot tube gear. (I'm a broadcast engineer; broadcast transmitters that are tube output have 10kV or more floating around them.) -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Re: [linux-audio-dev] [ann] unmatched - a LADSPA amp tone
On Tuesday 29 October 2002 10:27 am, Steve Harris wrote: > On Tue, Oct 29, 2002 at 02:20:32 +0100, Tim Goetze wrote: > > i've uploaded another image showing how the line output from > > the amp changes as the incoming sine increases in volume: > > http://quitte.de/3x-driven.gif > > admit i hope that frank's explanation holds, and that the > > valve_rect can be made to produce similar shaping. > Hmmm... if that is sag from the powersupply then it kicks in much lower > than I though. Another thing I guessed wrongly. Should make it easier to > implement though :) - more margin of error. I should have read this one before replying previously. This most certainly looks like the result of undersize interstage coupling caps -- a high pass filter. With the currents in those tubes being at most a few milliamps, and the power supply filter caps at 16 microfards, with a choke in the PI arrangement no less, it is unlikely this is sag, unless the third filter cap (there's a double-pi power supply filter here -- the first stage of the pi, the one with the choke, feeds the output tubes. The second stage, since the current is so much lower, uses a resistor in the top leg of the pi, which is perfectly fine for this application) is very leaky. If the power supply was sagging, the 6L6's would drop first, being that they need more current. You can measure the voltage rails to see (using appropriate caution, since there is lethal voltage in this circuit) if they sag. Now, there are two interstage coupling caps of interest. One is between the 12AY7 first stage and the cascade connected 12AX7, and the other follows the 12AX7 cascade. I can't read the value on the second one. (I know the first stage is actually a mixed twin stage -- it is simpler to drop one side of the mixer and treat it as a single stage, from the signal's point of view). Can a trace be made in the middle? I'm looking for a signal trace situation here -- the signal after each active component. Of course, you need a scope that can handle the voltage there, or build a series capacitor audio probe first. While much of the 'tube sound' comes from tubes, much more comes from the types of components used in tube circuits -- the circuit impedance dictates the technology of the capacitor, for instance. The 'tube sound' can be had with FET's, as long as they are biased right and you use depletion mode devices. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Re: [linux-audio-dev] [ann] unmatched - a LADSPA amp tone
On Monday 28 October 2002 05:33 pm, Steve Harris wrote: > On Mon, Oct 28, 2002 at 10:37:18 +0100, Tim Goetze wrote: > > it shows my badly-driven fender amp's line output (top) vs. the sine > > wave it was fed at the same time. i'm wondering how come the output > > overshoots every time the input crosses zero. trying to model this > I dont think it does, I still think this is just a phase effect. > OTOH it could just be an extreme case of hard clipping and HP filtering. I would lean this way as well, since the first interstage coupling caps are a mere .02 microfarads. Even at the circuit impedance there, you will have some serious overshoot due to the series capacitance. See the SPICE project for a circuit simulator program that can handle waveforms in this sort of circuit. SPICE is as old as dirt, but a very handy program for electrical engineers. The algorithms used in SPICE, once you have a working netlist, could theoretically be used on audio waveforms, but it would take a real machine to get realtime results through SPICE. The nice thing about SPICE is that, if you have the curves for the active devices, and the schematics for the circuit as a whole (which is the case here), you can model very accurately the circuit in question. To find SPICE, search virtually any archive of freeware in the engineering programs section. SPICE is the Csound of electrical engineering. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Re: [linux-audio-dev] [ann] unmatched - a LADSPA amp tone
[Note: I've only been loosely following this thread, but this message caught my broadcast engineer eye, being that I work with tube gear nearly daily.] On Monday 28 October 2002 01:55 pm, Tim Goetze wrote: > Steve Harris wrote: > >That is a side effect of class B amps IIRC. I would have though that > >preamps would be class A, but maybe not. > they are, afaik. you're right, it's a property of class B. > still my amp's preamp stage shapes the lower half differently > (less) than the top. It would depend upon where in the transconductance curves the tube is biased, as well as plate voltage. The behavior you desribe sounds like an underbias condition, where the tube isn't biased approximately in the middle of its linear range (for class A). Either that or the plate voltage has sagged (old dried out electrolytic caps?). And if it's a tetrode or pentode amp, the screen and suppressor bias level and type figure into it dramatically. > >> i'm still trying to model the hard-driven valve in the time > >> domain. the more i look at it, the more i think the 'building of > >> potentials' i've tried to describe comes near it. though it would > >> be nice to base it on hard facts about valve amp behaviour, too. > >'building of potentials'? Are you refering to your sinc summation idea? > >Its a nice idea, especially as you get anitaliasing for free, but I think > >it will be hard to turn a hardish clipping shape into a sum of sincs. > no, this is the other idea that would try to model a simple > wave shaper (pushing energies and so on). the sinc idea is > reserved for dire emergency situations, it's not really gentle > on the cpu and tough to get right. Ok, from an engineer's perspective: It seems to me that modeling the transfer function of a tube would involve running high level triangles at various fundamental frequencies. This data would then be analyzed to see the necessary time and frequency domain artifacts of tube operation. You need to see the group delay, and the frequency response for the fine details -- but the big issue is the simple 'if I put in X volts I get out Y volts' transfer function. This can be modeled with finite element techniques if you have the exact parameters of the tube (plate size and shape, interelectrode spacings, grid dimensions, filament/cathode emission and dimensions, etc). I have seen this done for large tubes (4CX15,000A's as used in broadcast transmitters), but not small ones (6146's, 2E26's, as well as the even smaller ones like the 12AX7 or AU7, or the venerable (and expensive) 5763, or even the ubiquitous 6L6 and variants like the 807). The purpose in the transmitter case is to see what frequencies need what compensation and potential neutralization. Since the 4CX15,000A is used at frequencies well over 100MHz, knowing this sort of thing (particularly interelectrode spacing and coupling) is essential is designing the tuned cavity output and input networks required at FM broadcast frequencies. But the old '15,000 would make a hoss of an audio amp -- the 15,000 number is the rated plate dissipation in watts. A pair in class B push-pull can make 50kW of output at audio frequencies easily. Certain frequencies must be avoided for these tubes -- if the frequency response has an area where the output is 180 degrees from the input potentially destructive positive feedback can occur. If not properly neutralized and bypassed, these tubes can self-destruct in a pyrotechnic manner. A 4CX15,000A takes around 160A at 12 volts AC for filament, and 10KV for the plate @ 2A or so, with several hundred CFM of air through its fins... A fun tube -- particularly when it blows. I can take a picture of one here (paperweight dud) if desired. For what it's worth I dug out my RCA Receiving Tube Handbook and its cousin, the RCA Transmitting Tube Handbook, from the mid sixties. Some curves are reproduced there, and I can probably get the curves you need from manuals I have. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Re: [linux-audio-dev] Wave Editors
On Friday 25 October 2002 02:18 pm, Paul Davis wrote: > >Is this really of any use? I never recorded with sweep (I use > >ecasound), but when I tried to load a 10 minute ogg file into sweep, > >it refused this because of exhausted memory. I have 256 MB, that > >should be enough for 10 minutes of sound data. So how good is sweep > >with longer soundfiles? > i would consider a much more fundamental problem with sweep (which the > author has plans to fix at some point) is the assumption that the > audio data will fit in memory. this just isn't viable for working with > "music" rather than "audio clips". > gnoise doesn't do this, and neither does snd. i am not sure about > audacity, but i suspect it doesn't either. I regularly edit 2 hour 44.1k stereo 16bit files with Audacity. Sweep looks really really good -- but won't open that size file. Audacity has a bug in its handling of that size file, which I need to report when I have time to write it up properly, but it's something I can work around easily enough. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Re: [linux-audio-dev] USB audio.c driver patch; complete n-channel/24 bit patch
On Friday 25 October 2002 07:13 am, Monty wrote: > Apologies taking time to package this up. The patches included are > tested against 2.4.19 or later. > This patch fixes a few bugs and implements full n-channel support of > greater-than-stereo USB audio devices, such as the emagic emi 2|6. I Question: does it include support of the Roland UA-100? The UA-30 I believe is supported, but the UA-100 is an entirely different beast. The once-off drivers for it are OK, but begin dropping samples after recording for more than a few minutes on my machine. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Re: [linux-audio-dev] Soundcard spotting
On Wednesday 23 October 2002 12:59 pm, ljp wrote: > It's not the equipment you have that really counts.. it's what you do with > it! One day a photgrapher was showing off some pictures at a gallery. An onlooker came up, admired the pictures, and asked the photographer what kind of camera it was that took the pictures. The photographer asked the onlooker what he did for a living. He said that he was a chef. The photographer then asked him if he was asked what kind of pots he used when cooking a meal. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Re: Linux 1394 A+M (was: [linux-audio-dev] App metadata intercomunication protocol..)
On Wednesday 24 July 2002 03:48 pm, Paul Winkler wrote: > On Wed, Jul 24, 2002 at 03:13:45PM -0400, Lamar Owen wrote: > > What ALSA USB audio? Owning a UA-100 I got off eBay cheap, it would be > > nice to see good USB ALSA support. The existing UA-100 USB driver does > > work, but it's a crippled OSS version. > There is ALSA USB support recently (within the last few weeks). > it's in the CVS version at least. I haven't tried it > (no usb audio gadgets here). Thanks. BTW, your Audio Quality HOWTO information on the UA-100 driver is why I grabbed this one. Man, it has *great* audio! All sorts of guitar effects in DSP hardware too. It is a neat box. The effects can be used without the computer being connected as well. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Re: Linux 1394 A+M (was: [linux-audio-dev] App metadata intercomunication protocol..)
On Wednesday 24 July 2002 08:05 am, Paul Davis wrote: > i'm hoping takashi will jump on this the way he did USB audio and get > this merged/extended into alsa. *REWIND* What ALSA USB audio? Owning a UA-100 I got off eBay cheap, it would be nice to see good USB ALSA support. The existing UA-100 USB driver does work, but it's a crippled OSS version. The audio quality of the UA-100 is stunning. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Re: [linux-audio-dev] RFC: API for audio across network - inter-host audio routing
On Friday 14 June 2002 01:58 pm, Richard C. Burnett wrote: > > Which is enough to reconstruct the sine wave if the output is through a > > proper post-DAC filter. > amplitude modulation from the different sample points. Have you ever > plotted a sine wave where you you don't pick enough points to show the > real shape? It's the same principle. The idea is that you get the integrated value of the amplitude of the sine wave, since a sine wave always has the same shape. But the amplitude, at the Nyquist frequency, cannot change. Yes, I really said that. If the amplitude of the sine wave changes, you get an upper sideband above the Nyquist rate that you cannot sample -- of course you also get a lower sideband that you can sample, but then the recovered envelope is distorted. Amplitude changes at the Nyquist frequency violate Nyquist's theorem. Thus the Nyquist frequency itself is an asymptote and cannot be accurately reproduced except in the steady state. It follows that as the sampled frequency approaches the Nyquist frequency its rate of amplitude change must be decreased due to that stubborn upper sideband. You end up with aliasing distortion from the upper sideband that passes the Nyquist filtering at the A/D, producing aliasing components reflected down in frequency. And if you can hear 20kHz (I barely can), you can detect the difference in attack times for sharply attacking instruments, which translates as noise, given a 44.1ksps rate. > But the higher your sampling rate, the more you are guaranteed not to miss > a max point or a min point, because when the signal is in those ranges, > it's able to grab many points. That's what the post-filtering is for. The post-filter acts as an electronic flywheel that fills in the points between samples. The difficulty is building accurate output filters -- and that also translates to the cost of the equipment. > Actually I read equal to in one of my text books, but that is beside the > point. It means that you can 'detect' frequencies at that frequency, but > it doesn't mean you can accuratly reproduce them. Even at say 18kHz > sampling at 40kz you would see essentially a beat frequency (I think that > is the term) as the sampling point is different in each cycle, and not > enough to capture the max/min every time. The flywheel effect of the post-filter eliminates that. What you do hear is the aliasing distortion from the loss of the upper sideband of the complex component of the sampled frequency. A change in amplitude of any given frequency translates to a static 'carrier' at the frequency of interest and two sidebands containing the change information. This is AM broadcast theory here. (I am a broadcast engineer by profession). > I've done the test. I listened to a CD recorded SACD and a standard CD, > same CD player. The difference was very audible, and a lot of it to me > was crispness in the upper frequency range. Loss of the upper sideband, as the frequency-domain signal acquires components approaching the Nyquist frequency, might possibly explain this. > My research indicated that > clock jitter is the number one cause of problems. This is why there are > $1000 CD players that do sound different, and their specs usually talk > about the jitter. I wholeheartedly agree with that. Jitter causes unmusical (additive instead of multiplicative) frequency transposition, which in turn creates FM sidebands in the decoded audio, perceived as 'grunge'. Which is why I spec broadcast-grade CD players here -- the difference is audible. Plus I get balanced outputs for RF resistance... :-) -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Re: [linux-audio-dev] RFC: API for audio across network - inter-host audio routing
en the eye receiving an image and the brain processing the image (which is pretty hefty horsepower, in reality). This is why all driving schools suggest three second following distances, to allow for the brain's latency (seeing the car's brake lights, understanding what that means, activating your own brakes, the latency of the brakes being applied and you stopping. And people are worried about the turn-on latency of incandescent lamps versus LED's -- it probably makes little real difference, but it looks good on papaer). Performers in an orchestra or band automatically and without much thought compensate for their own delays and latencies, including the one between the conductor's baton hitting the beat and their own brain seeing the conductor's baton hitting the beat. Yet no one is really aware of this high latency, because it is normally below the level of consciousness. I have actually experimented myself, just now, in trying to perceive the delay between thinking the word I'm going to type and seeing the word typed on screen. It is quite long, relative to the ms latencies we're talking about. In short, your brain doesn't have to be aware of it if it doesn't want to. Yet, there are other benfits of low latency. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Re: [linux-audio-dev] RFC: API for audio across network - inter-host audio routing
On Thursday 13 June 2002 11:59 am, dgm4 wrote: > Lamar Owen wrote: > >French Horn. Its bore is as long as a tuba's. I have played horn before, > > and there is a definite, barely detectable delay between initiation of > > the note and the perception of the note (which is both by ear and by hand > > in the case of the horn). The long bore is one reason the horn's attack > > is quite mellow. > To say nothing of pipe organs, where the latency can be nearly half a > second (!) in a large church. Yeah, but organists are trained to compensate for that. That's one reason there are so many manuals. But it does make the music interesting to play. I know a concert organist who is rather accomplished; I didn't even think about his techniques when I mentioned horn. When one stop is half a second removed from another, odd and interesting effects can be produced by one who know the instrument and the acoustics of the venue well enough. But I think most musicians don't want to have to deal with the pipe organ techniques. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Re: [linux-audio-dev] RFC: API for audio across network - inter-host audio routing
On Thursday 13 June 2002 09:29 am, Charlieb wrote: > On Thu, 13 Jun 2002, Steve Harris wrote: > > MAS works over LANs, and should be capable of 10ms latency, which isn't > > very low by BTW. You certainly can't play an instrument with 10ms > > latency. > Nonsense! What about tubas ? > I admit a guitar would feel pretty awful w/ 10 ms latency, an oboe or > trumpet only fells a little "slow to speak", and a Tuba , well, that > would be an exceptionally responsive low brass... French Horn. Its bore is as long as a tuba's. I have played horn before, and there is a definite, barely detectable delay between initiation of the note and the perception of the note (which is both by ear and by hand in the case of the horn). The long bore is one reason the horn's attack is quite mellow. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
[linux-audio-dev] OT Now I've seen everything (Audiophile related)
Maybe there's even Linux drivers for this thing: http://www.aopen.com/products/mb/ax4b-533Tube.htm Yes, you see right: a Pentium 4 Motherboard with a vacuum tube audio output. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Re: [linux-audio-dev] Writing a driver for this card: your thoughts?
On Wednesday 29 May 2002 02:50 pm, Paul Winkler wrote: > On Wed, May 29, 2002 at 02:22:09PM -0400, Lamar Owen wrote: > > interesting curves, maybe, but a compressor nonethless. And a compressor > > one can model and produce identical characteristics in effects plugins. > > :-) > In theory, yes. In practice, I think we're still in the "close but no > cigar" stage of modelling amplifiers. But I do think we'll get it > eventually. If one has the amplifier in question, one can produce a reasonable facsimile of the transfer function using various waveforms and frequencies, then interpolate (cubic splines, probably) to determine a transfer function that one cane then put into a 'transfer function engine' that would replicate said transfer function. You should be able to characterize down to the individual lot number level with enough resolution in the interpolation. Has such a 'transfer function engine' effect plugin been written? -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Re: [linux-audio-dev] Writing a driver for this card: your thoughts?
On Wednesday 29 May 2002 11:18 am, Paul Winkler wrote: > On Tue, May 28, 2002 at 07:43:14PM -0400, Lamar Owen wrote: > > Class A design has it's strong points. As long as you are in a good > > linear portion of the transconductance curve you're OK. > As a sometime guitarist, I'd say Class A has its strong points well > into distortion... But then the amplifier is *producing* sound rather than *reproducing* sound, and has become a form of compressor. A compressor with some interesting curves, maybe, but a compressor nonethless. And a compressor one can model and produce identical characteristics in effects plugins. :-) As a sometimes guitar player myself, that is. Still have my copy of Anderton's 'Electronic Projects for Musicians' lying around here. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Re: [linux-audio-dev] Writing a driver for this card: your thoughts?
On Tuesday 28 May 2002 07:20 pm, Tobias Ulbricht wrote: > one question: > could you do this for the unsophisticated audiophile with less Acronyms? > > > supply. Using a computer psu is going to severely limit what you are > ^^^ = power supply unit? Yes. > > decoupling is done at the amplifier rails, along with 'sag' compensating > > caps > ^^^ Voltage sag due to current draw. > > (with low ESR! Tantalum only, and preferably sintered slug) in the proper > ^^^ ? electron spin resonance :)? Equivalent series resistance. The higher the ESR, the slower the cap will discharge, and the less effective it is as a 'voltage flywheel'. > > But again, the hardware must be able to cancel out the enevitable RFI > > that is > ^^^ Radio Frequency Interference. Sorry. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Re: [linux-audio-dev] Writing a driver for this card: your thoughts?
On Tuesday 28 May 2002 06:40 pm, Tim Orford wrote: > On Tue, May 28, 2002 at 04:19:48PM -0400, Lamar Owen wrote: > :-) bring on the flames :-) This is a flame? Tempest in a teacup... :-) > and good quality audio sounds better? > this is a new one to me - i've never heard anyone > blame it on the source material beforehmmm...:-) Yes, actually, good quality source material sounds better. Orban's Optimod 9100 manual, circa 1987, mentions this as part of the setup instructions. > I do sympathise with you, but if that much compression was > desirable, then the tracks would be mixed like that in the first place. Have you checked the dynamic range (or lack thereof) on some recent CD's? They are compressed flat as a pancake. But, like I said, for AM radio coverage area is directly proportional to modulation percentage. FM radio doesn't have that excuse. And I personally process the least I can get away with. But it does compensate for much operator error in the lack of watching levels. And the six band limiter of the Optimod 9100 is pretty clean. > But like you said, it has been a big point of contention for a long > time, and i dont think we will solve it here :-) Yes, indeed. > > Phase-linear balanced outputs won't cancel _any_ harmonics. Where did > > that concept come from? > i have seen this in balanced internal circuitry, for example > in valve compressors. Its been a few years since i did much > analogue stuff, so i'm gonna be deliberately vague here. Certainly in a non-linear situation (such as a tube compressor, such as the ever popular UREI leveling amplifier (got one)) balanced versus non-balanced internal to the processing will change the transfer function. But this is an I/O discussion. > >And the Carver Silver Seven sounds better than the old > > M400, too, right? :-) (audiophile humor) > ok, i can see that you think that i am some kind of audiophile > lunatic, which maybe i am to a certain extent. There have been > several things which have changed my life in a major way in the > last few years: That wasn't my intention; my apologies. > One was the discovery of the Free Software movement. One was the > discovery of class A, low feedback design (thereby shattering > most of what i was taught at college). Class A design has it's strong points. As long as you are in a good linear portion of the transconductance curve you're OK. > I'm not really disagreeing with you, but i think my > point was that there are more factors to take into > account that you appeared to be ignoring. There's always factors. In another forum I might detail how the assymetry of tower base impedance creates distortion in the transmitted audio of an AM station, and how silver plated coils and multi-thousand dollar vacuum capacitors with computer modeled matching networks have more of a bearing on my sound than the audio inside the studio. My matching network here is worth over $75,000, thanks to the engineering behind it. And that's just so that my 11khz sliver of audio passband will be as flat as possible. But that would be a major digression. By private e-mail, perhaps. >There is a lot > more to analogue audio than just keeping impedances low, > wacking up the negative feedback, and measuring the noise > floor, as i'm sure you realise. Certainly. Transmission line factors must be taken into account for long runs at high frequencies, etc. Lots of factors. But the question I was answering was a simple 'I've never heard of balanced drivers; what are they?' > So to get back to the original point, i'm sure the cards > you mentioned are indeed fine cards, but if cost is no object > (ha ha!) and if quality is your objective, then you will put your > analogue converters in a separate box with a dedicated power > supply. Those ASI cards ain't cheap. Check them out: audioscience.com. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Re: [linux-audio-dev] Writing a driver for this card: your thoughts?
[I may regret this... :-)] On Tuesday 28 May 2002 01:19 pm, Tim Orford wrote: > Lamar Owen wrote: > > Also, due to the processing typical radio stations use in the air chain, > > in many cases the quality of playback and record hardware for on-air use > > must be up to the top quality of a recording studio. > such insane amounts of compression as used by most radio stations are not > usually related to 'quality' as understood by most poeple. What happens is that lower quality audio is made to sound that much worse by that very compression. Reverb is exaggerated, etc. As to the amounts being insane -- well, that is a big point of contention in the broadcast engineer and broadcast program director communities. > one of the most important aspects of analogue design is a good power > supply. Using a computer psu is going to severely limit what you are > going to achieve. Regulators are by no means perfect. If the output impedance of the output stage is low enough, and proper decoupling is done at the amplifier rails, along with 'sag' compensating caps (with low ESR! Tantalum only, and preferably sintered slug) in the proper places, DC rail regulation becomes moot. The key is a properly designed feedback network, with low net gain, using a high quality op amp with as high an open loop gain as possible, and operating the output well below rail voltage. If the output voltage goes over half rail, then all bets are off. > also, perhaps academic here, but using balanced > audio can actually degrade the sound by cancelling out even order > harmonics but leaving the odd order ones, or by increasing the component > count. Very high end stuff designed for non-hostile environments tends > to be unbalanced. Phase-linear balanced outputs won't cancel _any_ harmonics. Where did that concept come from? And the Carver Silver Seven sounds better than the old M400, too, right? :-) (audiophile humor) > ok, back to trying to get Ardour compiled.(does that make me > On-Topic now?) Hmmm. You know, a linux based broadcast compressor (on the order of an Omnia6 or Optimod 8400) would be an interesting project. Someone who wants to do serious DSP work could have a field day doing multiband limiting and the various other things broadcast processors must do. But again, the hardware must be able to cancel out the enevitable RFI that is going to be present. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Re: [linux-audio-dev] Writing a driver for this card: your thoughts?
On Friday 24 May 2002 10:11 pm, Paul Davis wrote: > >As to the AudioScience cards, they are common in radio stations and > > recording studios. > By my standards, anybody who puts A-D/D-A conversion inside their > computer chassis is by definition not concerned with "the best in the > business". The term "professional audio" for me doesn't include analog > I/O for a computer card unless the converters are in a separate > box. It might be good enough for a radio station, but for a recording > studio? Properly designed balanced in and out A/D and D/A converters can be completely immune to the PC's internal noise. But it all goes to proper design. The Antex SX series of cards likewise contain internal A/D converters. I have measured the noise figures of the Antex SX-36 we have at WGCR using state of the art audio systems analyzers, and the noise floor is below the LSB threshold. All due to balanced I/O, sound PC layout techniques, and top of the line components. With unbalanced I/O all bets are off, of course. But I still use an Echo Layla in our production studio -- and Layla's A/D is out of the PC in a rackmount chassis. Balanced I/O on TRS 1/4 inch jacks. But no Linux drivers yet. > I think you're always better off with 3rd party converters myself, so > you can make you're own choices on the quality level, and possibly > have multiple options (Fostex,Frontier Designs,Apogee for example) as > well as upgrade/downgrade paths. In a high RF environment, unless the converters are optically isolated from the PC, you might be asking for trouble. When I say 'high RF' I'm talking 10KW of AM transmitter fifteen feet away, with a measured RF field intensity of 105V/m (the ANSI exposure limit is around 645V/m). This means a one meter piece of wire that isn't properly grounded can develop 105V of RF energy. I have suffered RF burns of appreciable intensity touching wires that weren't connected to anything on either end -- they were just oriented along the field gradient. Also, due to the processing typical radio stations use in the air chain, in many cases the quality of playback and record hardware for on-air use must be up to the top quality of a recording studio. Typical radio stations use sophisticated compressors, multiband limiters, and many other DSP-driven techniques to maximize loudness -- and when the dynamics of the source material go pianissimo, the compressors drive up the noise floor to compensate. Noise in the outputs of a broadcast automation or music-on-hard-drive system is verboten. This is particularly (and somewhat paradoxically) true on an AM station, where the processing will be much more aggressive -- the higher the average modulation, the greater the effective coverage area for an AM station. Having said that, the distortion percentages aren't nearly as important for the exact same reason. But it is wrong to state that a recording studio will automatically need higher quality than a radio station. But in theory I agree with you on the topic of analog I/O into the PC -- but I have just seen top quality hardware with on-board analog I/O that had no measureable PC-induced noise too many times to ignore. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Re: [linux-audio-dev] Writing a driver for this card: your thoughts?
On Friday 24 May 2002 01:12 pm, Mark Rages wrote: > On Fri, May 24, 2002 at 05:47:07PM +1200, Eliot Blennerhassett wrote: > > - analog and digital audio I/O, balanced drivers > I don't know what balanced drivers are. Balanced I/O. Professional grade. As to the AudioScience cards, they are common in radio stations and recording studios. The audio specs (frequency response, distortion) are nearly the best in the business. They are NOT cheap, though. But multiple balanced ins and outs on XLR's (by way of octopus cabling) works very well. One of the radio stations I engineer for has a couple of the higher end ASI cards 4336 maybe? Anyway, they have the digital I/O (for triggers and switching, not digital audio), and they are very happy with the quality of the cards. If these cards get good Linux drivers, this will be killer. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Re: [linux-audio-dev] ANNOUNCE: Rosegarden-4 v0.1.5 released
On Saturday 04 May 2002 08:55 am, Paul Davis wrote: > IMHO, Qt is not a problem. KDE is. Same goes for GTK/GNOME. As I've > said before, I don't think people writing audio/midi/music > applications should be using "desktop environments". User interface consistency, perhaps? -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Re: [linux-audio-dev] OT: Electronic advice for PC.
On Wednesday 01 May 2002 06:35 pm, Patrick Shirkey wrote: > Reading the specs for the SFX power supply design guide it seems that the > minimum for a 120watt power supply is 1.5 amps and the max is 19.2 Looking at the specifcation at http://www.formfactors.org/developer/specs/microatx/microatxspecs.htm gives me much more of an idea of what you're dealing with. While it seems like a win to float a battery across the DC outputs of an SFX supply, this is a very bad idea for a number of reasons: 1.) Multiple voltages: you need a separate battery for each of 5V, 3.3V, 12V, and -12V. Some of these voltages are difficult to derive within the required tolerance via battery. 2.) Regulation of those voltages: worst speced voltage is the -12V rail at +/- 10%. Only NiCd cells are anywhere close to capable of +/- 10% over their discharge curve. A lead-acid 12V battery, for instance, is typically at 12.6V at full charge, and 10.0 or slightly less fully discharged. This is over 20% swing -- and won't cut the mustard for directly powering sensitive CPU's and the like. The spec mentions an SFX12V supply with a 12 volt nominal input voltage. This would be the way to go, in my book. I would set such a system up with a couple or three Power Wheels toy car batteries (these things stand deep cycle!) and the SFX12V supply. Barring the SFX12V supply availability, you can use the standard 120V AC supply and most any inverter of at least 200W rating (to handle the surge current on initial startup). Since this is an audio application, I would VERY HIGHLY recommend the SFX12V supply instead, as a typical AC inverter throws alot of audible hash off as RFI/EMI. You can get true sinwave inverters, but they're not cheap. The Power Wheels batteries have a recommended charger, and they're about $25 each in the States at Wal-mart. Don't know about Korea. They are sealed lead acid, not too heavy, very rugged, fused, and come with a pigtail. The special connectors can be cut off easily enough and replaced with more readily available Molex 20A connectors. The charger is a wall wart -- mount the Power Wheels batteries in the case, run the pigtails out the back, and put a pigtail on the SFX12V supply with mating connector. You can then run on one battery while the other charges, or somesuch. Sounds like an interesting project > Most of the time it will only be running the CPU, RAM, 1xHDD, PCI soundcard > and a usb numpad. Ocassionally you could throw in a remote sensor for a > keyboard/trackball (has it's own batteries anyway). If a cdrom/dvd was > being used most people would have access to a power supply (need it for the > monitor at least) and they definitely won't be running around with those > attached. None of the devices mentioned can be run directly off battery due to the regulation requirements. Notebooks contain special DC-DC converters to change the varying DC output of the battery to a regulated output. Oh, and contrary to popular belief, a voltage regulator can indeed step up the voltage if it is a switching regulator. Step-up switchers are harder to design properly, but they do work (using the flyback principle -- the same thing used by your television to generate the 25KV for the second anode of the CRT). -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Re: [linux-audio-dev] OT: Electronic advice for PC.
On Tuesday 30 April 2002 08:15 pm, Paul Winkler wrote: > The other thing is that digital electronics are very picky about > voltages, and battery voltage drops as the battery runs down. Which is one reason I recommend the inverter approach. Oh, and I do this sort of thing for a living as a broadcast engineer, for what THAT's worth. :-) -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Re: [linux-audio-dev] OT: Electronic advice for PC.
On Tuesday 30 April 2002 02:39 pm, Patrick Shirkey wrote: > >1.) Required voltage. What voltage is needed? If this is going to be > > driving an inverter, 12V is typical. > Why would I need an inverter if the power level from the batteres are > correct in the first place? > From my research so far I have estimated that the machine would draw about > 12v maximum. > Can anyone confirm or deny whether this is correct? > The machine is: > possible pci soundcard for pro recording. Is this a typical motherboard (ATX) or is this something oddball? My notebook requires 19.5V at the DC input -- but there are inside-the-case DC-DC inverters that transform to the required internal voltages. A standard MB takes +12V, -12V, 5V, and 3.3V, plus a signal back to the power supply called 'power good' (and then there's the turn-on lead). Standard desktop-style hard drives, floppies, and CD's take 12V and 5V. Notebook HD's take 5V only. Newer AGP stuff takes 1.5V. Do you have an existing AC power supply? If so, you need to actually measure the current consumed (and the voltage at which that current draw occurs) before you can size a battery. How do you plan to charge the battery? > >2.) Required current. At the required voltage, how much current does the > > PC draw? This is necessary for the next criterion: > Does anyone know what this would be based on the above hardware? You have to measure this with a multimeter. In case you have never done current measurements before, the basic concept is to place the ammeter in series with the power supply. This can be difficult, depending upon the supply. But, if you can get to one leg of the supply by itself, clamp-on DC ammeters are available that will allow you to get an accurate reading without messing with the wiring. Typically, if the machine is designed to run off AC, it's easier to buy an inverter and take the measurements on the DC going to the inverter. As a data point, Best Buy and others are selling a cute little 75W inverter made by APC as an 'automotive and airborne notebook power supply' -- just plug your AC supply into the handy 120V outlet, plug the cigarette lighter socket (or the airplane-compatible pigtail, which is included) into 12V, and start computing. The APC inverter is much less expensive than the DC-input supplies made by the notebook manufacturers. > >3.) Required battery run time. How long do you want the battery to provide > I would say 6 hours would be about right. Most performances don't last much > longer than that. Of course more would be better but this thing has to be > easily lifted - eg shoulder strap - as I expect people will want to use it > in the field. Ok, once we settle the current draw and operating voltage issues, you're well on your way. Supposing your machine draws 2A@12V, you would need a 12AH battery -- two of those 'Power Wheels' batteries would be just about right, in parallel. Quite totable, too. As another aside, I carry such an outfit with me all the time -- two Power Wheels 7AH 12V batteries plus a 120W inverter, all in a military surplus ammo case (7.62mm NATO, the small case). I'm an amateur radio operator (KF4MYT), and often need to run my Yaesu FT90 mobile radio outside the car. The ammo-pack power-pack does the trick without the inverter. It can also run my notebook with the inverter. You may find that the current draw of a typical desktop MB is very high. > Another question that I'm unsure of is whether having a battery that is too > powerful for the machine is going to cause problems or is that not possible > because the machine will just run for longer? Or is that where an inverter > comes in? A battery that has too much ampacity for the charger used is the biggest concern. As long as the voltage(s) isn't too high, you should be OK. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Re: [linux-audio-dev] OT: Electronic advice for PC.
On Monday 29 April 2002 12:16 pm, Patrick Shirkey wrote: > I am wondering if anyone can tell me how I can deduce the correct power > rating for this machine so that I can design a battery pack that will power > it efficiently. Ok, there are several criteria to consider for sizing batteries: 1.) Required voltage. What voltage is needed? If this is going to be driving an inverter, 12V is typical. 2.) Required current. At the required voltage, how much current does the PC draw? This is necessary for the next criterion: 3.) Required battery run time. How long do you want the battery to provide required voltage at the required current? Battery capacity is rated in ampere-hours (AH) -- suppose your PC draws 5A at 12V -- and you want to run 10 hours. 5x10=50AH. That is a little larger than a motorcycle battery. My Sony Vaio notebook has twin 3000mAH Li-Ion batteries. It runs for about 2.5 hours. This means it is drawing 6000mAH/2.5H= 2400mA=2.4A. Of course, the Li-Ion discharge curve being what it is, this is approximate at best. 4.) Charger ratings. The larger the battery in AH, the beefier the charger needs to be to charge it is a reasonable amount of time. I designed a battery system for our studio here. The requirements were: 1.) 12V for inverters (StatPower ProSine 1800 x2) 2.) 24 hour run time. Experiments concluded that the Prosine 1800's could reliably start and run about a 1000W load (monitor turn-on current surges will cause the inverter to drop out -- I measured the surge load of this 1KW average load as being about 2700W, which is within the 1800's 2900W peak rating). With a 1000W load and 12V, they draw right around 90A. To get 24 hour runtime, we need 90x24=2160AH of capacity. Fortunately, the 1000W is the designed largest load -- they typically run about 70A. Now, the local telco was needing a place to off-load some large flooded lead-acid cells rated 2320AH. We were able to get them donated. With the voltage drops in the wiring taken into account, we have about 24.2 hours runtime at an 80A load -- which is a little less than what I wanted, but good enough at this point in time. I just have to keep my inverter loads around 850W or so. At which load the Prosine 1800's are very happy. Now the chargers became a major problem. At 2320AH, you need 232A to recharge in 10 hours, which is the recommended rate for these cells. Well, I couldn't afford the real telco chargers necessary for such. So I compromised -- I get a 36 hour recharge rate by using a pair of 100A rackmount 13.8V regulated power supplies made by Samlex America. These supplies, with the resistance of the wire to the batteries, level off at 100A fo the first couple of hours, and then begin to taper the current down afterwards. A full equalizing charge requires 150 hours, but that's OK. Hope that helps. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Re: [linux-audio-dev] [OT] seriously screwed up Gtk installation ?FOLLOW-UP
On Sunday 14 April 2002 10:55 am, Dave Phillips wrote: > Well, yes and no. My troubles began when RH's 2.96 compiler gave me fits > over compiling MusE (briefly: it was impossible) As a very many programs have no problems with the Red Hat pre-gcc3 that is 2.96, I would have to say that it is a MusE problem, not a RH one. > Gtk. So no thanks to RH for deciding to be the only kid on the block > with the 2.96 ball. To be fair to RH, they are funding a large portion of GCC's development, as well as pouring a large amount of code into gcc3. Oh, RH 7.2 includes a gcc3 set of packages for you to use. > OTOH, (and as you say, to be fair), MusE apparently does now compile > under 2.96 so I'm wondering whether the path of least resistance is to > simply reinstall RH 7.2 on this machine and plan on a Debian install to > a new disk. While some may cringe at the thought, I think you would do well to install the Red Hat Skipjack public beta (7.2.93), or wait until the next RedHat is released (all indications are that that will be soon, as there have now been two public beta announcements). I'm running 7.2.93 here and like it. The 2.4.18 kernel in it appears to have the low latency and preemptible patches, making for a good low-latency platform. > The Book Of Linux Music & Sound at http://www.nostarch.com/lms.htm > The Linux Soundapps Site at http://linux-sound.org Not so incidentally, many thanks for both of these resources. I Bought the Book (TM), and it is good. And I use the linux-soud stuff all the time. While we're at it on that, does anyone know of a radio station on-air automation system in development? There are a couple of commercial ones available (one is On Air Digital -- see http://www.onairusa.com/rshd.htm for how they use Linux), but I'm not hot on commercial software. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Re: [linux-audio-dev] Interesting read on modelling instruments
On Thursday 11 April 2002 10:32 pm, Michael J McGonagle wrote: > Microsoft tried to do this with Kermit several years ago, the added a > single element to the standard and then they tried to patent the > documentation. The means that they used to distribute the package was as > a Windows Executable, thus tryying to protect "their" work. Someone had > dearchived the files and posted them on SlashDot. Microsoft appearently > tried to get them to remove the documents, but seeing as how they were > things that were pretty much in public usage (I don't know if Kermit was > in the Public Domain or not). That was Kerberos, which is under an MIT X-style license. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Delay line filtering (Was:Re: [linux-audio-dev] Still I cannot understand why...)
On Wednesday 19 December 2001 08:39 pm, Paul Davis wrote: > >Just curious, but could somebody explain *how* delay lines can be used > >implement EQ? I have a strong maths background, but no DSP experience if > >that helps. > i'm not a dsp programmer, but its really quite simple. if you > feedback with a delay of just 1 sample, and attenutate both the > current and previous sample by 0.5: > the actual details are extremely hairy though - there is a lot of > sophisticated math that goes into really good filter design, plus a > lot of subjective, non-double blind tested "opinion" :) In short: Z transforms are your friend. Once I grasped what the Z transform did for you in control systems theory, I immediately realized that filtering is a natural for Z transform math. But, in a nutshell: Delaying a set time and adding back to the original produces a 'comb' filter. The amount of the delay and the depth of the readdition together produce various degrees of filtering. Notch filters are easiest with delays -- delay one half cycle at the notch and add back one hundred percent. You get a rather tight notch. Along with other neat effects. :-) Like the peak at twice the notch frequency :-) And the secondary notch at thrice the notch frequency. Even multiples peak, odd multiples notch -- thus a comb filter. Comb filters are used rather nicely in chroma/luma separation in Never The Same Color video. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Re: [linux-audio-dev] So, what to do about it? (was: Still I cannotunderstand why...)
On Wednesday 19 December 2001 10:21 am, Juhana Sadeharju wrote: > >Been there; done that; have no desire to do it again. Resampled 48khz to > >44.1 khz sounds worse to my ears than the D/A->A/D converted signal. > [ ... ] > >IMHO, 88.2 sounds better than 96, if the result is going on Red Book CD. > So, we need a good resampler plug-in too to avoid above problems. Why even bother sampling at 48k in the first place if you are going to 44.1k? Now, I can fully understand the need for oversampled (88.2 and 96) tracks for mixdown use, but the math is pretty straightforward on showing that you are highly likely to get problems resampling from 48k to 44.1k. No filter is a perfect brickwall -- and you are going to have to have a tight anit-aliasing filter ahead of the resample. The tighter the filter, the more likely you will have problems with group delay and phasing around the cutoff knee. As an AM broadcaste engineer, I know a little about tight filters: the NRSC-1 filter is a bear, and is coupled with substantial preemphasis at it's knee. The group delay is audible, if you know what to listen for. It's a good thing most AM radios are narrowband, or that 'grunge' at 11khz would drive listeners batty. Although FM swish is, to me, much worse -- but my ears' high end response is more sensitive than most. If the filter isn't tight enough, you lose response below 22.05khz because of it. The distortion I have heard on resampled cuts is aliasing distortion, and is very distinctive in nature. Sounds much like FM multipath 'swish'. But a good resampler plugin would be a very good thing, with multiple antialias filter settings available. With 88.2, you simply average adjacent samples to get reasonable resampling; 96 isn't so easy. There is, of course, more than one meaning of average here -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Re: [linux-audio-dev] So, what to do about it? (was: Still I cannotunderstand why...)
On Tuesday 18 December 2001 11:14 am, David Gerard Matthews Jr. wrote: > dave willis wrote: > > ??? dats are 48000, and cds are 44100. doesn't some sort of resampling > > need to occur here? > Every pro DAT I've ever used has had the option to run at 44100, an > option I always to take advantage of to avoid resampling or multiple > D/A/D conversions. (BTW, unless you've got really good resampling > software/hardware, a D/A/D convsersion will often sound better than a > resample.) Amen. Been there; done that; have no desire to do it again. Resampled 48khz to 44.1 khz sounds worse to my ears than the D/A->A/D converted signal. But, I have always used Panasonic SV3700's, which work very well for 44.1khz rates. I currently am able to do S/PDIF with an older SV3200 chassis (and an SV3700 transport in it -- reverse of my normal!) into my Layla. Too bad Echo has been brain-dead about Linux drivers. I always run the sample clocks at an integer multiple of 44.1khz. IMHO, 88.2 sounds better than 96, if the result is going on Red Book CD. Run an analysis.. :-) -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Re: [linux-audio-dev] So, what to do about it? (was: Still I cannot understand why...)
On Saturday 15 December 2001 11:31 pm, Paul Davis wrote: > >Even the Alesis MasterLink buffers to disk first. Can you say 'Buffer > >Underrun"? Real-time burning is hard to do right, without a faster-than > >real-time buffered source. Of course, BURN-Proof helps. > sorry, but this is not true. go and get a tascam dedicated cdrw > unit. it works 100% of the time, perfectly, with a s/pdif real time > input. at least, the one i have access to does. it can only do "audio > time" burning, but given the dedicated nature of the beast, thats > ok. i very much doubt that its internal mechanism is significantly > different than the one in my yamaha computer-mounted burner. Pro level equipment (such as that first Marantz burner) certainly is a little different from consumer grade stuff. Mechanism is but half the battle -- the Panasonic SV3700 and ill-fated SV3200, for example, had identical mechanisms, but substantially different electronics. In fact, the SV3200 was buyable for less than the price of three shop visits for an SV3700 -- I swapped many a 3200 mechanism into a 3700. The 3200 had crippled S/PDIF, but the 3700 had AES/EBU. I had nine 3700's in constant use; and never did get any satisfaction from the service centers. Broken machines sent for service were returned broken -- and SV3200's went on sale. So I bought a dozen, swapped mechanisms, and dumpstered the carcases and the old 3700 mechanisms. > the technique to implement this is very simple, and even cdrecord does > it: you just buffer N seconds of the real time source before you start > the burn. And hope that your computer doesn't have a latency 'burp' lasting longer than the buffer. However, I'll concede the point that this is, indeed, the way to do it. A large FIFO works wonders. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Re: [linux-audio-dev] Still I cannot understand why...
On Friday 14 December 2001 09:02 am, Bill Schottstaedt wrote: > > > yes. But isn't 16 tracks a sign that something else is wrong? > > Can you elaborate? > No, sorry, I'm allergic to this kind of discourse and regret I > opened my big mouth. While I understand your reticence in this area, I personally would like to see an elaboration on this subject from one as experienced as you are, Bill. I know I could learn something. Please reconsider. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Re: [linux-audio-dev] Still I cannot understand why...
On Friday 14 December 2001 04:45 am, Alexander Ehlert wrote: > > audio current limitations log," right? :). You have said it the best: > > Linux overall, is acutely suffering from lack of coherent documentation, > Every programmer should write the documentation himself as he understands > what is going on, that is actually what we do in the GLAME project. You need a good technical writer to write good documentation. Typically, the programmers are too close to the code to write good end-user docs. There, are, of course, good programmers who are also good technical writers; but they are the exception, not the rule. Although the GLAME docs are better than most. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Re: [linux-audio-dev] Gibson develops audio over ethernet protocol
On Tuesday 04 December 2001 03:42 pm, DAVID G MATTHEWS wrote: > I just saw this on slashdot (and it actually looks interesting/useful): > http://www.techtv.com/news/culture/story/0,24195,3363342,00.html > 64 channels on cat5! Ethernet ports on a strat! AHEM. Les Paul, maybe, but not a Strat *duck* -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Re: [linux-audio-dev] multitrack and editor separate?
On Sunday 28 October 2001 12:47 pm, you wrote: > >audio track file -- but that's a different gripe) I would be in radio > >production heaven. > Good. Pack your bags. Ardour will take you there in a month or two. Oh, almost forgot: I also do long-form editing. The ability to handle a 1GB audo clip is also nice. :-) I guess I need to explain that one. We get programs here on CD that we rip to HD all the time. The problem is that our time slot for one the programs in question is longer than the programs they send -- by a factor of four. So we merge four programs into one, with our own lockout at the end (and we have the producer's permission, too). Then there's the one program that we overlay the promo halfway through the program (again, with permission) with our own PSA or promo instead of the producer's. Everything is automated, and off the HD here -- and CEP has made it all possible. I know a 'do-it-all' program is not necessarily desirable, but The one other common editing task I do is remastering of live LP vinyl. I use CEP to do the recording, normalize, process, denoise, depop, etc. I then pull over a neat hack called CDWAV that does the track splitting, on CD block boundaries, so that I can then burn DAO and retain the continuous 'live album' flow. I'm not expecting ardour to do all of this (although it would be nice) -- but I have yet to find a program even remotely like CDWAV under Linux. Know anyone developing such a beast? :-) -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Re: [linux-audio-dev] multitrack and editor separate?
On Sunday 28 October 2001 12:47 pm, you wrote: > >Again, if I could do transparent region editing in the CEP multitrack > > mode, with undo stacks allocated per-region, (working on a copy of the > > original > why per-region? what difference does that make? this is *important* to > me **right now** ... I would like to undo per region so that-- suppose I have two regions, A and B. Region A, to oversimplify, needs filtering to some extent, and region B needs compression, amongst other things. Time compression, maybe, to beat-sync the regions. Now, I slide the regions to where I need alignment, and apply the time-compression to region B. Then I apply my filter to region A. I then apply compression to B, then realize that I've overdone the filtering on A. I want to undo the filter while leaving the compression (and timebase shift) in place. Thus, each region ideally should have independent undo stacks. > >audio track file -- but that's a different gripe) I would be in radio > >production heaven. > Good. Pack your bags. Ardour will take you there in a month or two. Hmmm. There was something about ardour I didn't like, but I forget what it was right off (access website) Oh, yeah -- Red Hat's broken compiler issue. I use RH 7.2, and have for some time (beta tester here). 7.2 ships the gcc that doesn't exist (2.96-98). Any experience with that? What about the Official GCC 3.0 (which RHL 7.2 includes)? Also, as RPM maintainer for the PostgreSQL Global Development Group, I am used to difficult build procedures, but, pardon the pun, this one is ardourous And I make it policy to install from RPM whenever possible so that security updates are more easily accomplished -- especially on my intranet and internet servers for WGCR, where I may not be the one doing the updates (due to sickness or whatnot). For that matter, I can even do ardour RPM's, along with all the dependencies, at some point, when I get time to do so. Other than that, ardour is getting closer, from what I've read, to what I need. Now if ALSA only did Layla, which I have... -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Re: [linux-audio-dev] multitrack and editor separate?
On Friday 26 October 2001 09:23 pm, you wrote: > Or, more > >succinctly, multitrack recording and waveform/sample editing should not be > >considered separate tasks, > i don't have your experience, but i don't agree with you here. the > reason is subtle, but i find it compelling. > when working with multitrack recordings, what one is often doing is > manipulating semantically meaningful chunks of audio so that they are > correctly aligned with each, have appropriate gain and other FX > applied, and are sent to the appropriate outputs. > these tasks have little if anything to do with the process of editing > a waveform. you can make them both possible via the same GUI, or you A well-reasoned reply. However, you hit the nail on the head when you say '...have appropriate gain and other FX applied' -- in my experience, determining the appropriate FX levels and gains, etc, involves lots of test-mixes -- which, at least, CEP will do a real-time monitor mixdown in multitrack mode. Audio editing, as I am sure you are aware :-) is not a WYSIWYG or even WYHIWYG enviroment, as what looks like something that will sound good won't necessarily really sound good. And an edit/FX/adjustment on one 'clip/region/block' might sound very good or even great when listened to in single-track edit mode, and sound like junk in the context of the mix. Again, if I could do transparent region editing in the CEP multitrack mode, with undo stacks allocated per-region, (working on a copy of the original audio track file -- but that's a different gripe) I would be in radio production heaven. Fifty or more percent of my time is spent switching between editor mode and multitrack mode. What I want is a 'multitrack EDITOR' -- not a multitrack recorder with a halfway integrated editor accessed by a 'mode' or even a separate window. The fewer distractions to my editing (which is art) with the mechanics of doing the work the smoother the art works. Which is one reason many radio production rooms are still using analog multitrack tape, or something like an ADAT. The mechanics doesn't get in the way, even though digital editors are much more flexible. Again, I just want the capability to access the edit tools and FX inside the multitrack view. It's about user efficiency. As an example, I did a radio spot once that involved 16 audio clips, to be overlaid and voice-tracked with a promo, running a total length of 60 seconds. The first constraint was 60 seconds -- the second constraint is the pyschoacoustics of radio promo work that any individual clip in the mix shouldn't hog the sound. And my talent's voice hogged the sound, badly. Heavy sibilance and seriously punched 'p's' made the mix difficult -- I needed to hear the effect of sibilance filtering and compression concurrently with the bed of the mix in order to determine the right filter settings and the right compression knee. To compound the problem, I found that the amount of compression needed to be adjusted depending upon what the bed content was at any given instant. Had I had the editing controls for compression and filter available concurrent to the mix monitor, it wouldn't have taken long to find the magic points -- and a macro recorder to track adjustments I made to settings that could later be edited like the envelope and pan can be edited in CEP would have made this a moderately difficult mix. As it was, it took entirely too long to make the mix right. ProTools is pretty close to what I need, but not there yet. CEP is what I have, though. But I've rambled long enough. I just know that integrated effects editing inside the multitrack view in real time would be a significant feature for radio spot production. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Re: [linux-audio-dev] multitrack and editor separate?
On Tuesday 23 October 2001 10:11 pm, Paul Davis wrote: > >for this reason the ABC in my country, and several universities are > >replacing other professional editing/multitrack packages with Cool-Edit > >Pro..it is testimony that there is a wide demand for an editor and > >multitracker to be put together in an intuitive relation. > the relationship, as you noted, has more to do with "1 click away" > than it does with anything else. You know, I've used CEP here in production for this radio station for quite some time, and while the _capability_ to do the multitrack is great, and it works in practice, I would much rather have a setup where, like in koffice, when you go to edit the wave represented by the block you don't get transported to the single-track mode (unless you _want_ it that way) -- I would love for the multitracker to stay up while doing editing tasks on the individual wave blocks, with a 'frame' around the sound block you are working with. Work with the kparts-implemented koffice for just a little while -- embed a spreadsheet inside a kword document that also contains kontour or kivio frames -- and you will maybe see what I am talking about. A unified interface between the multitracker and the editor would be more than nice, too. After all, this _is_ the way analog multitrack on tape works -- patch the effect in on any track while working with all tracks. Most DAW setups allow similar things to be done -- so that you can hear the effect in the context of the mix, rather than the context of the track -- preferably in real-time. And that is my biggest gripe with CEP -- effects are done per track, and it is time-consuming to fathom the effect's effect on the total mix without quite alot of switching between the multitrack mode and the single track mode. When I can get my production lady to use a linux tool to do her daily multitrack jobs (which always involve compression, normalization, and basic EQ) then I will know that the state of the art for Linux sound is suitable for professional work in real-world environments. She took to CEP like a fish to water, FWIW. But my main point is this -- out in the radio world, for one, a sound editor and a multitracker are not necessarily different, and it would be more than nice to have an integrated 'arbitrary number of tracks EDITOR' that allows the sort of flexibility for multitrack compositions that desktop publishing systems have allowed for some time in the printing world. Or, more succinctly, multitrack recording and waveform/sample editing should not be considered separate tasks, in my twelve-year radio experience (ten of which have been with hard-drive PC-based automation systems). I look forward to the next O'Reilly network article on Snd, and on the continuing development of ardour. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
