Linux-audio-dev

linux-audio-dev@lists.linuxaudio.org

4 participants
7441 discussions

[linux-audio-dev] HDSP No Go With 2.6.11 Kernel

by Janina Sajka

In case this is news, I'm reporting a total failure of the snd-hdsp driver under the latest Fedora released kernel, 2.6.11-1.14_FC3spksmp, both with the x86_64 and i686 kernels. As a result, I've reverted to 2.6.10-1.770_FC3spksmp.i686. I'm using 1.0.9RC2 of alsa driver, lib, utils, and tools. Firmware is 1.0.8 -- all most current releases. It seems as if no symbol in the driver is recognized. Here's the output from attempting to start alsa, and the relevant lines in dmesg: service alsasound start Starting sound driver: snd-hdsp FATAL: Error inserting snd_pcm (/lib/modules/2.6.11-1.14_FC3spksmp/kernel/sound/core/snd-pcm.ko): Unknown symbol in module, or unknown parameter (see dmesg) WARNING: Error running install command for snd_pcm FATAL: Error inserting snd_hdsp (/lib/modules/2.6.11-1.14_FC3spksmp/kernel/sound/pci/rme9652/snd-hdsp.ko): Unknown symbol in module, or unknown parameter (see dmesg) done snd_pcm: disagrees about version of symbol snd_info_register snd_pcm: Unknown symbol snd_info_register snd_pcm: disagrees about version of symbol snd_info_create_module_entry snd_pcm: Unknown symbol snd_info_create_module_entry snd_pcm: disagrees about version of symbol snd_timer_notify snd_pcm: Unknown symbol snd_timer_notify snd_pcm: disagrees about version of symbol snd_timer_interrupt snd_pcm: Unknown symbol snd_timer_interrupt snd_pcm: disagrees about version of symbol snd_info_free_entry snd_pcm: Unknown symbol snd_info_free_entry snd_pcm: disagrees about version of symbol snd_ctl_register_ioctl snd_pcm: Unknown symbol snd_ctl_register_ioctl snd_pcm: disagrees about version of symbol snd_card_file_add snd_pcm: Unknown symbol snd_card_file_add snd_pcm: disagrees about version of symbol snd_unregister_device snd_pcm: Unknown symbol snd_unregister_device snd_pcm: disagrees about version of symbol snd_timer_new snd_pcm: Unknown symbol snd_timer_new snd_pcm: disagrees about version of symbol snd_device_new snd_pcm: Unknown symbol snd_device_new snd_pcm: disagrees about version of symbol snd_ctl_unregister_ioctl snd_pcm: Unknown symbol snd_ctl_unregister_ioctl snd_pcm: disagrees about version of symbol snd_info_create_card_entry snd_pcm: Unknown symbol snd_info_create_card_entry snd_pcm: disagrees about version of symbol snd_power_wait snd_pcm: Unknown symbol snd_power_wait snd_pcm: disagrees about version of symbol snd_device_free snd_pcm: Unknown symbol snd_device_free snd_pcm: disagrees about version of symbol snd_card_file_remove snd_pcm: Unknown symbol snd_card_file_remove snd_pcm: disagrees about version of symbol snd_info_unregister snd_pcm: Unknown symbol snd_info_unregister snd_pcm: disagrees about version of symbol snd_device_register snd_pcm: Unknown symbol snd_device_register snd_pcm: disagrees about version of symbol snd_register_device snd_pcm: Unknown symbol snd_register_device snd_hdsp: Unknown symbol snd_pcm_new snd_hdsp: Unknown symbol snd_interval_refine snd_hdsp: Unknown symbol snd_pcm_set_sync snd_hdsp: Unknown symbol snd_pcm_hw_rule_add snd_hdsp: Unknown symbol snd_interval_list snd_hdsp: Unknown symbol snd_pcm_lib_ioctl snd_hdsp: Unknown symbol snd_pcm_set_ops snd_hdsp: Unknown symbol snd_pcm_hw_constraint_list snd_hdsp: Unknown symbol _snd_pcm_hw_param_setempty snd_hdsp: Unknown symbol snd_pcm_hw_constraint_msbits snd_hdsp: Unknown symbol snd_pcm_period_elapsed [3 unrelated httpd lines] snd_pcm: disagrees about version of symbol snd_info_register snd_pcm: Unknown symbol snd_info_register snd_pcm: disagrees about version of symbol snd_info_create_module_entry snd_pcm: Unknown symbol snd_info_create_module_entry snd_pcm: disagrees about version of symbol snd_timer_notify snd_pcm: Unknown symbol snd_timer_notify snd_pcm: disagrees about version of symbol snd_timer_interrupt snd_pcm: Unknown symbol snd_timer_interrupt snd_pcm: disagrees about version of symbol snd_info_free_entry snd_pcm: Unknown symbol snd_info_free_entry snd_pcm: disagrees about version of symbol snd_ctl_register_ioctl snd_pcm: Unknown symbol snd_ctl_register_ioctl snd_pcm: disagrees about version of symbol snd_card_file_add snd_pcm: Unknown symbol snd_card_file_add snd_pcm: disagrees about version of symbol snd_unregister_device snd_pcm: Unknown symbol snd_unregister_device snd_pcm: disagrees about version of symbol snd_timer_new snd_pcm: Unknown symbol snd_timer_new snd_pcm: disagrees about version of symbol snd_device_new snd_pcm: Unknown symbol snd_device_new snd_pcm: disagrees about version of symbol snd_ctl_unregister_ioctl snd_pcm: Unknown symbol snd_ctl_unregister_ioctl snd_pcm: disagrees about version of symbol snd_info_create_card_entry snd_pcm: Unknown symbol snd_info_create_card_entry snd_pcm: disagrees about version of symbol snd_power_wait snd_pcm: Unknown symbol snd_power_wait snd_pcm: disagrees about version of symbol snd_device_free snd_pcm: Unknown symbol snd_device_free snd_pcm: disagrees about version of symbol snd_card_file_remove snd_pcm: Unknown symbol snd_card_file_remove snd_pcm: disagrees about version of symbol snd_info_unregister snd_pcm: Unknown symbol snd_info_unregister snd_pcm: disagrees about version of symbol snd_device_register snd_pcm: Unknown symbol snd_device_register snd_pcm: disagrees about version of symbol snd_register_device snd_pcm: Unknown symbol snd_register_device snd_hdsp: Unknown symbol snd_pcm_new snd_hdsp: Unknown symbol snd_interval_refine snd_hdsp: Unknown symbol snd_pcm_set_sync snd_hdsp: Unknown symbol snd_pcm_hw_rule_add snd_hdsp: Unknown symbol snd_interval_list snd_hdsp: Unknown symbol snd_pcm_lib_ioctl snd_hdsp: Unknown symbol snd_pcm_set_ops snd_hdsp: Unknown symbol snd_pcm_hw_constraint_list snd_hdsp: Unknown symbol _snd_pcm_hw_param_setempty snd_hdsp: Unknown symbol snd_pcm_hw_constraint_msbits snd_hdsp: Unknown symbol snd_pcm_period_elapsed snd_pcm: disagrees about version of symbol snd_info_register snd_pcm: Unknown symbol snd_info_register snd_pcm: disagrees about version of symbol snd_info_create_module_entry snd_pcm: Unknown symbol snd_info_create_module_entry snd_pcm: disagrees about version of symbol snd_timer_notify snd_pcm: Unknown symbol snd_timer_notify snd_pcm: disagrees about version of symbol snd_timer_interrupt snd_pcm: Unknown symbol snd_timer_interrupt snd_pcm: disagrees about version of symbol snd_info_free_entry snd_pcm: Unknown symbol snd_info_free_entry snd_pcm: disagrees about version of symbol snd_ctl_register_ioctl snd_pcm: Unknown symbol snd_ctl_register_ioctl snd_pcm: disagrees about version of symbol snd_card_file_add snd_pcm: Unknown symbol snd_card_file_add snd_pcm: disagrees about version of symbol snd_unregister_device snd_pcm: Unknown symbol snd_unregister_device snd_pcm: disagrees about version of symbol snd_timer_new snd_pcm: Unknown symbol snd_timer_new snd_pcm: disagrees about version of symbol snd_device_new snd_pcm: Unknown symbol snd_device_new snd_pcm: disagrees about version of symbol snd_ctl_unregister_ioctl snd_pcm: Unknown symbol snd_ctl_unregister_ioctl snd_pcm: disagrees about version of symbol snd_info_create_card_entry snd_pcm: Unknown symbol snd_info_create_card_entry snd_pcm: disagrees about version of symbol snd_power_wait snd_pcm: Unknown symbol snd_power_wait snd_pcm: disagrees about version of symbol snd_device_free snd_pcm: Unknown symbol snd_device_free snd_pcm: disagrees about version of symbol snd_card_file_remove snd_pcm: Unknown symbol snd_card_file_remove snd_pcm: disagrees about version of symbol snd_info_unregister snd_pcm: Unknown symbol snd_info_unregister snd_pcm: disagrees about version of symbol snd_device_register snd_pcm: Unknown symbol snd_device_register snd_pcm: disagrees about version of symbol snd_register_device snd_pcm: Unknown symbol snd_register_device snd_hdsp: Unknown symbol snd_pcm_new snd_hdsp: Unknown symbol snd_interval_refine snd_hdsp: Unknown symbol snd_pcm_set_sync snd_hdsp: Unknown symbol snd_pcm_hw_rule_add snd_hdsp: Unknown symbol snd_interval_list snd_hdsp: Unknown symbol snd_pcm_lib_ioctl snd_hdsp: Unknown symbol snd_pcm_set_ops snd_hdsp: Unknown symbol snd_pcm_hw_constraint_list snd_hdsp: Unknown symbol _snd_pcm_hw_param_setempty snd_hdsp: Unknown symbol snd_pcm_hw_constraint_msbits snd_hdsp: Unknown symbol snd_pcm_period_elapsed snd_pcm: disagrees about version of symbol snd_info_register snd_pcm: Unknown symbol snd_info_register snd_pcm: disagrees about version of symbol snd_info_create_module_entry snd_pcm: Unknown symbol snd_info_create_module_entry snd_pcm: disagrees about version of symbol snd_timer_notify snd_pcm: Unknown symbol snd_timer_notify snd_pcm: disagrees about version of symbol snd_timer_interrupt snd_pcm: Unknown symbol snd_timer_interrupt snd_pcm: disagrees about version of symbol snd_info_free_entry snd_pcm: Unknown symbol snd_info_free_entry snd_pcm: disagrees about version of symbol snd_ctl_register_ioctl snd_pcm: Unknown symbol snd_ctl_register_ioctl snd_pcm: disagrees about version of symbol snd_card_file_add snd_pcm: Unknown symbol snd_card_file_add snd_pcm: disagrees about version of symbol snd_unregister_device snd_pcm: Unknown symbol snd_unregister_device snd_pcm: disagrees about version of symbol snd_timer_new snd_pcm: Unknown symbol snd_timer_new snd_pcm: disagrees about version of symbol snd_device_new snd_pcm: Unknown symbol snd_device_new snd_pcm: disagrees about version of symbol snd_ctl_unregister_ioctl snd_pcm: Unknown symbol snd_ctl_unregister_ioctl snd_pcm: disagrees about version of symbol snd_info_create_card_entry snd_pcm: Unknown symbol snd_info_create_card_entry snd_pcm: disagrees about version of symbol snd_power_wait snd_pcm: Unknown symbol snd_power_wait snd_pcm: disagrees about version of symbol snd_device_free snd_pcm: Unknown symbol snd_device_free snd_pcm: disagrees about version of symbol snd_card_file_remove snd_pcm: Unknown symbol snd_card_file_remove snd_pcm: disagrees about version of symbol snd_info_unregister snd_pcm: Unknown symbol snd_info_unregister snd_pcm: disagrees about version of symbol snd_device_register snd_pcm: Unknown symbol snd_device_register snd_pcm: disagrees about version of symbol snd_register_device snd_pcm: Unknown symbol snd_register_device snd_hdsp: Unknown symbol snd_pcm_new snd_hdsp: Unknown symbol snd_interval_refine snd_hdsp: Unknown symbol snd_pcm_set_sync snd_hdsp: Unknown symbol snd_pcm_hw_rule_add snd_hdsp: Unknown symbol snd_interval_list snd_hdsp: Unknown symbol snd_pcm_lib_ioctl snd_hdsp: Unknown symbol snd_pcm_set_ops snd_hdsp: Unknown symbol snd_pcm_hw_constraint_list snd_hdsp: Unknown symbol _snd_pcm_hw_param_setempty snd_hdsp: Unknown symbol snd_pcm_hw_constraint_msbits snd_hdsp: Unknown symbol snd_pcm_period_elapsed -- Janina Sajka Phone: +1.202.494.7040 Partner, Capital Accessibility LLC http://www.CapitalAccessibility.Com Chair, Accessibility Workgroup Free Standards Group (FSG) janina(a)freestandards.org http://a11y.org If Linux can't solve your computing problem, you need a different problem.

19 years, 4 months

[linux-audio-dev] Nord Modular instrument converter

by Juhana Sadeharju

Hello. I started working on a Nord Modular to PD converter. ftp://ftp.funet.fi/pub/sci/audio/devel/nordmodular/ NM users have patched thousands of free instruments (http://nordsynth.zevv.nl). It would be nice to be able to use the user-made instruments elsewhere. I choosed PD but we should make the converter general enough so that converters to other modular systems can be written. I can work on them as well. Check for "http://nmedit.sourceforge.net" for a NM instrument file parser. The NM file format is close to PD's own. Anyone could rewrite the parser standalone in C, Python, etc? [[ I see no problem in writing the converter. Buying a Nord Modular does not mean that its users should restrict their intellectual property to Nord Modular. ]] Juhana -- http://music.columbia.edu/mailman/listinfo/linux-graphics-dev for developers of open source graphics software

19 years, 4 months

Re: [linux-audio-dev] CSound usability (was: Common synthesizer, interface...)

by steven yi

Hi Toby and All, >But from my (limited) experience I see that not only does writing a >CSound instrument require knowledge of the CSound language and of its >architecture (that's obvious), but that *incorporating* an existing >CSound instrument into a new composition requires almost the same >skills. And those are computer programmer-level skills, not average >music writer-level ones. I would say that most computer music people who use sequencers do not write their own instruments either, rather opting for instruments built by someone else and using presets and modification of parameters via GUI. The same is possible in Csound to reuse someone else's instruments and only explore the instrument's qualities via configuration with text. With blue, you can create a GUI for instruments using it's builtin UI Builder (http://csounds.com/stevenyi/blue/blueDocs/html/blueSynthBuilder.html). Also, you can trade instruments--UI, instrument code, and presets--via the builtin BlueShare community interface. (i.e. explore the instruments on the server, download directly to your instrument library and start working). So, with the BlueSynthBuilder instruments and the PianoRoll, you can really get to working with Csound with a minimal amount of Csound knowledge. >Let's make a comparison, although a simple, maybe unworthy one: Reasonâ„¢. >Novice users don't *need* to know how the MalstrÃ¶m* works to be able to >1. load a patch 2. give it MIDI input and 3. start playing. They only >need that kind of skill if they want to make their own patches or modify >existing ones. (*: a small piece of soft-synth found in Reasonâ„¢) > >Granted, the power of any synth lies in customization, but IMHO part of >its *usability* lies in being able to play it *without* knowing how to >program it. That's what presets are for anyways! > >I'm under the impression that CSound fails right there. I wouldn't quite agree. As mentioned above, one can reuse others' instruments with Csound and do the same thing as you mention, not concerning themselves with programming the instrument but exploring the parameters of the instrumet. With Csound alone it would be text as the interface versus Maelstrom's GUI interface, with blue there would be not much difference except blue's UI is not realtime. >An ORC file you say? Most of the instruments I've seen need both and >ORC and a SCO file to be of any use (problem #1.) Moreover, since you >need to come up with a single ORC and a single SCO to make CSound render >your composition, you have to merge the various ORC/SCO file-pairs of >the instruments you want to use, along with the additional SCO file >containing the actual notes (problem #2) and AFAIK you need vast >knowledge of the ORC and SCO syntax to be able to do it (problem #3.) blue has many features for orchestra management as well as SCO handling and generation via it's SoundObjects that generally alleviates issues as mentioned above with orc/sco file management. >I could go on, but I think you see my point. (Unless I'm seriously >misunderstanding how CSound works nowadays, in which case I'll apologize >to everybody and go read some CSound mailing list archives!) Well, I wouldn't say you've misunderstood Csound entirely, but just wanted to offer another view of Csound via my program blue in this message that may make Csound appear a bit differently than as you imagine. steven

19 years, 4 months

Re: [linux-audio-dev] Common synthesizer interface -or-, microtonal alternative to MIDI?

by steven yi

Hi All, Just thought I'd mention that my software blue (http://www.csounds.com/stevenyi/blue) supports tuning systems with a microtonal piano roll that reads in Scala files(http://csounds.com/stevenyi/blue/blueDocs/html/pianoRoll.html), and is somewhat like a sequencer application (mixing of SCO fragments, SCO generation scripts in python and javascript, etc.). It's built for use with csound and is GPL. Although I'm not sure if blue is in the same vein as what the original poster of this thread is looking to build, I thought it might be something worth checking out, perhaps simply for ideas on possible ways to implement (or not to implement) a solution. Also, I know that newer versions of Apple's Logic sequencer do support a limited degree of alternate tunings (can not find info on it on Apple's site at the moment). steven >Alfons Adriaensen wrote: > > > >>On Tue, May 03, 2005 at 08:36:29AM -0400, Dave Phillips wrote: >> >> >> >> >> >>>Considering its suitability for microtonality, why not design >>>something around Csound ? >>> >>> >>> >>> >>>From the origianl post: >> >> >> >> >> >>>The problem is that I don't know of any software synthesizer that is: >>> >>>1. good enough for decent music production; >>> >>> >>> >Well, Csound is being used for just that purpose. Perhaps the original >poster should check out recent traffic on the Csound mail lists. > > > >>>2. easy to use by non-experts (this is a direct stab at CSound, or >>> better at its lack of a decent GUI, of a standard instrument exchange >>> file format and of a decent, centalized library of presets) >>> >>> >>> >Csound has no integral GUI, sorry. It does have a set of FLTK-based GUI >widgets which lets you create your own GUI. > >The Csound orc file has been and still is the way Csounders exchange >instruments. There are in fact a number of instrument libraries out >there. I think the original poster might not be quite up to date on Csound. > > > >>>3. free software. >>> >>> >>> >>> >Csound is LGPL and has been for some time now. > > > >>To add my 0.02 Euro : I'm sure that OSC is the way to go for this project. >>And I'd love to have an 'OSC sequencer' -- something that allows you to >>schedule / edit / manipulate arbitrary OSC events, and with a non-destructive >>region editor similar to Ardour's. >> >> >> >> >Sounds cool, I'd like to see that too. > >Btw, Rocky was a project with somewhat similar goals, a sequencer for >22-tone ET, using Csound for its rendering engine and Java for its GUI. >Alas, Rocky appears to have disappeared. [Insert obligatory Sylvester >Stallone joke here]. > >Best, > >dp > > >

19 years, 4 months

[linux-audio-dev] Re: GTK performance?

by Juhana Sadeharju

>From: Jens M Andreasen <jens.andreasen(a)chello.se> > >Is it gtk then? Or the pixmap engine? I don't use pixmap decorations in my application, but only one pixmap of size 800x600 was too slow. I used the preferred pixmap functions of GTK2. The expose of the whole 800x600 pixmap took 120 ms (8 fps). That was impractical. Then I switched to gtkglext which in my system apparently uses Mesa with software renderer. (How to verify it?) Now the system is fast. One app renders 3D objects and another app draws 2D objects (http://www.funet.fi/~kouhia/enved7.png). I would like to know if gtkglext in my system uses Mesa and if Mesa uses software renderer. How that can be tested? What I would like to have would be vertex and fragment shaders for audio widgets. E.g., a 2D or 3D knob would rotate with vertex shaders. E.g., a level meter a la SoundForge would have a fragment shader dimming the top of the black-green-yellow-red texture map based on the meter value. Juhana -- http://music.columbia.edu/mailman/listinfo/linux-graphics-dev for developers of open source graphics software

19 years, 4 months

[linux-audio-dev] list removal

by David Wessel

Could you please remove me from your mailing list as I will be away from email for an extend period of time. I'm David Wessel at wessel(a)cnmat.berkeley.edu Thank you, David Wessel

19 years, 4 months

[linux-audio-dev] Mx44 update

by Jens M Andreasen

Hi! As you might know, the initial phase relation between oscillators in an FM synth is quite important for the resulting sound. Not least when you are dealing with feedback loops. I have had velocity sensitivity on phase for ages, but came to think of that keyfollow on phase might be more useful? The rationale being that adjecent notes would then have slightly different harmonic series (or dramatically different, depending on other settings.) One advantage would be that "clean" sounds (ie: Piano) could have some unique harmonic space surrounding each note, so that blockchords can live harmonically together in an even-tempered world, without too much beating and without resorting to detuning, PWM and whatnot. So I made this new button near the other phase parameters, added a few lines of code and prepared a test patch called "Test III" located in "H.4" (which at least to my ears and speakers is partially reminiscent of a piano.) The new button switches between phase-velocity or -keyfollow for the slider just below. What? Oh ... Here: http://hem.passagen.se/ja_linux (no new screenshot) -- ( ) c[] // Jens M Andreasen

19 years, 4 months

[linux-audio-dev] re: Chebyshev

by Bill Schottstaedt

About 3 years ago there was a thread here about using Chebyshev polynomials to mimic guitar amps -- I think I have found at least a partial solution to some of the problems mentioned at that time -- could someone send me the amplifier characteristics they were trying to reproduce, or any other tests? Thanks!

19 years, 4 months

[linux-audio-dev] Sequencer Concept

by Thorsten Wilms

Hi! I have been thinking about how an advanced sequencer could look and work over and over again and now finaly managed to come up with one consistent concept that i would like to present here now. A mockup to illustrate the following explainations: http://wrstud.uni-wuppertal.de/~ka0394/forum/sequencer_05.png The basic idea is to have nested containers to be arranged verticaly and horizontaly. All information is tied to or contained in these containers. As the horizontal axis stands for time, i needed to express the nesting only verticaly (plus color), so that's what the round corners and the empty bottoms of the containers are for. Maybe it helps when you think on Lisp and paranthesis, only vertcaly. On the mockup the big white container defines absolute time (min/sec) and the context for playback control (only one play position inside thsi container (for each user)). Several of them could exist in parallel, all with their own playback control. The next, yellow container defines the meter (the ruler) 4/4, followed by a tempo track set to 120 BPM. The blue container is an audio container. These can take others of their kind, audio inputs and outputs and finaly audio clips. This one defines an "Out 1" and its send level and conatins 3 clips. Below it, the green container sets a 3/4 meter. Because it is inside the 4/4 container, the quarter notes match. If outside, it would have to have its own and independent tempo track. The last Container is for MIDI. It has IN and OUT as attributes. Alternatively these could be expressed on tracks like used for tempo, what would make them changeable inside the container. Every Container can be used as a pattern (instances). They could have a dropdown menu to swutch between different versions (/takes). I have some more ideas and details, but i think this should be enough for now! :) I have only basic and seldomly applied coding skills, and this doesn't look like a one man project anyway ... So I hope for interested developers ... or that at least this gives someone some inspiration. I would be happy to further develop my concepts of course (allthough my diploma in industrial design, same topic: sequencer takes priortiy for the next 3 months). --- Thorsten Wilms

19 years, 5 months

[linux-audio-dev] Evolutif

by J_Zar, Gianluca Romanin

Hi all, I would like to know if someone knows if the Evolutif Audio ( http://evolutif.sourceforge.net/ ) project is alive (no CVS, no releases from 2003). If not, is there any other similar audio project actually in running? I'm thinking to extend this code stuff (Evolutif) and I would like to parse possibilities and efforts. Thanks, -- J_Zar Gianluca Romanin ---------------- See you at OpenJay.org

19 years, 5 months

Jump to page:

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