Re: [linux-audio-dev] Getting out of the software game
I think you misread my technical statement as a political one. I don't care about politics or the GPL, I just want Linux to be the most stable OS, and that can't happen if secret blobs of code are allowed to scribble all over kernel memory. I have an additional argument against binary drivers. Some years ago, we had a server with a Highpoint IDE RAID controller. We bought it because the Highpoint actually had an open source driver tgz for it on it on its webpage. It turned out though that this open source driver was a binary blob with some open source kernel glue code around it (just like the nvidia and ati drivers). Anyway, too late to go back, we used the controller with the binary driver, kernel 2.4. After a while had to to upgrade to a 2.6 kernel, but Highpoint only provided a 2.4 driver. This caused a lot of trouble. Needless to say, from that moment on, we have sticked with IDE controllers from manufacturers that truely support open source. And with software RAID. That said, I do use the nvidia binary drivers. NVidia follows kernel changes fast enough, and my experience is that you will not run into trouble if you using a (custom) kernel that is not totally cutting edge. I use Ubuntu, and using the NVidia drivers with it is pretty straightforward. So I really do not understand how this can make someone decide to stop developing software for Linux. maarten
Re: [linux-audio-dev] Apologies (was: Re: an relevant link about Vista)
spam. My idea is to find a way to tweak (or apply an existing patch
to) mailman so that messages marked as spam get discarded
automatically
mailman on my mailserver (Ubuntu Dapper out of the box) has this option:
Privacy options...
[Spam filters]
Header filters
Filter rules to match against the headers of a message.
In my case, I use the following:
regex: Subject:.*\{Spam\?\}
Action: reject
Re: [linux-audio-dev] crossplatform atomics
not sure what you mean, but on sparcs, int writes are not atomic unless you only use the lower 24 bits. right, this is exactly the point! 32 bits int might be atomic on a certain platform, but i have no idea about many others. in the meantime, a part from joq suggestion of LFDS, and niklas mention of qt-core libs, i also came accross th glib atomic operations http://developer.gnome.org/doc/API/2.0/glib/glib-Atomic-Operations.html and the MacOSX atomic functions as in CarbonCore/DriverSynchronization.h maarten
[linux-audio-dev] crossplatform atomics
Hello, I am looking for a cross-platform implementation of an atomic integer. Under Linux, a build an c++ class atomic around asm/atomic.h, (which I can use as if it where an int), but I'd like to have a solution that also works on Windows XP and Mac OS X. Thanks for any suggestions, Maarten
Re: [linux-audio-dev] Fixed vs. floating point
Very interesting reads. Thanks! Here's some papers specifically geared toward DSP processors that support the use of fixed point: Superior Audio Requires Fixed-Point DSP http://www.rane.com/note153.html 48-Bit Integer Processing Beats 32-Bit Floating-Point for Professional Audio Applications http://www.jamminpower.com/main/articles.jsp -Mark
Re: [linux-audio-dev] best LL kernel options with ingo molnar's patch
Hi, Thanks for the reply. CONFIG_PREEMPT_RT: Complete Preemption (Real-Time) [...] AFAIK this one. Hm, I am currently trying PREEMPT_DESKTOP. I got the impression _RT would be a bit of overkill for audio work. Unfortunately, I also try to get decent audio on my 2.6.12 machine but it seems to be tricky. After enabling the above option and kernel installation, you need to patch PAM and configure it accordingly or you need to try set-rtlimits. Is this documented somewhere? maarten
Re: [linux-audio-dev] best LL kernel options with ingo molnar's patch
List archives. There's no point documenting it because it's developing too fast. Ok. I gave up following the whole discussing on LKML because it was too fast :-) If your distro has a 2.6.12 kernel available, you need to file a bug report against PAM to support this new kernel feature. I maintain my own ubuntu-based packages for use inside our group, so that's no problem. I will make those publicly available once I have them ready and tested. maarten
[linux-audio-dev] best LL kernel options with ingo molnar's patch
hello, any advice on what would be the best kernel options when using ingo molnar's patch for an audio setup? CONFIG_PREEMPT_DESKTOP: Preemptible Kernel (Low-Latency Desktop) or CONFIG_PREEMPT_RT: Complete Preemption (Real-Time) CONFIG_PREEMPT_SOFTIRQS: Thread Softirqs CONFIG_PREEMPT_HARDIRQS: Thread Hardirqs yes or no? right now i am building with CONFIG_PREEMPT_DESKTOP, CONFIG_PREEMPT_SOFTIRQS and CONFIG_PREEMPT_HARDIRQS maarten
[linux-audio-dev] desktop audio resumed
Hello, I just did some rereading of some parts of the What Parts of Linux Audio Simply Work Great? thread, that talk about the problems with soundcards that do not support multiple streams, and thought it would be good if we could actually come up with an advice to the desktop developers (Gnome and KDE mainly), distribution developers, and audio application developers in general. This document should contain a detailed description of the current situation, of how we got there (i.e. how the desktop sound daemons actually created bigger problem than a solution, and why alsa does not do mixing in software by default), of how different user requirements lead to different solutions that are not always compatible (i.e. the professional audio vs normal users), and of all the different solutions currently available (and interfering with eachother). I believe such an overview is essential. I think most people on this mailing list have a pretty good idea about his, but do others? For example, I get the impression that there is a lot of misunderstanding or ignorance about alsa and dmix. Then it should propose an ad-hoc solution, and some guidelines of how to work towards a future in which everybody (including jwz ;-) ) is happy with linux audio that just works. (I found jwz rant unjustified and unpleasant, but we can use it in our advantage if we give the right response, which, with a bit of luck (?) will get the same attention from the slashdot hords as jwz's blog) The ad-hoc solution, I believe, is something that should work right now, or at least, as good as possible, with as little as possible changes to existing applications. For one, this would mean: making sure that dmix is being used when necesary, that no applications use the hw: devices explicitely, but the default, that OSS applications use libaoss (If I understand correctly, libaoss can be told the use the dmix plugin, while alsa oss emulation will always use the hw device, or am I wrong here?). This is mainly a thing of the distro's. The remaining problem here is what to do with jackd. When the professional user runs jackd, and jackd complains that it is not using the hw: device directly, the solution should be obvious for him, and the non-jack apps should continue to work like before (but should be restarted, I suppose). Could anyone comment on this? The occasional jackd user can just run jack through the dmix plugin, which, if I understand correctly, would cause higher latency, but we are not talking about the professional user here. Proposing a roadmap for the future is much harder, but I think we can talk about that later. For now, I would like your opinion on the issue. Do you agree that such a document would be feasible and useful, and that the proposed structure/contents make sense? I am not sure that the mailinglist is the best way to write this document, maybe we could use a Wiki. I guess the first step would be to look for the relevant messages in the What Parts of Linux Audio Simply Work Great? thread, and write a short overview of those. maarten
Re: [linux-audio-dev] desktop audio resumed
Hi Lee, why alsa does not do mixing in software by default Please reread the thread again. It does do this by default. ALSA 1.0.9 or later is required. I knew this. But in the context of explaining the problem, it's essential to mention it. I should have said did instead of does. All this mainly to give a reply to jwz (or better, to the people who read his rant and were influenced by it) So all the advice needed is make sure you use the latest ALSA. That, and: - make sure no applications use hw:0,0 instead of default - if you use oss applications, make sure you use libaoss (or am I wrong here? does alsa pcm emulation use default as well?) - if you use jack, either accept jack through dmix, or make sure you _always_ run jack, and use tell all applications that can to use jack, and redefine the default device to be the jack plugin for the other applications. Still, the amount of (unnecesary, in the light of dmix) sound daemons, remains a problem. Even though the dmix default would even allow to run several sound daemons at the same time, this is hardly a desirable situation. Maybe, as I think someone mentioned in the thread, the sound daemons will automagically cease to exist once developpers realize there is no need for them. But it would be good to speed up the process. maarten
Re: [linux-audio-dev] [ot] [rant] gcc, you let me down one time too many
Paul Davis [EMAIL PROTECTED] wrote: i'll leave making things as fast as possible to intel, AMD and the gcc team. When I read this when you posted this the first time, I thought: and what about PPC? But now, after Steve Jobs WWDC keynote, it turns out that your omission of PPC was visionary :-) maarten
[linux-audio-dev] Linux For Audio Tutorial at AES Convention
Hello, Yesterday, we gave a Tutorial called Linux for Audio at the AES Convention, which took place here in Barcelona. To quote the abstract: It is obvious that Linux is becoming a real alternative to other well-known operating systems. But, is Linux ready to support all the requirements of the audio industry? In this tutorial, the Linux audio infrastructure will be introduced showing how it compares to and competes with other operating systems, with emphasis on low latency, application interconnectivity, and modularity. In addition, various aspects of this audio infrastructure will be demonstrated, using several promising applications in the Linux audio arena. The tutorial was 2 hours long, and consisted of two parts: a talk and a demo. During the talk we gave several smaller demonstrations. This worked out really well, because it made the final demo much more agile, as we already explained many basic features and operations before. The talk consisted of the following parts: The Linux Operation System (history, distributions, latency), ALSA, Interapplication connectivity (jack, alsaseq), Plugins (LADSPA, DSSI, VST), and the final demo. This demo mimicked a real-life studio situation, with Ardour as the main application. We had some prerecorded material, but also recorded a new bass guitar track on site. We demonstrated basic editting with Ardour, the use of plugins (LADSPA, VST and Jack application inserts), mixing with multiple output channels, automation with an motorized console (Behringer BCF2000), synchronization with Hydrogen and with Rosegarden (connected to fluidsynth), and bouncing the output back to Ardour. We planned to show Jamin as well, but we ran out of time. About 80 people assisted the tutorial, which can be considered quite a lot, taking into consideration that the AES audience seems rather Windows and Mac OS X centered. A quick raise your hand survey showed that about 40 percent of our audience were developers. We have the feeling that the tutorial went very well, and that the audience got a good impression of the possibilities of Linux for audio. No real technical problems happened during the demo. We would like to thank all of you who made this possible. That means of course all of the developers, but also the entire community. We had a good time giving this Tutorial, and we hope to have generated some interest in the AES crowd, and given them a good idea of the current state of Linux audio applications. We put the slides at http://iua-share.upf.es/wikis/aes/ and tomorrow we will add some photos. Of course suggestions are welcome! Pau Arumi Maarten de Boer
[linux-audio-dev] problem latencytest: modprobe rtc: no such device
Hello, I decided to give kernel 2.6.10 a try, so I installed it in combination with Con Kolivas system system responsiveness patch. But when I try to run the latencytest (0.5.5), I run into the following problem: $ modprobe latency-test WARNING: Error inserting rtc (/lib/modules/2.6.10-ck2-ck2-pentium4/kernel/drivers/char/rtc.ko): No such device FATAL: Error inserting latency_test (/lib/modules/2.6.10-ck2-ck2-pentium4/misc/latency-test.ko): Unknown symbol in module, or unknown parameter (see dmesg) $ dmesg latency_test: Unknown symbol rtc_register latency_test: Unknown symbol rtc_unregister latency_test: Unknown symbol rtc_control Any suggestion? Maarten
[linux-audio-dev] Re: problem latencytest: modprobe rtc: no such device
Hi Takashi, Thanks for your reply. Did you enable HPET? Hmm, it seems so... I configured my kernel using the debian .config as oldconfig. $ grep HPET /boot/config-2.6.10-ck2-pentium4 CONFIG_HPET_TIMER=y CONFIG_HPET=y # CONFIG_HPET_RTC_IRQ is not set CONFIG_HPET_MMAP=y When hpet timer is enabled, it disables RTC interrupts. Ah, even when CONFIG_HPET_RTC_IRQ is not set?? Even worse, it disables RTC irq even if HPET is not detected from BIOS but only compiled. I see... Ok, I will recompile my kernel with HPET disabled. But maybe a HPET version of the latencytest would be nice, especially since: The High Precision Event Timer (HPET) hardware is the future replacement for the 8254 and Real Time Clock (RTC) periodic timer functionality. maarten
[linux-audio-dev] problems running latency-test 0.5.5 with latest VP kernel
Hello,
I decided to give the voluntary preempt patch a try, so I just build a
2.6.9-rc3-mm3-VP-T3 kernel. But when I try to run the latency-test I
run into the following problems:
First of all, a simple-to-fix compile error in showtrace.c, caused by a
missing
while ((c = getopt(argc, argv, k:hpr:)) != -1) {
while ((c = getopt(argc, argv, k:hpr:)) != -1) {
Now, I run as root, I create /dev/midi0, and I load the latency-test
module
mknod /dev/midi0 c 35 0
modprobe latency-test
but if I configure (default) to use /dev/midi0, I get:
error opening device
Using rtc instead doesn't work either:
error setting freq 1024
(the error is: Inappropriate ioctl for device)
I searched a bit in the archives, and found mention of these problems,
but no solution...
And just an observation, the default wakeup_count=2 fails, because
if (use_rtc wakeup_count != 1)
Any suggestion?
Maarten
[linux-audio-dev] Re: pci gfx card / jack xruns / pci latencies
Hello Florian, Is this with kernel 2.6.x or 2.4.x? I remember there were some problems with Matrox cards, that were initially not included in the 2.4.x low-latency patch, but I thought that at some point Andrew included them. http://www.eca.cx/lad/2002/06/0076.html maarten
Re: [linux-audio-dev] missing fonts in VST plugins: RESOLVED
[...] I didn't have the original MS TTF fonts anywhere on my system, so I grabbed them from my Better Half's machine For those of you that don't have a Better Half (that runs Windows), you can download these fonts from the http://corefonts.sourceforge.net/ download pages. You also need cabextract http://www.kyz.uklinux.net/cabextract.php to extract the .exe files. (This is what the Debian msttcorefonts package does, that's how I found out) maarten
Re: [linux-audio-dev] Tutorial on Professional Audio GNU/Linux Tools
Hello, [EMAIL PROTECTED] wrote: And did you find RoseGarden and Ardour we're sync'd up tightly? I have yet to find them REALLY syncing really tightly what distro are you on? what versions of the software? what hardware? Sorry for not replying earlier. We wanted to do some tests first, and that got delayed a little. About syncing: first of all, we have been using JACK for the sync mechanism. We also tried using MTC, but we could not get that to work. Syncing seems to work okay, in the sense that things keep in sync over time, but we had to adjust offsets to correct the initial sync. We made some tests to get a more clear picture, and in fact we got rather confused instead. I will just give you the results, without trying to explain what happens. I am sure some of you will be able to shed more light on these results. And maybe they can help ardour/jack/rosegarden developers in some way or another Test setup: - jack configured at 44100 Hz, and we tried with 2 buffers of 2048 and 2 buffers of 4096 - A MIDI track in rosegarden4, with a beat at 120 BPM. - MIDI output (USB MIDI-Sport 2x2) connected to an external MIDI module - Audio output from the external MIDI module connected to an Emagic EMI 2|6 USB audio device. - In Ardour, we create two tracks, one to record the audio from the MIDI module, one to record the ardour click (jack loopback). I know the buffersize of jack is very big, but for doing this test, the larger audio latency makes things more obvious. Also, we have not been able to use the EMI 2|6 with ALSA with a period smaller then 2048 without strange ticks. I should contact the ALSA list about this, but on the other hand, this device is a horrible piece of overpriced plastic crap with lousy connectors, that I would not recommend to anyone even with smaller buffer-sizes... Results: About the recorded (jack loopback) ardour-click: Strangly enough, the first click occurs before time=0. Looking at the second click, which should be at 0.5 sec = 22050 frames, we can see how much the clicks are ahead of time: - [EMAIL PROTECTED]: click at 20002 frames; offset = -2048 frames - [EMAIL PROTECTED]: click at 17954 frames; offset = -4096 frames Indeed: exactly 1 buffer. Strange, isn't it? More complicated is the recorded MIDI click. These occur even BEFORE the recorded jack clicks. Now, I am not 100% certain if maybe we set the delay of the MIDI track in Rosegarden (I don't have access to the machine right now, but I will tell you as soon as I do), but I don't think so, and even so, the results are strange. - [EMAIL PROTECTED]: click at 18450 frames; offset = -3600 frames - [EMAIL PROTECTED]: click at 14100 frames; offset = -7950 frames I don't see the relation between those numbers... Versions used: Hardware * Emagic EMI 2|6 * USB Midi-Sport 2x2 (in a Steinberg box) * Acer Travelmate 800 Sofware * Kernel 2.4.26 - patches: Preemptive 2.4.26-pre5-1, RTC 2.4.25, 2.4.25-low-latency * Alsa 1.0.5a * Jack 0.98.1 * Ardour 0.9 Beta 17.1 (Ardour/gtk 0.520.9, libardour 0.820.1) * Rosegarden4 0.98 Maarten
Re: [linux-audio-dev] Tutorial on Professional Audio GNU/Linux Tools
This combination won't work for synchronised MIDI and audio with Rosegarden. Really? It seems to have worked for us. What are the symptoms?
[linux-audio-dev] How does ASIO work?
Hello, I am preparing some slides about Linux audio, and while comparing Linux with Windows, I have been wondering how the ASIO drivers manage to obtain low latency on MS Windows, an operating system that does not seem capable of low latency in any other way. So what tricks did Steinberg come up with to get around that? I'd like to be able to say why the Linux approach is better/cleaner. Maarten
Re: [linux-audio-dev] Traps in floating point code
Hi Erik,
Depending on the ranges of your increment, and the accuracy you
want to obtain, you might consider doing this with integers only.
Maarten
The fix in this case was this:
for (;;)
{
/* Bunch of other code. */
fractional += increment ;
rem = fmod (fractional, 1.0); /* floating point modulus */
integer += lrint (round (fractional - rem));
fractional = rem;
}
Re: [linux-audio-dev]Using python for small multimedia app ?
Hi, This subject reminded me that some time ago, a friend of mine mentioned that he had read a message of James McCartney (SuperCollider) in which James talked about his decision of having implemented his own OO language for SC rather than reusing an existing, generic, OO language. I looked for this message but could not find it, so I wrote James directly, because I thought it might be an interesting addition to this thread. James gave me a very extensive reply, which I forward to the list. Maarten -8 Begin forwarded message: Date: Thu, 3 Jun 2004 15:34:01 -0700 From: james mccartney [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: supercollider vs generic OO languages I've included the original text file you are probably looking for below. Here's some current remarks.. First of all I'm not sure many folks had heard about Python and definitely not Ruby when I began writing SuperCollider in 1994. At that time Python was not the language it is now. So those languages weren't available as choices. Second, neither of those languages are meant for real time. SC has a real time garbage collector, constant time message lookup and various other features designed for real time operation. Python uses reference counting GC which has unbounded time cost when an object is freed. Third SC was written specifically for writing music and audio processes. The math system and behaviour of basic methods in the system were designed for this. I looked into what it might take to make the Ruby math system support building synthesis graphs the way that SC does, and it did not seem like an easy thing to do. I think that as languages SC is certainly comparable in strength to Python and Ruby. SC has the most flexible argument passing of any of them. Any or all arguments can be passed either positionally or by keyword to any function. Keyword arguments can occur in any order. Functions can be passed more or fewer arguments than defined. Unspecified arguments can have default values. Functions can be called with unspecified arguments bound dynamically in the caller's environment. Excess arguments can be collected in arrays. SC has closures and coroutines and is more consistent about their semantics than either Python or Ruby. SC's object model is based on Smalltalk but has also borrowed from Scheme, NewtonScript, J, Icon. SC has borrowed some syntax features from Ruby which happened to have co-evolved with a similar syntax. SC no longer has to run at interrupt level as it did on OS 9, but many of the issues for real time operation are the same. Rather than struggle with a language not designed for real time they should investigate using SuperCollider. It has been ported to linux. SuperCollider 2.0 Why SuperCollider 2.0 ? SuperCollider version 2.0 is a new programming language. Why invent a new language and not use an existing language? Computer music composition is a specification problem. Both sound synthesis and the composition of sounds are complex problems and demand a language which is highly expressive in order to deal with that complexity. Real time signal processing is a problem demanding an efficient implementation with bounded time operations. There was no language combining the features I wanted and needed for doing digital music synthesis. The SuperCollider language is most like Smalltalk. Everything is an object. It has class objects, methods, dynamic typing, full closures, default arguments, variable length argument lists, multiple assignment, etc. The implementation provides fast, constant time method lookup, real time garbage collection, and stack allocation of most function contexts while maintaining full closure semantics. The SuperCollider virtual machine is designed so that it can be run at interrupt level. There was no other language readily available that was high level, real time and capable of running at interrupt level. SuperCollider version 1.0 was completely rewritten to make it both more expressive and more efficient. This required rethinking the implementation in light of the experience of the first version. It is my opinion that the new version has benefitted significantly from this rethink. It is not simply version 1.0 with more features. Why use a text based language rather than a graphical language? There are at least two answers to this. Dynamism: Most graphical synthesis environments use statically allocated unit generators. In SuperCollider, the user can create structures which spawn events dynamically and in a nested fashion. Patches can be built dynamically and parameterized not just by floating point numbers from a static score, but by other graphs of unit generators as well. Or you can construct patches algorithmically on the fly. This kind of fluidity is not possible in a language with statically allocated unit generators. Brevity: In SuperCollider, symmetries in a patch can be exploited by either
[linux-audio-dev] high resolution time patch for 2.6.5 kernel
a collegue pointed me to this post about a high resolution time patch for the 2.6.5 kernel. i'm not 100% if it has been mentioned here before, nor of how much interest it is, but just in case. http://lwn.net/Articles/81400/ maarten
Re: [linux-audio-dev] Request to audio related LiveCD packagers
debian is about to exclude all non-free material from their distributions. this includes firmware, documentation et al. Hi Paul, Where did you read that? It is not what i understand from the changes to the Social Contract, http://www.debian.org/vote/2004/vote_003 -- 5. Works that do not meet our free software standards We acknowledge that some of our users require the use of works that do not conform to the Debian Free Software Guidelines. We have created contrib and non-free areas in our archive for these works. The packages in these areas are not part of the Debian system, although they have been configured for use with Debian. We encourage CD manufacturers to read the licenses of the packages in these areas and determine if they can distribute the packages on their CDs. Thus, although non-free works are not a part of Debian, we support their use and provide infrastructure for non-free packages (such as our bug tracking system and mailing lists). -- Which seems to me just like the current situation. But IANADGE (I am not a Debian guidelines expert) maarten
Re: [linux-audio-dev] Lionstracs / Linux Audio at Musikmesse report
The problem is that the guy that took the video used a camcorder with firewire output, he is not a Linux expert, he uses windows on his PC which has very to easy tools to transfer the videos to the PC and make a video file out of it. On Linux, kino will do this just fine, with a nice GUI. Or, on the command-line, dvgrab, lav2yuv, yuvdenoise, mpeg2enc, lav2wav mp2enc, mplex. I'm against proprietary formats too but unfortunately there is no pratical alternative yet (a format that can be easily viewed by anyone). How about VCD compatible mpeg? That should be possible to view natively on all platforms, right? maarten
[linux-audio-dev] [OT] Fw: 4 Open positions at the Music Technology Group
Begin forwarded message: The Music Technology Group of the Universitat Pompeu Fabra in Barcelona (www.iua.upf.es/mtg), a research group known for its work on audio processing technologies and their musical and multimedia applications, has 4 open positions in different areas and projects: - Graphical interface designer and programmer (MTG-2004-01-UI) - Young researcher: Java, C++ and Artificial Intelligence (MTG-2004-01-PAI) - Young researcher: Audio signal processing (MTG-2004-01-PSP) - Technician for digital music library classification (MTG-2004-01-DML) Find the details on our web page (Join us section). Interested people should send an updated resume (CV) to Salvador Gurrera ([EMAIL PROTECTED]).
[linux-audio-dev] bandwidth limited waveform generators?
hello, i remember that some time ago there was some discussion about bandwidth limited waveform generators. my question is: did anybody compare the various implementations, and does anybody have an idea what would be the fastest? (square, saw) maarten
[linux-audio-dev] Re: [Alsa-devel] alsa 1.0.0 API changes???
Thanks! Out of curiosity: how did you manage to keep binary compatibility? Maarten
Re: [linux-audio-dev] oh no ... virtual vocalists ...
oh it'll be audible, and as a lead vocal, you can bet it'll sound cheesy as hell, except for that FIRST person who uses it, which will probably be Prince but it might be useful for adding backup singers - which is actually what weirds me out - and during the composition phase, just to get a general idea of how the song will sound with the lyrics, without having to get the lead and/or backup singers to the studio.
Re: [linux-audio-dev] plugin GUIs
[snip: paul davis' gtk embedding example]
well, looking at your code, i am not really sure if this is what you
mean, but the attached code shows how to embed an existing X11 window
inside a fltk window (run it, find out the XId of any existing window
(with xwininfo), and enter it in the text input. it does not matter if
the existing window is gtk, qt, motif, fltk or plain X. however there
are some problems, if you move the parent window: motif menus are opened
at the position where the window was first embedded, and for fltk menus
even the menubar buttons itself. if anybody has a suggestion on how to
solve this...
maarten
g++ embed.cxx -lfltk
#include FL/Fl_Window.H
#include FL/Fl_Input.H
#include FL/Fl.H
#include FL/x.H
#include stdio.h
#include stdlib.h
#include string.h
class Fl_Embed_Window:public Fl_Window
{
public:
Window xid_;
Fl_Embed_Window(int ix,int iy,Window xid):Fl_Window(ix,iy,0,0)
{
xid_ = xid;
}
void show(void)
{
XWindowAttributes attribs;
XGetWindowAttributes(fl_display, xid_, attribs);
if (shown()) {
Fl_Window::show();
return;
}
Fl_X::set_xid(this, xid_);
size(attribs.width,attribs.height);
XReparentWindow (fl_display, xid_, fl_xid(window()), 0, 0);
}
};
void embed(Fl_Widget* widget,void* ptr)
{
Fl_Input* input = (Fl_Input*) widget;
Fl_Window* window = widget-window();
Fl_Window* embedded;
char tmp[256];
int xid;
strncpy(tmp,input-value(),255);
sscanf(tmp,%x,xid);
window-add(embedded = new Fl_Embed_Window(0,0,xid));
embedded-show(); // cause the reparent
}
main()
{
Fl_Window window(400,400);
Fl_Input input(0,380,400,20);
input.when(FL_WHEN_ENTER_KEY);
input.callback(embed);
window.end();
window.resizable(window);
window.show();
Fl::run();
}
Re: [linux-audio-dev] plugin GUIs
For what it's worth, this can also be done with FLTK. Maarten
Re: [linux-audio-dev] plugin GUIs
XEMBED style, or foreign window style ? i've already learnt how to do it with Qt ... I don't remember.. I did it once. I think it was foreign window style. Anyway, I'll give it a try tomorrow. Maarten
Re: [linux-audio-dev] What's the best audio IO API on Linux
you might also want to check out Gray Scavone's RtAudio, which is C++ where PortAudio is C, and it provides both blocked and callback based I/O. RtAudio is a C++ class which provides a common API (Application Programming Interface) for realtime audio input/output across Linux (native ALSA and OSS), Macintosh OS X, SGI, and Windows (DirectSound and ASIO) operating systems. RtAudio significantly simplifies the process of interacting with computer audio hardware. http://ccrma-www.stanford.edu/~gary/rtaudio/ maarten
Re: [linux-audio-dev] next power of two
By the way, it seems the PPC has instructions to do it. From the PPC compiler writers guide: Round Up or Down to Next Power of 2 The floor power of 2 ( flp2) and ceiling power of 2 ( clp2) functions are similar to the floor and ceiling functions, respectively, but they round to an integral power of 2, rather than to an integer.
Re: [linux-audio-dev] Job opening
PS: I couldn't tell from the list guidelines whether this kind of post is appropriate. If not, sorry! and please ignore it. I think that the general consensus is that this kind of post are welcome. Linux audio jobs, or even computer audio jobs, are rare enough, and an employer has little other reasonable means to get in contact with possible employees. Also, I'm sure that not all of the LAD subscribers are actually doing audio software development for a living, but might like to :-) Maybe the list guidelines should include something about this? Along the lines of You are welcome to send job offers and research positions to the list, provided they are directly related with audio software development under Linux. We can always reverse that policy if we notice that the amount of job offers gets in the way with the real discussions ;-) Maarten
[linux-audio-dev] next power of two
Hi,
A colleague of mine found this very clever algoritm to calculate the
next power of two for a given number. It comes from the Prophecy SDK for
3d game development
http://www.twilight3d.com/modules.php?op=modloadname=Downloadsfile=index
Since this is a kind of thing often needed in audio processing, I wanted
to share it with you. I certainly can not think of a faster (or more
elegant) way of doing it.
Maarten
//
/// Returns the closest power-of-two number greater or equal
/// to n for the given (unsigned) integer n.
/// Will return 0 when n = 0 and 1 when n = 1.
//
inline uint32_t nextPowerOfTwo(uint32_t n)
{
--n;
n |= n 16;
n |= n 8;
n |= n 4;
n |= n 2;
n |= n 1;
++n;
return n;
}
Re: [linux-audio-dev] Poll: Distro for audio and MIDI development
This is a nice coincidence, because I just installed Debian Sid
('unstable') on my home workstation.
I am also a convinced Debian user, and all the servers and workstations
I administrate are Debian Woody ('stable'). Now, recently, I have seen
myself forced to install more and more backported packages, and backporting
some myself, because Debian stable is rather conservative, and this can be
a problem if you have new hardware, esp. video cards, or if you need to run
recent versions of applications, are depend on recent versions of
libraries...
Personally, I think the release cycle of Debian should be a lot shorter,
and I think a lot of people agree with that. On the other hand, on the
web/mail/file/cvs servers I run, I really want stable. The good thing is,
you get the choice, and I think Debian is the only distro with such a
choice. A lot of distro's present unstable and untested things as
stable. For me the clearest example, and actually the reason I switched to
Debian, was RedHat's broken GCC (2.96 I think), which I guess was just
included to pretend to be cutting edge. Now, I recently installed a
RedHat 9, and with PlanetCCRMA on top, it is very nice, but running Debian
Sid does not feel less safe to me. And I would never run any mission-
critical servers with RedHat. Here Debian stable is the safest bet.
Anyway, I expect that I might switch to unstable, or at least testing, for
some of the workstations, when I feel that modifying stable becomes more work
and also more risky, than simply using unstable.
Maarten
Re: [linux-audio-dev] Poll: Distro for audio and MIDI development
By the way, Knoppix uses Debian sid, and is overall considered to be a very good demonstration of Linux' capabilities, both in features and in stability. I don't think it would have gotten the recognition it has, if people would have found it buggy or unstable. Maarten
Re: [linux-audio-dev] OpenAFS and preemptible patch
for the record, plain old nfs has always worked for me. any reasons you are not just using that ? (ok, i know it sucks in many respects, esepcially security, but then low latency audio implied a trusted environment anyway...) yes, nfs is what we are using currently. the problem is that users, being root on their own machine, can su to any other identity. nfs doesn't care about that. this is of course a feature :-( maarten
Re: [linux-audio-dev] OpenAFS and preemptible patch
We have the same situation at work, I have root on my desktop so I'm not allowed to NFS mount the fileserver. But it will allow you to su to any user id, and mount it. That's the problem. AUTH_DES seems to be the solution, but is not implemented on Linux :-( Have you looked at shfs, it allows you to mount filesystems using ssh, so you can just use key authentication so theres no need for passwords. http://shfs.sourceforge.net/ I've used it on a patched kernel without probems. Looks interesting, but the first line in the installation guide Warning: This is beta quality code. It was not tested on SMP machine. Backup data before playing with it! is a bit scary... Maarten
Re: [linux-audio-dev] OpenAFS and preemptible patch
http://shfs.sourceforge.net/ LUFS looks quite a bit more mature. http://lufs.sourceforge.net/lufs/
[linux-audio-dev] OpenAFS and preemptible patch
Hello, I have been doing some tests with OpenAFS, and it hangs on me frequently. On the OpenAFS I found out that this is very likely caused by the preemptible patch. Knowing that a lot of people around here are using that patch, I'd like to ask if any of you have experienced the same, and know of a solution, or an alter- native that NFS which would work well with low latency kernels. Maarten
Re: [linux-audio-dev] OpenAFS and preemptible patch
I experienced the same problem. I posted on OpenAFS-info but nobody came up with a solution or even indicated that the problem had been looked into at all. Well, I got a reaction that was even less encouraging: Well, it's either AFS or the preemption patch. You can choose... Maarten
Re: [linux-audio-dev] patches for kernel 2.4.21 ?
i'd encourage people to try 2.5 to iron out audio-specific problems before we go into 2.6-test and the developers get nervous... I'd love to, but a real show-stopper is that the (evil closed source) nvidia drivers don't support the 2.5 kernel... I've seen some patches for older versions (both kernel and drivers) but obviously I want cutting edge :-) . Has anybody got the (latest) NVidia drivers to work with the latest 2.5 kernel? (This might seem to be off-topic, but I need accelerated X to display audio) Maarten
Re: [linux-audio-dev] patches for kernel 2.4.21 ?
Has anybody got the (latest) NVidia drivers to work with the latest 2.5 kernel? Ah, answering myself, I just found patches at http://www.minion.de/ Maarten
Re: [linux-audio-dev] patches for kernel 2.4.21 ?
look here: http://members.optusnet.com.au/ckolivas/kernel/ thanks, that's a very interesting page. maarten
[linux-audio-dev] patches for kernel 2.4.21 ?
hello, it seems that the preemptible and the low latency patches are not yet available for the latest kernel, 2.4.21 has anybody succesfully applied older patches? any idea if the new patches are being worked on? maarten
Re: [linux-audio-dev] patches for kernel 2.4.21 ?
and that seems strange? ;-) no, though in the past i have been amazed sometimes :-) the -ac changelog. To me, it's trivial to patch the rejects, but to someone that isn't all that excited about it, it can be daunting. sure, but getting the rejects to patch does not mean that the patch is complete... i mean, new code paths might have been added that require new stuff to be added in the patch, especially since such a long time has passed between 2.4.20 and 2.4.21 anyway, i talked to andrew morton, and he suggests that it is better to go for 2.5.x ... maarten
Re: [linux-audio-dev] How to delay video?
On Thu, 6 Mar 2003 18:46:27 +0100 Maarten de Boer [EMAIL PROTECTED] wrote: i have not tried this, but i would say that using mencoder in copy mode writing to a fifo and mplayer reading from that fifo could do the trick. I was talking nonsense here. Maarten
Re: [linux-audio-dev] How to delay video?
i have not tried this, but i would say that using mencoder in copy mode writing to a fifo and mplayer reading from that fifo could do the trick. the time between launching mencoder and mplayer determines that delay. maarten
[linux-audio-dev] [ANNOUNCE] polarbear-0.5.0
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
[linux-audio-dev] [ANNOUNCE] tapiir-0.7.0
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
Re: [linux-audio-dev] Blockless processing
I couldn't resist it so I hacked up a quick script to try the blockless, dynamicly compiled processing we were discussing the other day. Hi, I missed that discussion (do you have a pointer?) but it all seems very much related to the example i posted some while ago: http://www.eca.cx/lad/2002/07/0409.html http://www.eca.cx/lad/2002/07/0410.html with the difference that in my case the same source can be used to either generate efficient code or be compiled and execute at runtime. Maarten
Re: [linux-audio-dev] smpte generating code
my thought was that i could avoid this by actually emitting SMPTE itself, which is an audio stream, and thus can be generated with perfect sample accuracy as we go. this can then allow people with equipment that can read a SMPTE signal and/or convert it to MTC to get their devices to lock to Ardour's timecode, rather than respond to it. that sounds like a good idea. anyway, my SMPTEDecoder is only a decoder, as it's name kinda suggest. I did write an encoder as well, though I have no idea where I left that code. That's more than 6 years ago. Anyway, encoding is be a lot easier than decoding. But if you want I can look for the code (don't hold your breath though) Maarten
Re: [linux-audio-dev] smpte generating code
i know that someone posted smpte-reading code here last year. does anyone have any pointers to source code to generate smpte? that's me :-) ftp://www.iua.upf.es/pub/mdeboer/projects/SMPTE/ you can find the sourcecode for the SMPTE decoder, and some reallife SMPTE signals (from analog tape) that I used to test the decoder. what do you want to use it for? i would be very happy if the code has some use. maarten
Re: [linux-audio-dev] smpte generating code
i just found the whole smpte discussion in the archives. it's a nice read, complete forgot that it was such a long thread. it starts with http://eca.cx/lad/2000/Jul/0287.html by the way, i quote from one of the messages: i wish to god that SMPTE had never taken off. its the most ridiculous thing since, errr, oh, something like APL. more precisely, its fine for video timing, but its *insane* that its become accepted for audio timing. written by paul david :-) . changed your mind, paul? ;-) maarten
Re: [linux-audio-dev] disk latency under 2.4.19 ll+preempt
On 19 Nov 2002 15:29:19 -0500 jfm3 [EMAIL PROTECTED] wrote: I'm running the low latency and preemption kernel patches on 2.4.19. I'm getting disk copy latency of around 10ms. Since I'm a real time person (according to M. Goggins) who doesn't use the hd in real time, I can live with this, but it bugs me. I've tried ext2 and ext3, no difference. Any other tips? Do you have support for your chipset unabled under IDE, ATA and ATAPI Block devices in your kernel configuration, and Use PCI DMA by default when available? I believe this is rather important. Maarten
Re: [linux-audio-dev] disk latency under 2.4.19 ll+preempt
On my asus A7V266-E board i had to set down dma mode from DMA100 to DMA33 get LL working fine. (3ms) That is very interesting information (I have the same board). Did you discover this by trial and error? Maarten
Re: [linux-audio-dev] OT CPU Fans
I have the same problem as you. And the additional problem of having the PC in the livingroom, where I am torturing my daughter and girlfriend with the noise :-( Anyway, when I bought my pc, the already gave me a more expensive fan, because the got so many people complaining about the noise. That fan was a Thermaltake Volcano. http://www.thermaltake.com/products/heatsink/v7.htm But it is still way to noisy for me. I replaced it by a Zalman. http://www.zalmantech.com/CNPS-5100CU.htm Noise did reduce, though certainly not as much as expected from the salestalk, and not as much as I hoped. And temperature gets pretty high, but I have been told that this is likely because of the mainboard, an ASUS A7V 266E. I am no overclocker, but even with underclocking I need to have the fan running rather high to keep temperatures reasonable. I also replaced the fan in the power supply, which did make some difference, but still not enough. The last thing I will try is replacing the fans with Verax Silencers or Verax Cair dB, but they are hard to find here (Barcelona) All in all, I am pretty annoyed with the whole thing. I certainly regret having bought an AMD Athlon and a ASUS mainboard. I have no experience with Pentiums and other mainboards, but as I understand they don't run as hot. If I would buy my computer knowing all this, I probably would by a PowerMac. Maarten
Re: [linux-audio-dev] OT CPU Fans
Really? I've got an A7V266E and haven't noticed anything hot.. and anyway, I've never heard of a motherboard making a system hot in the first place. I have no prove of this, it is just something I heard. But I do have to say mainboard temp gets high, but I am not sure if this is the processors fault. The A7V266E *does* happen to have a motherboard fan on it, but from what I hear it is just for show and overclockers. There are many other boards with the exact same chipset which don't come with a fan, so go figure. Asus always made their boards to be as stable as possible under overclocking conditions, so I guess that meant adding a cheap fan in this case. [...] Did you try removing the fan on the motherboard chipset? It's a worthless, cheap fan, which has been known to be loud. Yes, this is a particular noisy fan, with a very annoying high frequency component. Are you suggesting that I can turn it of safely if I am not doing overclocking? Currently, I am actually doing underclocking (running an AMD Athlon XP 1700+ at 1100) So I think that your regrets about the Asus motherboard and AMD athlon are likely to have been misplaced. In my experience, these choices have nothing to do with noise. It has much more to do with the particular fans you get. What fans do you use? Or isn't the noise a problem for you? Maarten
Re: [linux-audio-dev] OT CPU Fans
Where are you reading your temperatures? You sure that it's the motherboard and not the CPU? Do you know where on the motherboard this reading is coming from (the chipset, or just a general ambient case thermometer)? In the BIOS. I suppose it is the chipset. What type of climate do you live in? (Is the room temperature hot?) Köppen classification Csa ;-) (Barcelona) I do have airco though. Which makes a lot less noise than my PC! Anyway, thanks for all your suggestions and information Maarten
[linux-audio-dev] storing floats in ascii format
Hello, Storing large arrays of floats in XML files is very unefficient when it comes to space. Where in a binary format each float would contain only 4 bytes, in a ASCII format this number much bigger. A simple solution would be to store the values as binary inside the XML. It is too bad XML does not have a way to do this.. The binary format will contain \0's, and certainly most XML parsers will choke on those. So, I was thinking to use binhex, or something similar, encoding the 32 bits in 7 bit values in the ascii character range. Thus, each float would take 5 bytes. However, maybe a more compact encoding is also possible, using some variable length encoding. Does anybody have experience with this, or pointers to implementations? Or any suggestion at all? Maarten
Re: [linux-audio-dev] storing floats in ascii format
So, I was thinking to use binhex, or something similar, encoding the 32 bits in 7 bit values in the ascii character range. Thus, each float would take 5 bytes. i am wrong.. binhex, uuencode, xxencode and base64 use 6 bit values, also known as 3-in-4 encoding (3 8-bit values = 24 bit - 4 6-bit values) But the idea is the same. Maarten
Re: [linux-audio-dev] storing floats in ascii format
the thing i like about xml is it's human-readable. doing binary in xml combines all the bloat of the former with the ugliness of the latter... yes... do you expect to have such masses of float data that size will become an issue ? yes. lots of FFT bins, sinusoidal peaks and tracks... a 5 sec sound easily results into 5 meg analysis data. we will also use SDIF, but that has other issues. storing the large binary chunks somewhere else (after the xml), and have keep only references to these chunks in the xml seems the best solution. Maarten
[linux-audio-dev] Re: [linux-audio-user] bristol synthesis emulation
I take this to linux-audio-dev... Feature request: alsa 0.9 support, preferably including alsa sequencer support. I want to play these synths from If I can help please let me know ! What about MIDI control of the potentiometer / slider / switches ? I own all kind of doepfer's MIDI controller equipment, so my motivation to help is high ;-) Actually, it would be really nice if the communication between synthesis engine and gui would be (optionally) through the alsa sequencer. This would 1) make it very easy to control the synthesis parameters with some other program than the gui, typically a sequencer or jMax or PD or even an alternative gui, and 2) make it possible to record the parameter changes in a sequencer. By default the bristol engine and gui would be connected, but the user can decide to change that. This would really show the power of the alsa sequencer. Nick, would there be any inconvenience in using this approach, and how difficult would it be to implement? (I did not look into the bristol sources... does the synthesis engine fully implement the MIDI protocol of the emulated synthesizers? Ah well, of course not all of them have a MIDI protocol...) Maarten PS: Nick, are you on this list?
Re: [linux-audio-dev] Help with LATENCY FULL DUPLEX AUDIO
On Fri, 26 Apr 2002 00:37:21 +0200 (CEST) [EMAIL PROTECTED] wrote: Hello, I am just working (finishing) on modular realtime effect procesor. It is my thesis project. I would like to ask three questions: 1. How can I calculate the latency in ms with OSS driver? I would strongly advice you to use ALSA (0.9) instead. The alsa-lib/test/latency.c is a good starting point for realtime I/O, and it tells you the latency! 2. My program do the effects on audio in realtime. So I added recording the sound to hard disk. This work ok. But when I play back the recorded sound (from HD), it changes me buffer length that latency is very big. My solution to this problem was to close device and initalize same device one more time after playing the sound. Is there better solution for me? If you want low latency, you should never do playback and record to HD in the same thread as you audio i/o! The access to disk can take too long. Better to you a seperate thread for the disk i/o, and use some (circular) buffers in between, the gets filled by the audio in, and emptied by the disk out, or filled by the disk in, and emptied by the disk out. If you search the list archives, you can find some more e-mails about this by Paul Davis (though don't try to search just on paul davis, the amount of hits is dazzling ;-) 3. Is there some advices how to set the lowest latency? The is a lot of advice about this on the LAD webpage. Mainly: Patch your kernel. Maarten
[linux-audio-dev] [ANNOUNCE] alsamixergui and aconnectgui synced with 0.9.0rc1
Hello, I just updated alsamixergui and aconnectgui. The code is now up to date with alsa-utils 0.9.0rc1. alsamixergui and aconnectgui are fltk front-ends for alsamixer and aconnect. thet are written directly on top of the alsamixer and aconnect source, leaving the original source intact, only adding a couple of ifdefs, and some calls to the gui part, so they provide exactly the same functionality, but with a graphical userinterface. other changes: some bugfixes, most important a layout problem of aconnectgui Sources and screenshots can be found at http://www.iua.upf.es/~mdeboer/projects/ Please let me know if you encounter any problems. Maarten
[linux-audio-dev] Re: [Alsa-devel] ALSA homepage redesign
Hello Patrick, Looks very nice. Am I correctly assuming that you will be the maintainer of the ALSA pages from now on? Could you add the following alsa 0.9 applications I wrote: http://www.iua.upf.es/~mdeboer/projects/tapiir/ http://www.iua.upf.es/~mdeboer/projects/aconnectgui/ http://www.iua.upf.es/~mdeboer/projects/alsamixergui/ Thanks, Maarten
[linux-audio-dev] sound cancelation with anti-sound
i have been thinking about the following before, and now that i read about it on slashdot, and it got me thinking a bit more. the issue is sound cancelation. the article mentioned on slashdot, http://www.newscientist.com/news/news.jsp?id=ns2094 talks about a (very expensive) general approach of removing sound with anti-sound. personally, i am more interested in a very specific noise: the noise of the cooling fans in my pc. i am sure it would be possible to have a background application running that uses the soundcard (could be a cheap one) to do this. the sound of each fan has almost constant pitch, and i suppose it is harmonic. the application should record the noise, analyse it: determine the pitch of each fan and seperate the sounds of all fans, invert each signal, and play it back. this should work reasonably well as long as the pitch doesn't change. by reanalising constantly, any changes in the sampled signal have the be analyses and added to the canceling inverted signal. the problem is the sound seperation. The application should be low on CPU usage, so I guess time domain processing is the only option. but we are talking about let's say 3 different signals with rather simple content... any suggestions / remarks? maarten
[linux-audio-dev] RTC timer question
Hello, I sent the following to the ALSA list, but did not get any answer, so I repost it here, hoping anybody has delt with this before. First, I noticed that the alsa rtctimer is not compiled when you have the RTC in your kernel as a module. The problem is in alsa-kernel/core/Makefile, where CONFIG_RTC is tested for y and not for m. Second, I like to know where can I find up-to-date documentation about how to use the rtc timer. The latest I find is a mail by Takashi, that is a year old, which says: Installation: Add the following lines in /etc/modules.conf: options snd-timer snd_timer_limit=2 alias snd-timer-1 snd-rtctimer For using RTC timer in sequencer as default: options snd-seq snd_seq_default_timer=1 This is not working anymore, because parameters changed. Starting sound driver: snd-emu10k1 done /lib/modules/2.4.18/kernel/sound/acore/seq/snd-seq.o: invalid parameter parm_snd_seq_default_timer /lib/modules/2.4.18/kernel/sound/acore/seq/snd-seq.o: insmod /lib/modules/2.4.18/kernel/sound/acore/seq/snd-seq.o failed /lib/modules/2.4.18/kernel/sound/acore/seq/snd-seq.o: invalid parameter parm_snd_seq_default_timer /lib/modules/2.4.18/kernel/sound/acore/seq/snd-seq.o: insmod /lib/modules/2.4.18/kernel/sound/acore/seq/snd-seq.o failed /lib/modules/2.4.18/kernel/sound/acore/seq/snd-seq.o: insmod snd-seq-midi failed Also, is there any way (apart from 'listening') to know whether the rtctimer is used by the sequencer or not? Maarten
[linux-audio-dev] realtime audio i/o with disk input
Hello, I mainly write this mail to Paul Davis, but of course everybody is welcome to answer :-) I am trying to do realtime audio i/o in combination with disk input. I know that Paul has a lot of experience with this. Rather than looking through his code, I'd appreciate some description of the approach he uses. I will comment my approach here, to see if you consider it correct or not. . What I am doing: I have 3 threads: - standard priority GUI thread - audio I/O thread (SCHED_RR, max, using alsa polling) - disk input thread The disk-input thread writes to a circular buffer, reading blocks of data from the hard-disk. It actually pre-fills it before starting the thread. The audio i/o thread reads from the circular buffer (and mixes it with the soundcard input, and writes it to the soundcard output, but that is not really relevant) The disk-input thread looks if it has space to write the next block to the circular buffer (it checks if the write-index will not cross the read-index). If there is no space, it waits for the readindex to move. This is done with a pthread_cond_wait in the disk-input thread, and a pthread_cond_signal in the audio i/o thread. pseudo-code: disk-input thread: pthread_mutex_lock while writeindex+blocksize readindex pthread_cond_wait pthread_mutex_lock audio i/o thread: pthread_mutex_lock readindex += fragmentsize pthread_cond_signal pthread_mutex_unlock In a similar way, the audio i/o thread also checks if the readindex will not pass the writeindex, which happens when the disk input thread did not fill the circular buffer in time. Also this is done with a pthread_cond_signal / pthread_cond_wait. Problems: - It tends to run well, but sometimes it chews up a lot of CPU or even all. I don't understand when this happens exactly. (this is the second time I write this mail: the first time I had the application running and it froze my machine. Hint: never write long e-mails while beta testing realtime priority applications ;-) ) - I can cause internal underruns (not filling the circular buffer in time), by doing a cat /dev/hda /dev/null - Also using X-windows can cause problems. I suppose this is VM related? Questions: - Is this approach correct? - Is the pthread_cond_wait the correct mechanism for the thread synchronisation? - With what priority should the disk input thread run? - Is it better to use SCHED_RR or SCHED_FIFO for the audio i/o thread? - Should I call mlockall? What would be the best moment to do that? - What would be a reasonable size for the circular buffer? And what about the blocksize to read the data from disk? Does that even matter? My system is an AMD k7 700 MHz, hdparm tuned,. 2.4.17 Andrew Morton LL kernel. Greatly appreciating your time and effort, Maarten
Re: [linux-audio-dev] realtime audio i/o with disk input
Thanks. Looking through Mustajuuri code, I have the impression you use the same approach as I do (that's at least reassuring). I will do some tests to see if the same problems occur, which would mean that they are caused somewhere else. Maarten
Re: [linux-audio-dev] realtime audio i/o with disk input
Thanks Paul for your reply. don't ever run application threads at max priority. it makes it impossible to construct a watchdog for runaways. Okay, I'll make that max-1 you don't need to use mutexes for the buffer itself. when there is one reader and one writer, you can use a lock free ringbuffer. this will avoid blocking the audio thread when it goes to see if there is enough data. Okay. Anyway, things are Wrong when there is not enough data. however, you probably do need to use mutexes to drive the disk input thread's operations. in ardour, the disk input thread gets woken periodically by the audio thread when the latter believes that work might be necessary. the disk input thread wakes up, checks on the current state of things, and then (maybe) gets busy. Okay, so I understand that you use the audio thread check if the buffer needs to be filled, the opposite of my approach, where the disk in thread checks this. Any particular reason for this? Ah, okay, in my approach the disk-in thread enters a while to see if the readindex has moved enough. It checks all the time, even if the readindex did move but not enough. With your approach, you only signal when you _know_ it has moved enough. Is that it? What is the wake-up mechanism you use? pthread_cond_signal/wait? never beta test applications with RT priority :) you don't need RT priority to get this to work. But at some point I need to run in in RT priority to see if that works. are your IDE drives properly tuned with hdparm? there was a thread on alsa-devel about in the last 24 hours in which using hdparm completely fixed precisely this issue. I believe I did. I run tunedisk from Benno's latencytest. several people have reported X Window issues. this seems to be specific to particular video adapters and/or motherboards. are you using a low latency kernel, and is low latency turned on? which Yes (Andrew Morton), and yes (echo 1 /proc/sys/kernel/lowlatency) version of XFree86 are you using, and which video adapter? 4.1.0 (debian woody), Matrox MGA 400 Maarten
[linux-audio-dev] [ANNOUNCE] aconnectgui
aconnectgui is a FLTK based frontend for aconnect. It is written directly on top of the aconnect source, leaving the original source intact, only adding a couple of ifdefs, and some calls to the gui part, so it provides exactly the same functionality, but with a graphical userinterface. http://www.iua.upf.es/~mdeboer/ Note that this is a (quick) port to alsa 0.9.x . I wrote this originally for alsa 0.5, when it was called aseqpatchbay. I currently don't have a soundcard with any interesting MIDI devices, so I would apreciate if you let me know if it works for you. The code needs to be cleaned up and documented. Feel free to do this or make any other improvements :-) Maarten
[linux-audio-dev] Re: [Alsa-devel] [ANNOUNCE] aconnectgui
yes, that sounds like a layout problem. i will try to get my hands on a SBLive, and also use some virtual midi ports. as you might have noticed, this release is still rather beta: lot's of printf to be removed ;-) maarten
Re: [linux-audio-dev] [announce] ALSA Patch Bay 0.1
I just completed version 01 of a very scrappy but functional gui midi patch bay for alsa's seq api It's essentially just a graphical version of aconnect It's available from: I wrote one already a long time ago (though for alsa 05x, but it should be easy to port) ftp://wwwiuaupfes/pub/mdeboer/aseqpatchbay-01gif ftp://wwwiuaupfes/pub/mdeboer/aseqpatchbay-01tgz it has the same estetics as my alsamixergui (which I have a version for 09x, based on the latest CVS sources, I should make it available ASAP) Maarten
Re: [linux-audio-dev] [announce] ALSA Patch Bay 0.1
On Tue, 05 Mar 2002 08:33:53 -0500 Dave Phillips [EMAIL PROTECTED] wrote: Maarten de Boer wrote: ...my alsamixergui (which I have a version for 0.9.x., based on the latest CVS sources, I should make it available A.S.A.P) Please !!! You can download it from http://www.iua.upf.es/~mdeboer/projects Please let me know if you experience any difficulties compiling/running it. Maarten
[linux-audio-dev] 2.4.16 low latency freezes
Hello, Having changed my soundcard (from Trident 4D Wave NX to ens1371) while the trident driver is broken, I am now achieving good low latency results on my AMD Athlon, with a kernel compiled for Athlon. I moved to the latest kernel, 2.4.16, with Andrew Morton's low latency patch, but when I activate low latency (echo 1 /proc/sys/kernel/lowlatency), after a while my system starts slowing down (notable the mouse movement gets very sluggish) and finally freezes. I did not experience these problems with kernel 2.5.15-pre5 Any suggestions? Maarten
Re: [Alsa-devel] Re: [linux-audio-dev] latencytest results webpage
Andre Pang [EMAIL PROTECTED] wrote: I am thinking of setting up a webpage, where people can post their latencytest results, so we can keep an inventory of the several combinations, categorising on: This is a great idea. I actually started re-writing the latency testing harness scripts because I thought they were too inflexible, and I'm almost finished with the re-write. The idea is to include as much system information as possible in the results , such as kernel version, processor, SMP, VM parameters, as well as making it easy to add new tests to the testing suite. (Think 'download new file and drop in directory' easy). I'll write the list when the new testing suite is ready for release. Sounds very good. I can provide server space to host the test results, and write some CGI to display them. I think the best way is to submit them by e-mail, having the test scripts write out an e-mailable form. I am not very sure though what to do with the images; are these really necesary to get a good idea of the results, or would the maximum latency + number of underruns by sufficient? Maarten
[linux-audio-dev] Re: more bad low latency results
Takashi Iwai [EMAIL PROTECTED] wrote: Hmm, I'm using an Athlon 600 MHz and got promising results even with it. You can find the results (on different conditions) under http://alsa-project.org/~iwai/latency-results/2.4.12 The result with all LL-patches is found in ll-all directory. Yes, that really looks good. What do you man with all LL-patches? And what do you mean with VM-tuned? Where can I find information about that? The kernel was based on SuSE's 2.4.12, which is mostly equivalent with AA-patch. What is the AA-patch? Andrew Mortons' ? FS is reiserfs. Compiled with ARCH_M586. do you mean the kernel configuration, CONFIG_M586=y ? What soundcard do you use? Maarten
Re: [Alsa-devel] Re: [linux-audio-dev] Re: more bad low latency results
On Thu, 15 Nov 2001 18:35:33 +0100 Andy Lo-A-Foe [EMAIL PROTECTED] wrote: On Thu, Nov 15, 2001 at 05:28:19PM +0100, Maarten de Boer wrote: It would be really nice if somebody could repeat my tests on identical or similar hardware (AMD Athlon, Trident 4DWave NX), with the same versions of kernel, patch, and alsa (latest cvs that is). I will try with a es1371 to see what happens with the alsa I/O... I can give it a try. Which latencytest are you using? The lastest version I have here is latencytest0.42-png?! I have a AMD Athlon 1333 with a Trident 4DWave NX. That would be great. I use latencytest0.42 as well (gif). Tell me what kernel you use. Maarten
[linux-audio-dev] Re: [Alsa-devel] Re: more bad low latency results
Or, will you try AA patches? It's not a bad idea, since the current (vanilla) VM is based on Andrea's code. Linus still doesn't include all his patches. Yes, I will try the AA patches, though I am not very sure which to use, and on which kernel. The most recent one on a standard kernel (and not on a pre-release) seems to be http://kernel.org/pub/linux/kernel/people/andrea/patches/v2.4/2.4.12aa1.bz2 Or do you think it is better to jump into the deep, and try to apply 2.4.15pre1aa1.bz2 on 2.4.14 ? Maybe my 2.4.13 LL patches at ftp.suse.com/pub/people/tiwai/suse-patches can be applied without rejection. It's a different problem. The alsa capture adds random values at random places (not periodically as for a I can see) in a way that it sounds like a dusty vinyl record. This doesn't happen when I use arecord, it only happens with the alsa-lib/test/latency. I write each captured buffer to disk, and the random values are clearly visible (and hearable). It happens both in non-block and in poll mode. Hmm sounds like h/w problem, then.. It's interesting to know where the data is contaminated, whether on the driver level or transfer between capture and playback on user-space, or what else.. I would say on driver level: I write the data to disk right after the snd_pcm_readi call. Maarten
Re: [Alsa-devel] Re: [linux-audio-dev] Re: more bad low latency results
Okay, here's my setup: - kernel 2.4.15-pre4 + Robert Love's preempt patches (http://www.tech9.net/rml/linux/) - kernel HZ value set to 1000, default is 100 (see /usr/src/linux/include/asm/param.h) - alsa 0.9.0beta9 + Trident 4DWave NX - SCSI hard disk with ReiserFS - Geforce2 GTS videocard + NVidia binary drivers + XFree 4.1.0 - 1GB RAM Your results look good. For what processor did you compile your kernel? Can you run the alsa-lib/test/latency test (and use a CD as input) and tell me if it sounds good? Maarten
[linux-audio-dev] Re: more bad low latency results
On Thu, 15 Nov 2001 13:50:39 -0500 Paul Davis [EMAIL PROTECTED] wrote: Hmm sounds like h/w problem, then.. It's interesting to know where the data is contaminated, whether on the driver level or transfer between capture and playback on user-space, or what else.. I would say on driver level: I write the data to disk right after the snd_pcm_readi call. i hope i'm forgetting something. you're not writing to disk from the same thread as called snd_pcm_readi are you? that's guaranteed to eliminate low latency performance ... As a matter of fact I am, but in this case I am not measuring latency. What happens is that the sound thru of the alsa-lib/test/latency sounds bad. I want to know where this happens, so I write the input to disk right after snd_pcm_readi. With a big fragment size. And obviously, the problem existed before I started writing to disk; if not, I would not have written to disk :-) Maarten
Re: [linux-audio-dev] weird distortion with alsa latency test
When I compile my kernel for i386 on an AMD Athlon, the alsa latency test is giving me weird distortion (knispering sound, like a dusty vinyl record) $ arecord -r 44100 -f S16_LE | aplay does not seem to have this problem. I investigated this matter a bit further, and the crackling sounds are actually at capture: I run the alsa-lib/test/latency , and write all input sound to a file. When I look at it, it confirms what I hear: random values at random places. When I generate playback instead of playing the input sound, it sounds okay. This happens with latest alsa, and my kernel compiled for 386 on a AMD Athlon. Maarten
[linux-audio-dev] Re: more bad low latency results
I've used this setting: echo 6 /proc/sys/vm/vm_scan_ratio echo 2 /proc/sys/vm/vm_mapped_ratio echo 4 /proc/sys/vm/vm_balance_ratio Uuhh... I don't have these files... $ ls /proc/sys/vm/ bdflush kswapd overcommit_memory page-cluster pagetable_cache Did I miss something in my kernel configuration? That's really weird.. How about to measure the time of read/write responce in latency.c so that we can know at least whether it's related with the kernel latency. It's a different problem. The alsa capture adds random values at random places (not periodically as for a I can see) in a way that it sounds like a dusty vinyl record. This doesn't happen when I use arecord, it only happens with the alsa-lib/test/latency. I write each captured buffer to disk, and the random values are clearly visible (and hearable). It happens both in non-block and in poll mode. Maarten
Re: [linux-audio-dev] more bad low latency results
On Tue, 13 Nov 2001 14:40:42 -0600 Christopher Deckard [EMAIL PROTECTED] wrote: i'm getting ~8ms on an AMD K6 running 2.2.17 LL under RH6.1, and using uncsound 4.x. that's not 3ms either... Maarten
[linux-audio-dev] Re: more bad low latency results
I did not get any reaction on one of my previous mails, so I send it again. There have been numerous reports on this list about good LL, and now I find it very frustrating I can not get it myself. Please help me out! I'd really hate the get the impression that the whole LL issue is still unreal. Since with AMD Athlon I get either bad low latency (compiling for AMD) or bad sound quality (if I compile for 386. really don't understand why..), I now did some tests on a Pentium III. The results are still not good: kernel 2.4.14 low latency patch a Pentium III 800 Mhz, http://193.145.55.36/latencytest/2.4.14-LL-PIII/3x256.html I am getting really disappointed. It's no fun to compile kernels and alsa with different configurations lots of time only to get bad results. What kernels are you guys running? What would be the safest bet? On what processor? I really want it to work well on the AMD Athlon. Anybody using an AMD Athlon and has good LL results?
[linux-audio-dev] Compiling LL kernel for AMD without 3DNOW
Hello, In reply to D. Stimits and Roger Larsson about compiling an LL kernel for AMD Athlon without the 3DNOW optimizations I still get the undefined references to the *_mmx_* functions. I am perfectly sure that I really recompiled it all, and to demonstrate it, here follow the steps I toke: I try it with a freshly unpacked kernel, as follows: $ rm -rf linux $ rm -rf linux-2.4.10-LL/ $ tar xIf linux-2.4.10.tar.bz2 $ mv linux linux-2.4.10-LL $ ln -s linux-2.4.10-LL linux $ cd linux $ patch -p1 ../2.4.10-low-latency.patch $ make xconfig I set my Processor Family to Athlon/Duron/K7, turn of SMP (why is that set by default?), turn on low latency and low latency sys ctl, configure my SCSI and Ethernet drivers to be compiled as modules, and leave the rest of the options at their defaults. I now edit my .config, commenting out the line, changing CONFIG_X86_USE_3DNOW=y to # CONFIG_X86_USE_3DNOW is not set I edit the top Makefile, setting EXTRAVERSION = -LL-AMD-NO3DNOW and I compile with $ make dep $ make and get the undefined references!! Now, I try what Dave suggests: $ cp .config ../2.4.10-config $ make mrproper $ cp ../2.4.10-config .config $ make oldconfig $ make dep $ make and _AGAIN_ I get the undefined references. So I am really wondering now: what am I doing different? I mean you _did_ indeed compile the kernel for AMD without 3DNOW, did you? Maarten
[linux-audio-dev] jackd
Hello, When trying to run jack, I got the following error: jackd: error in loading shared libraries: jackd: undefined symbol: mknod This was easily solved adding #include unistd.h in engine.c Also, to compile the fltk client, I had to change the order of arguments: move the object file to the front, changing c++ -g -Wall -D_REENTRANT -I/usr/include/glib-1.2 -I/usr/lib/glib/include -o jack_fltk_client -L. -L/usr/X11R6/lib -lfltk -lX11 -lXext -ljack -lltdl -lpthread fltk_client.o -L/usr/lib -lglib to: c++ -g -Wall -D_REENTRANT fltk_client.o -I/usr/include/glib-1.2 -I/usr/lib/glib/include -o jack_fltk_client -L. -L/usr/X11R6/lib -lfltk -lX11 -lXext -ljack -lltdl -lpthread -L/usr/lib -lglib Maarten
[linux-audio-dev] Re: more bad low latency results
I made a webpage with the several tests I did. Please have a look at it. I ran tune_disk /dev/hda, and do_tests none 3 256 0 2048 (indeed a really small size for the disk i/o test, but I was more interested in the rest) http://193.145.55.36/latencytest The soundcard I use is a Trident 4DWave NX, drivers are latest alsa . First of all, it is really strange that 2.4.10-NO-LL-386 2.4.10-LL-386 are practically identical; it is as if the low latency patch is not working. Maybe I missed something here, but if cat /proc/sys/kernel/lowlatency gives me 1, I can be sure it is on, isn't it? The 2.4.14-LL-PIII test have bad disk results (ran with large size btw). No idea why. How do I solve that? The best results seem to be the 2.4.14-LL-386, but here the alsa-lib/test/latency gives me underruns, ./latency -r 44100 -m 512 -M 512 -t 1 -p XRUNs right away. ./latency -r 44100 -m 1024 -M 1024 -t 1 -p does work but - and this is very important - the sound get fucked up (dusty vinyl record effect). I can record this and make a soundfile available for download if anybody is interested. Maarten
Re: [linux-audio-dev] terrible latencytest results.. why??
I now try to compile my kernel for AMD K7, but without 3DNow disabled. Check if you have this in .config CONFIG_X86_USE_3DNOW=y I remove this line, and get the following undefined references: ld -m elf_i386 -T /mnt/hda8/src/linux-2.4.14-LL/arch/i386/vmlinux.lds -e stext arch/i386/kernel/head.o arch/i386/kernel/init_task.o init/main.o init/version.o \ --start-group \ arch/i386/kernel/kernel.o arch/i386/mm/mm.o kernel/kernel.o mm/mm.o fs/fs.o ipc/ipc.o \ drivers/char/char.o drivers/block/block.o drivers/misc/misc.o drivers/net/net.o drivers/media/media.o drivers/char/agp/agp.o drivers/char/drm/drm.o drivers/ide/idedriver.o drivers/cdrom/driver.o drivers/pci/driver.o drivers/video/video.o \ net/network.o \ /mnt/hda8/src/linux-2.4.14-LL/arch/i386/lib/lib.a /mnt/hda8/src/linux-2.4.14-LL/lib/lib.a /mnt/hda8/src/linux-2.4.14-LL/arch/i386/lib/lib.a \ --end-group \ -o vmlinux arch/i386/kernel/kernel.o: In function `machine_real_restart': arch/i386/kernel/kernel.o(.text+0x102): undefined reference to `_mmx_memcpy' arch/i386/kernel/kernel.o(.text+0x165): undefined reference to `_mmx_memcpy' arch/i386/kernel/kernel.o: In function `copy_segments': arch/i386/kernel/kernel.o(.text+0x488): undefined reference to `_mmx_memcpy' arch/i386/kernel/kernel.o: In function `copy_thread': arch/i386/kernel/kernel.o(.text+0x534): undefined reference to `_mmx_memcpy' arch/i386/kernel/kernel.o: In function `dump_extended_fpu': arch/i386/kernel/kernel.o(.text+0x6f82): undefined reference to `_mmx_memcpy' arch/i386/kernel/kernel.o(.text.init+0xab1): more undefined references to `_mmx_memcpy' follow arch/i386/kernel/kernel.o(__ksymtab+0x170): undefined reference to `mmx_clear_page' arch/i386/kernel/kernel.o(__ksymtab+0x178): undefined reference to `mmx_copy_page' kernel/kernel.o: In function `mm_init': kernel/kernel.o(.text+0x165f): undefined reference to `_mmx_memcpy' kernel/kernel.o: In function `copy_files': kernel/kernel.o(.text+0x1c64): undefined reference to `_mmx_memcpy' kernel/kernel.o(.text+0x1ca4): undefined reference to `_mmx_memcpy' kernel/kernel.o: In function `do_fork': kernel/kernel.o(.text+0x215b): undefined reference to `_mmx_memcpy' kernel/kernel.o: In function `sys_create_module': kernel/kernel.o(.text+0x3588): undefined reference to `_mmx_memcpy' kernel/kernel.o(.text+0x4a07): more undefined references to `_mmx_memcpy' followmm/mm.o: In function `do_wp_page': mm/mm.o(.text+0xe88): undefined reference to `mmx_clear_page' mm/mm.o(.text+0xe9a): undefined reference to `mmx_copy_page' mm/mm.o: In function `do_anonymous_page': mm/mm.o(.text+0x124b): undefined reference to `mmx_clear_page' mm/mm.o: In function `do_no_page': mm/mm.o(.text+0x1339): undefined reference to `mmx_copy_page' mm/mm.o: In function `pte_alloc': mm/mm.o(.text+0x14a0): undefined reference to `mmx_clear_page' mm/mm.o: In function `get_zeroed_page': mm/mm.o(.text+0x9a41): undefined reference to `mmx_clear_page' mm/mm.o: In function `shmem_getpage_locked': mm/mm.o(.text+0xc28b): undefined reference to `mmx_clear_page' mm/mm.o: In function `shmem_symlink': mm/mm.o(.text+0xcdc4): undefined reference to `_mmx_memcpy' mm/mm.o(.text+0xce79): undefined reference to `_mmx_memcpy' fs/fs.o: In function `block_symlink': fs/fs.o(.text+0x49b4): undefined reference to `_mmx_memcpy' fs/fs.o: In function `flush_old_exec': fs/fs.o(.text+0x834a): undefined reference to `_mmx_memcpy' fs/fs.o: In function `d_alloc': fs/fs.o(.text+0x11818): undefined reference to `_mmx_memcpy' fs/fs.o(.text+0x11d48): more undefined references to `_mmx_memcpy' follow make: *** [vmlinux] Error 1
[linux-audio-dev] weird distortion with alsa latency test
Hi, I wrote this before, but I did not get any response. When I compile my kernel for i386 on an AMD Athlon, the alsa latency test is giving me weird distortion (knispering sound, like a dusty vinyl record) $ arecord -r 44100 -f S16_LE | aplay does not seem to have this problem. It really does not make much sense to me, and I am recompiling (again) my kernel to make sure. Does anybody have a clue of what might be going on? Maarten
[linux-audio-dev] more bad low latency results
Since with AMD Athlon I get either bad low latency (compiling for AMD) or bad sound quality (if I compile for 386. really don't understand why..), I now did some tests on a Pentium III. The results are still not good: kernel 2.4.14 low latency patch a Pentium III 800 Mhz, http://193.145.55.36/latencytest/2.4.14-LL-PIII/3x256.html I am getting really disappointed. It's no fun to compile kernels and alsa with different configurations lots of time only to get bad results. What kernels are you guys running? What would be the safest bet? On what processor? I really want it to work well on the AMD Athlon. Anybody using an AMD Athlon and has good LL results? Maarten
Re: [linux-audio-dev] alsa latency statistics
dave willis [EMAIL PROTECTED] wrote: my system is an amd athlon 900 mhz [...] Dave here shows his LL results. However, Roger Larsson wrote: But wait... an AMD They have some 3DNow specific kernel optimizations that causes trouble - they need to disable preemtion (uses fp registers...) and Would Andrew Morton's LL patches also be affected by this? Yes, if this is the problem. So my question is: how did you compile your kernel, Dave? For AMD Athlon or for i386? Maarten
[linux-audio-dev] terrible latencytest results.. why??
Not understanding why I could not get alsa-lib/test/latency.c to work well, I decided to run Benno's latency test. It has been a long time since I did... The results are surprising, and nothing like the excellent results I have seen posted here. $ ./do_tests none 3 128 0 256 http://193.145.55.36/latencytest/ (yes, I use a very small size for the disk tests, but even then!) Something is definitely very wrong here. I am running kernel 2.4.13 patched with preempt-kernel-rml-2.4.13-2.patch $ cat /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 6 model : 2 model name : AMD Athlon(tm) Processor stepping: 1 cpu MHz : 704.936 cache size : 512 KB fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat pse36 mmx fxsr syscall mmxext 3dnowext 3dnow bogomips: 1405.74 I will check now what happens with 2.4.14 and Andrews LL patch... Maarten
[linux-audio-dev] Re: minimum tick time
Abramo Bagnara [EMAIL PROTECTED] wrote: This would not imply a major rewrite: the API and the kernel code has been thought for that. You need simply to have different snd_pcm_tick_set functions (see pcm_lib.c). That's interesting. So you think that that would be the prefered way to do low latency I/O with alsa? ./latency says: Tip #1 (useable latency with large periods, non-blocking mode, good CPU usage, superb xrun prevention): latency -m 8192 -M 8192 -t 1 -p I am correct if I think that these numbers (8192) could be a lot lower using the RTC for polling? Anyway, off to home know, let's see what cvs update gives me tomorrow ;-) Maarten
[linux-audio-dev] alsa latency.c in nonblock and block mode
Hello, I am using alsa 0.9.0beta8a, and I am having big difficulties with synchronous I/O. I am using the latency.c test. When I use it as it is, it eats all the CPU for 30 seconds (well, 3, I changed to value the second time I tried). I can understand why this happens, but it is certainly not what I want. I think that the best, and certainly the most logical, way to avoid this would be to use block mode. So, I change the NONBLOCK flags to 0, and snd_pcm_readi and snd_pcm_writei start returning -32 (Broken pipe ??) What am I doing wrong? I think it would be good if there would be a blocking version of the latency test (I think 0.5 was like that, or at least ifdef'ed) Maarten
[linux-audio-dev] dreamcast audio dev
Hello, As you may have heard, SEGA discontinued the Dreamcast, and you can buy them really cheap now. Looking at the specs, I realized that the Dreamcast would be a great standalone box for audio applications. And it runs Linux, or the open source OS KallistiOS. The CPU of the Dreamcast is a Hitachi 200 MHz SH-4 that does 1400 MFLOPS. It's only an idea, but I wanted to share it with you. Add a midi interface to the Dreamcast, and you could build a great synthesizer. A tracker application would also be nice. What is really missing is audio input though... Maarten References: http://www.m17n.org/linux-sh/dreamcast/ http://www.segatech.com/technical/cpu/index.html http://cadcdev.sourceforge.net/
Re: [linux-audio-dev] Very Urgent
[...] I got your reference from the Nigeria Exports Promotion Council (NEPC) [...] Okay guys, confess: who gave the mailinglist address to the NEPC?
