Linux-audio-dev

linux-audio-dev@lists.linuxaudio.org

6 participants
7504 discussions

[linux-audio-dev] Linux Alsa Audio over 1394 - a Thesis

by Mark Knecht

Some folks here might find this of interest. I do... http://www.cs.ru.ac.za/research/g99s2711/thesis/thesis-final.pdf Cheers, Mark

22 years, 4 months

[linux-audio-dev] Re: CSL Motivation (fwd)

by Kai Vehmanen

Let's continue the cross-post circus. :) Does anyone here have good connections to the GNOME audio folks? Is gstreamer leading the whole thing, or are there others? I think it would be great if we could at least manage to start living on the same planet (... and maybe even someday, gasp, cooperate! >;)). ---------- Forwarded message ---------- Date: Thu, 27 Feb 2003 00:05:04 +0200 (EET) From: Kai Vehmanen <kai.vehmanen(a)wakkanet.fi> To: KDE Multimedia <kde-multimedia(a)mail.kde.org> Cc: Paul Davis <paul(a)linuxaudiosystems.com> Subject: Re: CSL Motivation On Tue, 25 Feb 2003, Tim Janik wrote: > and, more importantly, stefan and i wrote a paper going into the details of > why we think a project like CSL is necessary and what we intend to achieve > with it: Ok, I already forwarded a few mails concerning this from lad. I'll add a few comments of my own: I think I understand your reasons behing CSL, and I think it (CSL) might just be the necessary glue to unite KDE and GNOME on the multimedia front. But what I see as a risk is that you forget the efforts and existing APIs outside these two desktop projects. In the end, it's the applications that count. It's certainly possible that you can port all multimedia apps that come with GNOME and KDE to CSL, but this will never happen for the huge set of audio apps that are listed at http://www.linuxsound.at. And these are apps that people (not all, but many) want to use. A second point is that for many apps, the functionality of CSL is just not enough. ALSA PCM API is a very large one, but for a reason. Implementing a flexible capabilities query API is very difficult (example: changing the active srate affects the range of valid values for other parameters). The selection of commonly used audio parameters has really grown (>2 channels, different interleaving settings for channels, 20bit, 24bit, 24-in-4bytes, 24-in-3bytes, 24-in-lower3of4bytes, 32bit, 32bit-float, etc, etc ... these are becoming more and more common. Then you have functionaliy for selecting and querying available audio devices and setting up virtual soundcards composed of multiple individual cards. These are all supported by ALSA and just not available on other unices. Adding support for all this into CSL would be a _huge_ task. Perhaps the most important area of ALSA PCM API are the functions for handling buffersize, interrupt-frequency and wake-up parameters. In other words being able to set a buffersize value is not enough when writing high-performance (low-latency, high-bandwidth) audio applications. You need more control and this is what ALSA brings you. And it's good to note that these are not only needed by music creation (or sw for musicians for lack of a better term) apps, but also for desktop apps. I have myself written a few desktop'ish audio apps that have needed the added flexibility of ALSA. Now JACK, on the other hand, offers completely new types of functionality for audio apps: audio routing between audio applications, connection management and transport control. These are all essential for music apps, but don't make sense in an audio i/o abstraction like CSL. So to summarize, I really hope that you leave a possibilty for these APIs (especially ALSA and JACK) in the KDE multimedia architecture, so that it would be possible to run different apps without the need to completely bypass other application groups (like is the situation today with aRts/esd/ALSA/OSS/JACK apps). As a more practical suggestion, I see the options as: 1) A front-end API that is part of the KDE devel API a) aRts b) gstreamer c) CSL d) Portaudio e) ... others? 2) Backend server that is user-selectable (you have a nice GUI widget for selecting which to use) a) aRts (current design, again uses OSS/ALSA) b) JACK (gstreamer already has support for it) c) ALSA (dmix or aserver) d) MAS e) ... others? All official (part of the base packages) KDE+GNOME apps would use (1), but 3rd party apps could directly interact with (2) if they so wished. If the required (2) is not running, user can go to the configuration page and change the audio backend. Comments? :) -- http://www.eca.cx Audio software for Linux!

22 years, 4 months

[linux-audio-dev] [ANNOUNCE] polarbear-0.5.0

by Maarten de Boer

Hello, I just released polarbear. I had the code lying around, and just merged it with the jack/alsa i/o code of tapiir. Note that this is the first public release. I did not test it thoroughly, and I am not sure if the GUI is obvious enough (it should be if you are familiar with complex filters), so any input is welcome. polarbear is a tool for designing filters in the complex domain. Filters can be designed by placing any number of poles and zeros on the z plane. >From this the filter coefficients are calculated, and the filter can be applied in real time on an audio stream. polarbear can be found at http://www.iua.upf.es/~mdeboer/projects/polarbear/ For the (far) future, the idea is that polarbear and tapiir can work together, in the sense that the filter coefs calculated by polarbear can be used to control the gains of tapiir. maybe polarbear and tapiir might even merge. that would be some animal :-) Maarten

22 years, 4 months

[linux-audio-dev] BruteFIR + jack = crackling noise?

by Werner Johansson

Hi all! First post to this list for me.. I have observed a strange thing with my jackd + BruteFIR setup, it looks something like this: HW: Emagic 2|6 USB thing (hw0), directly connected to a USB port, no hubs.. This runs with both inputs and outputs in analog mode for now to rule out any kind of sample rate/clock rate mismatches digital mode can introduce. Kernel 2.4.19-1LL (running Planet CCRMA software here with lowlatency enabled in the kernel) - have tried this on both a RedHat 7.3 and RedHat 8.0 system. jackd -R -d alsa -d hw:0 -r 44100 -p 2048 BruteFIR running at 44100Hz with a filter size of 2048,8 This gives me a faint crackling noise in the output (sounds like latency issues, but nothing gets logged anywhere).. The symptom is the same for 48kHz, and to make sure that's it not really anything directly hardware related I can start jack up and instead of connecting BruteFIR I can connect AlsaPlayer and play MP3's or whatever just fine (!)... That's not the most interesting part though - the crackling disappears if I choose a filter size of 4096,4 (or 8) instead, with the same period size for jack - that really shouldn't make any difference, should it?? Anyone else that have seen/heard this problem, or is it just me? :) It seems that my 2|6 likes period sizes of 44100/1000 or 48000/1000 much better than the BruteFIR-enforced 2^something sizes though - I can't reliably play anything using a period size of 1024, but one of 820 is fine @ 44100Hz rate (?) What other information would be relevant here? /WernerJ

22 years, 4 months

[linux-audio-dev] Fwd: CSL Motivation

by Roger Larsson

Hi, There are discussions on kde-multimedia about the future of Linux/Unix multimedia (especially sound). This is one of the most interesting messages. /RogerL ---------- Forwarded Message ---------- Subject: CSL Motivation Date: Tuesday 25 February 2003 16:26 From: Tim Janik <timj(a)gtk.org> To: KDE Multimedia <kde-multimedia(a)mail.kde.org> hey all, due to the recent discussions involving CSL (amongst other projects) on this list, i've put up a preliminary web presence at: http://sfk.evilplan.org/csl/ and, more importantly, stefan and i wrote a paper going into the details of why we think a project like CSL is necessary and what we intend to achieve with it: http://sfk.evilplan.org/csl/csl-paper.ps --- ciaoTJ _______________________________________________ kde-multimedia mailing list kde-multimedia(a)mail.kde.org http://mail.kde.org/mailman/listinfo/kde-multimedia ------------------------------------------------------- -- Roger Larsson Skellefteå Sweden

22 years, 4 months

Re: Re: [linux-audio-dev] BruteFIR + jack = crackling noise?

by Taybin Rutkin

>> BTW, can JACK handle several HW interface using different blocksizes >> at a time (assuming sample frequencies are coherent) ? >No, but you could run several instances of JACK. Acutally, I'm afraid that you can't do that currently. Taybin

22 years, 4 months

[linux-audio-dev] LADSPA valgrind test wrapper

by Steve Harris

I hacked up a shell script [attached] to valgrind LADSPA .so files. It will report leaks, bufferoverruns, reads from unitialised variables and so on, but it doesn't totally exercise the plugin so it may miss some things. Obviously it helps if you rebuild with -g on and it works best with gcc3 (better inline debugging). You can't just "valgrind applyplugin ..." becuase valgrind doesn't chase the dlloaded objects and applyplugin is full of memory errors and leaks :) Usage: ladspa-valgrind <plugin.so>+ I dont recommend running it on my current plugin set ;) Requires gcc and valgrind 1.0+ - Steve

22 years, 4 months

[linux-audio-dev] problems with Midisport 2x2

by Ivica Bukvic

Hi all, I've got a small problem with my Midisport 2x2 MIDI interface. While it worked ok before, now for some odd reason I cannot get it to open for MIDI output (from the computer). I've checked the /var/log/messages and this is what I got: Feb 24 20:44:41 mycomp kernel: hub.c: USB new device connect on bus2/1, assigned device number 2 Feb 24 20:44:41 mycomp kernel: usb.c: USB device 2 (vend/prod 0x763/0x1001) is not claimed by any active driver. Feb 24 20:44:44 mycomp /etc/hotplug/usb.agent: Setup ezusbmidi for USB product 763/1001/1 Feb 24 20:44:44 mycomp /etc/hotplug/usb.agent: Module setup ezusbmidi for USB product 763/1001/1 Feb 24 20:44:44 mycomp /etc/hotplug/usb/ezusbmidi: load /usr/share/usb/ezusbmidi/ezusbmidi2x2.ihx for 763/1001/1 to /proc/bus/usb/002/002 Feb 24 20:44:44 mycomp kernel: usb-uhci.c: interrupt, status 2, frame# 1645 Feb 24 20:44:44 mycomp kernel: usb.c: USB disconnect on device 2 Feb 24 20:44:44 mycomp kernel: hub.c: USB new device connect on bus2/1, assigned device number 3 Feb 24 20:44:44 mycomp kernel: usb.c: USB device 3 (vend/prod 0x763/0x1110) is not claimed by any active driver. Feb 24 20:44:48 mycomp /etc/hotplug/usb.agent: Setup snd-usb-audio audio usb usb-midi for USB product 763/1110/1 Feb 24 20:44:48 mycomp kernel: usb.c: registered new driver snd-usb-audio Feb 24 20:44:48 mycomp kernel: snd-usb-midi: MIDIStreaming version 01.00 Feb 24 20:44:48 mycomp kernel: snd-usb-midi: EP 01: 2 jack(s) Feb 24 20:44:48 mycomp kernel: snd-usb-midi: EP 81: 2 jack(s) Feb 24 20:44:48 mycomp kernel: snd-usb-midi: created 0 output and 4 input ports Feb 24 20:44:48 mycomp kernel: usb-uhci.c: ENXIO c0008380, flags 0, urb cdc59d60, burb cdc59ce0 Feb 24 20:44:48 mycomp kernel: snd-usb-midi: usb_submit_urb: -6 Feb 24 20:44:48 mycomp /etc/hotplug/usb.agent: ... blacklisted module: audio Feb 24 20:44:48 mycomp kernel: usb.c: registered new driver midi Feb 24 20:44:48 mycomp /etc/hotplug/usb.agent: ... blacklisted module: usb-midi It says that the device was opened with 4 input and 0 output ports. Why is this the case? I have no problem getting the midi input going, but my output is mysteriously dead. I've read somewhere that if the device is reconnected that the output stops working (might have been CCRMA's Fernando), but this is the log from the initial connect as soon as the computer boots. I've also made sure that no MIDI devices were connected to the MIDISPORT upon starting up. Any help on this issue is greatly appreciated! Sincerely, Ico

22 years, 4 months

Re: [linux-audio-dev] BruteFIR + jack = crackling noise?

by John Lazzaro

> we don't care about non-power-of-two periods, i think. however, i do > consider periods defined in units of times and not frames to be broken > hardware design. it forces inefficiencies into the software that are > totally unnecessary. For what its worth, the SAOL standard has to deal with this problem too, since the user gets to specify an integer k-rate and an integer a-rate. Eric went for this solution: 5.8.5.2.2 krate parameter <global parameter> -> krate <int>; The krate global parameter specifies the control rate of the orchestra. [...] The krate parameter shall be an integer value between 1 and the sampling rate inclusive, specifying the control rate in Hz. [...] If the control rate as determined by the previous paragraph is not an even divisor of the sampling rate, then the control rate is the next larger integer that does evenly divide the sampling rate. The control period of the orchestra is the number of samples, or amount of time represented by these samples, in one control cycle. --- This has been controversial, since it limits the ability to use SAOL to emulate existing coding standards that have non-integer relationships betweens frames and the sample rate. The win has been decoder implementation simplicity. ------------------------------------------------------------------------- John Lazzaro -- Research Specialist -- CS Division -- EECS -- UC Berkeley lazzaro [at] cs [dot] berkeley [dot] edu www.cs.berkeley.edu/~lazzaro -------------------------------------------------------------------------

22 years, 4 months

[linux-audio-dev] [ANNOUNCE] tapiir-0.7.0

by Maarten de Boer

Hello, I just released a new version of tapiir. Tapiir now supports jack. Tapiir can be found at http://www.iua/~mdeboer/projects/tapiir/ Tapiir is a simple and flexible audio effects processor, inspired on the classical magnetic tape delay systems used since the early days of electro-acoustic music composition. It provides a graphical user interface consisting of six delay lines, or "taps", which can introduce an almost arbitrarily big or small delay to their inputs and can be feed back to each other. A wide set of effects can be easily achieved by properly configuring and connecting the delay lines: complex echo patterns, resonances, filtering, etc. Delays, interconnections and gains can all be controlled in real time. Maarten

22 years, 4 months

Jump to page:

2025

2024

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