[linux-audio-dev] Reliability of SPDIF sync w/ onboard audio?
Ok, given a pair of commodity Linux PC's with cheapo onboard audio codecs capable of SPDIF input and output, assuming I sent identical input signals into both machines and didn't perform any processing in the middle, could I reasonably expect the output signals to be synchronized, or should I expect unpleasant phasing / delay effects when listening to both channels simultaneously as a result of the inherently flakey consumer-grade codecs? The above is a simplification that should address my major concern... The goal here is to use a pair of redundant, inexpensive machines for live midi-controlled (headless) playback where the physical security of the location is lax enough that using my laptop + hammerfall would be too risky, not to mention 35 channels worth of overkill. Ideally these two machines would accept some sort of SPDIF format square-wave from some low power clock logic on their inputs and play identical, pre-cached wav files on their outputs when they recieve simultaneous "go" signals from the MIDI playback desk. Any experiences or opinions are welcome... Thanks, - Mike Piantedosi
Re: [linux-audio-dev] Request to audio related LiveCD packagers
On Tue, Apr 27, 2004 at 08:13:36AM -0400, Paul Davis wrote: > debian is about to exclude all "non-free" material from their > distributions. this includes firmware, documentation et al. If you're referring to the recent vote, the point was to make sure the debian system didn't *require* non-free software to function. They're still keeping 'non-free' and 'contib' around. They say that these two areas are 'no longer part of the distribution', but they'll still support them as part of the archive and via their bug-tracking system. So, in order to get the firmware, you'll probably just have to do something like 'apt-get install alsa-nonfree'. Cheers, - Mike
Re: [linux-audio-dev]converting old pc hardware to a live musicperformance toy
> > Yeah, there are plenty of these out there. I know off the top of my > > head that Roland, Yamaha, and Behringer make 'em. I've got a Behringer. > I checked on the Behringer website, and the only MIDI controller stuff I It's probably someplace nonsensical, it's called an "FCB1010 MIDI Foot Controller", and you can find it on most sites that sell MIDI synth gear. Hope that helps. Lates, - Mike
Re: [linux-audio-dev]converting old pc hardware to a live music performance toy
> as a knob. I have yet to buy the controller so I'm open to suggestions. It Yeah, there are plenty of these out there. I know off the top of my head that Roland, Yamaha, and Behringer make 'em. I've got a Behringer. It's cheaper, uses a standard AC power cord, so no wall wart, and has an extra built in variable pedal. The only issue is that even though the casing is made out of metal, the pedals themselves are made out of plastic, tough plastic, but still... it makes me nervous sometimes. > would work with USB or MIDI, or better both. If MIDI, then I also need a Hrm, can't think of any USB pedals... > MIDI input card. Ultimately I would like the software to be as compact as The most practical midi I/O interfaces I've seen probably come in the form of breakout boxes. I've seen them in USB, Serial and Parallel versions. You can also get a cable that breaks out the two midi ports (in and out) and a joystick port without the midi pins from a standard PC joystick port. The only thing you've got to watch out for here is that newer 'soundchip' based 'cards' (this includes most motherboard audio) or standalone gameport interfaces won't have midi. If you've got an ISA interface though (don't know how 'old' your hardware is) and an old sound blaster 16 or somesuch kicking around, those usually have rather decent midi capabilities. Not only that, but you can usually find them pretty cheap, or in some 486 somebody threw in the trash, and they're supported by just about everything ever made (though the sound output is noiser than a tractor trailer truck). Well, I hope this helps! Cheers, - Mike
Re: [linux-audio-dev] Windowmanager (Re: Alternative Sequencer User Interface)
On Tue, Apr 13, 2004 at 06:14:37PM +0200, Thorsten Wilms wrote: > On Tue, Apr 13, 2004 at 05:01:39PM +0200, Tim Orford wrote: > > > > i agree that this is fairly essential functionality. > > > > but i think there is an argument that windows should be managed by > > the window manager:-) Actually, something that's kinda nice is that I think in the opera web browser you can configure it to use either one monolithic window for everything (the original behavior), or use the wm for windowing. I think it's nice to give the user these choices. > Oh, and WMs usualy don't manage loading/saving setups (Screens > in Blender). And you can't change which app is displayed > in a window ... There are some programs that "remember" where all your windows were, but if you shut down the app and start it back up (yay for dev software!), you're pretty much out of luck. > I think Blender's style is much more clear (where sections start/end). > Also note that it provides no means to undock anything. A simplifying > limitation, which has not shown to be a problem. > And the KDE and Gnome docking systems will be designed to work inside > the scope of _one_ app. I agree with being able to completely fullscreen one little bit for a short period of time to make a minor tweak. I prefer the blender interface to many others I've used (Lightwave, at least a few years ago, gave me a headache with its very inflexible 2x2 matix). > > the screenshot you refer to shows separate windows running under the Ion > > window manager which provides most if not all the features you mentioned. > > Perhaps having these services provided by the wm makes certain things harder, > > but it seems to be the most versatile; all apps benefit, and the user > > has more choice and more consistency. > > Ion ... if I remember corectly it can't handle dialog windows gracefuly!? > However, it's certainly not for every one, and I'm disappointed, because > this means your app has lots of little windows Hrm, I guess the only thing that bothers me about the Ion approach, is how to get the wm to organize the windows in a useful manner on the screen (similar sorts of windows next to each other). In order to get these sorts of things working in one big monolithic window, everything is taken care of by the main program, but when a window manager is involved, I'm concerned that too much effort on the part of the user will be expended trying to get the two to play nice together and in the end there will be a whole bunch of little config file hacks that would be completely unneccessary if the wm and the app were able to communicate better. Of course, it would be nice if things just worked like this so you could have a whole bunch of useful windows from different programs on the same screen in a unified fasion... - Mike
Re: MID vs MOD - WAS : Re: [linux-audio-dev] ".mid" files playing in Linux games
On Mon, Feb 02, 2004 at 01:23:51PM -0500, Dominic Genest wrote: > > I think perhaps a better terminology might be "ideation" and > > "realization". But again, ideation has nothing to do with a file format. > > No matter which word we choose, the choice of a file format highly influences > the level of abstraction of the idea the file expresses. > > Think about a webpage. Imagine your favorite website as a single big ".GIF" > image map instead of an HTML structure. Well it could work and probably even I think that an 8-bit 22kHz "flac" would have greater similarity to a "gif" of a site (low bit depth, lossless compression), while a "mod" would have greater similarity to a tarball of the "html" and "png" files that make up the site. I'd say that the "mid" representation is more akin to distributing an html file by itself but with properly descriptive alt tags letting you know what you ought to see in the empty spots so you may fill them in as necessary. Of course if you give this to a motivated graphic designer, the site may well look better than the version you dreamed up... :) Personally, I write rather experimental music, and some of the sounds and effects necessary for certain segments aren't easy to replicate on a stranger's equipment, so I often prefer to exercise the extra control. If I just wrote something for an equal tempered solo piano, I suppose a ".mid" would suffice, though I would certainly recommend installing some quality soundfonts ;P Cheers, 784 - Michael C. Piantedosi - [EMAIL PROTECTED]
Re: MID vs MOD - WAS : Re: [linux-audio-dev] ".mid" files playing in Linux games
Well, from the initial reading, it sounded like the author of this game wanted to embed a software synthesizer into his game to play the tunes. In that case I figured that unless he could find some really nice engine for producing realistic piano tunes, libmikmod or timidity (with bundled samples) would be fine and take less processing power than a physical modelling software synthesizer or something. It didn't sound to me like he was intending on using general MIDI (which gave me an extrememly biased view of MIDI as a whole until I started collecting controllers and rack gear myself... ;P). Cheers, 784 - Michael C. Piantedosi - [EMAIL PROTECTED]
Re: [linux-audio-dev] ".mid" files playing in Linux games
On Fri, Jan 30, 2004 at 04:12:17PM -0600, RTaylor wrote: > The label "[EMAIL PROTECTED]" hathe been affixed to this message, > >On Wed, Jan 28, 2004 at 03:52:38PM -0500, Dominic Genest wrote: > > >> Mine are rather "piano only", classical-like, songs. Those usually sound > >> better with midi sequencers. > > > >I would have to completely disagree. It isn't that one is "better" than > >the other, they both have pluses and minuses. At a certain level, > > ...His songs, guy. I was just attempting to point out that the formats themselves do not constrain the ability of the composer to write music in one style or another. You could write a piece with an acceptable piano simulation in either format. What constrains the composer is the amount of support for "piano" sounds he could find related to these formats. If this was a commercial project, I could think of numerous commercial MIDI synths that have decent piano simulations, the problem is that I personally haven't heard any good piano simulations of the free software variety, and plugging in your own piano sounds is just as easy with a tracked song as with a MIDI song. Cheers, 784 - Michael C. Piantedosi - [EMAIL PROTECTED]
Re: [linux-audio-dev] ".mid" files playing in Linux games
On Wed, Jan 28, 2004 at 03:52:38PM -0500, Dominic Genest wrote: > Yes I am familiar with "mod" files which, more precisely, were born in the > Amiga world. Generally speaking, they're best at techno songs. > > Mine are rather "piano only", classical-like, songs. Those usually sound > better with midi sequencers. I would have to completely disagree. It isn't that one is "better" than the other, they both have pluses and minuses. At a certain level, however, you can achieve roughly the same overall efficiency. A properly coded software synthesizer is by all means more versatile and more likely to make things sound "natural", but on the other hand, this is only if your music (and the synthesizer) take proper advantage of MIDI's "expressive controls". The most important of which is velocity, I'd say. If you don't plan on using any velocity information, you can do the same thing with a good set of samples (~one per octave per instrument) and a tracker as you could with a MIDI synth that uses up around the same amount of system resources. You could also do this with timidity, but I kinda think a tracker would be more intuitive... I mean, timidity isn't exactly a synthesizer, it works pretty much like a tracker as far as I can tell. To find a true "synth" that runs with this much efficiency and sounds just as good as the tracked (or timidity) option, I think it would be easier to find the nice piano samples. Of course, if you're willing to shell out more system resources (mostly processing power) to make your velocity information truly "synthesize" the sounds in an expressive manner, that would certainly sound better. The thing that you (IMHO) want to figure out is if you can sacrifice that processing power and resources, and if a good synth like that even exists... which is why you're asking... but I just thought I'd toss out the tracker/timidity option as a truly viable alternative if you can't find something that sounds better at a reasonable resource level. Cheers, 784 - Michael C. Piantedosi - [EMAIL PROTECTED]
Re: [linux-audio-dev] question about time and compressed formats
On Fri, Nov 14, 2003 at 09:20:47AM -0500, Fred Gleason wrote: > On Thursday 13 November 2003 16:48, J_Zar wrote: > > > I' ve done some tests on a bunch of songs in different compressed > > formats - snip - > > different values for Ogg and Mp3? Ogg will be affected by bitrate? > > An MPEG frame always contains 1152 PCM frames, as per the standard. This is > true of Layers One, Two and Three. Thus, the time length of an MPEG frame > would be: > > l=1152/fs > > where > l = Length of frame in mS > fs = Sample rate in kHz > > Thus, for your example case, the calculated length would be: > > 1152/44.1 = 26.1 mS > > thus yielding good agreement with your measured results. > > I don't know how it is with Vorbis, but I'd suspect something similar. See: > > http://www.xiph.org/ FYI, from the vorbis docs: Vorbis provides none of its own framing, synchronization or protection against errors; it is solely a method of accepting input audio, dividing it into individual frames and compressing these frames into raw, unformatted 'packets'. The decoder then accepts these raw packets in sequence, decodes them, synthesizes audio frames from them, and reassembles the frames into a facsimile of the original audio stream. Vorbis is a free-form variable bit rate (VBR) codec and packets have no minimum size, maximum size, or fixed/expected size. Packets are designed that they may be truncated (or padded) and remain decodable; this is not to be considered an error condition and is used extensively in bitrate management in peeling. Both the transport mechanism and decoder must allow that a packet may be any size, or end before or after packet decode expects. Vorbis packets are thus intended to be used with a transport mechanism that provides free-form framing, sync, positioning and error correction in accordance with these design assumptions, such as Ogg (for file transport) or RTP (for network multicast). So, if I'm reading this correctly, the vorbis framesize is not fixed within the general spec, so you'd have to be prepared for all sorts of frame sizes. 784 - Michael C. Piantedosi - [EMAIL PROTECTED]
Re: [linux-audio-dev] Slashdot: linux-based music =?iso-8859-1?q?keyboard workstation?= released
> Speaking of which; I'd be really rather interested in a UI like that, > but as an extra interface for a normal computer based studio. Sort of > like a DAW terminal with a display and a custom control panel that I > can put right above my master keyboard, so I don't have to turn > around to, or reach for the computer all the time. Well, if you look back at my post a few back about my setup I tossed together, I haven't gotten around to this yet, but Doepfer also makes big slider boards and knob boxes and stuff that send midi signals, check these links out: http://www.doepfer.de/db.htm http://www.doepfer.de/pf.htm Once I run out of possiblities with the builtin knobs / sliders, footpedal combimations, etc, I was planning on getting some of these to mount on the frame that my laptop's currently bolted onto. 784 - Michael C. Piantedosi - [EMAIL PROTECTED]
Re: [linux-audio-dev] Slashdot: linux-based music keyboard workstation released
Well, just FYI, I got myself a laptop, Doepfer 88 hammer action controller keyboard (with fully configurable midi signals and response curves), a bunch of midi-footpedals, and and HDSP to plug into my laptop for around that same price ($5k) to use as a linux audio workstation. I also welded together a mounting rack that bolts to the back of my keyboard stand and holds all the other stuff quite well, really a rather integrated package and everything comes apart and packs up nicely as well. However, this keyboard thingy we're talking about also looks really sweet, heck, after tossing all my stuff togehter I was thinking how it would be cool if people (maybe even myself) were to make keyboards that were really just badass linux boxes on the inside to sell to people. I can certainly say that I'm glad it's been done, it's (IMHO) a really cool and useful hardware concept, and a very good way to showcase linux to the pro-audio world. 784 - Michael C. Piantedosi - [EMAIL PROTECTED]
Re: LADPA (was Re: [linux-audio-dev] emagic (logic) drops VST support under OS X)
On Wed, Sep 04, 2002 at 10:37:34AM +0100, Steve Harris wrote: > On Tue, Sep 03, 2002 at 11:26:04 +0200, Tim Goetze wrote: > > agree, that would be great. it doesn't solve problems like running > > for example both ardour (gtk) and muse (qt) under the same jackd > > though. > > Nope, like you said, that has to be solved by having them in seperate > processes. I think there is a need for an inprocess only host/plugin > system, like LADSPA, but more suphisticated though. > Before I go off ranting about the current state of audio guis, are you saying that clients with different gui toolkits can't connect to the same jack server? That seems kinda messed up to me... I feel like I'm misunderstanding. 784 - Michael C. Piantedosi - [EMAIL PROTECTED]
