Linux-audio-dev December 2002

linux-audio-dev@lists.linuxaudio.org

75 participants
96 discussions

Fwd: Re: [linux-audio-dev] XAP: Pitch control

by David Olofson

(Oops. Replied to the direct reply, rather than via the list. Please, don't CC me - I'm on the list! :-) ---------- Forwarded Message ---------- Subject: Re: [linux-audio-dev] XAP: Pitch control Date: Wed, 11 Dec 2002 18:05:57 +0100 From: David Olofson <david(a)olofson.net> To: Nathaniel Virgo <nathaniel.virgo(a)ntlworld.com> On Wednesday 11 December 2002 17.50, Nathaniel Virgo wrote: > On Wednesday 11 December 2002 3:41 pm, David Olofson wrote: > > On Wed, Dec 11, 2002 at 12:40:18 +0000, Nathaniel Virgo wrote: > > > I can't really say I can think of a better way though. > > > Personally I'd leave scales out of the API and let the host > > > deal with it, sticking to 1.0/octave throughout, but I can see > > > the advantages of this as well. > > > > Problem with letting the host worry about it is that the host > > would normally not understand anything of this whatsoever, since > > the normal case would be that a sequencer *plugin* controls the > > synths. It would be a hack. > > Oh. Well, when I said host I meant sequencer. I see. Well, either way, I still prefer thinking of scale converters as something I may just plugin, rather than waiting for my favourite sequencer to support the kind of scales I want. One multichannel event processor plugin more or less in the net won't be a disaster - and again, you *can* use 1.0/octave in the sequencer as well as an alternative. //David Olofson - Programmer, Composer, Open Source Advocate .- The Return of Audiality! --------------------------------. | Free/Open Source Audio Engine for use in Games or Studio. | | RT and off-line synth. Scripting. Sample accurate timing. | `---------------------------> http://olofson.net/audiality -' .- M A I A -------------------------------------------------. | The Multimedia Application Integration Architecture | `----------------------------> http://www.linuxdj.com/maia -' --- http://olofson.net --- http://www.reologica.se ---

21 years, 9 months

[linux-audio-dev] band limited interpolation

by Henry Gomersall

I'm trying to oversample to smooth the display on my software audio scope using band limited (sinc) interpolation. I have a quick question to ask. Which of the following implementations is liable to take more processing time: 1) Padding my data, and then convolving the original (non-zero) samples with a sinc function (from a LUT). I think it's only feasible to have a LUT for a sinc of unity amplitude. or 2) Doing an FFT on my original sample set. Padding, and multiplying by a rectangular window, then doing an iFFT to return to the time domain. The FFT library I would use would be FFTW. Cheers Henry

21 years, 9 months

[linux-audio-dev] unsunscribe

by ShezZan

unsunscribe

21 years, 9 months

Re: [linux-audio-dev] Plugin APIs (again)

by John Lazzaro

> Steve Harris <S.W.Harris(a)ecs.soton.ac.uk> writes: > > Yeah, please do that would be damn useful. For rapid prototyping if > nothing else FYI, making sfront produce code suitable for .so's is at the top of the list of things to do these days, because AudioUnits support awaits it. But, that's the "sfront enhancements" list of things to do, which is kind of subordinate to the "get MWPP to Last Call in the IETF" list of things to do ... so it may take a while. Basically, many Logic users would like to use SAOL as a scripting language for their own plugins ... thus, AudioUnits support. This could actually be a catalyst for SAOL becoming more popular generally, if it works out ... ------------------------------------------------------------------------- John Lazzaro -- Research Specialist -- CS Division -- EECS -- UC Berkeley lazzaro [at] cs [dot] berkeley [dot] edu www.cs.berkeley.edu/~lazzaro -------------------------------------------------------------------------

21 years, 9 months

RE: [ardour-dev] Re: [linux-audio-dev] HDSP 9652 Users - Request for info

by Mark Knecht

Paul, I think that if the dmesg/var/log/messages output said there were buffers, then it was getting loaded by automatically. Most likely this is because it is in modules.conf. However, when I ran insmod snd-hdsp by hand, I got some error messages that were a bit different than the :init_module message that shows up at boot time. These messages (from memory) had something to do with memory buffer or memory addresses more memory names. I don't remember right now, but will check it out later and report back. Mostly Fernando and I wanted to know what configurations successful users were using. Since I'm on 7.3, I have this funky C compiler, and just wanted to know if others were successful. I'm still considering a RH8.0 upgrade simply to get rid of some of these issues with Ardour and Rosegarden. (And probably create new issues...who knows?) thanks, Mark -----Original Message----- From: Paul Davis [mailto:paul@linuxaudiosystems.com] Sent: Tuesday, December 10, 2002 11:36 AM To: Mark Knecht Cc: D R Holsbeck; linux-audio-dev(a)music.columbia.edu; PlanetCCRMA; Ardour; Ardour-User-List; alsa-user(a)lists.sourceforge.net Subject: Re: [ardour-dev] Re: [linux-audio-dev] HDSP 9652 Users - Request for info > Hi. Actually, I tried that last night, but I didn't load the >snd-hammerfall-mem. It complained about some sort of missing references. >I'll give this a try later today. Thanks. in the message you sent recently, snd-hammerfall-mem worked just fine, and reported allocating buffers for the card. if snd-hammerfall-mem doesn't load, then neither snd-hdsp nor snd-rme9652 (not relevant here) can do so. --p

21 years, 9 months

[linux-audio-dev] [admin] lau postings from lad'ers [was Fwd: [admin] list policy, non-member posting]

by Joern Nettingsmeier

hi guys ! as most of you will know, the linux-audio-user list is members-only. many of you post helpful and perfectly on-topic replies there, which is great, but unfortunately from a non-subscribed address, which is not :( i used to hand-approve them, but there are just too many of those messages now to do that, so i'm getting anal about the policy and reject everything regardless of sender or topic. please, everyone, do not cease to follow lau, and please do share your expertise, but also please do it from a subscribed account. it really hurts me to stash messages from bill s. or paul d. into the bit bucket, but i just can't keep up. :( unfortunately, there is no easy and reliable way to tell mailman to accept all members of another list as posters, and i do not have the necessary privileges on the list server to roll my own cross-authentication. check out the possibility described below if you need to post from several mail accounts. best, jörn forwarded from lau: Jörn Nettingsmeier wrote: > > hi everyone ! > > lately, the number of posting attempts from non-members has risen to a > point where i'm just rejecting them without reading each one and checking > if it's on-topic or has already been sent to the list from another > account. > > our current list policy is members-only posting, for the following > reasons: > * i believe people who want to profit from a community should take part in > it > * spam prevention. so far, it has saved everyone from about .5k spam msgs. > > a number of list subscribers seem to post from different addresses, so > some of their mails are being rejected. if this applies to you, there is > always the possibility of subscribing multiple addresses and disabling mail > delivery for all but one via the web interface. > > best, > > jo"rn -- Jörn Nettingsmeier Kurfürstenstr 49, 45138 Essen, Germany http://spunk.dnsalias.org (my server) http://www.linuxdj.com/audio/lad/ (Linux Audio Developers)

21 years, 9 months

[linux-audio-dev] Synth APIs, pitch control

by Sami P Perttu

Hi everybody. I've been reading this list for a week. Thought I'd "pitch" in here because I'm also writing a softstudio; it's pretty far already and the first public release is scheduled Q1/2003. First, I don't understand why you want to design a "synth API". If you want to play a note, why not instantiate a DSP network that does the job, connect it to the main network (where system audio outs reside), run it for a while and then destroy it? That is what events are in my system - timed modifications to the DSP network. On the issue of pitch: if I understood why you want a synth API I would prefer 1.0/octave because it carries less cultural connotations. In my system (it doesn't have a name yet but let's call it MONKEY so I won't have to use the refrain "my system") you just give the frequency in Hz, there is absolutely no concept of pitch. However, if you want, you can define functions like C x = exp((x - 9/12) * log(2)) * middleA, where middleA is another function that takes no parameters. Then you can give pitch as "C 4" (i.e. C in octave 4), for instance. The expression is evaluated and when the event (= modification to DSP network) is instantiated it becomes an input to it, constant if it is constant, linearly interpolated at a specified rate otherwise. I should explain more about MONKEY for this to make much sense but maybe later. Anyway, the question I'm most interested is: why a synth API? -- Sami Perttu "Flower chase the sunshine" Sami.Perttu(a)hiit.fi http://www.cs.helsinki.fi/u/perttu

21 years, 9 months

[linux-audio-dev] HDSP 9652 Users - Request for info

by Mark Knecht

Hi, I would like to request that if there are any users of the new RME HDSP 9652 card that are able to successfully install and use this card, would you please get in touch with me and let me know what your system configurations are? I understand that there are at least a couple of you out there somewhere. Please let me know what distribution, kernel, C compiler, Alsa revision and anything else you think might be important. Using the PlanetCCRMA flow I am unable to get this card configured and running. We believe that we have patched the Alsa layer correctly to add the 0x64 check but I am still unsuccessful. Thanks in advance. With best regards, Mark

21 years, 9 months

RE: [linux-audio-dev] Audio s/w ui swallowing

by STEFFL, ERIK (SBCSI)

> -----Original Message----- > From: Joshua Haberman [mailto:joshua@haberman.com] > Paul Davis <paul(a)linuxaudiosystems.com> wrote: > > >Has anybody actually tried to get gtk+ and qt working in the same > > >application? > > > > its been done. > > > > it was ugly as sin. > > This is a strong counterexample to the oft-repeated maxim > that "choice is > the strength of OSS." ??? this is a property/feature of X. and btw I think you would run into same kind of problems in ms windows (remember, lot of toolkits available for X are available for ms windows, there are also different ms windows specific toolkits - can you combine them easily in one program?) > But I guess the fact that 10 random linux audio applications > are written to 10 > different APIs that can't interoperate is another. what do you mean? _one_ program will probably use different APIs, depending what it needs to interface to (e.g. there would be linux (or posix) API (system calls), standard library API (most of the programming languages have some standard library), one (or more) sound API, some UI API... just because applications use same API does not mean that applications will be able to interoperate. they have to be designed to interoperate (first part of that would be to define what it actually means in context of given applications) > In my opinion, this is why the deskop projects (KDE and Gnome) are so > important. They give consistency of behavior and > interoperability between > applications. IMO in a wrong way - instead of providing protocols to communicate they lock you in specific implementation. and they are quite messy. it looks like it's getting better, somewhat... ... > Think about the difference between writing a game for Win32 > vs. Linux. With > Win32 you keep your Direct* reference handy and away you go; > it's an entire > platform. With Linux you have to make umpteen decisions you also have openGL. probably other ones (macromedia for kiddie games?) > about what system to > use for graphics, sound, networking, timers, etc. People often make > less-than-optimal decisions due simply to lack of knowledge. What the it's in process of development. confusion is expected. in graphics area it is fairly stabilized, as far as networking etc. goes there shouldn't be any confusion. sound is a big mess (remember oss is considered not good, alsa just recently stabilized API, it's still not 1.0) the problem is not that there are many choices, the problem is that there are not good enough choices in some areas (but that's changing rapidly) erik

21 years, 9 months

[linux-audio-dev] XAP: Multiple Event Ports or not?

by David Olofson

And now I just realized something else... Why argue whether or not there should be a single event port per plugin instance, or one per Channel, or whatever? Just have the *plugin* set up the ports, and have the host ask a callback XAP_event_port *get_event_port(XAP_cnx_descriptor *cd); when it wants the port to use to reach a specific Bay:Channel:Slot. Most plugins will probably consider only the Bay and Channel fields, but some may ignore all fields and always return the same port, while others may split the range of Slots of multiple ports in arbitrary ways. That way, you can have *one Event Port per Control* if you like. :-) Well, yes, there is one issue, of course: When you use the same port for multiple Channels and/or multiple Bays, you'll need the Channel and/or Bay indices as arguments in the event struct. I'm thinking that you might still just have a 32 bit "index" or "slot" field in the event struct, but optionally split it up, encode it or whatever, as you like. It would be easy enough to have the plugin do that as part of the get_event_port() callback above; something like: XAP_target_descriptor { XAP_event_port *port; unsigned long id; /* Plugin's reference; * may be *anything*. */ } int map_target(XAP_cnx_descriptor *cd, XAP_target_descriptor *td); That is, the map_target() call converts <port, bay, channel, slot> inte <port, id> in whatever way the plugin author wants. The ID/index/slot thing is just "that value you're supposed to write into the "index" field of events sent to this target" anyway, so it doesn't matter the slightest to senders - or the host - what the value actually means. Example: * Plugin wants *everything* on one port. * Plugin will return the same physical port whichever event input Bay:Channel:Slot you ask for. int map_target(XAP_cnx_descriptor *cd, XAP_target_descriptor *td) { MY_plugin *me = cd->plugin; /* Get "this". */ td->port = me->my_universal_event_port; td->id = cd->bay << 24; td->id |= cd->channel << 16; td->id |= cd->slot; return 0; /* Ok! --> */ } * In the single event processing loop, the plugin will just extract the bay, channel and slot fields like this: int bay = event->index >> 24; int channel = (event->index >> 16) & 0xff; int slot = event->index & 0xffff; Is this ok? //David Olofson - Programmer, Composer, Open Source Advocate .- The Return of Audiality! --------------------------------. | Free/Open Source Audio Engine for use in Games or Studio. | | RT and off-line synth. Scripting. Sample accurate timing. | `---------------------------> http://olofson.net/audiality -' .- M A I A -------------------------------------------------. | The Multimedia Application Integration Architecture | `----------------------------> http://www.linuxdj.com/maia -' --- http://olofson.net --- http://www.reologica.se ---

21 years, 9 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 December 2002