I guess this question is for Guenter Geiger, but I'd like to know what is the format used by streamin~ and streamout~ (I'm just too leasy to look at the source). Is it similar to the "raw" format? I'd like to use those externals with cstream (http://www.cons.org/cracauer/cstream.html) to get audio streams in and out of PD. -- Marc
The streamin and streamout objects use packets of more or less fixed length (64 samples in general). Each of these packages has a header that encodes the format as defined in the t_tag structure in stream.h.
It used to be raw format, but I changed that in order to be switchable during runtime and to extend the objects to multichannel (haven't done that yet ...)
Maybe the streamin13 and streamout13 objects still preserve the "raw" format.
G.
On Fri, 14 Nov 2003, Marc [iso-8859-1] Lavall�e wrote:
I guess this question is for Guenter Geiger, but I'd like to know what is the format used by streamin~ and streamout~ (I'm just too leasy to look at the source). Is it similar to the "raw" format? I'd like to use those externals with cstream (http://www.cons.org/cracauer/cstream.html) to get audio streams in and out of PD. -- Marc
PD-list mailing list PD-list@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-list
On Fri, Nov 14, 2003 at 07:14:11PM +0100, guenter geiger wrote:
It used to be raw format, but I changed that in order to be switchable during runtime and to extend the objects to multichannel (haven't done that yet ...)
Maybe the streamin13 and streamout13 objects still preserve the "raw" format.
streamin13 and streamout13 are like your externals, but with the multichannel feature. They don't seem to preserve the raw format. Actually, they don't work at all... (nothing is streamed).
I might write my own externals then.
Marc
i didn't use streamin/out13~ for a while, and they have several bugs, but they used to work (somehow) and support 8bit, 16bit and 32bit resolution samples. the format is not really raw audio, because extra information about the number of channels and the resolution is sent.
regards d13b
streamin13 and streamout13 are like your externals, but with the multichannel feature. They don't seem to preserve the raw format. Actually, they don't work at all... (nothing is streamed).
I might write my own externals then.
Marc
PD-list mailing list PD-list@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-list
On Fri, 14 Nov 2003, Marc [iso-8859-1] Lavall�e wrote:
On Fri, Nov 14, 2003 at 07:14:11PM +0100, guenter geiger wrote:
It used to be raw format, but I changed that in order to be switchable during runtime and to extend the objects to multichannel (haven't done that yet ...)
Maybe the streamin13 and streamout13 objects still preserve the "raw" format.
streamin13 and streamout13 are like your externals, but with the multichannel feature. They don't seem to preserve the raw format. Actually, they don't work at all... (nothing is streamed).
I might write my own externals then.
Another possibility would be to extend cstream in a way that it transmits format information.
I am sorry that collaboration within the pd community doesn't seem to work out, otherwise we would probably have a single set of working multichannel streaming objects.
Guenter
On Sun, Nov 16, 2003 at 01:37:06PM +0100, guenter geiger wrote:
Another possibility would be to extend cstream in a way that it transmits format information.
Cstream is not designed specifically as a sound application, although it can emulate a sound card. Extending it is a good idea.
I am sorry that collaboration within the pd community doesn't seem to work out, otherwise we would probably have a single set of working multichannel streaming objects.
Let's collaborate then; I always wanted to get sound in and out of PD.
What would be the specifications of these streaming objects? How to extend
cstream? Does OSC handle sound streams, and how alsa/jack fit in this
scheme? Should we start a streaming project on the pure-data.org web site?
--
Marc
Marc Lavallée schrieb:
Let's collaborate then; I always wanted to get sound in and out of PD. What would be the specifications of these streaming objects? How to extend cstream? Does OSC handle sound streams, and how alsa/jack fit in this scheme?
As far as I got it, jack only works on one machine. You can't use it to send audio over a network. - And things should work cross platform. Please remember that there still are some stupid windows users like me... ;-)
Should we start a streaming project on the pure-data.org web site?
Probably a good idea. BTW, I once started to make a stremin~ compatible VST PlugIn to send audio from VST-capable apps to Pd. But I never got it working because streamin~ and streamout~ frequently crashed on Windows. I could provide the sources in case someone want's to have a look at it.
Olaf
I had tried some similar VST myself using Perry Cook's "TcpWvIn" and "TcpWvOut", never getting to a point where it was very stable, though...
But, perhaps that code would be useful to someone? It's crossplatform, under a flexible license.
http://www-ccrma.stanford.edu/software/stk/ http://www-ccrma.stanford.edu/software/stk/classTcpWvIn.html http://www-ccrma.stanford.edu/software/stk/classTcpWvOut.html
-- eric
Probably a good idea. BTW, I once started to make a stremin~ compatible VST PlugIn to send audio from VST-capable apps to Pd. But I never got it working because streamin~ and streamout~ frequently crashed on Windows. I could provide the sources in case someone want's to have a look at it.
Olaf
PD-list mailing list PD-list@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-list
------ http://USFamily.Net/info - Unlimited Internet - From $8.99/mo! ------
And STK works with flext. Mmhh...
On Sun, Nov 16, 2003 at 10:55:04PM -0600, e skogen wrote:
I had tried some similar VST myself using Perry Cook's "TcpWvIn" and "TcpWvOut", never getting to a point where it was very stable, though...
But, perhaps that code would be useful to someone? It's crossplatform, under a flexible license.
http://www-ccrma.stanford.edu/software/stk/ http://www-ccrma.stanford.edu/software/stk/classTcpWvIn.html http://www-ccrma.stanford.edu/software/stk/classTcpWvOut.html
-- Marc
On Sun, 16 Nov 2003, Marc [iso-8859-1] Lavall�e wrote:
On Sun, Nov 16, 2003 at 01:37:06PM +0100, guenter geiger wrote:
Another possibility would be to extend cstream in a way that it transmits format information.
Cstream is not designed specifically as a sound application, although it can emulate a sound card. Extending it is a good idea.
I am sorry that collaboration within the pd community doesn't seem to work out, otherwise we would probably have a single set of working multichannel streaming objects.
Let's collaborate then; I always wanted to get sound in and out of PD. What would be the specifications of these streaming objects? How to extend cstream? Does OSC handle sound streams, and how alsa/jack fit in this scheme? Should we start a streaming project on the pure-data.org web site?
Ok, that would be great.
As Olaf already pointed out, JACK and ALSA is very linux specific, but the solution we come up should be crossplatform.
OSC is not a streaming architecture, It doesn't provide a framework to add this.
I think we would have to search around the web for existing solutions (like CStream etc.), then take a look at them and decide if we can reuse them.
Guenter
On Sun, Nov 16, 2003 at 07:55:37PM +0100, guenter geiger wrote:
As Olaf already pointed out, JACK and ALSA is very linux specific, but the solution we come up should be crossplatform.
I understand, but I'm mostly interested in using sound applications on Linux that can handle the Unix stdin/out mechanism. Maybe with cygwin it would be possible to do the same on Windows. It would work on MacOSX. Maybe streaming throught stdin/out is a bad idea... Any opinions?
I think we would have to search around the web for existing solutions (like CStream etc.), then take a look at them and decide if we can reuse them.
Cstream is a general purpose streaming tool. We could add translation routines from the streamin/out~ formats to RAW or WAV.
But is there some sort of standard audio streaming protocol out there?
-- Marc
On Sun, 16 Nov 2003, Marc [iso-8859-1] Lavall�e wrote:
On Sun, Nov 16, 2003 at 07:55:37PM +0100, guenter geiger wrote:
As Olaf already pointed out, JACK and ALSA is very linux specific, but the solution we come up should be crossplatform.
I understand, but I'm mostly interested in using sound applications on Linux that can handle the Unix stdin/out mechanism. Maybe with cygwin it would be possible to do the same on Windows. It would work on MacOSX. Maybe streaming throught stdin/out is a bad idea... Any opinions?
No, I think it is a good idea.
Actually you might be able to achieve your goals with the piperead~, pipewrite~ externals. You have to use the mkfifo command to create a named pipe, then redirect the raw audio data into that pipe and read it from pd with piperead~ from ext13. Its a bit messy but it might work.
Another solution would be to extract the formatting and networking code out of the streaming externals and make them usable as a library.
Then it would be only a few lines of code to either make the "audiocat" command, include it into a plugin or even writing a small jack client.
I think we would have to search around the web for existing solutions (like CStream etc.), then take a look at them and decide if we can reuse them.
Cstream is a general purpose streaming tool. We could add translation routines from the streamin/out~ formats to RAW or WAV.
But is there some sort of standard audio streaming protocol out there?
Thats another question. There are streaming formats like, quicktime. Maybe ffmpeg includes already all that would be needed (and that would mean support for "raw" data as well as more CPU intensive compressed formats such as mpeg and ogg).
So the user could choose between low latency intranet and low bandwith internet streaming without having to change the patch.
At the end it would be nice to have one streaming object pair that can do everything instead the different externals that we currently have. (like mp3, ogg and the strange streamin/streamout format).
Guenter
guenter geiger schrieb:
(and that would mean support for "raw" data as well as more CPU intensive compressed formats such as mpeg and ogg).
ogg does no compression. It just defines how to pack data into packages. This data can be vorbis compressed, flac or probably even raw audio data.
At the end it would be nice to have one streaming object pair that can do everything instead the different externals that we currently have. (like mp3, ogg and the strange streamin/streamout format).
Hhm, the main difference I see here is that mp3 and ogg are server based sreaming externals. So one needs a server running to connect to. No direct connection between apps like with streamin/out~. Yves has made a similar thing with mp3, but it's in no way compatible to 'ordinary' mp3 streaming.
Olaf
On Mon, Nov 17, 2003 at 01:10:11AM +0100, Olaf Matthes wrote:
ogg does no compression. It just defines how to pack data into packages. This data can be vorbis compressed, flac or probably even raw audio data.
That's interesting, especially if uncompressed audio is supported by all ogg compatible command line applications. Does ogg support multiple (uncompressed) audio channels (more than two)? -- Marc
Marc Lavallée schrieb:
On Mon, Nov 17, 2003 at 01:10:11AM +0100, Olaf Matthes wrote:
ogg does no compression. It just defines how to pack data into packages. This data can be vorbis compressed, flac or probably even raw audio data.
That's interesting, especially if uncompressed audio is supported by all ogg compatible command line applications. Does ogg support multiple (uncompressed) audio channels (more than two)?
At the moment raw audio is not supported, it seems. But in the end the ogg format is publicly available so it would be possible to put raw audio data (even multichannel) into it. Another solution would be to use flac. This (lossless) format is currently being integrated into the ogg bitstreams. But his still requires more or less CPU intensive compression. The question is whether we wan't to make everybody happy with our multichannel streaming format or just the Pd users. In the latter case we could just invent anything within Pd or debug streamin/out~.
Olaf
-
d -
e skogen -
guenter geiger -
Marc Lavallée -
Olaf Matthes