Linux-audio-dev June 2004

linux-audio-dev@lists.linuxaudio.org

99 participants
93 discussions

by Dave Phillips

Greetings: Can someone explain why TiMidity eventually hogs the CPU at 95% or more after running for a while (like 12 hours or more) ? I'm talking about hogging the chip while TiMidity is idling, not playing. I'm using it as a softsynth, it works well, but even in the latest version its CPU usage just soars. Here's how I'm invoking 2.13.0 : timidity -iA -B2,8 -c /home/dlphilp/timidity.cfg -A100 -Oj -EFreverb=0 -EFchorus=0 Takashi: Obviously I spoke too soon in my earlier message. I just looked at top again and saw that TiMidity was eating up 96% of the CPU. :( Best, dp

19 years, 10 months

[linux-audio-dev] jack alsa driver cannot set period size below 512 for capture --> update

by Lee Revell

Hey, I posted this a few weeks ago, here is the original thread: http://eca.cx/lad/2004/06/0046.html After doing some research it seems that the issue is actually with JACK. The SBLive does not allow the hardware capture buffer to be set to any values other than these: static unsigned int capture_period_sizes[31] = { 384, 448, 512, 640, 384*2, 448*2, 512*2, 640*2, 384*4, 448*4, 512*4, 640*4, 384*8, 448*8, 512*8, 640*8, 384*16, 448*16, 512*16, 640*16, 384*32, 448*32, 512*32, 640*32, 384*64, 448*64, 512*64, 640*64, 384*128,448*128,512*128 }; This limits the allowed period sizes you can set with snd_pcm_hw_params_set_period_size; this is what jackd uses to set the period size to whatever is specified in the -p argument. However as far as I can tell, you should be able to use the ALSA xfer_align parameter to set this to, say, 128. Then, you set the playback period size to 128, and whenever you get an interrupt from the playback buffer running low you write the next 128 frames to the output device and read the next 128 from the capture buffer. Since the different sized hardware buffers for capture and playback are a quirk of the SBLive, I think this would require hardware-specific code for the EMU10K1 in JACK, the way there is one for the Hammerfall, HDSP, and ICE1712 already. Would someone with more low level knowledge of JACK and ALSA care to comment? Lee

19 years, 10 months

[linux-audio-dev] FYI (FW: [The end of an era])

by Claudio Mettler

...

19 years, 10 months

[linux-audio-dev] Terminology / sampler architecture

by Thorsten Wilms

Hi all! Besides widgte-level gui standards another topic for general usability is terminology. Naming of concepts like sessions, banks, presets, patches and so on. I expect quite some resistance about renaming stuff in existing apps, but a guideline would still be a good thing for future developments and minimizing confusion. So I would like to hear of personal preferences and known differences in naming on existing apps. Of special interest to me is naming and structure of the different organizational levels of samplers. And a specific questions: what is thought to be the best approach to allow both having multiple samples with greatly varying setups of filters/amps/etc (drumkits) and multiple samples for chromatic instruments with smooth changes of filter/amp/etc settings? Thanks in advance for any input! --- Thorsten Wilms

19 years, 10 months

[linux-audio-dev] Splitsheet

by Thorsten Wilms

Hi! While thinking about structure/organization for LDrum, I developed a concept for the gui of a modular system. http://wrstud.urz.uni-wuppertal.de/~ka0394/forum/04-06-15_splitsheet_01.png All happens in one window, with blocks that represent modules. These modules can be input filters (filtering channels, notes, velocity ranges), oscilators, sound filters, amp and everything else known from modular systems. The type of module for a block is determined by a dropdown menu. Other content are the type specific controls. Each block can be split up horizontaly or verticaly to create new blocks (see mockup for a horizontal split). Splitting could be offered in conetx menu or through dedicated buttons. Signal flow starts at the top and goes through top and bottom edges of blocks (no sideway signal flow). Splitting up and mixing happens automaticaly. Of course moduletypes could not be selected freely, because input filters would have to be chained directly, and could not be placed behind oscilators and the like. The system would make it easy to build rather simple chains of modules quite fast. noterange filters would allow to split things up using multiple samples or varying synthesis setups and join it back together at any stage. Alternatively to the block splitting, modules could be layed out on a canvas/grid. But that would require means to resize modules to form various relations. In short I think it would require more interaction for similar results. So this is a rough idea, free to be picked up. If there's real interest (a chance of implementation), it would be my pleasure to further develop it in cooperation. --- Thorsten Wilms

19 years, 10 months

[linux-audio-dev] [ANN] updates

by Fons Adriaensen

Already some bugfixes to the things I announced less than 24 hours ago... jaaa-0.1.1.tar.bz2 clthreads-0.0.3.tar.bz2 as usual to be found on <http://users.skynet.be/solaris/linuxaudio> Thanks to Jesse Chappell for pointing out the problems. -- FA

19 years, 10 months

[linux-audio-dev] [ANNOUNCE] Editor/Librarian for Rolands Alpha Juno synths

by Chris

Hi, The first release of my patch editor and librarian for Rolands Alpha Juno synths is available at: http://www.chriswareham.demon.co.uk/software/alphajuno/index.html It has been tested with an Alpha Juno 1, but should also support the Alpha Juno 2 and MKS 50 synthesisers. Now the bad news. I wrote the program on NetBSD, and I don't have access to a Linux machine to tweak and test it there. The only things that should need tweaking are in the source file "midi.c". If anyone could compile the program on Linux and let me have a diff of any changes, I would be most grateful. Failing that, I hope to have enough disk space to dual boot Linux as well as NetBSD in the near future, at which time I will port the program myself. As this has been quite an enjoyable and easy program to write, I am now interested in writing a generic editor and librarian for free Unix platforms. I am aware of the excellent JSynthLib, but its reliance on Java means it isn't easily ported across all the free Unix flavours. Writing a similar program in C or C++ would be the goal I'd like to pursue. Anyone interested in helping out (or who can point me at a project that's already undertaken this) please get in touch. Regards, Chris

19 years, 10 months

[linux-audio-dev] Sliders 2

by Ben

Thorsten, Regarding the fan display, how do you handle the case where the fader is at the very top or bottom of the screen? -Ben

19 years, 10 months

[linux-audio-dev] Draft position statement of AGNULA on ALSA firmware

by Andrea Glorioso

Dear all, after a very busy period I finally managed to find the needed time and concentration to write the first darft of AGNULA position on distributing ALSA firmware. To make a long story short, the final position I'm proposing is that AGNULA *should* distribute such firmware, but should carefully explain why it's doing it and how it thinks that this is not the optimal solution. I'd like all of you to comment on the following draft statement, whether you find it acceptable or not. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ +++ THE AGNULA PROJECT POSITION ON ALSA FIRMWARE For quite a long time, the ALSA project [0] has been providing a reference architecture and top-quality Linux drivers for a wide variety of sound cards. All the code of the core ALSA system and of the drivers has been released under either the GNU GPL license or under a Free Software license, as defined by the Free Software Foundation. The AGNULA project is very thankful to the ALSA team for allowing the A/DeMuDi distribution to use and distribute their software. However, AGNULA is facing a difficult problem dealing with a subtle issue: firmware. Many professional grade soundcards require "firmware" (hexadecimal blobs of data which have to be "uploaded" on the hardware for it to do work properly, or to work at all in some cases), which the ALSA project distribute in a separate package. The question arose whether AGNULA would be entitled to distribute such firmware as part of its A/DeMuDi distribution. During its funded lifetime as a European Commision IST project, AGNULA was bound to only distribute Free Software as defined by the Free Software Foundation guidelines; the participation of Free Software Foundation Europe as a member of the AGNULA Consortium was meant to guarantee this specific part of the agreement. After the end of the funded lifetime, AGNULA has become a (mostly) volunteer project; however, FSFE has registered the "AGNULA" trademark and allows it to be used only by projects which fulfill the general goal of supporting Free Software, from both the technical and the philosophical points of view. Current AGNULA volunteers have, of course, no problem with FSFE registering the trademark - on the contrary, we feel this is a useful strategy to avoid our work being misused. To make a long story short, AGNULA has reached the conclusion that it *will* distribute the firmware needed to make some sound cards properly work. To make a short story long, let us explain our line of reasoning: (1) The first question is whether we can legally distribute such firmware at all, barring for a moment the problem of its "freeness". The ALSA project has been given permission to distribute it, and our investigation showed no proof that this permission refers to the ALSA project and not to other parties; so we concluded that we could legally distribute such firmware. (2) The second question is whether such firmware is "software" (i.e. a computer program) or "data". The distinction between the two is very, very blurry. The position of AGNULA is that the firmware we are discussing about can be actually considered software (i.e. a computer program) in the sense that it is interpreted by a piece of hardware to execute some operations. (3) The third question is, given that we consider firmware as software, what is the "preferred form for modification" of such firmware. The wording we use is not random: it's the way the GNU GPL license defines the "source code" of a program. Now, if the "preferred form for modification" of said firmware is editing the hex codes themselves, then we are actually distributing the source together with the program. Unfortunately, we are quite convinced (based on our personal experience, and on us being overly cautious) that the "preferred form for modification" of such firmware is not hacking on hexadecimal values; we think the firmware is the result of some higher-level language being compiled into the resulting "blob" (no more and no less than what happens with "ordinary" computer programs). Given (1), (2) and (3) we conclude that the firmware we are discussing about can't actually be considered Free Software. However, given that: (4) without such firmware, most professional-grade sound cards won't work; (5) the Free Software community, and AGNULA specifically, has not gained enough momentum in the audio field to be able to convince any major sound card manufacturer that it should release the source code of its firmware (supposing (3) is true, of course) lest AGNULA won't distribute such firmware inside A/DeMuDi, (6) the unwillingness by AGNULA to distribute such firmware would actually *damage* Free Software, because we think most people - who for years have been using proprietary software to do their pro audio and sound work - will simply refuse to accept the extra burden of having to download a separate package and configure it outside the usual distribution mechanism; (7) we feel that providing a downloader for such firmware would be a hypocritical stance - "we don't give you X, but we give you an easy way to get X". We don't see the point in acting this way. the AGNULA project has decided that it *will* distribute the alsa-firmware package in the next releases of its AGNULA/DeMuDi distribution. Please bear with this long message a bit more. (8) We don't feel this is a completely satisfactory solution. We think the user should be in complete control of the system s/he is using, and the only way to get that is to have complete access to the source code of the software s/he is using and the possibility to modify and redistribute it without too much hassle. Media Innovation Unit - Firenze Tecnologia (MIU-FT), itself a part of the AGNULA team, is convinced that Free and Open Hardware is an interesting line of research that should be further investigated, and will allocate a part of its resources in the coming months to understand the issues involved and the possible solutions. Interested parties should contact MIU-FT technical coordinator (Andrea Glorioso <sama(a)miu-ft.org>). (9) Although A/DeMuDi distributes jMax, a program which is in and by itself Free Software but is currently depending on non-free Java Runtime Environments implementations, we don't feel obliged or compelled to distribute a non-free JRE because of our decision to distribute ALSA firmware. We feel the two situations are non-comparable: providing an alternative to those parts of jMax which depend on a non-free JRE (namely the GUI) is substantially easier, both technically and legally, than writing replacement firmware for the sound cards which need it. (10) This decision on firmware *only* applies to ALSA firmware - i.e. the firmware currently distributed by the ALSA project. We reserve the right to decide, on a case by case basis, whether we will distribute firmware which will be included into the ALSA package in the future and/or firmware for other parts of a system running our A/DeMuDi distributioon. (11) We do know that the Debian project has taken a different route than us. Although we are striving to make A/DeMuDi as much integrated into Debian as possible, we want to reserve - in this and in other occasion - the freedom to decide autonomously what we feel is better for the advancement of Free Software. On behalf of the AGNULA project, Andrea Glorioso [0] http://www.alsa-project.org/ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Comments, criticisms, whatever should be sent to: <users(a)lists.agnula.org> Best regards, -- Andrea Glorioso andrea.glorioso(a)agnula.org AGNULA Technical Manager http://www.agnula.org/ M: +39 333 820 5723 F: +39 (0)51 930 31 133 "Libre Audio, Libre Video, Libre Software: AGNULA"

19 years, 10 months

[linux-audio-dev] [ANNOUNCE] Yatm 0.1.0

by Mario Lang

Hi. It is small, dumb, and simple, but I just couldn't resist letting you all know about my first Linux audio application written in C (well, actually C++, but I had no choice!) What is it? Yatm is a small command-line mp3 player with tempo variation capabilities. It uses libao for audio output, libmad to decode MPEG audio, and libsoundtouch to do the tempo changing. A sample usage case would be for listening to audiobooks at a different tempo than originally recorded. It could also be used as a backend for DAISY Digital Talking Book format player in the future (see http://www.daisy.org/). The name Yatm stands for Yet Another Time Machine :-). Where is it? http://delysid.org/yatm-0.1.0.tar.gz TODO: * Add support for seeking and timed playback (using the original time of the audio file, such that indexes into a file do not need to be translated according to current tempo) * Add support for playing RIFF WAV files and OGG/Vorbis. * Add a simple command-line interactive mode to be able to change tempo during playback without interrupting the program. * Add the ability to define several indices at startup which will be reported to stdout when reached. This could be used to advance a reading cursor when presenting a DAISY book which does have detailed index information. Since this is my first Linux Audio app, comments are highly appreciated. -- CYa, Mario | Debian Developer <URL:http://debian.org/> | Get my public key via finger mlang(a)db.debian.org | 1024D/7FC1A0854909BCCDBE6C102DDFFC022A6B113E44

19 years, 10 months

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

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 June 2004