Linux-audio-dev April 2005

linux-audio-dev@lists.linuxaudio.org

107 participants
90 discussions

[linux-audio-dev] jack and alsa design issue

by Hans Fugal

I'm writing an application that will use alsa in the common case, but be jack-capable. I'm faced with the following design question: Do I wrap the jack part to emulate the read/write of alsa, or do I wrap the alsa part to emulate the callback style of jack? In other words, do I push or pull from the audio segment of the program? As I understand it, alsa can be asynchronous but it requires using SIGIO which doesn't excite me. So I'd have to create another thread that selects and fills a ringbuffer. To adapt jack, I'd have a ringbuffer which is drained when the program pulls the audio. Adapting Jack seems the easier thing to do, but what do you think? -- .O. Hans Fugal | De gustibus non disputandum est. ..O http://hans.fugal.net | Debian, vim, mutt, ruby, text, gpg OOO | WindowMaker, gaim, UTF-8, RISC, JS Bach --------------------------------------------------------------------- GnuPG Fingerprint: 6940 87C5 6610 567F 1E95 CB5E FC98 E8CD E0AA D460

18 years, 5 months

[linux-audio-dev] Oggz 0.9.1 Release

by Conrad Parker

Oggz 0.9.1 Release ------------------ Oggz comprises liboggz and the command-line tools oggzinfo, oggzdump, oggzdiff, oggzmerge, oggzrip and oggz-validate. liboggz is a C library providing a simple programming interface for reading and writing Ogg files and streams. Ogg is an interleaving data container developed by Monty at Xiph.Org, originally to support the Ogg Vorbis audio format. This release is available as a source tarball at: http://www.annodex.net/software/liboggz/download/liboggz-0.9.1.tar.gz New in this release: * Added new oggzinfo tool ------------------------- oggzinfo displays information about the contents of Ogg files. By default it displays basic information such as audio samplerate and video dimensions: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - $ oggzinfo 2004-12-04-cc-theora.ogg Content-Duration: 00:01:54.748 Theora: serialno 1648191042 3442 packets in 251 pages, 13.7 packets/page Video-Framerate: 29.970 fps Video-Width: 160 Video-Height: 128 Vorbis: serialno 0317964026 4935 packets in 138 pages, 35.8 packets/page Audio-Samplerate: 22000 Hz Audio-Channels: 2 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - oggzinfo also has options to display the following information for the entire file, and also for each logical bitstream: - length in bytes, kB, MB, GB - average bitrate in bps, kbps, Mbps, Gbps - statistics on page lengths (maximum and standard deviation) - statistics on packet lengths (maximum and standard deviation) The man page for oggzinfo(1) can be read online at: http://www.annodex.net/cgi-bin/man/man2html?query=oggzinfo * Added new oggz-validate tool ------------------------------ oggz-validate checks the ordering of packets within an Ogg file, and also checks that it complies with the Ogg bitstream mapping restrictions. The man page for oggz-validate(1) can be read online at: http://www.annodex.net/cgi-bin/man/man2html?query=oggz-validate * improved oggzdump tool ------------------------ oggzdump now displays packet lengths (in bytes, kB, MB, GB ;-) and timestamps (rather than just byte offsets). It now interprets theora granulepos as a split of keyframe|pframe: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 00:00:07.733: serialno 0539503247, granulepos 89|27, packetno 119: 277 bytes 0000: 506c a908 120e 3d0b 88d7 73e9 7227 227c Pl....= ..s.r'"| 0010: 9f40 7463 f789 87c1 8b79 043b 183c 946f .@tc.....y.;.<.o 0020: d1e3 3e47 0798 9fcd 61a9 f113 e261 d1ec ..>G....a....a.. ... - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - oggzdump now also has a --content-type (or -c) option for specifying the name of a particular bitstream to dump: oggzdump --content-type theora file.ogg will dump only the packets in the theora logical bitstream. The man page for oggzdump(1) can be read online at: http://www.annodex.net/cgi-bin/man/man2html?query=oggzdump * bugfix in oggzdiff tool ------------------------- r1176: fix some typos in oggzdiff which prevented multiple hide options from being specified The man page for oggzdiff(1) can be read online at: http://www.annodex.net/cgi-bin/man/man2html?query=oggzdiff * liboggz: bugfix in raw seeking -------------------------------- liboggz provides seeking by time or byte offsets in multitrack Ogg files. It automatically handles time offsets for files containing Theora, Speex, Vorbis, FLAC and CMML. r1092: fix a bug in raw seeking, where doing a raw seek by bytes and back again by time (to the original time point) hadn't invalidated the cached time offset, hence the second seek was considered unnecessary and skipped. This change correctly invalidates the cached time offset when doing a raw byte seek. * unnecessary optimisations in oggzrip tool ------------------------------------------- Optimised packet filtering: filtering decisions are now made at the start of each logical bitstream, not at every packet. Additionally, the hardcoded limit of extracting no more than 64 logical bitstreams from the input file was removed. The man page for oggzrip(1) can be read online at: http://www.annodex.net/cgi-bin/man/man2html?query=oggzrip About Oggz ---------- Oggz comprises liboggz and the command-line tools oggzinfo, oggzdump, oggzdiff, oggzmerge, oggzrip and oggz-validate. liboggz supports the flexibility afforded by the Ogg file format while presenting the following API niceties: * Full API documentation * Comprehensive test suite of read, write and seeking behavior. The entire test suite can be run under valgrind if available. * Developed and tested on GNU/Linux, Darwin/MacOSX, Win32 and Symbian OS. May work on other Unix-like systems via GNU autoconf. For Win32: nmake Makefiles, Visual Studio .NET 2003 solution files and Visual C++ 6.0 workspace files are provided in the source distribution. * Strict adherence to the formatting requirements of Ogg bitstreams, to ensure that only valid bitstreams are generated; writes can fail if you try to write illegally structured packets. * A simple, callback based open/read/close or open/write/close interface to raw Ogg files. * Writing automatically interleaves with packet queuing, and provides callback based notification when this queue is empty * A customisable seeking abstraction for seeking on multitrack Ogg data. Seeking works easily and reliably on multitrack and multi-codec streams, and can transparently parse Theora, Speex, Vorbis, FLAC, CMML and Ogg Skeleton headers without requiring linking to those libraries. This allows efficient use on servers and other devices that need to parse and seek within Ogg files, but do not need to do a full media decode. Full documentation of the liboggz API, customization and installation, and mux and demux examples can be read online at: http://www.annodex.net/software/liboggz/html/ Tools ----- The Oggz source tarball also contains the following command-line tools, which are useful for debugging and testing Ogg bitstreams: * oggzinfo: Display information about one or more Ogg files and their bitstreams. * oggzdump: Hexdump packets of an Ogg file, or revert an Ogg file from such a hexdump. * oggzdiff: Hexdump the packets of two Ogg files and output differences Oggz is Free Software, available under a BSD-style license. * oggzmerge: Merge Ogg files together, interleaving pages in order of presentation time. * oggzrip: Extract one or more logical bitstreams from an Ogg file. * oggz-validate: Validate the Ogg framing of one or more files. License ------- Oggz is Free Software, available under a BSD style license. More information is available online at the Oggz homepage: http://www.annodex.net/software/liboggz/ enjoy :) -- Conrad Parker Senior Software Engineer, Continuous Media Web, CSIRO Australia http://www.annodex.net/ http://www.ict.csiro.au/cmweb/

18 years, 5 months

[linux-audio-dev] LAC 2005 streaming: please test!

by Joern Nettingsmeier

hi everyone! we are currently setting up a stream network for lac2005 (http://lac.zkm.de) since we are trying to provide video streams for the first time, i would welcome testers to shake out any problems beforehand. our master server is currently open for public testing at http://lac2005.zkm.de:8000. in order to conserve bandwidth, the number of clients is limited. there is one video (un chien andalou by salvador dali) and one audio stream (the jazz tune "melancia" played by a friend of mine) streamed in two different bitrates each. please test them (especially the video stream). since theora streaming is quite bleeding-edge, few distros will support it out-of-the-box. in order to generate some documentation for stream users, we have borrowed frank barknechts wiki, please go to http://footils.org/cms/pydiddy/wiki/LinuxAudioConference2005 and add hints for your own distro. ! note that after this initial test period, the master server will be closed to the public again. during the conference, only relays will be given access. you can tune to one of the relays instead. urls will be posted real soon now. anticipating some bug reports: * yes, the video is black-and-white. * yes, there is some (intentional) distortion in the audio stream. * yes, there is currently no metadata displayed. * yes, the streams are not continous, i.e. your player will quit after the piece ends. * yes, you will see greenish garbage at the beginning. that's your player waiting for a theora keyframe. like last year, there will be irc channels: #lac2005 @ irc.freenode.net for general conference issues and feedback from remote conference participants #lac2005-tech @ irc.freenode.net for stream-related technical issues if you have problems or success stories, share them on the lists or on irc. best, jörn

18 years, 5 months

[linux-audio-dev] jack ports & alignment

by Tim Blechmann

hi all, just a short question about jack ... the pointer that void *jack_port_get_buffer (jack_port_t *, jack_nframes_t); returns, is that 128 bit aligned (for simd use)? thanks ... tim -- mailto:TimBlechmann@gmx.de ICQ: 96771783 http://www.mokabar.tk latest mp3: kMW.mp3 http://mattin.org/mp3.html latest cd: Goh Lee Kwang & Tim Blechmann: Drone http://www.geocities.com/gohleekwangtimblechmannduo/ After one look at this planet any visitor from outer space would say "I want to see the manager." William S. Burroughs

18 years, 5 months

[linux-audio-dev] Realtime convolution - a threading problem?

by Sune Mai

Hello! I just joined the LAD-list to get some feedback on the following topic: Convolution is really nice - I use it all the time to get perfect reverb, nice guitar amp-sound etc. The only serious drawback is the high input-output latency of simple FFT based algorithms. I'd like to see if it is possible to improve on this situation without sacrificing to much efficiency. If the impulse response (the FIR) is N samples long, the complexity of a naive (non FFT) implementation scales as N, i.e. it uses N operations per sample of input. A simple (single block overlap-add) scales as ln_2(N), since FFT has complexity N ln_2(N). If one wants both computational efficiency and low latency, one can do (at least...?) two things: 1: Split the FIR in smaller blocks. This is fairly simple, but has a serious drawback: As the latency, L, goes down, the efficiency of the algorithm approaches the naive non-FFT implementation. So the computational cost scales as N for "zero" (L<<N) latency. 2: Another approach is to split the FIR in blocks of different sizes, as can be seen in the bottom figure of this page: http://www.music.miami.edu/programs/mue/Research/jvandekieft/jvchapter2.htm This approach has an obvious advantage in that it allows "zero" latency, while still retaining some of the computational efficiency of the high-latency FFT based method. As far as I can see, the complexity of this algorithm scales as (ln_2(N))^2 for zero-latency. This is not as good as the high latency efficiency of ln_2(N) - but still far better than using method 1. with low latency. As far as I know, the programs I've come across so far (most notably BruteFIR and Jack_convolve) uses method 1. to get low latency. This leads to my first question: Has anybody implemented method 2. in a jack application, or, more generally, under GPL?. If not, are there any reasons that I'm not aware of, why one should not choose algorithm 2 instead of 1? The only difficulty I can see with method 2 is the scheduling of the different sub tasks. One way to get smooth processor load, is to do the FFT of the different block-sizes in different threads. This involves that the computation of the smallest blocks (triggered by the jack callback mechanism), should somehow preemt the thread doing the double sized blocks - and this thread should in turn preemt the thread doing the quadruple size FFT-blocks etc. According to the FFTW documentation the FFT algorithm is thread-safe, and can be used in this way. I don't have much experience with threads - and none of the resources I've found seems to deal with this kind of realtime problem. Is the above a stupid way to deal with the scheduling problem? And are there any resources you know of, that describes this kind of problem in detail? \Sune Mai _________________________________________________________________ Is your PC infected? Get a FREE online computer virus scan from McAfee® Security. http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963

18 years, 6 months

[linux-audio-dev] A computer is looking for a ride to LAC!

by Martin Habets

I'm looking for someone going to LAC from Zurich (or travelling through it), who can pick up a computer for me there and meet me at the LAC. I'll be coming from Schotland myself, and want to use it for ALSA testing among other things. A bit a of a strange passenger I know. I promise it won't need a toilet break along the way! For this and some other "more fleshy" travelmates see http://footils.org/cms/pydiddy/wiki/GetToLac2005 Please resond to me and Tormod (on cc) if you can be of assistance. Thanks, Martin

18 years, 6 months

[linux-audio-dev] sample-accurate comparison

by Andrew Gaydenko

Hi! The aim is trivial: - get some wav file, - burn it to CD-R(W), - rip it, get a copy, - compare the original file with the copy. If I understand well, the main problem here is to determine "the same starting point" for each of files. Is there some kind of software which may be useful in such comparison. (probably, some of answer may be like this: "learn scheme/ruby and use snd". I'm interested in more short way :-) Andrew

18 years, 6 months

[linux-audio-dev] Re: LAC 2005 streaming: please test!

by Jordan

Seems to be pretty good. The audio samples were flawless in XMMS. I played the video files in the VideoLAN client. They seemed to be pretty good, but the video was quite a bit jumpy in high-res mode (could be on my end, of course).

18 years, 6 months

Re: [linux-audio-dev] GPL concerns

by eviltwin69＠cableone.net

On Wed, 6 Apr 2005 22:09 , Erik de Castro Lopo <erikd-lad(a)mega-nerd.com> sent: >On Wed, 06 Apr 2005 00:31:15 -0500 >Shane lists(a)itsagesolutions.com> wrote: > >> Hey everyone. I have a bland but important question for everyone. Say >> hypothetically a company is developing an audio product using lots of >> GPL source, but for whatever marketing reasons asks for NDA concerning >> the codebase. Lots of GPL work is referenced and at least dynamically >> linked, and though the company has directly stated that it will release >> the codebase publicly with the product release (once it is complete). >> >> I am curious as to the general feel in the community on such practices. >> Would this 1) be a violation of the GPL, > >Yes. > >> 2) if it is how tolerant would >> the OSS community be, considering the general good intent of the >> project, and > >If any of my code is involved, I will prusue the matter. > > >> 3) if I were asked to sign such a NDA would that document >> be a binding agreement even if the NDA itself might be a violation of >> the GPL since it is inherently counterintuitive to the intent of the >> GPL. > >The GPL is pretty clear about this. The GPL comes into action when >the binaries or code derived from GPL code is **distributed**. >That means that you and the company can hack on whatever GPL code >you like as long as they don't release a binary (under NDA or not). > If you are part of the company or a contractor to the company and the product is not distributed outside the company you can do whatever you want with the code without having to release it. If you are outside the company and have to sign an NDA then I think that would be considered distribution and would therefore violate the GPL. As Erik said, once it's distributed then it has to be released. Jan

18 years, 6 months

Re: Re: [linux-audio-dev] FOSS-tools for realtime audio analysis?

by mathias_lundgren＠bredband.net

> > From: Alfons Adriaensen <fons.adriaensen(a)alcatel.be> > Date: 2005/04/06 on PM 01:00:45 GMT > To: "The Linux Audio Developers' Mailing List" > <linux-audio-dev(a)music.columbia.edu> > Ämne: Re: [linux-audio-dev] FOSS-tools for realtime audio analysis? > > You may mave a look at JAAA, (JACK and ALSA Audio Analyser). This is a > realtime 'technical' (rather than musical) spectrum analyser, designed > to make accurate measurements. It will also generate sines and white > Gaussian noise. It's at > > <http://users.skynet.be/solaris/linuxadio> > > You will also need some small shared libs available from the same > place. > > I'm considering some additional functionality, and if you have any > specific requirements I'd be interested to know. > Thanks! Actually, it's a friend of mine interested in something like this. One thing that I know he was curious about was if it would be possible to develop some kind of test-case for external hardware, which could give an indication of whether something is wrong with it or not. >From just taking a peek at it, I'm getting the impression that this is mainly a graphical tool (which is really cool). Anyway, he's not afraid of hacking if this is what he's looking for. Are features like these anything you've considered/already implemented/interesting? > I am also working on a Room Impulse Response measurement system using > a sine sweep as the stimulus. First release expected in a about two > months. > > -- > FA > > > >

18 years, 6 months

← Newer
1
2
3
4
5
6
7
8
9
Older →

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Linux-audio-dev April 2005