"Frank Smith" <[EMAIL PROTECTED]>
Nice point and this is the strength of OS. the problems are addressed
far quicker than in Prop' software.
Yes, that's good. Microsoft doesn't give a hoot about professional
audio. We can actually tweak the OS, and Wine, to improve performance of
our specific
Lee Revell wrote:
However I didn't realize that you were using 2.4. 2.6 with the -rt
patches should definitely give better latency than Windows. In fact
it's capable of uselessly low latencies like 0.66ms on some hardware,
which is exactly the kind of thing the marketing guys love ;-)
We have
On Tue, 2007-01-30 at 21:05 +, Bob Ham wrote:
Further to that, something constructive: perhaps you could try telling
your customers why *you* chose linux, rather than trying to find reasons
to tell them *they* should.
My reasons, from back in about 2000, were "cost" and "interesting".
First
Stéphane Letz wrote:
You'll probably first have to decide which Windows version you're
comparing since Vista is supposed to be better than XP:
See:
http://createdigitalmusic.com/2007/01/19/vista-for-music-pro-audio-exclusive-under-the-hood-with-cakewalks-cto/
Thanks for the link. There sure
Can anyone suggest ways to compare audio/midi performance between Linux
and Windows that (1) are relevant to non-technical musicians and (2)
make Linux compare favorably?
Not things like "I just don't like Windows" or software feature
comparisons or the politics of open vs. closed source, but rat
On Thu, 2006-06-15 at 13:59 -0400, Paul Davis wrote:
> On Thu, 2006-06-15 at 10:49 -0700, Michael Ost wrote:
> > As we looked over the Jack docs, it seems like a natural for supporting
> > this kind of architecture. We would break out our VST support into a
> > separate app an
We are considering re-architecting our VST host in Receptor to run each
plugin in a separate process and connecting the processes with Jack. How
much extra overhead can we expect?
Receptor is basically a PC running our VST host. That's the only audio
app that is running. Currently all the VSTs run
.. mo
===
Michael Ost, Software Architect
Muse Research, Inc.
[EMAIL PROTECTED]
u want. They have no business
interest in changing the terms of VST. It isn't going to happen. It's
even difficult to get some of the key, larger plugin vendors to do
anything for Linux but we are chipping away at it.
- mo
===
Michael Ost, Software Architect
Muse Research, Inc.
[EMAIL PROTECTED]
> That sounds more sophisticated than what I did, but if it's not
> satisfactory (e.g. if you meant internet instead of ethernet), you can
> check out nmidi here: http://hans.fugal.net/src/nmidi-0.1.0.tar.gz
>
> It runs over tcp/ip, uses alsa, and was intended to be an MWPP (now
> called rtp-midi
d our marketing
guys want to show something at NAMM (that's January!). We might be able
to shake loose some shekels if there is some code that's close but needs
some tweaks.
Cheers... mo
===========
Michael Ost, Software Architect
Muse Research, Inc.
[EMAIL PROTECTED]
.
Cheers... mo
===========
Michael Ost, Software Architect
Muse Research, Inc.
[EMAIL PROTECTED]
On Tue, 2004-07-20 at 21:23, Dave Phillips wrote:
> A while ago I was mucking around with fonts to work with Finale under
> WINE. I don't know what I did, but now when I run a VST instrument the
> fonts have been replaced by little empty squares. If anyone can help
> I'll provide the details a
4.19 with glibc 2.3.2 which provides the
libpthread implementation we use to create threads.
Thanks in advance for any help... mo
=============
Michael Ost, Software Architect
Muse Research, Inc.
[EMAIL PROTECTED]
PS: moderator, I tried to remove a similar message sent from another
ema
On Thu, 2004-07-01 at 19:16, Paul Davis wrote:
> When the dust settles from the kernel and NPTL, 2.6 will be more
> viable. Right now, even though it works for some people, its not a
> generally viable platform for realtime audio.
What sort of issues are you seeing with NPTL and the 2.6 kernel? Ar
On Mon, 2004-06-21 at 23:20, Benno Senoner wrote:
> Since we want sample accurate midi triggering (which traditional MIDI
> over serial does not provide) we could do the following:
> a MIDI command is usally not longer than 3 bytes (let's forget abut
> sysex etc for now).
Perhaps sysex calls for
On Sat, 2004-06-12 at 17:01, Benno Senoner wrote:
> As said low latencies are cool so everyone tries to cheat and provide
> the per-fragment latencies in their settings/specs.
The MAudio driver setup card was downright dishonest. It said "latency:
128 samples", when actually latency was 256... th
ency. This despite the
128-sample-like latency claims in the MAudio driver setup dialog.
Anyway, more info for the curious... mo
On Thu, 2004-06-10 at 20:52, Michael Ost wrote:
> Hi.
>
> Does anyone out there know what the audio buffer size settings in
> Windows and MacOS really mean? I
be more with
the 256 setting in Windows.
But when we hooked a Windows system up to a scope it looked more like
the 128 sample setting was running 2x64 samples. So... we're confused.
Any pearls of wisdom out there? ... mo
===========
Michael Ost, Software Architect
M
On Thu, 2004-06-10 at 06:39, Dave Robillard wrote:
> On Thu, 2004-06-10 at 00:10, Michael Ost wrote:
> > On Wed, 2004-06-09 at 15:56, Dave Robillard wrote:
> > > I don't think I could possibly care less who uses 'linux audio'. I
> > > don't really t
On Wed, 2004-06-09 at 15:56, Dave Robillard wrote:
> I don't think I could possibly care less who uses 'linux audio'. I
> don't really think anyone else here should either - we should be aiming
> to build the best system possible, period. Not saying "look! popular
> software the people pay money
On Thu, 2004-06-03 at 00:34, Florian Schirmer wrote:
> Both preempt and ll are known to cause deadlocks on 2.4. If you want a rock
> solid system i recommend to go either with vanilla 2.4 or even better 2.6.
Thanks, Florian. What do you mean by 'vanilla' 2.4? Straight from
kernel.org? Ours does co
On Wed, 2004-06-02 at 14:26, Roger Larsson wrote:
> > We found that a nasty system crash was fixed by turning off preemption.
> > The crash would happen fairly reliably by switching between virtual
> > terminals a number of times. It locked up the system hard. So hard that
> > we can't really find
On Wed, 2004-06-02 at 13:41, Paul Davis wrote:
> completely stuck system and debugging it will be a work of pure
> machocism.
Great word! Is that macho + masochism? We'll give c+a+sysrq a try. Thanks... mo
reemption off.
Does anyone have some suggestions about what differences to expect and
what we might have a closer look at?
Also, we are newbies about reporting this kind of crash. Any clues about
where to report it or ask about it?
Thanks for any help... mo
=======
M
On Mon, 2004-04-19 at 14:42, Tim Hockin wrote:
> On Mon, Apr 19, 2004 at 05:29:00PM -0400, Dave Robillard wrote:
> > Should we maybe organize a letter-writing campaign or something like
> > that to attempt to convince Steinberg to make VST free?
>
> My understanding was that they would do it, exce
On Tue, 2004-04-20 at 09:04, [EMAIL PROTECTED] wrote:
> On Mon, Apr 19, 2004 at 07:12:00PM -0700, Michael Ost wrote:
> > Our Wine based VST hosting app is doing much better with very recent
> > Wine's: we are happy with the April 4th build. Most of the compatibility
>
Our Wine based VST hosting app is doing much better with very recent
Wine's: we are happy with the April 4th build. Most of the compatibility
issues are with GUIs.
Also if you're using threading, they recommend a not-too-recent 2.3.2
glibc to help with threading issues. We are using 2.3.2-4.80.8 a
Thanks to the list for all the helpful replies. I am working on
implementing them.
- mo
As I nervously enter the fray... I work for Muse Research. And yes we
are using Linux. But no we aren't going to tell customers about it in
any obvious way. Most of them don't care, and would indeed be confused
by that piece of information.
We have a team with good knowledge of this market (forme
Our Menlo Park, CA based startup is looking for someone with strong Wine
skills to help us support VST plugins in a Wine environment. Plugin
compatibility issues need to be tracked down and solved, either by
patching Wine or our hosting environment.
Deep experience in Wine configuration and develo
un
it with CONFIG_PREEMPT on and see what happens?
Cheers...
=======
Michael Ost, Software Architect
Muse Research, Inc.
[EMAIL PROTECTED] mo
brings up
bazillions of links for online wine merchants.
How about you rid the world of OMCA (one more cryptic acronym) and call
it Linux Audio Kit or something like that?
I'll go back to my Budweiser and reruns of America's Funniest Home
Videos now... %)
- mo
==
Thanks for the "debugging". We are looking into it and will correct it.
- mo
On Mon, 2003-12-01 at 13:02, Tim Orford wrote:
> > Maybe I can answer that, since I work for Muse. I just grep'd the web
> > pages and didn't find 'license free'. Where did you see that?
> >
> > I am a bit mystified by
Maybe I can answer that, since I work for Muse. I just grep'd the web
pages and didn't find 'license free'. Where did you see that?
I am a bit mystified by that statement and would like to look into it.
Some licenses I can think of off hand that we are using are GPL, LGPL,
FreeBSD, and the Steinb
The coolest thing about OSS for me was when I finally realized that all
I had to do was open a file (/dev/dsp), read from it and write to it to
capture sound and play it back. I made a stupid little 'feedback'
application in about 10 lines of code.
Figuring that out took a while. I just knew it ha
An interesting historical sidenote on this came from of our programmers,
who was deep in the BeOS. He told me that their timeslice was 3 msecs
once everyone had 500 MHz machines. It was down to 1 msec for the never
released R6 version... back in, what 1999? 2000?
Open source is a bit slower to mov
My company is looking for a Systems Programmer to (among other things)
maintain our Linux running on an embedded music product. If you/someone
you know are/is interested and live/s in the San Francisco Bay area,
please let me know.
Cheers... mo
PS: I couldn't tell from the list guidelines whethe
On Mon, 2003-09-15 at 04:28, Paul Davis wrote:
> a few corrections:
>
> >Well, the main differences between the OSS-Layer and ALSA are:
> >1.) alsa is the new driver in linux kernel >= 2.6.X
> >2.) oss-layers need ioctl() - calls to manage/configure sound devices (and ioctl()
> >calls
> >are jus
I found some definitions in boost/detail/atomic_count.hpp, with gcc,
win32, etc. flavors. I still haven't figured out how they are used! But
at least there is source to play with.
- mo
On Mon, 2003-09-08 at 22:13, Jack O'Quin wrote:
> Michael Ost <[EMAIL PROTECTED]> writes:
I know this message is ancient, but if you are still looking for atomic
primitives I just ran across some in the boost code base. I can't figure
out how to use them (!) but perhaps you can? Boost, if you don't know,
seems to be kind of a proving ground for the C++ working group. Lots of
libraries w
for any help mo
===
Michael Ost, Software Architect
Muse Research, Inc.
[EMAIL PROTECTED]
On Thu, 2003-09-04 at 10:33, Mark Rages wrote:
> On Thu, Sep 04, 2003 at 07:37:31AM -0700, Greg Reddin wrote:
> > > (badly enough there are still too many audi
Is there SCHED_FIFO style priority available in the new kernel, with its
new threading model? Realtime audio processing doesn't share the CPU
very well. The ear can pick out even the slightest glitches or delays.
So for Linux to be usable for audio applications or embedded audio
devices it needs so
, top priority scheduling.
There was the start of a thread on this on this mailing list about a
month ago, but I didn't see many follow up messages. Perhaps some of you
who are trying to use the new kernel have some information to share.
Thanks... mo
=======
M
44 matches
Mail list logo
