hi,
anyone around who ran audio stuff on the xbox/linux yet ?
Forwarded message:
> From owner-music-dsp(a)shoko.calarts.edu Tue Nov 12 05:34:54 2002
> Date: Mon, 18 Nov 2002 12:22:30 +0800
> Subject: Re: [music-dsp] XBOX as an audio DSP?
> From: Stewart Greenhill <sgreenhill(a)iprimus.com.au>
> To: music-dsp(a)shoko.calarts.edu
>
> On Tuesday, November 12, 2002, at 11:38 AM, Russell Borogove wrote:
[irrelevant parts snipped]
.
.
>
> Ultimately, it may be possible to run Linux (for example) without
> modding the box. An anonymous donor has offered $US 200,000 towards the
> development of such a "fix" so presumably if it is technically possible
> it will be eventually done. Therefore, I guess one could eventually make
> a CD image that boots the OS _and_ the application without requiring
> mods or installs.
>
> But its really not an "unfinished" OS. Its just unix with X11 and ALSA.
> A single API targets both environments, so the extra work required to
> make an app run on the xbox may not be great.
>
> Personally, I doubt that I would pursue this route. However, it does
> give an interesting "mass market" for linux audio applications.
>
> Cheers,
> Stewart
>
>
> dupswapdrop -- the music-dsp mailing list and website: subscription info,
> FAQ, source code archive, list archive, book reviews, dsp links
> http://shoko.calarts.edu/musicdsp/
>
--
chris(a)lo-res.org Postmodernism is german romanticism with better
http://pilot.fm/ special effects. (Jeff Keuss / via ctheory.com)
> This is a bit off-topic, but did you use CoreAudio when porting to OSX?
yes -- the code is in Snd's (sndlib's) audio.c.
> You mean, there is now a Snd for OS-X? Wow, at work, I'll have to
> choose between Win-XP and OS-X in the near future, and this is a very
> important argument pro OS-X.
You've considerably brightened up my morning!
Don't worry David, I think we are wasting our precious time with these
talks (but it is interesting anyway :-) )
Regarding source and binary code:
Being or app opensource, we have the advantage that the source code
does not constitute a runnable application and this provides several
legal advantages.
Just to cite an example:
The freetype library http://www.freetype.org/ contains a bytecode
interpreter for font hinting on which Apple holds a patent.
But they can distribute the source because it is disabled in the default
Makefile. This makes me think that opensource software that might
contain "controversial" code can always be shipped in sourceform since
it is not the final product since only a "description of it".
(where the compiler turns this description into the final product).
back to coding .... (guess what ? :-) )
cheers,
Benno
David Burrows wrote:
> Send the source code to me and I will release it. Why? Because
> I believe what I said in the above paragraph is true. It is immoral to
> have software patents, not violate them. Especially ones as
> absurdly simple as this. How could they proove that you did not
> come up with the idea yourself? Whatever happened to innocent until
>proven guilty
--
http://linuxsampler.sourceforge.net
Building a professional grade software sampler for Linux.
Please help us designing and developing it.
Hi all,
I am currently writing an article talks (among other things) about Linux
as one of the currently viable pro-quality-audio platforms. I am trying
to get a hold of some specs in relation to JACK, so I'd appreciate it if
you can give me a quick rundown of the following information:
All of these pertain to ALSA or JACK:
1.) What is the lowest stable achievable latency with the current stable
(2.4) branch of the kernel (with ll and preempt patches) using Alsa on a
modern system (i.e. at least 1GHz machine)?
2.) What is the lowest stable achievable latency utilizing
app<--->jack<--->audio hw
kind of setup on a modern system (i.e. at least 1GHz machine) with the
current stable (2.4) branch of the kernel (with ll and preempt patches)
using Alsa?
I would appreciate it if you restrict your responses to simple numbers
(i.e.
1) 1.6ms
2) 2ms
)
since I do not have the time to have a discussion on this matter, but am
rather looking for a quick list of testimonials in regards to the two
given questions.
Thank you for your help! Sincerely,
Ivica Ico Bukvic, composer, multimedia sculptor,
programmer, webmaster & computer consultant
http://meowing.ccm.uc.edu/~ico/
============================
"To be is to do" - Socrates
"To do is to be" - Sartre
"Do be do be do" - Sinatra
"I am" - God
> it's much easier to port from Un*x to OSX
> than vice versa. A far greater number of
> *nix libraries have been ported from the *nix world to OSX than the
> other way around. You can even run X windows
> on OSX
I think "OroboroSX", or some such name, is an X window manager
for OSX that makes X apps fit in with Mac apps so it's not
obvious which style is running. Gtk and Motif have been ported,
so the GUI is not a big issue. The audio side is still primitive,
but easy to use. Porting Snd took a few days, mostly spent
chasing down dumb things like the -framework loader switch.
I'd say it took about the same effort overall as porting
to the Sun.
Paul what you described is very unfortunate. Although I have not had
time to perform any tests lately, I always had the bad feeling that the
out-of-process model would cost us some performance because the kernel
would screw us in some way.
As said, two years ago I was able to achieve 2.1msec latency with the
LinuxSampler proof-of-concept code and I think for many low-latency
fetishists (a drummer playing a midi drumkit) it would be hard to give
up these excellent response times especially since we are talking about
a software implementation of a MIDI instrument that ideally should as be
as good as the hardware counterparts in terms of playability.
Regarding the sampler we are currently solving other basic design
problems so for now I think we can let this issue aside since we will
probably perform the first tests with direct ALSA/OSS output and
standard out-of-process JACK mode (in the latter case not expecting to
get extremely low latencies), but in order to get latencies at par with
ALSA , when using JACK the in-process model is as you said probably
mandatory. (and according to Steve Harris JACK would need some
extensions to handle the loading of these in-process jack "plugins"
at run time).
For now we will probably test the extremely low latency cases using
direct audio output otherwise it would be hard to isolate timing
problems.
(Was the deadline miss due to the sampler or due to jack not getting
scheduled in time ? -> double frustration :-) ).
Paul, do you think that in (near) future it will be possible to run
an entire virtual studio using jack's in-process model that runs
all active apps (eg ardour, sampler, snyth, FXes etc) as plugins
of a single process ?
This would be really useful for those that need these extremely
low latencies while at the same time being able to access to a
fully fledged virtual studio where your only limitation is the
CPU speed and RAM/disk speed/size.
cheers,
Benno
Paul Davis wrote:
> the JACK data i provided covers an out-of-process client. the
> all-in-process client case has the same latency as ALSA only.
>
> the difference between the two is that although 99.9% of the time, the
> kernel operates as desired and JACK can provide ALSA-only/in-process
> performance in the out-of-process case, every once in a few tens of
> thousands of process() cycles, the kernel messes up our scheduling and
> this causes an xrun. tracking this down is an important but very, very
> difficult case. its possible that it may never be solved.
>
> --p
--
http://linuxsampler.sourceforge.net
Building a professional grade software sampler for Linux.
Please help us designing and developing it.
I suspect that Steinberg (and others) went the wait-and-see attitude.
They recognized that the patent was simply too broad and that an
eventual lawsuit would have caused quite a controversy in the audio
world. (Perhaps damaging good relations between Tascam and other audio
sw producers, generating bad press and probably in the end resulting in
the patent declared invalid).
Plus it seems that soon there will be new contenders on the commercial
disk based samplers area.I believe that regarding the patent they took
the same stance as (probably) Steinberg did.
For example Native Instrument announced that
they will add disk streaming support to their Kontakt sampler this
month.
----
http://www.nativeinstruments.de/index.php?kontakt_us
Direct From Disc extension
In November 2002 a free Mac and PC update for registered KONTAKT users
will add the Direct From Disc extension. This feature will enable
KONTAKT to play samples directly from the hard drive. Sample size will
no longer be limited by the amount of physical RAM - an instrument can
be as large as available hard drive space. All instruments utilizing
this technology will load many times faster than RAM-based instruments.
---
You are probably aware that Invision has a patent about the PC softsynth
this means that there are literally hundreds of such apps "violating"
the patent.
The idea of caching data in RAM that resides on a mass storage device is
just too old, it has existed since the first mass storage device was
introduced.
Anyway if you care, in the good old Amiga days I implemented routines
that allowed the streaming of large audio clips from disk and CDROM with
instant play by caching the first part of the clip in RAM.
It was 1991-92 I believe the project was part of an italian version
of the Grolier Encyclopedia for the Amiga and that strange CD-like
player amiga device. (I do not remember the name anymore).
This is just a small example of "prior art" :-)
I guess there are hundreds other of examples too.
I fully agree with what David Burrows said. :-)
cheers,
Benno
Paul Davis wrote:
>>Do we know what Steinberg did about this, if anything?
>i asked karl steinberg. he was unwilling to say anything about it.
--
http://linuxsampler.sourceforge.net
Building a professional grade software sampler for Linux.
Please help us designing and developing it.
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
has the plots, a link to the spice model source, the hard
clipper ladspa implementation and the mandatory mp3:
http://quitte.de/brat.mp3
which is the output from this signal chain:
guitar (bridge pickup, humbucker) ->
HiPass (200) ->
Gain (db = 30) ->
clipper.so ->
unmatched.so
it may not be a true amp model, but to me ... it rocks.
i'm still pondering whether antialiasing is needed, and if so,
how to do it (fit in a windowed sinc where the signal hits
the clipping threshold? thoughts welcome).
for building a decent 'virtual amp', i imagine some combination
of Steve's excellent valve and valve_rect for a good, smooth
and warm lowish-gain tone, a bit of tunable eq and this kind of
hard-clipping for hi-gain, harsh distortion topped off with a
cabinet response will just about do it for me.
tim