Linux-audio-dev

linux-audio-dev@lists.linuxaudio.org

2 participants
7501 discussions

[linux-audio-dev] maximum ports -problem

by Brett McCoy

Last night I was setting up a session in Ardour. I had three tracks for keyboard parts that were from imported audio files, so they did not have any input ports set. I wanted to bring in drum parts from Hydrogen, and started setting up tracks to correspond with the tracks I was using in Hydrogen. I got maybe 3 or 4 tracks set up, with the correct inputs, and then suddenly Ardour kept telling me that I was out of jack ports and needed to reset jack. What is this? I had used maybe 4 stereo ports total. My sound card has 12 in/10 out (but I was wasn't using them), and Hydrogen presented 32 stereo tracks via Jack, and I was no where near the limit. I looked at my jack settings via qjackctl and it was set for 128 ports (assuming this is the same thing). After I restarted jackd (and not making any changes in qjackctl), Hydrogen refused to start (it would segfault on startup, but if I started Hydrogen without jackd it would startup fine), and when I reopened the same session in Ardour, the entire screen would freeze (except the mouse). All of my versions of jack, ardour, etc., are fairly recent, built from CVS within the past two weeks. I haven't had any chance to look at this in more detail this morning. Anyone have any suggestions on what I should look at? -- Brett ----------- Programmer by day, Guitarist by Night http://www.chapelperilous.net http://www.alhazred.com http://www.revelmoon.com

19 years, 11 months

[linux-audio-dev] [ANN] E-Radium V0.61b

by Kjetil Svalastog Matheussen

Download from http://www.notam02.no/arkiv/src/ E-Radium V0.61b --------------- Released 12.7.2005 INTRODUCTION ------------ E-radium is Radium and a special version of E-UAE. Radium is a midi music editor for the amiga and E-Uae is an amiga emulator. This version of E-Uae is a hacked version of 0.28cvs, which runs with realtime priority to get accurate timing and supports alsa-seq to access midi. It does not hog the cpu as much as e-uae does either so it can be used together with various sound synthesis software running simultaniously in linux. E-radium has been tested with both the 2.4 kernel and the 2.6 kernel and with a ~1GhZ machine and a ~2ghz machine. (A 2.4 kernel with a 100hz resolution timer will proably not work very nice though.) COMPILING --------- make RUNNING ------- 1. Run ./e-radium 2. Unpress the "Pause" button. 3. Select which resolution you want to run radium with. 4. Connect midi-ports with qjackctl, aconnect, qconnect or similar tools. CONFIGURING THE KEYBOARD ------------------------ If you are a non-us keyboard user, you might have to configure the keyboard by setting the approporitate type. e-uae currently supports fr, us, de, dk, se, it and es. Pick the one closest to what you use, and put it into the "kbd_lang"-field in the file ".uarc-radium". (The keyboard should rather have been mapped directly from the keys though....) QUICK RADIUM GUIDE ------------------ * Move the editor-window to front, press "Ctrl + 1". * Maximize the editor-window, press "Altgr + 1" * Maximize the tracks in the editor-window, press "Ctrl + m" * Move the playlist-window to front, press "Ctrl + 2". * Move the Midi-properties-window to front, press "Ctrl + 3". * Move the Help-window to front, press "Ctrl+4". (Use right mouse button to access menues) * Play song press Altgr+Space. * Play block, press Right windows + Space * Stop: Press space * Continue song: Press Right Shift + Space * Undo: Press Right Windows + U * Redo: Press Right Windows + Right Shift + U * Toggle midi-editing on/off, press Esc. * Move 10 lines up/down: Press Left shift + up/down * Move between tracks: Press AltGr + left/right * Add block: Press Ctrl + f * Move to next block: Press f * Move to prev block: press a * PANIC! Hold down left and right mouse buttons for 2-10 seconds. The player should then stop. + A lot more. Check out bin/keybindings.conf for the complete list. This file can also be editied. ABOUT MIDI ---------- E-radium creates 8 public alsa-midi seq ports. Currently, only the 2 first ones are enabled. To enable more, check out the file s/startup-sequence. On the linux-side (alsa-seq), the name of the ports are uae0, uae1, uae2 and so on. On the amiga-side (camd), the name of the ports are mmp.0, mmp.1, mmp.2 and so on. These are directly connected if enabled in s/startup-sequence. Radium is currently configured to read midi from the uae0 alsa midi port. LINUX VERSION OF RADIUM ----------------------- Radium runs quite okey on its own (v0.63), but its not quite there yet. Until its there, running it via uae is the only way to use it besides using a real amiga of course (altough that is much slower than emulating). LINKS ----- Radium: http://www.notam02.no/radium/ E-uae: http://www.rcdrummond.net/uae/ --

19 years, 11 months

[linux-audio-dev] Audigy 2 ZS Notebook drivers

by Melanie

Hi, i have searched the web and the ALSA pages and found very little information concerning the status of the development efforts, if any, and who might be interested. This card seems like a good means to hook a notebook into a DJ mixer, splitting the output into 2 or 3 stereo outs. I am very interested in such a driver, but I dud find a reference to a kernel PCMCIA bug on the ALSA sound card list. How much of a showstopper is it? Is there any problem that could be fixed by throwing money at it? And, if it is a money problem, if the funds were available, how long would it take for a driver to be completed? My minimum requirement would be a driver that would support the Audigy 2 ZS Notebook as well as an Audigy Platimun or SB Live! is supported. Melanie

19 years, 11 months

[linux-audio-dev] LADSPA: getting sample rate

by Artemio

Hello all! I am wondering, in my runMyPlugin() function, how do I get the sample rate value? Thanks! Artemiy.

19 years, 11 months

[linux-audio-dev] Support for the Hammerfall HDSP-RPM

by Daniel Frauchiger

Hi, as an owner of a RPM (not a Digiface nor a Multiface) I am wondering if this is supported by hdsploader. Thank you for clarifying, Daniel --

19 years, 11 months

[linux-audio-dev] LADSPA plugin parameters realtime control

by Artemio

Hello all! I am here to ask you one thing. If I want sample-precise realtime control for the plugin, should I be getting all the parameters inside the cycle which travels through the buffer contents? E.g., should the code that looks like this: fParameter = *(psMyPlugin->m_pfSomeParameter); pfInput = psXShaper->m_pfInputBuffer1; pfOutput = psXShaper->m_pfOutputBuffer1; for(lSampleIndex = 0; lSampleIndex < SampleCount; lSampleIndex++){ /* do something with the data */ } be replaced by this: pfInput = psXShaper->m_pfInputBuffer1; pfOutput = psXShaper->m_pfOutputBuffer1; for(lSampleIndex = 0; lSampleIndex < SampleCount; lSampleIndex++){ fParameter = *(psMyPlugin->m_pfSomeParameter); /* do something with the data */ } I believe the answer is yes... But maybe I'm wrong? Thanks! Artemiy.

19 years, 11 months

[linux-audio-dev] [ANN] Specimen v0.5.0 and PHAT v0.3.0

by Pete Bessman

Ladies, gents, and those in between, I got back into the hacking thing a couple days ago, and I'm pleased to announce new versions of both the Specimen sampler and the Phat Audio Toolkit. As always, the real tip can be had at www.gazuga.net. The stuff that I remember changing follows: Specimen -------- * Fixed CPU hogging * Added keyboard for setting MIDI parameters * Made patch list auto sorting * Made volume logarithmic PHAT ---- * Added a new widget, the PhatKeyboard Stay tuned for more! Peace out, -Pete

19 years, 11 months

[linux-audio-dev] desktop audio resumed

by Maarten de Boer

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

19 years, 11 months

[linux-audio-dev] Pointer: IETF RTSP stage and studio I-D ...

by lazzaro

Hi everyone, This may be of interest to standards-oriented LAD-folk: http://www1.ietf.org/mail-archive/web/mmusic/current/msg03497.html And the initial discussions: http://www1.ietf.org/mail-archive/web/mmusic/current/msg03498.html http://www1.ietf.org/mail-archive/web/mmusic/current/msg03499.html http://www1.ietf.org/mail-archive/web/mmusic/current/msg03501.html http://www1.ietf.org/mail-archive/web/mmusic/current/msg03503.html Feel free to join MMUSIC and discuss standards-oriented issues, or discuss here for LAD-specific issues. --- John Lazzaro http://www.cs.berkeley.edu/~lazzaro lazzaro [at] cs [dot] berkeley [dot] edu ---

19 years, 11 months

[linux-audio-dev] best LL kernel options with ingo molnar's patch

by Maarten de Boer

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

19 years, 11 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Linux-audio-dev