Re: [linux-audio-dev] Moog VCF in SpiralSynthModular
Taybin Rutkin wrote: On Fri, 24 May 2002, Paul Davis wrote: LADSPA currently makes audio+control ports orthogonal to each other. i don't think there are any LADSPA hosts at this time that allow the user to connect the ports by hand ... Doesn't GLAME let you draw lines between LADSPA plugins? IIUC, glame only displays audio ports by default. controls are accessed via the prefs menu.
Re: [linux-audio-dev] LADSPA v1.1 Alternative Proposal
On Mon, May 27, 2002 at 02:21:04 +0200, Tim Goetze wrote: so what do you think about the actual proposal? (*DataLocation = default in connect_port) I don't think it gains anything over Richards original suggestion, does it? The problem is that it moves the definition of the defualt values away from the definition of the port's data. - Steve
[linux-audio-dev] Does someone knows about RTP ??
Hello, I'm working on a project about adding RTP audioports to jMax (http://www.ircam.fr/equipes/temps-reel/jmax/fr/index.php3), in order to be able to do real-time streaming over the net between instances of jMax. So, I am searching for people witch have try some RTP libraries because I have to choose one to include it on jMax. If someone have hints for me as this one have too much bug like..., this other one have many payload available etc... Thank you all Bye Nicolas
[linux-audio-dev] [ANN] New LADSPA filter from cookbook formulae
Hi, As suggested by Paul Davis in the Moog VCF thread, I implemented the biquad filters found in http://www.harmony-central.com/Computer/Programming/Audio-EQ-Cookbook.txt and a simple resonant lowpass by Paul Kellett as LADSPA plugins: ftp://ftp.suse.com/pub/people/mana/kalsatools-current/vcf-0.0.3.tar.bz2 Two .so files will be built: vcf.so has single audio input and output. vcf_cv_in.so has additional audio rate inputs for frequency-, resonance- and dBgain control. These ports need not be used by the host. In this case the host should init them with NULL. The plugin will interpret a NULL pointer as unused audio port. I updated my host AlsaModularSynth and added an example for the new filters (example_ladspa_vcf_cv_in.ams) ftp://ftp.suse.com/pub/people/mana/kalsatools-current/ams-1.2.0_pre5.tar.bz2 The lower and upper bounds of some control parameters may still need some refinement. Suggestions ? When playing with the filters, the spectrum analyzer KWaveView might be helpful. BTW KWaveView does not require KDE... Have fun ! Matthias -- Dr. Matthias Nagorni SuSE GmbH Deutschherrnstr. 15-19phone: +49 911 74053375 D - 90429 Nuernberg fax : +49 911 74053483
Re: [linux-audio-dev] Writing a driver for this card: your thoughts?
On Mon, May 27, 2002 at 10:48:28PM -0400, Lamar Owen wrote: 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. Just to try and put things in perspective, surely once you go beyond a certain level, signal-unrelated noise is one of the least important indications of sound quality? For me anyway. The quality of the noise is important also :-) 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. your requirements do seem to be rather different than a recording studio :-) 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. [] such insane amounts of compression as used by most radio stations are not usually related to 'quality' as understood by most poeple. 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. 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. sorry if i'm just being pedantic :-) cheers Tim Orford ok, back to trying to get Ardour compiled.(does that make me On-Topic now?)
Re: [linux-audio-dev] Does someone knows about RTP ??
Hi Nicolas, There are advantages to writing your own RTP library customized to the application -- sfront does this in its implementation of MWPP, the MIDI RTP packetization we're standardizing through the IETF. You can get a sense of the complexity involved in writing a custom RTP library, by looking as the sfront/src/lib/nsys/ directory in the latest sfront distribution: http://www.cs.berkeley.edu/~lazzaro/sa This implements both SIP and RTP, customized to sfront; most of the complexity is in the MIDI packetization payload, not the RTP header processing. Also, you might want to consider adding support for the MIDI RTP packetization as part of your project, if so see: http://www.ietf.org/internet-drafts/draft-ietf-avt-mwpp-midi-rtp-03.txt for the latest version, although you probably would want to join the IETF AVT working group mailing list: http://www.ietf.org/html.charters/avt-charter.html and track the changes in MWPP as it heads towards standardization ... - John Lazzaro -- Research Specialist -- CS Division -- EECS -- UC Berkeley lazzaro [at] cs [dot] berkeley [dot] edu www.cs.berkeley.edu/~lazzaro -
Re: [linux-audio-dev] Writing a driver for this card: your thoughts?
On Friday 24 May 2002 22:11, Paul Davis wrote: 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? Sounds like you've never heard one of these cards in action. The entire analog section is mu-metal shielded, and in terms of quality can stand with the best of the external designs. Personally, I define professional as that which meets a certain standard of quality in operation and features, which these cards certainly do. *How* that is achieved is really irrelevant. BTW, these cards work very well under Linux right now, using AudioScience's HPI interface. Cheers! |-| |Frederick F. Gleason, Jr.|WAVA Radio - 105 FM |Voice: 1-(703)-807-2266 | | Director of Engineering |1901 N. Moore Street| FAX: 1-(703)-807-2245 | | |Arlington, VA 22209 | Web: HTTP://www.wava.com| |-| | Some changes are so slow, you don't notice them.| | Others are so fast, they don't notice you. | | -- Anonymous | |-|
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 Tuesday 28 May 2002 16:19, Lamar Owen wrote: 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. Actually, I just heard an interesting rumor. One of the major broadcast transmitter manufacturers (the one with sales offices in Mason OH) is implementing their exciter for the new Ibiquity FM DAB system on an embedded Linux platform. This includes some very high end encoding technologies (like PAC/AAC). It'll be interesting indeed to see how this pans out. Cheers! |-| |Frederick F. Gleason, Jr.|WAVA Radio - 105 FM |Voice: 1-(703)-807-2266 | | Director of Engineering |1901 N. Moore Street| FAX: 1-(703)-807-2245 | | |Arlington, VA 22209 | Web: HTTP://www.wava.com| |-| |The real problem with hunting elephants is carrying the decoys. | | -- Anonymous| |-|
Re: [linux-audio-dev] Writing a driver for this card: your thoughts?
one question: could you do this for the unsophisticated audiophile with less Acronyms? What's all that: supply. Using a computer psu is going to severely limit what you are ^^^ = power supply unit? decoupling is done at the amplifier rails, along with 'sag' compensating caps ^^^ (with low ESR! Tantalum only, and preferably sintered slug) in the proper ^^^ ? electron spin resonance :)? But again, the hardware must be able to cancel out the enevitable RFI that is ^^^ thanks, tobias.
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?
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] LADSPA v1.1 Alternative Proposal
regarding the provision of default values in LADSPA, I totally support Tim's suggestion -- in fact, I reckon it is brilliant for reasons I'll outline below :) On Tue, May 28, 2002 at 04:25:21PM +0200, Tim Goetze wrote: Steve Harris wrote: On Mon, May 27, 2002 at 02:21:04 +0200, Tim Goetze wrote: so what do you think about the actual proposal? (*DataLocation = default in connect_port) I don't think it gains anything over Richards original suggestion, does it? The problem is that it moves the definition of the defualt values away from the definition of the port's data. agree. however i reckon it won't hurt too badly to have default values no sooner than when the plugin is instantiated. I think it's even more powerful this way because it lets a plugin calculate defaults programmatically, taking into account the instantiated sample rate and the state of the plugin. if we restricted ourselves to keeping the definition of default values near the definition of the port's data, we would restrict ourselves to static default mechanisms, such as simple default values or kludgy default boundaries. by making the defaults an outcome of connect_port() instead, we get a dynamic mechanism for free. Default frequencies can be related to the sample rate, etc. Going further (but still without breaking binary compatibility), we see that we are already allowed to call connect_port() multiple times, even between calls to run(); from ladspa.h: connect_port() may be called more than once for a plugin instance to allow the host to change the buffers that the plugin is reading or writing. These calls may be made before or after activate() or deactivate() calls. so, a very smart plugin could profile the data it is being fed via run() and then suggest a very relevant default value for a parameter on a subsequent call to connect_port(). So, now, default values can be related to the plugin's state and the kind of data being processed (eg. a suggested compression ratio for the kind of data that has been processed so far). All this requires is that a plugin suggest default values in the way Tim proposed: by setting *DataLocation before returning from connect_port(). It would still be perfectly valid for a host to ignore this, and it would still be perfectly valid for a plugin to not modify *DataLocation, so existing hosts and plugins should not be affected. the LADSPA_HINT_DEFAULT_* solution looks very awkward to me, and despite all the code it involves it isn't even capable of expressing any value from the valid range. i think it would even be better to break binary compatibility now than force ourselves to support a kludge like this (sorry, richard) in future versions of the API. it is better to admit that we cannot have a perfect solution without breaking binary compatibility, and thus should at least go for the simpler one, i think. totally agree -- Tim's solution doesn't break binary compatability, doesn't introduce any new symbols or macros and doesn't consume any bits out of the port hints; plus, it allows plugins to set defaults using any criteria they like. all it requires is additional (but backwards-compatible) behaviour for those plugins and hosts that care about default values, and that this behaviour be documented in ladspa.h. a suggested patch to ladspa.h, touching comments only, is attached :) Conrad. --- /usr/include/ladspa.h Wed Aug 8 20:21:03 2001 +++ ladspa.hWed May 29 14:08:46 2002 -352,14 +352,20 to be an array of LADSPA_Data for audio ports or a single LADSPA_Data value for control ports. Memory issues will be managed by the host. The plugin must read/write the data at these - locations every time run() or run_adding() is called and the data - present at the time of this connection call should not be - considered meaningful. + locations every time run() or run_adding() is called. + + The data present at the time of calling connect_port() should not + be considered meaningful. However a plugin may suggest a default + control value by setting this data before returning from + connect_port(). Thus a host that requires useful default values + for control inputs can get these by examining the data contents + immediately after a call to connect_port(). connect_port() may be called more than once for a plugin instance to allow the host to change the buffers that the plugin is - reading or writing. These calls may be made before or after - activate() or deactivate() calls. + reading or writing, or to request updated default control values. + These calls may be made before or after activate() or deactivate() + calls. connect_port() must be called at least once for each port before run() or run_adding() is called. When working with blocks of
[linux-audio-dev] unsubscribing
[OT] How do I unsubscribe to this mailing list? /Mikael
