[linux-audio-dev] [Release] GSMP v0.0.5

[Rene Rebe]

Hi all.

After making many code-fixes due to compiling GSMP with the new
gcc-3.1 in ROCK Linux (http://www.rocklinux.org), we decided to
release the next GSMP version 0.0.5 - with some stability improvements
we already had in CVS.

So the ChangeLog:
- some sability improvements
- (many) GCC-3.1 compile fixes

(Next months') Roadmap:
- stabilize the MP3 StreamIO class
- rework PCM streaming code
- add MIDI support (aka start the Studio)
- continue the own Canvas implementation
- integrate the new Dynamic Application Model (DAM)
- rework the whole graphic code (aka throw Gtkmm away)

We also start to document the new idas and the design. Take a look at:
  http://drocklinux.dyndns.org/gsmp/developers.html

k33p h4ck1n6
  René

--  
René Rebe (Registered Linux user: #248718 )
e-mail:   [EMAIL PROTECTED], [EMAIL PROTECTED]
web:  www.rocklinux.org, drocklinux.dyndns.org/rene/

Anyone sending unwanted advertising e-mail to this address will be
charged $25 for network traffic and computing time. By extracting my
address from this message or its header, you agree to these terms.

Re: [linux-audio-dev] Audio stream setup

[John Lazzaro]

> What are your experiences and which setup would you recommend?

Here's how jwz does it for the DNA lounge:

http://www.dnalounge.com/backstage/src/icecast/

Perhaps its different in Eastern Europe, but in the US today
multicast is rarely an option on the commercial Internet, so
the practical approach is to put up a server that sends out
as many unicast streams as you have the bandwidth to provide.

-
John Lazzaro -- Research Specialist -- CS Division -- EECS -- UC Berkeley
lazzaro [at] cs [dot] berkeley [dot] edu www.cs.berkeley.edu/~lazzaro
-

[linux-audio-dev] Audio stream setup

[Miha Tomšič]

Hello!

Our local LUG is about to perform a small conference in a few weeks and we would
like to stream the lectures (just audio) over the net. I was told we would need
a server that can do multicast. 

What are your experiences and which setup would you recommend?

Thanks and take care,

Miha...

 - Miha Tomšič --- C. na postajo 55 -- SI-1351 Brezovica pri Lj. --- SLOVENIA -

[linux-audio-dev] SuperCollider...

[Kasper Souren]

Hi,

I just heard that there is something interesting to be found at the 
SuperCollider FTP site. But I'm not able to do something useful with a .dmg 
file. Supposedly you can only open it in MacOSX... I would be very happy if 
someone could mail me the contents of the archive. (Large files in my 
mailbox are no problem.)

Here is the file:
ftp://www.audiosynth.com/pub/dev/SCserver-dev.dmg.gz

greetz,
Kasper

Re: [linux-audio-dev] RFC: API for audio across network -inter-host audio routing

[Nelson Posse Lago]

On Thu, Jun 13 2002 at 11:55:11am +0200, Men Muheim wrote:
> > http://magic.gibson.com/
> Looks interesting. Thanks for the info. 
> [...]
> The discussion here should not be about the network but about an audio
> API which is independent of the underlying network stack.
> [...]
> I think the first thing to do is to define an audio API that reflects
> network capabilities and design the according audio library / server.
> Maybe the server could base on some of the JACK technology. Only after
> that the "network driver" comes into place.

Hi,

I think what I intend to do is somewhat related to this. I'm not sure if
what you are talking about are systems for synchronous or asynchronous
data transfer. As for asynchronous, I suspect that (as pointed out by
Steve Harris) MAS and RTP are good starting points.

I intend to write (RSN - I turned it into a school assignment) a "remote
effects processor": suppose I'm running a JACK graph where I have a lot of
LADSPA plugins running, and I want to add another one but my hardware
can't keep up; I'd like to be able to offload some of the work to another
machine. So, I'll create a host that simply grabs the data fed by jack,
sends it to be processed on a different machine, gets it back and feeds it
back to jack. To achieve this, we simply send the data during one jack
"cycle" and receive the processed data on the next "cycle" (which would
mean add something to the total latency). I want this to work over
ethernet, probably with UDP.

This would be a proof-of-concept implementation. If it works, I'd like to
implement a more general idea to do this on top of JACK, maybe even a
patch to JACK; this would allow us, for instance, to have all the UI work
done on one machine, all the disk I/O work done on 2-3 other machines, all
the DSP work spread over a bunch of machines and all the audio I/O done on
a single machine. Given that "older" hardware is extremely cheap and might
be able to do some parts of this work very well, I believe this would
offer an interesting setup to work with. In fact, the system may be made
"smart" so that different paths on the jack graph are treated "in
parallel": this way, we might even be able to send and receive the data
through the network within a single jack "cycle".

As Steve Harris also pointed out, a system like this can only output data
from a single machine, since everything needs to be run in sync with the
soundcard; compensating for the innacuracies doesn't seem to be adequate
on this scenario, which is geared IMHO to a recording studio, where plugin
processing power AND absolute audio quality are mandatory. However, maybe
adding the possibility of multiple soundcards on different machines with
drift compensation is an interesting idea and useful in other setups.

If the proof-of-concept implementation goes reasonably well, I intend to
pursue this further and make this the subject of my masters thesis.

As for the patent of Magic, I didn't read the specs, but from the
description of what Magic is, I guess this goes like:

Tech: "Hey, what if we use a network like ethernet to send data around
between digital equipment?"
Boss: "Great idea! Let's patent it."

Needless to say, that's ridiculous. The only "original" idea here is that
the data is audio, which is as original an idea as transposing the art of
fugue to a brass quartet.

See ya,
Nelson