Re: [linux-audio-dev] Just for fun - Hearnet
Hans Fugal wrote: This is a little toy I hacked up while learning the Jack API today. It is not sophisticated, it is hackish, and it is probably not really doing precisely what I intended it to do. But it's fun. It does a simple form of granular synthesis: it plays a grain for every incoming packet in realtime. Requires libpcap and libjack (of course). http://falcon.fugal.net/~fugalh/hearnet/ Feedback is welcome. :-D to further boost the uselessness of this wonderful thing, how about mapping different grains to protocol, port numbers and direction? just imagine: # ping somehost ping ... pong ... ping ... pong ... ping ...pong or even # ping -f somehost pgniogingpgnigongpgignpgoigpnigiongpgnogignpgipgnpoingopingopngignoin soon we will see network operators starring at contemporary music festivals. ;) jörn -- To someone whose only tool is a hammer, each problem looks like a nail. - Edsger W. Dijkstra, EWD838 Jörn Nettingsmeier Kurfürstenstr 49, 45138 Essen, Germany http://spunk.dnsalias.org (my server) http://www.linuxaudiodev.org (Linux Audio Developers)
[linux-audio-dev] Check this out!
http://www.lionstracs.com/ -- Matt Gerassimoff
Re: [linux-audio-dev] question about time and compressed formats
On Thursday 13 November 2003 16:48, J_Zar wrote: I' ve done some tests on a bunch of songs in different compressed formats ( samplerate = 44100 ): Mp3 and Ogg. For the Mp3 format I tested various bitrates and I find out that on the playback phase this format has a value of 26.12 milliseconds/frame ( meaning that every frame cover 26.12 ms! ). My ask: is there a general algorythm to calculate the ms/frame value for all conpressed formats? Could someone confirm my values? Are this values affected from some parameters ( I think surely samplerate... )? Why 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/ Cheers! |-| | Frederick F. Gleason, Jr. | Director of Broadcast Software Development | | | Salem Radio Labs| |-| | Logic is a way to go wrong with confidence. | | --Robert Heinlein | | The Notebooks of Lazarus Long | |-|
Re: [linux-audio-dev] Check this out!
On Fri, Nov 14, 2003 at 07:58:29AM -0600, Matt Gerassimoff wrote: http://www.lionstracs.com/ -- Matt Gerassimoff i like seq24 very nice thing -- torben Hohn http://galan.sourceforge.net -- The graphical Audio language
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] Just for fun - Hearnet
I read: soon we will see network operators starring at contemporary music festivals. actually sonification of traffic is already passe, you probably should have attended some of the festivals ;) regards, x -- [EMAIL PROTECTED] Postmodernism is german romanticism with better http://pilot.fm/special effects. (Jeff Keuss / via ctheory.com)
Re: [linux-audio-dev] Just for fun - Hearnet
On Fri, 14 Nov 2003 16:08:32 +0100 (CET) CK [EMAIL PROTECTED] wrote: I read: soon we will see network operators starring at contemporary music festivals. actually sonification of traffic is already passe, you probably should have attended some of the festivals ;) Well, it's not all passee.. Here in my university we have a guy that sonificates Highway traffic :) And the weather Flo -- music: http://www.soundclick.com/bands/9/florianschmidt.htm
Re: [linux-audio-dev] Check this out!
On Fri, Nov 14, 2003 at 07:58:29AM -0600, Matt Gerassimoff wrote: http://www.lionstracs.com/ you're late to the party ;-) we started discussing this on the 10th. -- Paul Winkler http://www.slinkp.com Look! Up in the sky! It's FAKER DART! (random hero from isometric.spaceninja.com)
Re: [linux-audio-dev] Just for fun - Hearnet
I read: Well, it's not all passee.. Here in my university we have a guy that sonificates Highway traffic and stupid me thought that highway traffic sonificates itself pretty well already. regards, x -- [EMAIL PROTECTED] Postmodernism is german romanticism with better http://pilot.fm/special effects. (Jeff Keuss / via ctheory.com)
Re: [linux-audio-dev] Just for fun - Hearnet
* Joern Nettingsmeier [Fri, 14 Nov 2003 at 11:36 +0100] :-D to further boost the uselessness of this wonderful thing, how about mapping different grains to protocol, port numbers and direction? If boredom allows, I will probably do the following: Make it extensible via a config file, so that you can specify your own grains to play according to whatever libpcap filter you want. Everyone's creativity can really flow then, and it might end up being useful. (I actually wrote this in part to help gauge the rate that we're sending network packets at work - my other attempts at timing are giving ambiguous results, but my ear won't lie to me) Make it stereo (or even more channels) so that inbound goes out one speaker and outbound out the other. Again, probably configurable in a config file along with libpcap filters. Version 0.0.2 is already out. ChangeLog at the site. -- Hans Fugal | De gustibus non disputandum est. http://hans.fugal.net/ | Debian, vim, mutt, ruby, text, gpg http://gdmxml.fugal.net/ | WindowMaker, gaim, UTF-8, RISC, JS Bach - GnuPG Fingerprint: 6940 87C5 6610 567F 1E95 CB5E FC98 E8CD E0AA D460 pgp0.pgp Description: PGP signature
[linux-audio-dev] [OT] Linux soundapps site updated
Greetings: Yes, it's true, I've finally updated the sites with a new edition for your weekend browsing pleasure. If you don't already know the drill, you can follow these links to the goods: http://linux-sound.org(USA) http://www.linuxsound.at(Europe) http://linuxsound.jp(Japan) Have fun ! Best regards, Dave Phillips
[linux-audio-dev] [RFC] Request For Contest - The Linux-2.6 theme song contest !
Hi Everybody, This mail is a direct consequence of the song Austin Acton posted recently. :) A nice little tune made with linux, about linux, that has been quite successful with very little advertisement. After a few brain rotations (before you ask, yes, I think by rotating my brain) I came to the conclusion that RIGHT NOW is a wonderful time to start a write_the_best_linux_song_contest! My reasoning is that linux-2.6 is just around the corner, people are hungry for any kind of linux related information, no matter how far fetched (I don't even think this is very far fetched). Making a little contest to choose THE linux-2.6-theme-song seems like a very good way to attract some easy publicity, the main thing we want to do is make people interested in (and aware of) audio production under linux. I'm confident that Slashdot (or any news site in the free software world for that matter) would gladly do a story on this event. BUT before we get to that, let's atleast produce some music ! :) Some criteria I thought would be applicable: - The song must be about linux in some way (about linux 2.6 seems the obvious choice). - The song must be (atleast) processed with a computer and that computer must run linux. - No computer running an operating system that is nonfree can be used in the production. (External synthesizers or similar stuff with advanced capabilties don't count as computers and can thus be used) - The song must be written by the artist (possibly used with permission). - The song would preferably contain some kind of voice track ( it might be hard to hear that it's about linux otherwise, and it would be nice to know how you people sound :-) - the better the audio quality the better, though I think there are other qualities of the recordings that count. - Some info about the applications/gear used should be included (atleast applications). - No prices, just free publicity for anybody that joins, and most publicity for those that reach the top in the event that we actually pull of a vote. We already got one song, Austins! I'm in the middle of producing a naive electronic piece myself (I mainly play the guitar) that I think will be applicable also. But... two songs don't make a contest... So, what do you say? Are we up to it? I'm calling all linux-artist wannabees, this is the time! I dare all developers that aren't on a deadline to take some time of from coding and also participate, bring out the artist in you! :) Wouldn't you just die to hear The ballad of Alan Cox, or Linus' Theme or The Bitkeeper Blues :) (those are free btw if anyone gets any bright ideas ;) From now til, say, December 14, one month, might be enough time to do something creative, yes? Let me know if there is any interest for this then I will try to formalize things a bit, website etc. Well don't just sit there, let's do it! :) /Robert
Re: [linux-audio-dev] Just for fun - Hearnet
This is a little toy I hacked up while learning the Jack API today. It is not sophisticated, it is hackish, and it is probably not really doing precisely what I intended it to do. But it's fun. It does a simple form of granular synthesis: it plays a grain for every incoming packet in realtime. Requires libpcap and libjack (of course). http://falcon.fugal.net/~fugalh/hearnet/ Feedback is welcome. :-D to further boost the uselessness of this wonderful thing, how about mapping different grains to protocol, port numbers and direction? just imagine: # ping somehost ping ... pong ... ping ... pong ... ping ...pong or even # ping -f somehost pgniogingpgnigongpgignpgoigpnigiongpgnogignpgipgnpoingopingopngignoin soon we will see network operators starring at contemporary music festivals. ;) Done by Chris Chafe :-) ;-) :-) See http://www-ccrma.stanford.edu/~cc/sfmoma/topLevel.html (pretty picture at: http://www-ccrma.stanford.edu/~cc/sfmoma/LAtimesGraphic.jpeg) And/Or http://www-ccrma.stanford.edu/groups/soundwire/ -- Fernando
Re: [linux-audio-dev] [PATCH] oss support for jack
On 14 Nov 2003, Jussi Laako wrote: I've written preliminary OSS driver for JACK. Patch for jack 0.80 [...] If you are compiling with OSS Lite, please comment out the non-S16 formats. Workaround for this: --cut-- #ifndef AFMT_S32_LE #define AFMT_S32_LE 0x1000 #endif #ifndef AFMT_S32_BE #define AFMT_S32_BE 0x2000 #endif --cut-- ... and so on. This should be added before committing this to CVS as most people have OSS-Lite. -- http://www.eca.cx Audio software for Linux!
Re: [linux-audio-dev] [PATCH] oss support for jack [UPDATE]
Of course I forgot something out of the patch. Here's additional patch for drivers/oss/Makefile.am... -- Jussi Laako [EMAIL PROTECTED] --- jack-audio-connection-kit-0.80.0/drivers/oss/Makefile.am 1970-01-01 02:00:00.0 +0200 +++ jackit/drivers/oss/Makefile.am 2003-11-14 21:04:01.0 +0200 @@ -0,0 +1,10 @@ +MAINTAINCLEANFILES = Makefile.in + +AM_CFLAGS = $(JACK_CFLAGS) -I/opt/oss/include + +plugindir = $(ADDON_DIR) + +plugin_LTLIBRARIES = jack_oss.la + +jack_oss_la_LDFLAGS = -module -avoid-version +jack_oss_la_SOURCES = oss_driver.c oss_driver.h
Re: [linux-audio-dev] Slashdot: linux-based music =?iso-8859-1?q?keyboard workstation?= released
On Wednesday 12 November 2003 18.10, [EMAIL PROTECTED] wrote: 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 That's some really nice stuff they've got there! :-) Not quite what I'm looking for right now, though. (Although I could definitely find uses for these gadgets as well. :-) Right now, I'm thinking in terms of a rather minimal sequencer control panel, preferably integrated with a relatively large color LCD. I want to be able to record and arrange a whole MIDI song using only this UI and the master keyboard. Shuttle control, navigation, selection and basic edit functions must be easilly accessible. //David Olofson - Programmer, Composer, Open Source Advocate .- Audiality ---. | Free/Open Source audio engine for games and multimedia. | | MIDI, modular synthesis, real time effects, scripting,... | `--- http://audiality.org -' --- http://olofson.net --- http://www.reologica.se ---
Re: [linux-audio-dev] [PATCH] oss support for jack
Jussi Laako [EMAIL PROTECTED] writes: I've written preliminary OSS driver for JACK. Patch for jack 0.80 attached. With current CVS you can just run `jackd -d portaudio'. -- Jack O'Quin Austin, Texas
Re: [linux-audio-dev] Linux Security Module for realtime audio
[EMAIL PROTECTED] writes: attached is what i have done today works, but needs to be checked by someone who can judge about the sideeffects. Cool. Thanks, Torben. Doing it with so little code is encouraging, and speaks well for the modularity of the 2.6 kernel. I looked at your code, but am not completely up to speed on kernel security modules yet. It looks like your module essentially duplicates the effect of the 2.4 capabilities patch. With this loaded, it will be possible to run the existing `jackstart' exactly as we do today on a capabilities- enabled 2.4 kernel. Is that right? That is wonderful. i am not so sure about them. I'm not sure about the side effects either, but I plan to study the matter carefully. There is a [EMAIL PROTECTED]' mailing list. Maybe we should post there, asking for comments and suggestions. I've been thinking about ways to use this feature to improve and simplify the current security situation for Linux audio. No conclusions, but here are some thoughts for discussion: (1) There should a simple way for the sysadmin to reliably disallow realtime privileges. One way to allow (or prevent) access to realtime privileges for any program is via a sysctl global variable. Of course, loading the kernel extension is a privileged operation, anyway. But, I prefer some positive means of blocking it. (2) Using sysctl, set a group id (like `audio') for which realtime privileges are automatically granted. Then, we could just install realtime apps with `setgid audio'. This seems much better than opening things up to *any* application. And, audio applications would not need root privileges any more. This would be a rather big improvement over the current jackstart/jackd situation. (3) We could also define a default realtime group (gid 0 maybe), since `audio' probably does not exist on many distributions. IIUC, this is originally a Debian idea. I don't know how widely it has been adopted. I like it and think it should become a universal Linux convention, allowing access to the sound card as well as realtime privileges. -- Jack O'Quin Austin, Texas
Re: [linux-audio-dev] [PATCH] oss support for jack [UPDATE]
Jussi Laako [EMAIL PROTECTED] writes: Of course I forgot something out of the patch. Here's additional patch for drivers/oss/Makefile.am... I am *very* sorry that you went to all this work. Not only is its function mostly duplicated in the PortAudio driver, but the entire JACK driver interface has also undergone *major* changes since 0.80.0. We are about to release JACK 0.90.0 with these new interfaces. No one realized that anyone outside jackit-devel was working on drivers, or we would have warned you. (There *is* a warning in the README.developers.) The PortAudio driver has been used for the MacOSX port of JACK for quite a while. But, it is quite immature running on Linux with OSS. There may be bugs or missing features that will need to be fixed. But, I would much prefer to do that than to take on the extra maintenance load for yet another driver (we already have three). Would you mind terribly redirecting some of this fine work in the direction of testing and fixing problems with the PortAudio driver, instead? Regards, -- Jack O'Quin Austin, Texas
Re: [linux-audio-dev] [PATCH] oss support for jack [UPDATE]
But, I would much prefer to do that than to take on the extra maintenance load for yet another driver (we already have three). i welcome as many drivers as people can provide, on the understanding that they will not necessarily be maintained by anyone except the contributor, and if the internal API changes (as has happened between 0.80 and 0.90) and the driver is not ported, it will be removed from the Makefiles. --p
Re: [linux-audio-dev] [PATCH] oss support for jack [UPDATE]
Paul Davis [EMAIL PROTECTED] writes: But, I would much prefer to do that than to take on the extra maintenance load for yet another driver (we already have three). i welcome as many drivers as people can provide, on the understanding that they will not necessarily be maintained by anyone except the contributor, and if the internal API changes (as has happened between 0.80 and 0.90) and the driver is not ported, it will be removed from the Makefiles. That may be clear to the driver writers, but it won't make any sense to users filing bug reports in Mantis because one of our supported features doesn't work on their hardware. If you really want to wash your hands of all responsibility for this code, it needs to come from some other package, *not* from JACK CVS. -- joq
Re: [linux-audio-dev] [PATCH] oss support for jack [UPDATE]
contributor, and if the internal API changes (as has happened between 0.80 and 0.90) and the driver is not ported, it will be removed from the Makefiles. That may be clear to the driver writers, but it won't make any sense to users filing bug reports in Mantis because one of our supported features doesn't work on their hardware. what kinds of features are you thinking of? most of the hardware-related features derive from the ALSA driver, not JACK itself. If you really want to wash your hands of all responsibility for this code, it needs to come from some other package, *not* from JACK CVS. that would be fine with me. we can package jack-audio-connection-kit with just the core supported drivers (whatever they may be) and then jack-audio-connection-kit-foo for other drivers. its a trivial change to the Makefiles that i know taybin will love to do :) --p
